On Thu, 2006-08-31 at 09:20 -0500, Jason Martens wrote: > Simon Josefsson wrote: > > I can confirm this as well. Suspend to RAM in 2.6.16 worked fine, but > > 2.6.17-1 and 2.6.17-2 broke this. I have a Dell Precision M65 (which is > > labeled as 'Latitude D820', for some reason). > > > > I don't get a black screen, as in the fedora reports that Pierre > > mentioned. I get a kernel backtrace in the 'myecho' process inside > > 'suspend_return', or something like that. The backtrace isn't saved to > > disk. Jason, Pierre, do you get the same behaviour? > > > I can't see any error messages on my system. It actually suspends > correctly (and the power status flashes slowly like it should), but > after waking the system up, the screen never comes on and I don't see > any activity. I do not have a serial port on this system.
It suspends correctly here too, but after waking it up, I see a kernel backtrace. The fedora report suggests that the system is live after resuming, IIRC, and that he could log into the system and reboot it. Can you? If so, perhaps this is two different problems. One theory as to why I see a kernel backtrace is because I have externally connected monitors, and have a complex nvidia configuration. It may be the case that the kernel backtrace just isn't displayed correctly for you. Anyway, if you can log in to the system when the screen is black, and get it to respond somehow, that would tell the difference. I've also noticed another similar report, with a patch: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=382339 I don't have time to test the patch right now. Anyone else? The report suggests uswsusp was brand new in 2.6.17, which doesn't sound like something good if 2.6.17 is the releasable kernel for etch. But I'm not really familiar with swusp, so I'll trust the kernel package maintainers to do the right thing. /Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
