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 -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html