Deferred disk spinup during system resume

Deferred disk spinup during system resume

[Brian Norris]

Hi Tejun,

I would like some advice regarding a patch you sent a while ago. I'd
greatly appreciate some help.

I'm working on an embedded platform in which the resume from suspend
process takes an excessive amount of time waiting on the disk to spin
up, even though the disk is not integral to system wake-up. You sent
this patch a while back to deal with this issue:
http://article.gmane.org/gmane.linux.scsi/64719

Unfortunately, this doesn't seem to work on my system. With this
applied to either 2.6.37 (current kernel near the time of the patch)
or 3.3, a simple suspend/resume cycle no longer actually spins down
the disk. The problem is actually worse on 2.6.37, where I get errors
like this during resume:

sd 1:0:0:0: [sda] Starting disk
ata1: SATA link down (SStatus 0 SControl 300)
ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 320)
sd 1:0:0:0: [sda] START_STOP FAILED
sd 1:0:0:0: [sda]  Result: hostbyte=0x04 driverbyte=0x00
pm_op(): scsi_bus_resume_common+0x0/0x6c returns 262144
PM: Device 1:0:0:0 failed to resume async: error 262144

And any subsequent I/O fails:

sd 1:0:0:0: [sda] Unhandled error code
sd 1:0:0:0: [sda]  Result: hostbyte=0x04 driverbyte=0x00
sd 1:0:0:0: [sda] CDB: cdb[0]=0x28: 28 00 00 00 00 00 00 00 20 00
end_request: I/O error, dev sda, sector 0
Buffer I/O error on device sda, logical block 0
Buffer I/O error on device sda, logical block 1
Buffer I/O error on device sda, logical block 2
Buffer I/O error on device sda, logical block 3
sd 1:0:0:0: [sda] Unhandled error code
sd 1:0:0:0: [sda]  Result: hostbyte=0x04 driverbyte=0x00
sd 1:0:0:0: [sda] CDB: cdb[0]=0x28: 28 00 00 00 00 00 00 00 08 00
end_request: I/O error, dev sda, sector 0
Buffer I/O error on device sda, logical block 0

(I do not experience the last two problems on my 3.3 kernel)

I understand that your original patch was given the "not tested"
disclaimer, but I wanted to know if you had any immediate advice on
why this failed so miserably for me, before I go trying to dig in to
this issue more deeply. For instance, maybe there's been enough code
change between 2.6.37 and 3.3 (or current upstream - 3.6-rc2) that
would require a change in approach.

Thanks,
Brian

Re: Deferred disk spinup during system resume

[Tejun Heo]

Hello, Brian.

On Fri, Aug 17, 2012 at 07:12:30PM -0700, Brian Norris wrote:
> I understand that your original patch was given the "not tested"
> disclaimer, but I wanted to know if you had any immediate advice on
> why this failed so miserably for me, before I go trying to dig in to
> this issue more deeply. For instance, maybe there's been enough code
> change between 2.6.37 and 3.3 (or current upstream - 3.6-rc2) that
> would require a change in approach.

Yeah, I'm not particularly fond of how resume is implemented.  It can
and should be more asynchronous, I think. :( Unfortunately, I'm a bit
too preoccupied at the moment.  A quick & dirty hack would be simply
skipping ATA_CMD_VERIFY so that the drive spins up on the actual next
command.  If that's acceptable, just add "goto skip;" right after "if
(cdb[4] & 0x1)" test in ata_scsi_start_stop_xlat().

Thanks.

-- 
tejun

Re: Deferred disk spinup during system resume

[Brian Norris]

Hi Tejun,

Thanks for the tips. Sorry for the delay in response; I meant to
respond sooner...

On Mon, Aug 20, 2012 at 1:57 PM, Tejun Heo <tj@kernel.org> wrote:
> On Fri, Aug 17, 2012 at 07:12:30PM -0700, Brian Norris wrote:
>> I understand that your original patch was given the "not tested"
>> disclaimer, but I wanted to know if you had any immediate advice on
>> why this failed so miserably for me, before I go trying to dig in to
>> this issue more deeply. For instance, maybe there's been enough code
>> change between 2.6.37 and 3.3 (or current upstream - 3.6-rc2) that
>> would require a change in approach.
>
> Yeah, I'm not particularly fond of how resume is implemented.  It can
> and should be more asynchronous, I think. :( Unfortunately, I'm a bit
> too preoccupied at the moment.

I understand the "preoccupied"! I'm interested in seeing this done at
some point, but like you, I don't have a lot of time. And unlike you,
I'm not so familiar with the current resume process :(

> A quick & dirty hack would be simply
> skipping ATA_CMD_VERIFY so that the drive spins up on the actual next
> command.  If that's acceptable, just add "goto skip;" right after "if
> (cdb[4] & 0x1)" test in ata_scsi_start_stop_xlat().

This worked OK. However, it means that the drive doesn't even start
spinning up until resume is totally complete and somebody/something
makes a request to the drive. Then, the requester waits just as long
for the spinup. This isn't really "asynchronous" as much as reordering
the resume sequence (or delaying spinup indefinitely, if the disk is
not being used).

Regards,
Brian