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
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?
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
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...
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
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.
haien, is this bug fixed on the 945GM machine or not? Bryce, any update from the original bug reporter?
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...
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.
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.
Created attachment 19232 [details] pre-suspend.out
Created attachment 19233 [details] post-resume.out
(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.
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 +(II): PP_ON_DELAYS: 0x00000000 +(II): PP_OFF_DELAYS: 0x00000000 +(II): PP_DIVISOR: 0x00270f04 (II): PFIT_CONTROL: 0x80002668 (II): PFIT_PGM_RATIOS: 0x00000000 (II): PORT_HOTPLUG_EN: 0x00000020 @@ -76,7 +76,7 @@ (II): DSPBTILEOFF: 0x00000000 (II): PIPEBCONF: 0x80000000 (enabled, single-wide) (II): PIPEBSRC: 0x027f018f (640, 400) -(II): PIPEBSTAT: 0x00000202 (status: VSYNC_INT_STATUS VBLANK_INT_STATUS) +(II): PIPEBSTAT: 0x00000042 (status: LBLC_EVENT_STATUS VBLANK_INT_STATUS) (II): FPB0: 0x00031107 (n = 3, m1 = 17, m2 = 7) (II): FPB1: 0x00031108 (n = 3, m1 = 17, m2 = 8) (II): DPLL_B: 0x98026003 (enabled, non-dvo, spread spectrum clock, LVDS mode, p1 = 2, p2 = 14, SDVO mult 1) @@ -94,7 +94,7 @@ (II): VCLK_POST_DIV: 0x00020002 (II): VGACNTRL: 0x22c4008e (enabled) (II): TV_CTL: 0x00000000 -(II): TV_DAC: 0x70000000 +(II): TV_DAC: 0x00000000 (II): TV_CSC_Y: 0x00000000 (II): TV_CSC_Y2: 0x00000000 (II): TV_CSC_U: 0x00000000 According to the diffs, both LVDS and the panel power regs are getting hosed. The LVDS bits don't have the correct polarity (assuming the pre-suspend values are right) and the panel power regs are totally wrong, meaning the panel probably won't even power up. Haien, what symptoms do you see at resume time? Is the panel totally off or do you see artifacts?
(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 > -(II): PP_DIVISOR: 0x00270f05 > +(II): PP_ON_DELAYS: 0x00000000 > +(II): PP_OFF_DELAYS: 0x00000000 > +(II): PP_DIVISOR: 0x00270f04 > (II): PFIT_CONTROL: 0x80002668 > (II): PFIT_PGM_RATIOS: 0x00000000 > (II): PORT_HOTPLUG_EN: 0x00000020 > @@ -76,7 +76,7 @@ > (II): DSPBTILEOFF: 0x00000000 > (II): PIPEBCONF: 0x80000000 (enabled, single-wide) > (II): PIPEBSRC: 0x027f018f (640, 400) > -(II): PIPEBSTAT: 0x00000202 (status: VSYNC_INT_STATUS > VBLANK_INT_STATUS) > +(II): PIPEBSTAT: 0x00000042 (status: LBLC_EVENT_STATUS > VBLANK_INT_STATUS) > (II): FPB0: 0x00031107 (n = 3, m1 = 17, m2 = 7) > (II): FPB1: 0x00031108 (n = 3, m1 = 17, m2 = 8) > (II): DPLL_B: 0x98026003 (enabled, non-dvo, spread spectrum > clock, LVDS mode, p1 = 2, p2 = 14, SDVO mult 1) > @@ -94,7 +94,7 @@ > (II): VCLK_POST_DIV: 0x00020002 > (II): VGACNTRL: 0x22c4008e (enabled) > (II): TV_CTL: 0x00000000 > -(II): TV_DAC: 0x70000000 > +(II): TV_DAC: 0x00000000 > (II): TV_CSC_Y: 0x00000000 > (II): TV_CSC_Y2: 0x00000000 > (II): TV_CSC_U: 0x00000000 > > According to the diffs, both LVDS and the panel power regs are getting hosed. > The LVDS bits don't have the correct polarity (assuming the pre-suspend values > are right) and the panel power regs are totally wrong, meaning the panel > probably won't even power up. Haien, what symptoms do you see at resume time? > Is the panel totally off or do you see artifacts? > after suspending,we can see the power led are flickering,it seems like suspending normally. And at resume time ,the panel can also power up,we could not see any artifacts but a gray screen.
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.
verified.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.