Supend to RAM corrupts X Server with enabled AIGLX [i945GM]

[xRaich[o]²x]

Binary package hint: xserver-xorg-video-intel

Current Hardy KDE4.0.3 (with enabled desktop effects)

After resuming my notebook from Suspend to RAM I get a corrupted display (black with some colored vertical stripes).

Relevant lspci output:

00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)

I can work around the bug by switching to the console and suspend the machine by issuing echo mem > /sys/power/state, after resuming i can switch to the X server without problems, but the screen gets corrupted again when i shut down the machine.

[Bryce Harrington (bryce)]

Could you please test if this helps? Add these lines to the appropriate section of your xorg.conf:

  Section "Device"
    ...
    Option "ForceEnablePipeA" "true"
  EndSection

If that eliminates the issue, then please give following information:

  * Paste in the output of `lspci -vvnn | grep -A1 "VGA compat"`
  * Give the laptop model name and number
  * Confirm that adding "ForceEnablePipeA" solved the problem

Then I can add a quirk for your hardware too (these can be sru'd, so Hardy users will benefit).

[xRaich[o]²x (raichoo)]

Nope, that didn't help. It acutally froze the whole System (needed a hard reboot). I don't really remember if the System froze without the added line.

[xRaich[o]²x (raichoo)]

Sorry, i added the line to the wrong section (need some sleep). The system does not crash anymore (can do a clean shutdown by pressing the power button) but the display is still corrupted.

Btw.: I issue "echo mem > /sys/power/state" inside a KDE Konsole to send the computer into sleep mode. Dunno, maybe this is the "wrong" approach.

[unggnu (unggnu)]

Is it still possible to change to a console with ctrl + alt + F1 after resume?
Please post the files /var/log/Xorg.0.log and /var/log/Xorg.0.log.old and the output of lspci -vvnn.
Does the screen coruption/crash happen without AIGLX too? Could you recheck suspend/resume with a Ubuntu Hardy Live CD which has compiz enabled by default?

[xRaich[o]²x (raichoo)]

Here is the lspci output. The other logs will follow.I'm downloading the Ubuntu LiveCD right now.

[Bryce Harrington (bryce)]

00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller [8086:27a2] (rev 03) (prog-if 00 [VGA controller])
 Subsystem: Fujitsu Siemens Computers Unknown device [1734:10c7]

[xRaich[o]²x (raichoo)]

For the sake of being complete, here is the xorg log. Option "ForceEnablePipeA" "true" is still in the xorg.conf

[Bryce Harrington (bryce)]

Okay, thanks for testing it. Sounds like a pipe A quirk won't solve it...

[Bryce Harrington (bryce)]

Forwarding this bug report from an Ubuntu user:
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/225824

Original Report:

"Current Hardy KDE4.0.3 (with enabled desktop effects)

After resuming my notebook from Suspend to RAM I get a corrupted display (black with some colored vertical stripes).

Relevant lspci output:

00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)

I can work around the bug by switching to the console and suspend the machine by issuing echo mem > /sys/power/state, after resuming i can switch to the X server without problems, but the screen gets corrupted again when i shut down the machine."

00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller [8086:27a2] (rev 03) (prog-if 00 [VGA controller])
 Subsystem: Fujitsu Siemens Computers Unknown device [1734:10c7]

Setting the "ForceEnablePipeA" option appears to have stopped the crashes, but the display still remains corrupted.

Xorg.0.log: http://launchpadlibrarian.net/14259841/Xorg.0.log

[Bryce Harrington (bryce)]

xRaich, I've forwarded your bug upstream to https://bugs.freedesktop.org/show_bug.cgi?id=16722. Could you please subscribe to that bug, so if the upstream developers need further information or wish you to test things, you can work with them directly on it? Thanks ahead of time.

Also, if possible it would be helpful if you could see if you can reproduce this problem using Intrepid.

[Jesse Barnes (jbarnes-virtuousgeek)]

What kernel are you running (new kernels have fixes for suspend/resume)? When you say that you get corruption at shutdown, exactly what do you see?

[Bryce Harrington (bryce)]

Presumably he's running the stock Hardy kernel, which is
Linux 2.6.24-15-generic #1 SMP Fri Apr 4 03:48:31 UTC 2008 i686 GNU/Linux

[Bryce Harrington (bryce)]

Upstream is also asking to see a screenshot, photograph of the screen, or a very detailed description of what you're seeing exactly.

[Jesse Barnes (jbarnes-virtuousgeek)]

Ok, can you try a 2.6.25 or newer kernel? They have suspend/resume support in the drm driver; it seems to be working well for many users...

