On Tuesday, August 17, 2010, Tejun Heo wrote: > Hello, > > On 08/17/2010 11:32 AM, Stephan Diestelhorst wrote: > > Indeed. Like I said, I have similar issues on a another Samsung HDD in > > an AMD system. I have not yet got around to try the fix there, but I > > suspect it is the same thing. > > > > I have attached the full /var/log/messages and /var/log/kern.log with > > multiple suspend-to-ram runs and the last one failing. > > Hmm... are you sure the patch is applied? There's no debug message > outputs in the log which the patch added. > > > Would it make sense to add Rafael's workaround upstream, maybe enabling > > it only for particular platforms / HDDs / with a parameter? > > Yeah, maybe. The problem is that I'm a bit reluctant to do that for > all cases as it may cause other obscure failures and we don't know > whether the problem is controller or device specific at this point, > so... Well, I wonder what the real reason for doing the link power management thing at this particular point in the suspend code path is. It just seems to disable the link power management, but then the controller is put into a low-power state and is reset from scratch during resume, so I'm not quite sure how skipping that code could possibly lead to any problems. Perhaps we could move the link PM manipulation to the prepare stage of suspend? Thanks, Rafael -- 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
