Hello, Sorry that i have not had time to investigate further. However, it would seem that the logs provided by bladud shows (as i see it) the problem (the logs Aaron requested). https://bugzilla.kernel.org/show_bug.cgi?id=48951 1) When running without async suspend, the disks are suspended *after* the sata_nv module. That makes sense, as we cannot expect the controller to handle commands after it has been suspended. 2) when running with async suspended, the disks are suspended *before* the sata_nv module. This does not make much sense. This would also explain certain strangeness (different outcome) in the bug, as effectively the disks are racing against their own controller! Hmmmm how is this supposed to work? Even though async suspend is enabled, the kernel must still have some dependencies that describe in which order things can be suspended. What is the correct way of telling the kernel (PM) that sata_nv cannot be suspended before all child disks are suspended? How do other drivers handle this? Any comments? /pedro 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. > > -Aaron > -- 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