[Haien-liu (haien-liu)]

we try S3 with kernel 2.6.26-rc6 on our 945gm and get a gray screen when bringing back from S3.I'm not sure whether it is the same as your issue.

following is our system details:
Host: 945gm
Arch: i386
OSD: Fedora release 7 (Moonshine)
Kernel: 2.6.26-rc6
Libdrm: 2.3.0 d51e1bb56ca2f7858cdeac6f61a7b747c1e15b1e
Mesa:7.0branch 2a47ead225bca8be6fdf5079cf08a7a0031f9f05
Xserver: 1.4branch ff49f5944d06b17fb904c4f64b8660aab60d8d0d
Xf86_video_intel:2.4branch d5fd845aab4074ed6d0950551e007ea43fd2d0df

[Bryce Harrington (bryce)]

I've asked the user to try a newer version of the kernel or test against the intrepid alpha cd, but no response so far. I pinged him again, and will let you know either way.

[Bryce Harrington (bryce)]

xRaich, are you still interested in this bug? Upstream is requesting that you try against a newer version of the kernel - 2.6.25 or newer, which has suspend/resume support added in the drm driver, which many people report as working well.

You can also test the Intrepid alpha-4 Live CD, which has a newer kernel, if you prefer.

If we don't hear back from you by September, we'll have to assume the bug's fixed and no longer a concern for you, but it'd be great if you could confirm one way or the other.

[Michael Fu (michael-fu-intel)]

haien, is this bug fixed on the 945GM machine or not?

Bryce, any update from the original bug reporter?

[Michael Fu (michael-fu-intel)]

Jesse, haien's comment in comment# 4 is still true. would you please work with him to collect information? I'll remove the NEEDINFO tag for now...

[Bryce Harrington (bryce)]

There's been no response at all from the Ubuntu user. I've closed the downstream Ubuntu bug as expired. You can consider the problem mentioned in comment #4 as the focus of this report, or else close this bug as expired if you prefer.

[Jesse Barnes (jbarnes-virtuousgeek)]

liuhaien, I'll need register dumps from before and after the suspend/resume cycle to debug this. In general, for suspend/resume problems that'll be true, so I have a script that does it for me:

[root@jbarnes-t61 ~]# cat s3.sh
#!/bin/bash
intel_reg_dumper > pre-suspend.out
echo mem > /sys/power/state
intel_reg_dumper > post-resume.out

that makes it easy to diff the register state to figure out what's going wrong.

[Bryce Harrington (bryce)]

Since there's been no response from the reporter in quite some time, I'm closing this issue.
Please feel free to reopen with the requested info if the problem still exists in current Intrepid.

[Haien-liu (haien-liu)]

Created an attachment (id=19232)
pre-suspend.out

[Haien-liu (haien-liu)]

Created an attachment (id=19233)
post-resume.out

[Haien-liu (haien-liu)]

