On Mon, 2013-03-11 at 21:51 +0800, Aaron Lu wrote: > On 2013-03-11 16:49, James Bottomley wrote: > > On Mon, 2013-03-11 at 11:42 +0800, Aaron Lu wrote: > >> Hi all, > >> > >> I've seen some reports on STANDBY IMMEDIATE failed on NVIDIA MCP5x > >> controllers when system goes to suspend(this command is sent by scsi sd > >> driver on system suspend as a SCSI STOP command, which is translated to > >> STANDBY IMMEDIATE ATA command). I've no idea of why this happened, so > >> I wrote this email in hope of getting some new idea. > >> > >> The related bug report: > >> https://bugzilla.kernel.org/show_bug.cgi?id=48951 > >> > >> And google search showed that Peter reported a similar problem here: > >> http://marc.info/?l=linux-ide&m=133534061316338&w=2 > >> > >> And bladud has found that, disable asyn suspend for the scsi target > >> device can work around this problem. > >> > >> Please feel free to suggest what can possibly be the cause, thanks. > > > > You really need to discriminate better between conditions we should and > > shouldn't care about for suspend. so in sd_suspend, we definitely care > > if we can't flush the cache of a write back device because the power off > > could lose data. We don't really care if the disk says I can't stop, so > > this is probably the correct fix. > > Yes, this will make suspend succeed, but the problem is still there - > the drive does not respond to this command, while it will if async > suspend for the target device is disabled. I don't think scsi code has > any fault here, it feels more like a chip bug to me. > > And if we solve it this way, affected user may complain about long > delay when suspending or uncomfortable with the error messages in dmesg, > since that command would eventually timeout. So I hope we can nderstand > what is going wrong here and perhaps do something to avoid it. Oh, that seems to be the suspend order isn't careful enough. __device_suspend() waits for its children, but the host disk are too far separated in the device tree. If the immediate children of the host are all sync, that wait never actually waits for anything. James -- 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
