Bug 6265 - radeonfb - Radeon Mobility 9000 needs video bios POST on S3 resume on Dell 600m (and others)
radeonfb - Radeon Mobility 9000 needs video bios POST on S3 resume on Dell 60...
Status: REJECTED DUPLICATE of bug 7225
Product: Drivers
Classification: Unclassified
Component: Console/Framebuffers
i386 Linux
: P2 normal
Assigned To: Rafael J. Wysocki
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-03-21 14:19 UTC by steve
Modified: 2007-04-28 12:49 UTC (History)
2 users (show)

See Also:
Kernel Version: All of 2.6
Tree: Mainline
Regression: ---


Attachments

Description steve 2006-03-21 14:19:41 UTC
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.
Comment 1 Antonino Daplas 2006-03-21 16:14:22 UTC
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.
Comment 2 steve 2006-03-21 17:37:04 UTC
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.
Comment 3 Benjamin Herrenschmidt 2006-03-21 17:49:53 UTC
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...
Comment 4 steve 2006-03-21 18:05:49 UTC
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.
Comment 5 Antonino Daplas 2006-04-26 05:52:20 UTC
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
Comment 6 Antonino Daplas 2006-04-26 05:53:30 UTC
Oh, and try not using vbetool to POST the card while you have acpi_sleep=s3_bios...
Comment 7 steve 2006-04-26 11:59:55 UTC
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?
Comment 8 Benjamin Herrenschmidt 2006-04-26 15:18:10 UTC
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...
Comment 9 Rafael J. Wysocki 2006-11-13 10:38:22 UTC

*** This bug has been marked as a duplicate of 7225 ***

Note You need to log in before you can comment on or make changes to this bug.