(In reply to comment #9)
> liuhaien, I'll need register dumps from before and after the suspend/resume
> cycle to debug this. In general, for suspend/resume problems that'll be true,
> so I have a script that does it for me:
>
> [root@jbarnes-t61 ~]# cat s3.sh
> #!/bin/bash
> intel_reg_dumper > pre-suspend.out
> echo mem > /sys/power/state
> intel_reg_dumper > post-resume.out
>
> that makes it easy to diff the register state to figure out what's going wrong.
>
I'm so sorry for being late to respond ,I am busy in testing 2008-q3-rc2 recently.
attachments are the output of reg_dumper,hope it can help you.

[Jesse Barnes (jbarnes-virtuousgeek)]

Ok, this is a little funky:

--- pre-suspend.out 2008-09-30 13:26:17.000000000 -0700
+++ post-resume.out 2008-09-30 13:26:24.000000000 -0700
@@ -21,26 +21,26 @@
 (II): DSPCLK_GATE_D: 0x00001000 (clock gates disabled: DPLUNIT)
 (II): RENCLK_GATE_D1: 0x00000000
 (II): RENCLK_GATE_D2: 0x00000000
-(II): SDVOB: 0x00480000 (disabled, pipe A, stall disabled, not detected)
-(II): SDVOC: 0x00480000 (disabled, pipe A, stall disabled, not detected)
+(II): SDVOB: 0x00300000 (disabled, pipe A, stall disabled, not detected)
+(II): SDVOC: 0x00300000 (disabled, pipe A, stall disabled, not detected)
 (II): SDVOUDI: 0x000000fe
 (II): DSPARB: 0x00001d9c
 (II): DSPFW1: 0x00000000
 (II): DSPFW2: 0x00000000
 (II): DSPFW3: 0x00000000
 (II): ADPA: 0x40008c18 (disabled, pipe B, +hsync, +vsync)
-(II): LVDS: 0xc0300300 (enabled, pipe B, 18 bit, 1 channel)
+(II): LVDS: 0xc0008000 (enabled, pipe B, 18 bit, 1 channel)
 (II): DVOA: 0x00000000 (disabled, pipe A, no stall, -hsync, -vsync)
-(II): DVOB: 0x00480000 (disabled, pipe A, no stall, -hsync, -vsync)
-(II): DVOC: 0x00480000 (disabled, pipe A, no stall, -hsync, -vsync)
+(II): DVOB: 0x00300000 (disabled, pipe A, no stall, -hsync, -vsync)
+(II): DVOC: 0x00300000 (disabled, pipe A, no stall, -hsync, -vsync)
 (II): DVOA_SRCDIM: 0x00000000
 (II): DVOB_SRCDIM: 0x00000000
 (II): DVOC_SRCDIM: 0x00000000
 (II): PP_CONTROL: 0x00000001 (power target: on)
 (II): PP_STATUS: 0xc0000008 (on, ready, sequencing idle)
-(II): PP_ON_DELAYS: 0x025907d1
-(II): PP_OFF_DELAYS: 0x01f507d1
-(II): PP_DIVISOR: 0x00270f05 ...

[Haien-liu (haien-liu)]

(In reply to comment #13)
> Ok, this is a little funky:
>
> --- pre-suspend.out 2008-09-30 13:26:17.000000000 -0700
> +++ post-resume.out 2008-09-30 13:26:24.000000000 -0700
> @@ -21,26 +21,26 @@
> (II): DSPCLK_GATE_D: 0x00001000 (clock gates disabled: DPLUNIT)
> (II): RENCLK_GATE_D1: 0x00000000
> (II): RENCLK_GATE_D2: 0x00000000
> -(II): SDVOB: 0x00480000 (disabled, pipe A, stall disabled, not
> detected)
> -(II): SDVOC: 0x00480000 (disabled, pipe A, stall disabled, not
> detected)
> +(II): SDVOB: 0x00300000 (disabled, pipe A, stall disabled, not
> detected)
> +(II): SDVOC: 0x00300000 (disabled, pipe A, stall disabled, not
> detected)
> (II): SDVOUDI: 0x000000fe
> (II): DSPARB: 0x00001d9c
> (II): DSPFW1: 0x00000000
> (II): DSPFW2: 0x00000000
> (II): DSPFW3: 0x00000000
> (II): ADPA: 0x40008c18 (disabled, pipe B, +hsync, +vsync)
> -(II): LVDS: 0xc0300300 (enabled, pipe B, 18 bit, 1 channel)
> +(II): LVDS: 0xc0008000 (enabled, pipe B, 18 bit, 1 channel)
> (II): DVOA: 0x00000000 (disabled, pipe A, no stall, -hsync,
> -vsync)
> -(II): DVOB: 0x00480000 (disabled, pipe A, no stall, -hsync,
> -vsync)
> -(II): DVOC: 0x00480000 (disabled, pipe A, no stall, -hsync,
> -vsync)
> +(II): DVOB: 0x00300000 (disabled, pipe A, no stall, -hsync,
> -vsync)
> +(II): DVOC: 0x00300000 (disabled, pipe A, no stall, -hsync,
> -vsync)
> (II): DVOA_SRCDIM: 0x00000000
> (II): DVOB_SRCDIM: 0x00000000
> (II): DVOC_SRCDIM: 0x00000000
> (II): PP_CONTROL: 0x00000001 (power target: on)
> (II): PP_STATUS: 0xc0000008 (on, ready, sequencing idle)
> -(II): PP_ON_DELAYS: 0x025907d1
> -(II): PP_OFF_DELAYS: 0x01f507d1 ...

[Haien-liu (haien-liu)]

the issue has gone against the latest code:
xf86_video_intel xf86-video-intel-2.6-branch
       commit b156b3165e1aae5df0353737d0335ac2e653f5fd

mesa intel-2008-q4 branch
       commit 154a9e5317f890618932cea0129ef887e16baf84

kernel for-airlied branch
        commit 66647dc60d16fae9f6963fd98b6d9baa1a8dac69

libdrm master branch
       commit b0d93c74d884b40bd94469a5ef75fdb2fef17680

xserver 1.6 is recommended.

[Haien-liu (haien-liu)]

verified.