Hello. I have a Dell Inspiron 600m laptop with a Radeon Mobility 9000 video card. I like to use S3 suspend (to ram). If I enable radeonfb (or the old driver) in the kernel, the framebuffer works fine until suspend/resume. The machine suspends fine, but resume never completes - just a black screen, and nothing on the serial console. This is due to the fact that on this particular laptop radeonfb needs to POST the video card or it will lock up the system. A workaround has been to use VGA framebuffer instead of radeonfb, and let Xorg's radeon driver POST the video card. But, this does not work with radeonfb because it tries to do some operations on the uninitialized graphics card upon resume.
With the most recent kernel, you can try to add this in your suspend script: echo 1 > /sys/class/graphics/fb0/state /* suspend then resume here */ /* post the video card - ie, with vbetool */ echo 0 > /sys/class/graphics/fb0/state echo'ing 1 to the 'state' attribute will keep the graphics card from being touched by the framebuffer console until 0 is 'echoed' again to the state.
Thank you, but that didn't really work. Yes, echoing 1 and 0 to that file effectively locks / unlocks the radeonfb. However, this does not help with the suspend issue. Vbetool is able to "properly" reinit my graphics card if like, vga or vesa framebuffer is running (or none I guess) but with radeonfb, it does not help. In all cases, vbetool post segfaults for me, but without radeonfb the suspend script is able to reinit the card (even though vbetool still segfaults). And even if I don't use radeonfb (which is totally fine) I think my X driver tries to post the video card too, but it does so in a strange way, which on kernels above 2.6.11 causes occasional (byt very irritating) system hangs. (Currently installing an X without this patch to see what happens). Why can't radeonfb reinit the graphics card? This seems most appropriate. I remember there being a crude patch for this, but it had its own side effects. I read in the changelogs for 2.6.16 that it reinits the radeon card on some brand of laptop, just not my own.
It doesn't re-init all cards simply because it doesn't know how to do so... I have code there that can re-init some mac cards that I have written after hours spent reverse engineering the macos drivers... some of that code appears to work with some x86 laptops too and thus was enabled for them as well, but that's all at this point. If your BIOS isn't re-initing things and you don't have a way to get vbetool (or whatever other mecanism that s3 suspend has to try to get the BIOS to re-POST the video chip) to work, I don't see any solution. I also see no reason why the presence of radeonfb would prevent the card from being re-inited by vbetool... I would expect that to work unless the BIOS is doing some dodgy things with the card's PCI mapping...
I do not understand it either, but with radeonfb enabled, vbetool won't post the card. I don't know if vbetool is right for this system, as it does always segfault with post... whether or not it actually posts the card in the process depends on whether or not radeonfb is enabled. Like I said, X has a patch to post the radeon card, but it gets flaky above kernel 2.6.11. In a bit I will try using vgafb, vbetool, and an unpatched X to see what will happen.
If you are using acpi, try adding this in your boot line: acpi_sleep=s3_bios If the above still does not work acpi_sleep=s3_bios,s3_mode
Oh, and try not using vbetool to POST the card while you have acpi_sleep=s3_bios...
Nope, still not working. My laptop does not support the s3bios state. Adding any one of these acpi_sleep=s3_bios acpi_sleep=s3_mode acpi_sleep=s3_bios,s3_mode will simply cause the machine to reboot when coming out of suspend. Ie, it suspends fine, but when I open the lid, it just goes to the Dell logo and boots from scratch. Xorg has a patch for its Radeon driver to post the video card, and that is what wakes up my card currently. Why can't radeonfb make use of this?
Because X includes an x86 emulator and/or uses vm86 to run the BIOS which can't be made from kernel mode or would be too ugly to be acceptable. It might be possible to split that as a separate binary though and have radeonfb call it on wakeup and avoid touchign the display while it's off...
*** This bug has been marked as a duplicate of 7225 ***