Bug 6265

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 ***