Re: [PATCH 1/3] sd: don't bother spinning up disks on resume

2013-11-27 Thread Phillip Susi
-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

Re: [PATCH 1/3] sd: don't bother spinning up disks on resume

2013-11-20 Thread Mark Lord
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 ).

Re: [PATCH 1/3] sd: don't bother spinning up disks on resume

2013-11-20 Thread Phillip Susi
-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

Re: [PATCH 1/3] sd: don't bother spinning up disks on resume

2013-11-18 Thread Phillip Susi
-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

Re: [PATCH 1/3] sd: don't bother spinning up disks on resume

2013-11-17 Thread Phillip Susi
-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

Re: [PATCH 1/3] sd: don't bother spinning up disks on resume

2013-11-17 Thread Douglas Gilbert
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

Re: [PATCH 1/3] sd: don't bother spinning up disks on resume

2013-11-17 Thread James Bottomley
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,

Re: [PATCH 1/3] sd: don't bother spinning up disks on resume

2013-11-17 Thread Phillip Susi
-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

Re: [PATCH 1/3] sd: don't bother spinning up disks on resume

2013-11-17 Thread Phillip Susi
-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

Re: [PATCH 1/3] sd: don't bother spinning up disks on resume

2013-11-16 Thread Phillip Susi
-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

Re: [PATCH 1/3] sd: don't bother spinning up disks on resume

2013-11-16 Thread James Bottomley
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.

Re: [PATCH 1/3] sd: don't bother spinning up disks on resume

2013-11-16 Thread Phillip Susi
-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

Re: [PATCH 1/3] sd: don't bother spinning up disks on resume

2013-11-16 Thread James Bottomley
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

Re: [PATCH 1/3] sd: don't bother spinning up disks on resume

2013-11-15 Thread Mark Lord
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

Re: [PATCH 1/3] sd: don't bother spinning up disks on resume

2013-11-07 Thread Douglas Gilbert
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

Re: [PATCH 1/3] sd: don't bother spinning up disks on resume

2013-11-07 Thread Phillip Susi
-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