When I try to resume with radeonhd the machine locks up. The machine is so dead that capslock toggling doesn't work - but the screen gets some kind of signal; it wakes up but shows no signal. Is this a known problem? Is it related to the graphics driver at all? Is it a kernel bug? Is a hal quirk needed? Running Fedora 8 with 2.6.23.1-49.fc8 on Dell Optiplex 745 with RV516 X1300 pro and homebuilt driver from 20071123git f5ffe41a6c1ffa9418782b7059b075da06e7c496 Suspend/resume works fine with the motherboards intel graphic card.
Is this a suspend to disk of suspend to ram? Can you describe what happens when you resume? What do you see? Does it work when you vt switch to a console before suspending?
Not sure that this applies to your case, but anyways... I had a similar kind of problem just recently, only my machine didn't quite get to actually suspend. It seems that this was due to the fglrx driver that I had used previously, but not yet uninstalled after changing to radeonhd. Thus the fglrx kernel module was still loaded. I prevented that from loading and suspend has worked just fine since then.
Mads, were you running fglrx before?
I'm using xorg-x11-drv-radeonhd-1.0.0-0.2.20071209git.fc8 from fedora koji, on kernel-2.6.23.8-63.fc8. No, I haven't used fglrx. When I suspend I use what Fedora calls Suspend, that is suspend to ram. When I use pm-suspend from text mode, with or without quirks, then the machine resumes to a running state, but without display; I can issue commands, but not see what I'm doing. When I do the same with X running (or choose the suspend option from Fedora Gnome Shut Down menu) then it won't resume. So: There is a kernel/PM problem with suspend/resume and the radeon card. But the radeonhd driver somehow makes it worse, either because of the first problem or because of another problem. Does suspend/resume work for others with similar graphic cards? Without quirks? From text as well as X?
Yes, some people are happy with suspend resume.
I would assume that those people who are happy with suspend resume have some tool running that switches the Xserver back to the console before suspending. With APM the Xserver itself called LeaveVT() before it gave APM the signal to continue. Before we look into any driver issues we should check if this is really the case.
AFAIK the kernel always switches to a VT before actually doing suspend. openSUSE does this explicitly before suspending, I guess to give the Xserver some more time for actually doing this.
I don't think the kernel does. At least not in the past. I need to recheck this...
We had some save/restore bugfixes lately, can you retest with 1.2.0 or current git? > When I use pm-suspend from text mode, with or without quirks, then the machine > resumes to a running state, but without display; I can issue commands, but not > see what I'm doing. In that case your card is probably not initialized after resume. You should try different combinations of acpi_sleep settings on the kernel line (s2ram is a wrapper that can set this from user mode as well). Typically, acpi_sleep=s3_bios is enough. You also might need (additionally) the vbetools to restore the console mode.
Please verify with current git.
No feedback for over two month. Closing.
Sorry for falling into a deep hole and disappearing. I just came back to the hardware. I confirm that it works 99.9% now. Great. Thanks! However, occasionally, after a resume some bitmaps are bad; there are line of "noise" in some windows titles, and the icons shown when alt-tab-switching between applications is just noise. The funny thing is that switching to text mode once changes nothing, but changing back and forth a couple of times fixes the problem. Should I create another issue with this? xorg-x11-drv-radeonhd-1.2.1-1.1.20080429git.fc9.i386
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.