Drobo/eSATA/Win 7 x64 not seen on startup

If anyone can give me a clue as to what is happening. I have one of the recommended cards installed, Rosewill RC-219.

When I power off my computer at night, for example, the next morning Windows does not see the drive. The drive does appear to come out of standby mode. What I have to do is disconnect and reconnect the eSATA cable and all is fine.

I have this same problem or a very similar problem. The drobo will flash yellow lights and then act like it’s rebooting and try again. This will happen over and over until it “gives up” and a little yellow light in the bottom left (facing the device) glows yellow. I can sometimes flip the rocker switch in the back at that point and the unit powers off. I have tried to then power it back on via the rocker switch again which sometimes works and sometimes repeats the annoyance above.

There are other times when I will boot up my computer after it was off overnight and the drobo comes on with no probem. It is incredibly irritating and I have been meaning to call support and figure out the issue, but I haven’t yet.

My device is connected via an “approved” 3rd party iogear esata card.

Isn’t it the way of things… I post on this board and it comes up fine, for the first time this morning…lol

I did make one change in the bios before I turned off the PC last night. I turned of PCI Bus Mastering.

We’ll see how it goes later today when I turn it off/on again.

Additional information. I do have the latst firmware installed on the Drobo S.

It seems that turning off PCI Bus Mastering on the motherboard fixed my problem. If only everything was so easy.

Now I need to find a way to be able to create and access a volume greater than 2 TB via eSATA.

What else is effected if I turn off OCI Bus Mastering that I might not want? What exactly does OCI Bus Mastering do?

In my case, I haven’t noticed any difference. You can Google it, if you wish.

PCI Bus Mastering is always a bit fuzzy.

In the olden days, the “IDE Busmaster” setting used to allow an add-in IDE/ATAPI (PATA, for you younger folks) controller board to control the bus and do direct communication without the CPU/OS.

These days it tends to be something fuzzier.

The danger in allowing bus master is that a high-bandwidth/high-traffic device might “hog” the bus and starve other devices of I/O.
In this case, it might simply have been that allowing bus master keeps the card “on” somehow and doesn’t give the Drobo the “break” it needs to complete its boot.

As a side note, there are three common BIOS settings that have been voodoo-ish (ie, sometimes good, sometime bad, always mysterious):

  1. PCI Bus Master
  2. Spread Spectrum Modulation
  3. PCI Latency Timer

#1 I already described.

#2 is designed to allow the system clocks to be varied to reduce EM emissions.
On some systems I have seen this option actually over- or underclock all the system buses. For devices that are timing-critical (anything that has a clock that’s supposed to somewhat relate to real wall-time - especially prosumer video and audio devices), the clock variances often mess things up because of the changes in timings.

#3 is a fun one. It usually means “the maximum number of attention cycles a device can have before we stop its turn and move to the next device.”

In other words, it’s like setting a time-limit on the how long someone can speak at an event. It’s a limit, not a set slice time - if the speaker (device) is done, it can end early.

A longer time limit means a person could communicate a lot of information, but it also risks that someone else may simply not get their turn.

A shorter time limit means all the speakers get a turn to speak, but they may not be able to communicate their entire message and their message may be fragmented across multiple rounds, or not be delivered in its entirety.

Most times this one defaults to 32 or 64.
If there are high-traffic devices (again, video capture boards fit this) this can sometimes provide a huge throughput benefit by being set to 128 or 192. I’ve seen cases where it needed to be increased to 256, though that is rare.

On the other hand, if there are devices that require constant attention (or have small buffers), the increased latency between attention cycles can cause buffer overflow or loss.

Thanks for that explanation.

This evening when I powered on my PC, the Dobro appeared to wake up but was not seen by my PC. I had to unplug, then plug the Esata cable in back of the Drobo for it to be recognized. Argggg… this is starting to get annoying since I wanted a fuss free setup.

What state was your PC in before you powered it on - completely shut down or standby?

Another option to check in the BIOS:
PCIe Link State something-or-other

and Windows power management. Essentially you want to look for things that might allow or disallow the card to power down or enter power-save.

It was completely shut down and powered off. The Drobo was on standby.

Very strange. The card should’ve re-initialized at startup and Drobo should have awoken. I’m out of ideas on this one.
Okay I lied. One more… If your SATA controller has some kind of Stagged Spin-up or Spin-up Delay option, try toggling that.

I’m using Rosewill RC-219 add in card since I started to have issues with the onboard eSATA ports before I got the Drobo. There doesn’t appear to be any settings that are user adjustable.

Hahaha I typoed I meant “staggered” but if it doesn’t have any settings or its own BIOS options (on modern systems this can flash past in literally a blink) then I’m stumped. Wow, I can’t type today - I had to retype this more than 3 times.

All has been fine the last 3 turn ons so it might just have been an abberation. If it happens once a week or so, I won’t be too inconvenienced.