Le janvier 28, 2010 04:14:03 PM, Michael Biebl a écrit :
> On 28.01.2010 09:28, Filipus Klutiero wrote:
> > Package: pm-utils
> > Version: 1.2.6.1-3
> > Severity: important
> >
> > After suspending with pm-suspend, suspend works except for the screens
> > which stay completely black...making pm-suspend pretty much unusable.
> >
> > I'm using a Compal FL90 laptop with an integrated GeForce 8600M GT video
> > card. This issue happens when I'm in a tty or running X with the nv
> > driver. Suspend works fine with the nvidia driver (even if the suspend
> > happens from a tty). I didn't try vesa.
> >
> > This happens whether vbetool is installed or not. The log seems
> > completely normal. auto-quirks selects --quirk-vbe-post. The problem also
> > happens with no quirk, with --quirk-s3-bios or --quirk-s3-mode. This
> > happens on 2.6.32 686 or amd64, with the kernel sleep module.
> 
> Have you tried all different combinations of pm-suspend?
Do you mean combinations of quirks? If so, I have not. As I wrote, I tried no 
quirk, --quirk-vbe-post, --quirk-s3-bios and --quirk-s3-mode, but no 
"combination" of these nor any other quirk. I reboot the machine each time a 
test fails, so with the log analysis, the tests I made caused about 10 reboots 
and took me well over an hour. I consider I tried the most likely quirks. If I 
go over them:

>--quirk-dpms-on
> This option forces the video hardware to turn on the screen during resume.
> Most video adapters turn on the screen themselves, but if you get a blank
> screen on resume that can be turned back on by moving the mouse or typing
> then this option may be useful.

Not my problem.

> --quirk-dpms-suspend
> This option forces the video hardware to turn off the screen when
> suspending. Most video adapters seem to do this correctly, but some do not,
> which wastes lits of power. If your screen is still on after successfully
> suspending you may need to use this option.

Not my problem.

> --quirk-radeon-off
> This option forces Radeon hardware to turn off the display during suspend
> and turn it back on during resume. You only need to do this on some old
> ThinkPads of the '30 series (T30, X31, R32,... ) with Radeon video
> hardware.

Not my hardware.

> --quirk-s3-bios
> This option calls the video BIOS during S3 resume. Unfortunately, it is not
> always allowed to call the video BIOS at this point, so sometimes adding
> this option can actually break resume on some systems.

Tried.

> --quirk-s3-mode
> This option initializes the video card into a VGA text mode, and then uses
> the BIOS to set the video mode. On some systems S3 BIOS only initializes
> the video bios to text mode, and so both S3 BIOS and S3 MODE are needed.

Tried.

> --quirk-vbe-post
> This option will attempt to reinitialize the video card when resuming from
> suspend, using the same code the system BIOS uses at boot in order to
> initialize the video hardware. Not all video cards need this, and using
> this option on systems where it is not needed can cause a system to lock up
> when resuming.

Used by default.

> --quirk-vbemode-restore
> This option will save and restore the current VESA mode which may be
> necessary to avoid X screen corruption. Using this feature on Intel
> graphics hardware is probably a bad idea.

"Screen corruption"... does this apply to me? I just have the screen off.

> --quirk-vbestate-restore
> This option saves and restores some low level hardware state which may be
> invalid after suspend.

Could this avoid my problem?

> --quirk-vga-mode3
> This option will try to force the video card into a standard text mode on
> resume.

Could this avoid my problem?

> --quirk-save-pci
> Save the PCI config space for the VGA card.

Could this avoid my problem?

> It's most likely not a bug in pm-utils, but simply hal(-info) is not
>  providing the correct quirk for your hardware.
> 
> As an alternative, you might try the noveau driver, which uses KMS and so
>  no longer needs any suspend quirks.
nv and nvidia are buggy enough for me. As I wrote, things work fine with 
nvidia. My concern is partly personal, since I sometimes use nv, but mostly 
for other users, since I usually use nvidia. By default, KDE 4 installs offer 
suspend to RAM, and NVIDIA cards will use by default the nv driver. Hopefully 
not all NVIDIA cards have this issue, otherwise this bug is serious.


With so many relevant quirks, trying all combinations is out of question, 
however I could try the 3/4 quirks at the bottom if someone thinks they're 
likely to help. Or some combination more likely to help. If you propose some 
combinations to try, I would appreciate to have them in an order of likeliness 
to fix.



--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]

Reply via email to