iSCSI, PC hangs when waking from sleep


Dashboard installed on Vista Ultimate x64 SP2.
Created one 16TB NTFS volume using USB.
Using static IP, drobopro connected to switch, PC connected to switch.
Rebooted into iSCSI, dashboard sees drobopro.
PC sees volume, all seems ok.

I start running robocopy to copy data from my file server to the drobo volume.
I go to have dinner.
Come back, and my PC went to sleep, this is normal, robocopy does not keep PC awake.
Drobopro is also asleep (yellow light on).

On waking machine, robocopy does not resume copying, just hangs half way through a file.
Opening any other apps just hangs.
Ctrl-Alt-Del, reboot, does nothing.
Have to reset machine.

After reboot, dashboard loads, robopro wakes up.
All seems fine, restart robocopy.

I’ve used robocopy while my machine goes to sleep while copying to/from DAS/NAS and never had a problem resuming after sleep.

Any ideas on why the drobopro did not wake up when my machine woke up?

Are there any known problems with using drobo / iSCSI and letting machines sleep?


Was the iSCSI connection (not the NIC connection, but the iSCSI mount) restored after resuming from sleep?

I don’t know, every window or app I opened hanged.
I assume not because the drobo did not wake up.

Explorer hanging can definitely be caused by querying a non-existent or non-responsive drive. You’ll see that happen with mounted network shares that can’t be accessed too.

What version of dashboard are you running?

Hi Jennifer,
Dashboard 1.6.6, Firmware 1.1.4.

I notice the NT eventlog contains several iScsiPort event errors, e.g.:
Event Id 9: “Target did not respond in time for a SCSI request. The CDB is given in the dump data.”
Event Id 39: “Initiator sent a task management command to reset the target. The target name is given in the dump data.”
Event Id 129: “The description for Event ID 129 from source iScsiPrt cannot be found.”
Event Id 1: “Initiator failed to connect to the target. Target IP address and TCP Port number are given in dump data.”
Event Id 7: “The initiator could not send an iSCSI PDU. Error status is given in the dump data.”

I have thus far had 2 hangs on waking from sleep, and 6 wakes without issue, so about a 33% failure rate.


Yes that is actually a known issue in the new dashboard. You can restart the DDservice to reestablish a connection.

How serious is this “known issue”?
E.g. if my machine wakes up and the drobo LUN does not wake up as expected by the OS, could it cause data loss or corruption?

Putting the machine to sleep should cause pending writes to finish, so data-wise it should be safe.

The only “risk” I can think of from experience is if you have an application that does not fail gracefully when trying to access a file. For example, if you have a word processor open, type a document, sleep, resume, then hit Save and the program tries to access the now-missing drive and crashes instead of letting you save the document elsewhere.

And if you have a program that crashes when it can’t find the most-recently used (MRU) location, it’s time to get a patch or a different program. Pausing is okay… but it shouldn’t crash.

It just means dashboard isn’t connecting to the Drobo. Just close dashboard and relaunch or restart the DDService.

Dashboard does nothing to your data.

Jennifer, I understand that he dashboard does nothing to the data.
But, after a S3 to S0 transition (wake from sleep) the OS and applications expects the volume to still be present.

Unless the drive was explicitly unmounted and the OS and applications received the volume unmount notification, and approved, any application may legally still have data in a non-quiescent state on that drive.

For the drive to simply not be present on wake from sleep can cause data corruption.


Do you have a support case opened?

I just opened one:
Question Reference #091222-000063

Thank you.