On Wed, Oct 29, 2008 at 9:30 PM, Stephen Hemminger
> On my desktop with Intel graphics ( 82G33/G31 ), I noticed some problems when
> doing resume from ram. The system takes some key strokes to come back correctly:
> Resume (power button)
> 1) LCD comes up in a resolution it can't display
> Hit Alt-F1, Alt-F7 and gets back
> 2) Screensaver unlock password box
> 3) Screen goes black with only mouse cursor. VT swapping
> again seems to get it back.
> 4) Screen sometimes does a short flip to black and then back
> some 5 seconds after that. No real reason why, some X server
> Steps 1 seem to be necessary, though I don't think it always lost
> its mind about resolution. but these happen with 2.6.26 and 2.6.27
> Step 3 is new in 2.6.28
> It could be that since is Ubuntu Hardy, and their suspend/resume does lots of
> "workaround" video wanking that it may just be fighting itself. Any ideas?
> It could be related to 3D effects which I really don't care about and could
> turn off.
If you're using suspend from the desktop GUIs, then HAL is calling the
pm-suspend script with some quirks in its database. Since there have
been fixes in the intel drm driver in the past few kernel releases, I
suspect that some of the video BIOS quirks HAL thinks are needed
aren't necessary anymore and are actually causing damage.
You can try running `pm-suspend --quirk-none', which is exactly the
same as what HAL is doing, but not doing any BIOS quirks. This should
be basically equivalent to doing `echo mem > /sys/power/state'. You
can see how HAL would normally be calling pm-suspend by looking at the
quirks with `lshal | grep power_management.quirk' (with minor
translation to pm-suspend options).
If you've been running `echo mem > /sys/power/state' the whole time,
then that's a kernel regression.