On Mon, 2012-07-30 at 05:55 -0700, ny6p01@xxxxxxxxx wrote: > On Mon, Jul 30, 2012 at 09:44:24AM +0100, Bryn M. Reeves wrote: > > On Sun, 2012-07-29 at 20:13 -0700, ny6p01@xxxxxxxxx wrote: > > > That's not a disk problem. That's the disk failing to remount itself > > > properly after the suspend. This is very common. In fact, I wrote a script > > > (in Gentoo) to unmount external drives before a suspend operation, so that > > > the numbering of disks in /dev don't become littered with 'zombie' drives. > > > > > > I'm sure there's a super-slick way of getting drives to remount themselves > > > after a suspend, but mounting drives is relatively easy to do either with > > > gui or cli tools, so I don't tear my hair over it. > > > > An eSATA device should be able to suspend and resume properly (just like > > the other ATA devices in your system). > > > > Debugging it may be difficult unless you can get console logs showing > > what's happening during the suspend/resume cycle (serial console or > > possibly netconsole). > > > > What state is the device in following a resume? > > (/sys/block/sd*/device/state). > > > > Never knew about that file. Thanks! It only shows the SCSI state of the device but it can be a useful check when trying to narrow down the problem. If the SCSI layer was aware of problems it will often have set the state to 'offline'. If the device is out to lunch but the file still shows 'running' it suggests that there is a problem lower down and that the upper layers have not been informed of a problem. Bryn. -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
