| Message ID | 927e15641f27b46f206f8ae8110201c8fd77b7e1.1383789225.git.psusi@ubuntu.com |
|---|---|
| State | Not Applicable |
| Delegated to: | David Miller |
| Headers | show |
On 13-11-06 08:57 PM, Phillip Susi wrote: > Don't bother forcing disks to spin up on resume, as they > will do so automatically when accessed, and forcing them > to spin up slows down the resume. Add a second bit to the > manage_start_stop flag to restore the previous behavior. SCSI disks when in STOP state do not spin up "automatically when accessed". If you haven't looked at the SAT-2 standard (SAT-3 drafts) then perhaps you should as that gives insights into how SCSI and ATA disks can play together in the same sandpit (and the code you are patching is in the SCSI part of the sandpit). And your choice of bits looks like it will favour fixing broken SATA behaviour but as a by-product break working SCSI disk behaviour. Doug Gilbert > --- > drivers/scsi/sd.c | 6 +++--- > include/scsi/scsi_device.h | 2 +- > 2 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c > index e62d17d..3143311 100644 > --- a/drivers/scsi/sd.c > +++ b/drivers/scsi/sd.c > @@ -3083,7 +3083,7 @@ static void sd_shutdown(struct device *dev) > sd_sync_cache(sdkp); > } > > - if (system_state != SYSTEM_RESTART && sdkp->device->manage_start_stop) { > + if (system_state != SYSTEM_RESTART && (sdkp->device->manage_start_stop & 1)) { > sd_printk(KERN_NOTICE, sdkp, "Stopping disk\n"); > sd_start_stop_device(sdkp, 0); > } > @@ -3107,7 +3107,7 @@ static int sd_suspend(struct device *dev) > goto done; > } > > - if (sdkp->device->manage_start_stop) { > + if (sdkp->device->manage_start_stop & 1) { > sd_printk(KERN_NOTICE, sdkp, "Stopping disk\n"); > ret = sd_start_stop_device(sdkp, 0); > } > @@ -3122,7 +3122,7 @@ 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) > + if (!(sdkp->device->manage_start_stop & 2)) > goto done; > > sd_printk(KERN_NOTICE, sdkp, "Starting disk\n"); > diff --git a/include/scsi/scsi_device.h b/include/scsi/scsi_device.h > index d65fbec..1c46d2d 100644 > --- a/include/scsi/scsi_device.h > +++ b/include/scsi/scsi_device.h > @@ -152,7 +152,7 @@ struct scsi_device { > unsigned use_192_bytes_for_3f:1; /* ask for 192 bytes from page 0x3f */ > unsigned no_start_on_add:1; /* do not issue start on add */ > unsigned allow_restart:1; /* issue START_UNIT in error handler */ > - unsigned manage_start_stop:1; /* Let HLD (sd) manage start/stop */ > + unsigned manage_start_stop:2; /* Let HLD (sd) manage start/stop */ > unsigned start_stop_pwr_cond:1; /* Set power cond. in START_STOP_UNIT */ > unsigned no_uld_attach:1; /* disable connecting to upper level drivers */ > unsigned select_no_atn:1; > -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/7/2013 1:21 PM, Douglas Gilbert wrote: > On 13-11-06 08:57 PM, Phillip Susi wrote: >> Don't bother forcing disks to spin up on resume, as they will do >> so automatically when accessed, and forcing them to spin up slows >> down the resume. Add a second bit to the manage_start_stop flag >> to restore the previous behavior. > > SCSI disks when in STOP state do not spin up "automatically when > accessed". The drive does not, but the scsi error handling notices when a command fails because the drive needs started, starts it, and retries the command. > And your choice of bits looks like it will favour fixing broken > SATA behaviour but as a by-product break working SCSI disk > behaviour. No, it has nothing to do with sata behavior; it has to do with whether or not all disk drives should be restarted immediately after a resume, or only when they are accessed. I happen to have a few older drives that I very rarely access and would rather they not start up every time I resume. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSfANJAAoJEJrBOlT6nu75BIAIALHveooj3EuVQ9DmzsCKezT2 ILHsGKAecgojAbxNFp4JXTwmlnNMUQzGaaxfXgoTES4WBiDnba0sedVW+aPqI8Ul cA8FXeIPtk1U5/xA6iW9XFInOTkvpXSnl9yeX7zldtcjxBm0bQ49JUk4zI68jQwF YPxEb0bxPpJvUcoYbM6eo+I6GnBqpCU9FDVoy0wnb1Zp6qQEY59kOvQc51Pl10KR Vwmayc7B9dncfk9+46knt4ocBUdSdX1rzRqN0EfGIZtkWysP6w5HmA0ejocEIyHT YErI94JvAEOZkzGHZgaMykxTE5SGYX8Fz3w3LVc9uAc40oIf3qFHb5Bob6Ecy6Q= =SkP3 -----END PGP SIGNATURE----- -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 13-11-07 01:21 PM, Douglas Gilbert wrote: > On 13-11-06 08:57 PM, Phillip Susi wrote: >> Don't bother forcing disks to spin up on resume, as they >> will do so automatically when accessed, and forcing them >> to spin up slows down the resume. Add a second bit to the >> manage_start_stop flag to restore the previous behavior. > > SCSI disks when in STOP state do not spin up "automatically > when accessed". .. Ditto for many SATA disks with "power up in standby" enabled. -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 11/16/2013 12:23 AM, Mark Lord wrote:
> Ditto for many SATA disks with "power up in standby" enabled.
Ditto for my previous response; the kernel ( in this case the libata
layer ) notices this and takes care of starting it. The third patch I
posted suppresses this startup at resume time so that it will be done
on access instead.
I currently have two disks with PuiS enabled that no longer have to
spin up and down again every time I resume from suspend, but wake up
nicely when I mount them.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBCgAGBQJSh4aPAAoJEJrBOlT6nu75bV0IAImEyIJlIF6O69mqLS3A6z/r
xtUQlxg5gfE91PteNdtNYd9v54uwCw2uldSAGOEm4DR7LOErVu54J+6rVZKFRF0L
ocmE2VEKhzNTA21pt5rCPDsQ9BHJ7ljWXbGTUC7zFN4VCYTEkPVuO5Owedjd9sb8
+BUHCD9+au7CRf5SLU4qSoqT8DNUPREv70WL1Ze8LhQt9R+APBclyeXHBYc+Hgpd
Idzp/EFt+SPRGrJL+XyC6/F0Mz3kLRD/2Ij0kRSux1E5DNG1SQTq+FdqUIa2sTDf
volJRiUS3/rtNr/2c4F9awQNbsCZRceTIq71PA3dvgxM21sjpXpLUe2A65u9gNQ=
=jhXC
-----END PGP SIGNATURE-----
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 2013-11-07 at 16:16 -0500, Phillip Susi wrote: > On 11/7/2013 1:21 PM, Douglas Gilbert wrote: > > On 13-11-06 08:57 PM, Phillip Susi wrote: > >> Don't bother forcing disks to spin up on resume, as they will do > >> so automatically when accessed, and forcing them to spin up slows > >> down the resume. Add a second bit to the manage_start_stop flag > >> to restore the previous behavior. > > > > SCSI disks when in STOP state do not spin up "automatically when > > accessed". > > The drive does not, but the scsi error handling notices when a command > fails because the drive needs started, starts it, and retries the command. No disk does, neither SCSI nor ATA. The error handler is not automatically activated for a not ready/initializing command required because of multi-path. We override the default behaviour via allow_restart only for IBM vfc/vscsi and ATA disks. With this patch SCSI devices would no longer ever restart after suspend. > > And your choice of bits looks like it will favour fixing broken > > SATA behaviour but as a by-product break working SCSI disk > > behaviour. > > No, it has nothing to do with sata behavior; it has to do with whether > or not all disk drives should be restarted immediately after a resume, > or only when they are accessed. I happen to have a few older drives > that I very rarely access and would rather they not start up every > time I resume. As Doug said, if you don't restart a SCSI device after resume, it will never get started. James -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 11/16/2013 01:20 PM, James Bottomley wrote: > No disk does, neither SCSI nor ATA. The error handler is not > automatically activated for a not ready/initializing command > required because of multi-path. We override the default behaviour > via allow_restart only for IBM vfc/vscsi and ATA disks. With this > patch SCSI devices would no longer ever restart after suspend. I don't follow. A scsi disk returns a sense status saying it requires a START UNIT command when issued a command before being started. This triggers the eh which notices that sense status and issues the command. My first version seemed to cause hdparm to fail on an ata drive that required SET FEATURES command to start up after power on, so the next version I set the DFLAG_SLEEPING bit which causes a preemptive start command on access even for SGIO, which otherwise seems to suppress eh. > As Doug said, if you don't restart a SCSI device after resume, it > will never get started. If something ( and I am still not clear on what ) is suppressing the error handling code for scsi disks, it should be able to be handled in a simiar way to ata: set a flag that causes preemptive startup even if eh is suppressed. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJSiDzoAAoJEJrBOlT6nu75kXIIAJ+7wO8jcnw4LzlBoB8ELY8m pZxsgvM0c4fQlqNvsCgXbhRYaNK5aHTk1RtguTuV4iJ8rQj+73jmuftar4kq5As2 yZZ2LCYKNdHgBhCe0t2o+vVFKdh6Vaqawm0Gsaqy1D6WNUWXh8D0wicD9gLwJBxo R1nH2UNw337e6fnhTvF6uzA3OKUC9mJyJIrfrM7djCg46I/QkL0G2gDif8EQbTvo /XpHywFheFUz5LEz6Ctbxb7VvacE62Nj9kmnDNc2rE+bpP/GeQ72sxmKCtVcm515 HqMRaU8efo8EIRIBNUqYRxZuIDr9vA9rsHq5XxtDAeWPXfjibcEaA/iwBZp6oyY= =vVEg -----END PGP SIGNATURE----- -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, 2013-11-16 at 22:50 -0500, Phillip Susi wrote: > On 11/16/2013 01:20 PM, James Bottomley wrote: > > No disk does, neither SCSI nor ATA. The error handler is not > > automatically activated for a not ready/initializing command > > required because of multi-path. We override the default behaviour > > via allow_restart only for IBM vfc/vscsi and ATA disks. With this > > patch SCSI devices would no longer ever restart after suspend. > > I don't follow. A scsi disk returns a sense status saying it requires > a START UNIT command when issued a command before being started. This > triggers the eh which notices that sense status and issues the > command. OK, so three people have now told you that's not how the code works. Why don't you just read it? because there's not really much point us reading your patches until you do. James -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 11/17/2013 01:43 AM, James Bottomley wrote: > OK, so three people have now told you that's not how the code > works. Why don't you just read it? because there's not really much > point us reading your patches until you do. I have, which is why I said it handles it via scsi_eh_stu. If I'm not understanding it correctly, then by all means, explain. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJSiOumAAoJEJrBOlT6nu75j6QH/3QURQwEXSjeQRaHdEo3dPUp eKSf7ix/6kOlWDzqzyNB0BWb0NDmCVc7v0GfKmcO0/7U2VoC4N5WqhvcXHU6X/PO ZjhcvKvuZEK9z8H9+Dx2CsB2nZ1p3hnQq6GXk1oa4tNx4id+sXioG8qX8Uw5AurA 6O+ceHnb3hggvC8Oojo2YCwEMJiOYw+xhEjnleMcDAj+T5X3T4SMR/N6rM9NgX1L 4ekrQMi3dNrizZaFKXjkf8/xult/nsnk1jKnhvJ/Sdl3EOSMTMypjdVo3W4VHpZ1 0aDE8qIiLaU8x/xNjT4oQrVfseHexjzHVlQ7O5fc79+Tz+ej8PbjDLTtltPmn5M= =fnx7 -----END PGP SIGNATURE----- -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 13-11-17 11:15 AM, Phillip Susi wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 11/17/2013 01:43 AM, James Bottomley wrote: >> OK, so three people have now told you that's not how the code >> works. Why don't you just read it? because there's not really much >> point us reading your patches until you do. > > I have, which is why I said it handles it via scsi_eh_stu. If I'm not > understanding it correctly, then by all means, explain. Even if the SCSI EH code does spin-up the disk, it is inefficient and undesirable to send a device into EH for what is a normal, predictable situation (i.e. that a SCSI disk will need a START STOP UNIT (start) command as part of a resume operation). A big server machine could have thousands of SCSI disks (many potentially virtual). Sending them all into EH during a resume would be a really good test for EH, but horrible for performance. If I was designing the SCSI EH I would probably assume not all disks would go into EH at roughly the same time. Also if that many devices went into EH on the same controller (HBA) it might be reasonable to assume that the controller they share needs resetting. Doug Gilbert -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, 2013-11-17 at 11:15 -0500, Phillip Susi wrote: > On 11/17/2013 01:43 AM, James Bottomley wrote: > > OK, so three people have now told you that's not how the code > > works. Why don't you just read it? because there's not really much > > point us reading your patches until you do. > > I have, which is why I said it handles it via scsi_eh_stu. If I'm not > understanding it correctly, then by all means, explain. Because you don't damn well listen. Two emails ago I said: The error handler is not automatically activated for a not ready/initializing command required because of multi-path I don't really understand how I can be clearer. You keep wittering about the error handler spin up but if the error handler doesn't activate, the disk is never spun up with your patch. This is the problem we keep telling you about. You can't make the error handler always activate because then multi-path would fail. James -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 11/17/2013 06:54 PM, Douglas Gilbert wrote: > Even if the SCSI EH code does spin-up the disk, it is inefficient > and undesirable to send a device into EH for what is a normal, > predictable situation (i.e. that a SCSI disk will need a START STOP > UNIT (start) command as part of a resume operation). The device doesn't need the START STOP UNIT command as part of the resume operation; it only needs it prior to other commands. What is inefficient is starting up drives that won't be accessed. I don't see anything particularly inefficient about issuing the command in the eh path ( in fact, libata always uses the eh path to handle power management ). You can of course, use the manage_start_stop flag to have the disk start on resume if you really want. > A big server machine could have thousands of SCSI disks (many > potentially virtual). Sending them all into EH during a resume > would be a really good test for EH, but horrible for performance. > If I was designing the SCSI EH I would probably assume not all > disks would go into EH at roughly the same time. Also if that many > devices went into EH on the same controller (HBA) it might be > reasonable to assume that the controller they share needs > resetting. They don't all go into EH during resume; they go into EH when they are finally accessed, which for many of them is probably not for some time. This also sounds like a bit of speculation and/or hand waving. Is there really a problem with multiple devices going into EH? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJSiWgGAAoJEJrBOlT6nu75klwIAK29G/p+pZhccbfXBnIpvq8m oIuCOCgMjIbSkJDEo52BiEf6d52tK8aQNTXcHZCC7T2/yvWV55vGHeXbxZ9iospp IsoJOMLtcM9p5DHZido5RubXrq63cU3yGovGbsp834Ij+d51HB17Dh4Dc1iU/mQV 4X6623hH0ooHWjmtoK6l5rGfKxkPe2ZKP3RAOpW5hiFaGPFWpc375Kukf6Zvw161 mBRfdWtc1SRGme/dcEEggH5t20R0kJteAey4RLF77W8VcooVbE3zCESpVNwqHxYK 6Mc67avVzMyk+Cmb2IN9iMB05oPDIzhKU4kStyYKVGqiS1D2NHUUi56GZTN5Ry0= =kmdB -----END PGP SIGNATURE----- -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 11/17/2013 07:09 PM, James Bottomley wrote: > Because you don't damn well listen. Two emails ago I said: > > The error handler is not automatically activated for a not > ready/initializing command required because of multi-path And I replied that that *if* eh is suppressed ( and I'm still not clear on why multipath would do that ), then a flag could be used to pro actively start the drive despite the suppression, like I did with libata. > I don't really understand how I can be clearer. You keep > wittering about the error handler spin up but if the error handler > doesn't activate, the disk is never spun up with your patch. This > is the problem we keep telling you about. You can't make the error > handler always activate because then multi-path would fail. Why does multi-path -> no eh? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJSiWlcAAoJEJrBOlT6nu755h4H/AwoDzPc/iNAw/v3h+HGszCx 3AZUJUbabF7XB8NxbfyLG/vvaGEqxatv5fX3y0I6CmWpWBGQYyDL7W6uQIgKjqAt OmUCEEv3PqnytTg7VjyBBif+TMxM35gZvqzFYWU5DOMB9D+QtvfIHmyH4rCMujYl tLJqArxLMBLnLmpSTp0/TTrvjxDThjkCF6vlM0iSe7C8xZsByRcpoIQJlsvTW7YT IWVop4H9iAW4CZhiSQwdf+IiK8Av45RW8i20em+LlaVvbofoBlUOgUrxIIXu7trT cslbwtPQ2N3SsTEd5E43W3bzDO19gzQHJf5wHTiMg3++yPWqP0hMUgU0ci0Y4aI= =DleI -----END PGP SIGNATURE----- -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/17/2013 8:06 PM, Phillip Susi wrote: > I don't see anything particularly inefficient about issuing the > command in the eh path ( in fact, libata always uses the eh path to > handle power management ). You can of course, use the > manage_start_stop flag to have the disk start on resume if you > really want. Yikes, I think I see now why scsi eh is so bad: the entire host, not just the device is quiesced. I suppose now the question is how to issue the START STOP UNIT from sd_prep_fn()? I gather you can't just call scsi_execute_req() from there? Is there maybe a way to insert a START STOP UNIT request into the queue ahead of the current request being prepped? Can sd_prep_fn() be called concurrently on multiple cpus? Hrm.. what about TCQ? Would it be bad if the original request were queued ( to the drive ) before the START STOP UNIT command completed? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSijguAAoJEJrBOlT6nu75AlIH/3n1XFrWWjU2D209hwaBlRCu OHdAI40OUW0dqRrF7hyhH62X6SmDFG9pkZcCeZUNmSOEBtvkVjxJRv2VvpXpQL50 xXEiLCLukOYWG7krnVhD1BCrt9SfAjMsCpWmbC14m3epCWd9OQNFfU9vqU7mW18b 2NJPBukq+l8nzZtCl+8UMIQxH4RSkceJs3X7y4PhM65nN4kDMmJUABjJhHBZX30/ MQqu6pu2AW6Wf6SH0Sh1qIWfu45cIneuSDRP9qK5U/9902vhmGCLlt4zgbow8CQh muspp8A+bhcVQAJVdZvHz9gQMHS0dDRjLgBE23Yik0t+zBl0wvoFsaAG4BEi0lY= =6HCd -----END PGP SIGNATURE----- -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 13-11-18 10:54 AM, Phillip Susi wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 11/17/2013 8:06 PM, Phillip Susi wrote: >> I don't see anything particularly inefficient about issuing the >> command in the eh path ( in fact, libata always uses the eh path to >> handle power management ). You can of course, use the >> manage_start_stop flag to have the disk start on resume if you >> really want. > > Yikes, I think I see now why scsi eh is so bad: the entire host, not > just the device is quiesced. > > I suppose now the question is how to issue the START STOP UNIT from > sd_prep_fn()? I gather you can't just call scsi_execute_req() from > there? Is there maybe a way to insert a START STOP UNIT request into > the queue ahead of the current request being prepped? Can > sd_prep_fn() be called concurrently on multiple cpus? Hrm.. what > about TCQ? Would it be bad if the original request were queued ( to > the drive ) before the START STOP UNIT command completed? Yeah, solve that, and you're golden. I totally understand the motivation for this patch, and would love to have it working on my machines here too. But it may have to be some kind of sysfs optional setting, defaulting to current behaviour, to keep the server keepers happy. Cheers -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/20/2013 9:23 AM, Mark Lord wrote: > Yeah, solve that, and you're golden. I totally understand the > motivation for this patch, and would love to have it working on my > machines here too. > > But it may have to be some kind of sysfs optional setting, > defaulting to current behaviour, to keep the server keepers happy. My original idea was actually to just have the system resume force the runtime pm status to suspended, then it will take care of calling the runtime resume which can easily start the drive, but I was hoping to get it working whether or not runtime pm is configured. I may just have to fall back to that. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSjMvDAAoJEJrBOlT6nu75J5QH/2APABstv5HejNp5R4uvmAuL xTZyHHOFvcMBDpCFLtlWK6PhnKmN7C/eFlzc7xaadtd0wmgjOqZVLTgfYSWBON6X /kRz/QtDMhsppah7t1T/QzPPQ/z2j4j2/ffwDRRN4bCdM39B/QQCUeVCxVK0mEx3 w5A2Xiro1gAknh1xb/0SfSb9M35H5bLBt4Pz5Ql/75to9jEeH0MlTthZmm+CJPC/ RcBgCkOG6kEOeqCj4tehnTOrs4a8ghdeGNnR6W6UDaeRh3QjRwOvAmwIbZsxkXgs XSP52adzt5fnZi8uQAzV0bIGN+8Zttx0PHdl3AsVt56CMfdfAHVbL1RVo+Pl85E= =fnz3 -----END PGP SIGNATURE----- -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 11/20/2013 09:48 AM, Phillip Susi wrote: > My original idea was actually to just have the system resume force > the runtime pm status to suspended, then it will take care of > calling the runtime resume which can easily start the drive, but I > was hoping to get it working whether or not runtime pm is > configured. I may just have to fall back to that. So the problem with this is that some drives spin up without being issued the START UNIT command. ATA disks without PuiS enabled do, and the SCSI standards indicate that scsi disks can be configured to do so as well, though the method for configuring that is not defined in the standard ( do such things actually exist? ). This would leave the drive spun up but the kernel thinking it is runtime suspended, which isn't good either. I think the way to deal with this is to throw a work queue item in the system resume method that issues TEST UNIT READY and if the drive indicates that it is currently active, then force the runtime pm status back to active. According to SAT-3, an ata emulation layer should issue CHECK POWER MODE and return POWER CONDITION CHANGE TO STANDBY, but libata does not do this; instead it always returns 0/0/0 for the sense status, so this would need fixed as well. Does this sound like the right idea? Also, I don't see any of the ASQ/ASCQ codes defined in the headers. Am I missing them or are they just not there? Also, I'm a bit unclear on whether you actually have to issue TEST UNIT READY or can just issue REQUEST SENSE to check the power condition. The standards seem to indicate the latter, but I'm not sure if REQUEST SENSE would return the sense status of the previous command rather than the power status, so you need the TEST UNIT READY first. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJSlp7ZAAoJEI5FoCIzSKrw5PIH/0wGsyAEr9xR6BkN/C7SOSNh ArhET3A+Af4Zo1HTe9vKDOIsf9OTrjXxWuLYDBoZSCC0GOw3XPYPdnZ1V4xIBtey 0lMSa8VU9KZMZs8KTYNp6LWToBqChBHSFEd9FLwdWnqLKCp/CtOqgeHO1wOyt1LJ NkYM4Mpsx6dGO7dzCTZ6Q5ogoXtGcokbGvUXbvuR1idNy1dEdBHaGStaVmIXxImd u2uJI+1ygk9lMvIa66zJK4f5X6OATd3+SkJlJTsAiEayOEqSAxXNh3QmYJzmJdy/ PDVdgjkgavpKDvbJjNBDSF9skbF9z40EK2NQ9R2kvUMHA8ui66/AQfQHAr04aZI= =kjuO -----END PGP SIGNATURE----- -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c index e62d17d..3143311 100644 --- a/drivers/scsi/sd.c +++ b/drivers/scsi/sd.c @@ -3083,7 +3083,7 @@ static void sd_shutdown(struct device *dev) sd_sync_cache(sdkp); } - if (system_state != SYSTEM_RESTART && sdkp->device->manage_start_stop) { + if (system_state != SYSTEM_RESTART && (sdkp->device->manage_start_stop & 1)) { sd_printk(KERN_NOTICE, sdkp, "Stopping disk\n"); sd_start_stop_device(sdkp, 0); } @@ -3107,7 +3107,7 @@ static int sd_suspend(struct device *dev) goto done; } - if (sdkp->device->manage_start_stop) { + if (sdkp->device->manage_start_stop & 1) { sd_printk(KERN_NOTICE, sdkp, "Stopping disk\n"); ret = sd_start_stop_device(sdkp, 0); } @@ -3122,7 +3122,7 @@ 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) + if (!(sdkp->device->manage_start_stop & 2)) goto done; sd_printk(KERN_NOTICE, sdkp, "Starting disk\n"); diff --git a/include/scsi/scsi_device.h b/include/scsi/scsi_device.h index d65fbec..1c46d2d 100644 --- a/include/scsi/scsi_device.h +++ b/include/scsi/scsi_device.h @@ -152,7 +152,7 @@ struct scsi_device { unsigned use_192_bytes_for_3f:1; /* ask for 192 bytes from page 0x3f */ unsigned no_start_on_add:1; /* do not issue start on add */ unsigned allow_restart:1; /* issue START_UNIT in error handler */ - unsigned manage_start_stop:1; /* Let HLD (sd) manage start/stop */ + unsigned manage_start_stop:2; /* Let HLD (sd) manage start/stop */ unsigned start_stop_pwr_cond:1; /* Set power cond. in START_STOP_UNIT */ unsigned no_uld_attach:1; /* disable connecting to upper level drivers */ unsigned select_no_atn:1;