Re: Disk wakeup on resume

[Douglas Gilbert <dgilbert@interlog.com>]

On 13-11-04 09:37 PM, Phillip Susi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> I can not figure out what is waking up disks on resume from suspend.
> I thought it was sd.c, and setting manage_start_stop = 0 should stop
> that.  It does stop the message printed saying it is being started,
> yet the disk is still started, and this makes the resume take nearly
> 10 seconds.  So it seems sd_resume()'s attempt to start the disk is
> pointless and redundant, and something else is starting up the disk.
> Oddly, if I unbind the sd driver ( echo 1 >
> /sys/block/sdx/device/delete ), then after a resume the disk remains
> off ( and spins up again on rescan ).

I think that you might find that almost any SCSI
command (translated to its ATA equivalent command)
will wake up a SATA disk. Perhaps just this sequence:
   fd = open(<ata_bloc_device>) ; close(fd) ;
is sufficient.


Strange things do go on with SATA disks and the block
layer. smartmontools has problems spinning them down,
given:

# lsscsi -g
[6:0:1:0]  disk ATA ST3500418AS CC34  /dev/sdc /dev/sg2

Then:

# sg_start --stop /dev/sdc
# sg_turs /dev/sdc
# # No answer means ready, but I asked it to stop??

# sg_start --stop /dev/bsg/6:0:1:0
# sg_turs /dev/bsg/6:0:1:0
device not ready
# # Yes, that is what I expect from a TEST UNIT READY

So the above is accessing the same SATA disk via the block
layer then via the bsg pass-through. In both cases the disk
is asked to stop (spinning). The SCSI TEST UNIT READY command
is used to check the state of the disk. The request works
when sent via the pass-through (i.e. the bsg driver as shown
above or the sg driver (e.g. /dev/sg2)).

When sent via the block layer initially it works, until
you do a close() on the file handle that was used to
send the SCSI command (translated to the ATA equivalent
command). However when you do that close() the block layer
decides to access the disk and that access spins it up :-)
And there is a click sound from my SATA disk and I think:
that must be good for it.


BTW There were no mounts active on /dev/sdc . The above was
tested on lk 3.12.0 . Only SATA/ATA disks have this feature,
SCSI disks work as expected via the block layer or a
pass-through.

Also this test was with a decent SATL (mpt2sas) not with this
howler from drivers/ata/libata-scsi.c

         /* no-op's, complete with success */
         case REZERO_UNIT:
         case SEEK_6:
         case SEEK_10:
         case TEST_UNIT_READY:
                 ata_scsi_rbuf_fill(&args, ata_scsiop_noop);
                 break;

Doug Gilbert