On Mon, 15 Dec 2008 17:08:47 +1100, Nigel Cunningham wrote: > Hi Brian.
Hi Nigel, > You might also carefully examine your system after the first cycle. This > sort of behaviour is always the result of some driver properly saving > and restoring its state (or not saving/restoring at all), and often > results in the relevant hardware not working perfectly after the first > cycle as well as dying properly on the second attempt at > suspending/hibernating. It all seems to work quite well, even after the first suspend/resume cycle. > I'd therefore also suggest that you try building as much as possible as > modules, and try to rule things out by suspending a couple of times > without the appropriate module loaded. One of the first things I tried in fact was unloading as many modules as I could, including bringing down network interfaces, etc. ISTR I had it down to a dozen or less modules loaded and it still did the same thing. > Hopefully you'll get to a point > where you can say "if I suspend with module X loaded, it hangs". Well, I have already gotten to a point where, if it's a module, I cannot, not have it installed. > Start > with testing after booting from init S, just in case it's something > that's still built in after you've done the > modularising-as-much-as-possible. I'm not sure I'm following you on this instruction. Can yo elaborate, if it's still relevant given my description above? I think also, the work I did with /sys/power/pm_trace and detailed in the lkml posting that I pointed to in my original posting here points squarely at video doesn't it? I certainly could be wrong. I'm far from an expert at troubleshooting this suspend/resume issues. I find in fact that we (the linux community) are still to this day struggling with suspend/resume quite saddening and frustrating. b. _______________________________________________ Pm-utils mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/pm-utils
