Disk wakeup on resume

Disk wakeup on resume

[Phillip Susi]

-----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 don't see why the kernel needs to delay completing the resume until
after the disks have spun up when they will automatically spin up when
accessed, which may be never ( thus they should be left spun down ),
but I can not find the culprit causing this.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJSeFnWAAoJEJrBOlT6nu758QwIAJAhlQ5o6qDG9fm98w0j7MY9
OYp/NTd/nO4LGPGaTob/JCyuMDPMtXCOdueLxStlqnBLnPgfANZWD+VSSbsm/uae
pzvjihe6uU+mTCbPW0MNPEiFpH2mfVY8NMhrAEI/n0j9fjgd7E33NI2fedymEDPk
LcgdOtdQP3VSMMs6pjPRpkpVBJG1g3Y6XPLV8IFj8RPz6lUj3k5qj45lsgf//Am8
5vD8SRoZZd7bZghqOCeUU2I/1kntKI5qz4cDUQq6wTVwqAuhLbpjFMOk5lX3gg/h
Q25FGU6Rc8nMyLw4eLbRA8Tvh2aLX5anPkdJqkb132ulbmqP7b8hjUZ4qtNQ/wA=
=JmIT
-----END PGP SIGNATURE-----

Re: Disk wakeup on resume

[Aaron Lu]

On 11/05/2013 10:37 AM, 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.

Are you using an ATA drive?
Last time I checked, the spin up actually happened while the ata port is
resumed(when it will be reset):
https://lkml.org/lkml/2013/2/4/361

-Aaron

> 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 don't see why the kernel needs to delay completing the resume until
> after the disks have spun up when they will automatically spin up when
> accessed, which may be never ( thus they should be left spun down ),
> but I can not find the culprit causing this.
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.14 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQEcBAEBCgAGBQJSeFnWAAoJEJrBOlT6nu758QwIAJAhlQ5o6qDG9fm98w0j7MY9
> OYp/NTd/nO4LGPGaTob/JCyuMDPMtXCOdueLxStlqnBLnPgfANZWD+VSSbsm/uae
> pzvjihe6uU+mTCbPW0MNPEiFpH2mfVY8NMhrAEI/n0j9fjgd7E33NI2fedymEDPk
> LcgdOtdQP3VSMMs6pjPRpkpVBJG1g3Y6XPLV8IFj8RPz6lUj3k5qj45lsgf//Am8
> 5vD8SRoZZd7bZghqOCeUU2I/1kntKI5qz4cDUQq6wTVwqAuhLbpjFMOk5lX3gg/h
> Q25FGU6Rc8nMyLw4eLbRA8Tvh2aLX5anPkdJqkb132ulbmqP7b8hjUZ4qtNQ/wA=
> =JmIT
> -----END PGP SIGNATURE-----
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: Disk wakeup on resume

[Phillip Susi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/5/2013 4:05 AM, Aaron Lu wrote:
>> Are you using an ATA drive? Last time I checked, the spin up
>> actually happened while the ata port is resumed(when it will be
>> reset): https://lkml.org/lkml/2013/2/4/361

Why does resetting the port spin up the drive?  And I'm pretty sure I
still saw the port reset messages after unbinding sd, yet the drive
remained spun down.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSePuHAAoJEJrBOlT6nu75NYMIAL41IBonf1CAP/OVEXBwpBIa
HXQoo7Icz5ZQ+Tu/Tj2orumu0m0Cm3O7aUt30Gye+Vca8UpWDUjcqQ0br+dymdXq
PFkPS7Dr2zF3mSULDBUn6mHXUuUgS5Vmdf2+FLSldfa8SyTsT2Nwzz8hnUCAZQEO
C7aA2fZCQ1yZYCXrXKSh/TZg2RGT+eg57kNLQ2hwBrDwHKL+p7UbWESuqEFeR5U9
bj3JCO6/erG19/tibVHP7tuJokxSWrbQZbHrjO8a74ms5esiEAHpnka7q8wp/FbS
gPklZJJjk+C0akaHDbj1dslEXgozoam42GhYeq7Lgo0O3Wx1N1/Fy5ZBxW3KTu0=
=Ci32
-----END PGP SIGNATURE-----

Re: Disk wakeup on resume

[Phillip Susi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/5/2013 4:05 AM, Aaron Lu wrote:
> Are you using an ATA drive? Last time I checked, the spin up
> actually happened while the ata port is resumed(when it will be
> reset): https://lkml.org/lkml/2013/2/4/361

Is there a reason these patches weren't applied?  It looks like it
should be pretty simple to have ata_port_resume return without
blocking on the reset, but I wonder if that would cause a problem?

Doesn't the pm core sequence the resume of the various devices, so
that the ata device is resumed after the ata port has been resumed, so
wouldn't returning before the reset has finished mess up the ata
device resume, which expects that the port is already online?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSeWP5AAoJEJrBOlT6nu757vUIALEW810IW5FMyCQp6qx80U1w
QnEcY212ZdBCLqCiF/u8BaoVECM7VsdwjfVeI3CKUYvemNAXPJBCTpB/5KUMWL43
KbpK3A0EkrdEsNjescmP+i0mYEIWXhB9Kj8IDMKR3HypNESua8X8YUaiNzkxNNGz
aK11EsNn1Ut5FC0jzWInBfUq8E9WwYmPItxddb8ISIxr8vSbI5AME8HuupH+tT8f
6VVmCFQwxj5zbiGOJEUZPmwTvE0GgzY+rSYVKvRLRoi+Cv8C2AI/nAMEpYlzuGYT
Ku8RzUxV3nO8AAlX4yrnvplgWV2HDX0FvW7jl38fDJsxW1306j4BECJ8Rs8tbCQ=
=Ylq6
-----END PGP SIGNATURE-----

Re: Disk wakeup on resume

[Aaron Lu]

On 11/06/2013 05:32 AM, Phillip Susi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 11/5/2013 4:05 AM, Aaron Lu wrote:
>> Are you using an ATA drive? Last time I checked, the spin up
>> actually happened while the ata port is resumed(when it will be
>> reset): https://lkml.org/lkml/2013/2/4/361
> 
> Is there a reason these patches weren't applied?  It looks like it

The problem is system PM and runtime PM are independently
configurable... some system may have CONFIG_SUSPEND enabled but not
CONFIG_PM_RUNTIME, that would make this not usable.

> should be pretty simple to have ata_port_resume return without
> blocking on the reset, but I wonder if that would cause a problem?

Todd has been optimising system resume for SATA drives without touching
runtime PM:
http://www.spinics.net/lists/linux-scsi/msg69532.html
You may want to take a look.

-Aaron

> 
> Doesn't the pm core sequence the resume of the various devices, so
> that the ata device is resumed after the ata port has been resumed, so
> wouldn't returning before the reset has finished mess up the ata
> device resume, which expects that the port is already online?
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.17 (MingW32)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQEcBAEBAgAGBQJSeWP5AAoJEJrBOlT6nu757vUIALEW810IW5FMyCQp6qx80U1w
> QnEcY212ZdBCLqCiF/u8BaoVECM7VsdwjfVeI3CKUYvemNAXPJBCTpB/5KUMWL43
> KbpK3A0EkrdEsNjescmP+i0mYEIWXhB9Kj8IDMKR3HypNESua8X8YUaiNzkxNNGz
> aK11EsNn1Ut5FC0jzWInBfUq8E9WwYmPItxddb8ISIxr8vSbI5AME8HuupH+tT8f
> 6VVmCFQwxj5zbiGOJEUZPmwTvE0GgzY+rSYVKvRLRoi+Cv8C2AI/nAMEpYlzuGYT
> Ku8RzUxV3nO8AAlX4yrnvplgWV2HDX0FvW7jl38fDJsxW1306j4BECJ8Rs8tbCQ=
> =Ylq6
> -----END PGP SIGNATURE-----
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: Disk wakeup on resume

[Phillip Susi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/6/2013 12:49 AM, Aaron Lu wrote:
> Todd has been optimising system resume for SATA drives without
> touching runtime PM: 
> http://www.spinics.net/lists/linux-scsi/msg69532.html You may want
> to take a look.

Thanks for the pointer, but is there somewhere you can download the
bloody full original message with headers so I can generate a proper
reply?

Also, last night I noticed that ata_port_resume() ( which is called
both for runtime and system resume ) was explicitly calling into the
pm core to set the runtime status to active.  I thought that was the
problem so I disabled that code and made it work the other related
functions and just return success without resetting the link if it is
runtime suspended, but it seems that the runtime suspend state is
being cleared already by the time the system resume is called and I
haven't figured out where yet.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSelTcAAoJEJrBOlT6nu75L3cH/0/cRtaW2n8viQvIJgwM2N5P
t2WnQMEgYse9zOrkuDNWQyTXOib0ccYR3aQZuu9XXWVXG+w3KvT+D8yyWlyFkvz2
pQZErEF0vZeWVNlJPzQZqWlQQfpIocF6Ebleo5j6i0xzgNFxwVMC+ICqCLPYbjZa
lxGTP3bX1TMEdA4D9rTkIfi3naVSbITY9pm0oe+aKzknFjDKmx5Zj6SIjdUFfm9B
CUJxvYCcj4NKhLqcBJRTiNnIK/Wtg1twbXWbGSWvIGe01aShD7FXRDxmCL4FgYG1
YZ/MSlb4R4IQxtetgxaqC/ujOkf6FNvCUV3Y8qvlvSKdeVSzoz0wDgjgK4VWDmg=
=GpAA
-----END PGP SIGNATURE-----

Re: Disk wakeup on resume

[Phillip Susi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

I found the culprit.  It seems that ata_port_reset identifies the
device, and if it has power up in standby enabled, and requires the
SET FEATURES command to spin up, issues the command right away.  I wonder:

1)  If the spinup command can't be delayed until the disk is actually
accessed and/or

2)  If the disk is in runtime suspend when the system is suspended,
why doesn't it remain suspended when the system is resumed, thus
delaying the port reset until the runtime suspend is lifted ( when the
disk is accessed ).

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJSeYhMAAoJEJrBOlT6nu75jUgH/A64U4GQZxzLdkM6/ewpSK31
C+UZ+PAy3l0jUdCtYwDCca7k7bC94Jh5vrOi2WlglmRIVnRl1PzcMfOFalm0Ca2m
uibKvA3LSLsE/ICB+gl0329au5GADO/hLcuLb8v0U7ZgTPwSwdrqFM5ApUatPFf5
RBVZbwMojl7aXSRkmHS1L48BIRc9X4G2wLB4qgE+tJFP8s04l1cC7fWSf5e7vUNw
4scSPzahgGAOrsy7tQQgc2vP7uM/m0LRFN4Gs6gC9axFfCTQ5oYA/0TiOVpeRDYh
PfPfp0InoNiOuq1QPW+T9TbuAsHp7GxxoAl6ljqOUAZ3sWisEV56lYYsNjwCEs0=
=wQsh
-----END PGP SIGNATURE-----

Re: Disk wakeup on resume

[Douglas Gilbert]

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

Re: Disk wakeup on resume

[Phillip Susi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/5/2013 10:56 AM, Douglas Gilbert wrote:
> 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.

No, otherwise hdparm, udisks, etc would not be able to issue the CHECK
POWER command without waking the disk.  Most commands do wake the
drive, but as far as I can see, nobody is sending down any, and more
importantly, the wake is happening within the kernel pm resume path,
not by userspace after resume.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSeRuFAAoJEJrBOlT6nu75zOcH/1eKDZW73qiWN5x1mHnkZCx2
+khrRybBM+d6iwsfKODdMPkfXe89QxNxZArPMP60OtCTzfnUuzpK9SfNuzB2CB3p
zKX1H5tOQEowUd9A2DpzJmN89UGi/+ZVDEQBlo6byqXKhd/Gj10TuD8vyaHSSadN
XYYvWIlreayELaI70uQLdntfHufProdoZQ+kB9pQhvvq8IhtcuARjUeaGbnHxznc
UT2SvYeGritndPLzBOAeWw6/WZ/Rvzo5Q9s2nZAWyWnNlrdt95cmLl+56vCP2AJW
b4Tf4TrPGbhB0EPFU+vWy6mT4DFReqDbkMvgsWoOrFF8OPgrUx3l+9gWifejLw8=
=77FK
-----END PGP SIGNATURE-----

Re: Disk wakeup on resume

[Douglas Gilbert]

On 13-11-05 11:23 AM, Phillip Susi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 11/5/2013 10:56 AM, Douglas Gilbert wrote:
>> 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.
>
> No, otherwise hdparm, udisks, etc would not be able to issue the CHECK
> POWER command without waking the disk.  Most commands do wake the
> drive, but as far as I can see, nobody is sending down any, and more
> importantly, the wake is happening within the kernel pm resume path,
> not by userspace after resume.

hdparm is quite capable of using a pass-through device
to access disks. That allows it (and smartmontools) to
access physical disks in a RAID when the block layer
can only see the logical disk out front.

udisks is not that smart.


Perhaps you need to start debugging around here:

static int sd_resume(struct device *dev)
{
         struct scsi_disk *sdkp = scsi_disk_get_from_dev(dev);
         int ret = 0;

         if (!sdkp->device->manage_start_stop)
                 goto done;

         sd_printk(KERN_NOTICE, sdkp, "Starting disk\n");
         ret = sd_start_stop_device(sdkp, 1);

done:
         scsi_disk_put(sdkp);
         return ret;
}

to work out if it is spun up before or after that call.

Doug Gilbert