Summary: | [GM965] black screen after suspend | ||||||
---|---|---|---|---|---|---|---|
Product: | xorg | Reporter: | Valery Inozemtsev <shrek> | ||||
Component: | Driver/intel | Assignee: | Chris Wilson <chris> | ||||
Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> | ||||
Severity: | critical | ||||||
Priority: | medium | CC: | antony.gelberg, ed, eric, florian, n-roeser, peter.hutterer, plaes | ||||
Version: | 7.5 (2009.10) | ||||||
Hardware: | All | ||||||
OS: | Linux (All) | ||||||
Whiteboard: | |||||||
i915 platform: | i915 features: | ||||||
Attachments: |
|
Description
Valery Inozemtsev
2009-12-03 05:04:21 UTC
I have similar issue on Lenovo x60s laptop that has 945GM chip: [snip] 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) [/snip] It seems to be only happening when you go to suspend running on battery power. When suspend has been initiated while on AC power, machine works fine. on the X61s does not affect AC power is connected or not if done # echo "mem"> /sys/power/state then returned to normal. but if you close the lid, then we get this effect it when working on battery for MSI MS-6837D wakes up normally oops ... if the MSI MS-6837D sleep on the battery, wakes up fine, but after a few minutes the screen goes black. restarting x server back to its normal state can not, just reboot I have a Dell D430 with: 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) running PLD Linux with kernel 2.6.30.5 (2.6.32 since yesterday) with KMS. I use xserver 1.7.3, intel driver 2.9.1, libdrm 2.4.16 and Mesa 7.6. I have no problems when suspending to RAM. I also have no problems hibernating, but I use TuxOnIce for it. The only requirement is, that I must do it under X - if I do it uder console, I have problems similar to described before. My wife has a Dell D400 (my previous machine), on which I also had no problems suspending to RAM and hibernating (also TuxOnIce) and it was less than a month ago. Will you please boot the system and do the following test? 1. kill the process which is using /proc/acpi/event(use the command of "lsof /proc/acpi/event" to get the process id) 2. cat /proc/acpi/event > event_log 3. close and reopen the LID twice and then press the "CTRL+C" 4. attach the output of event_log It will be great if you can attach the output of acpidump on your box. The acpidump can be obtained by using the pmtools-20071116, which can be downloaded in: http://www.lesswatts.org/projects/acpi/utilities.php thanks. Yakui is not the LID. If before the suspend-to-ram does not switch on the console, wakes up in the norm. With suspend-to-disk in any case will be switching to the console and after spilling black screen kernel 2.6.32.8 or 2.6.33-rc7 xorg-server 1.7.4.902 mesa 7.7.1-devel or 1.7.99.2 7.8-devel xf86-video-intel 2.10.0 libdrm 2.4.17 with xorg-server 1.6.5 after suspend-to-disk everything is OK Similar issue with 945GM was fixed for me in bug 24314. I have a Lenovo ThinkPad X61s with: 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c) (In reply to comment #10) > with xorg-server 1.6.5 after suspend-to-disk everything is OK Given this, would it be possible for you to perform a git bisect to identify the offending commit in the X server? Thanks, -Carl oh ... tried, it is not clear in which part of the watch I see this too on my R61. Very annoying. I have read the comments but it's not clear - is there a workaround? I'm using kernel 2.6.34 and xorg 1.7.7. Basically sometimes when I resume from hibernate, my laptop screen is blank. If I try dual-head with xrandr, I only get a display on the external screen. Switching to another X session gets the screen working, but when I switch back to the important session, it's blank again. Also, all virtual consoles are blank. Would really appreciate some debugging / workaround advice on this, it's making things really difficult. Have been chatting with ickle in #intel-gfx who told me to add my following xrandr output to the bug: Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192 VGA1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 510mm x 287mm 1920x1080 60.0*+ 1600x1200 60.0 1680x1050 60.0 1280x1024 60.0 1440x900 59.9 1280x960 60.0 1280x800 59.8 1024x768 60.0 800x600 60.3 56.2 640x480 60.0 LVDS1 connected 1680x1050+0+0 (normal left inverted right x axis y axis) 331mm x 207mm 1680x1050 60.0 + 84.9* 74.9 69.9 60.0 50.0 1600x1024 60.2 1400x1050 85.0 74.8 70.0 60.0 1280x1024 85.0 75.0 60.0 1440x900 59.9 1280x960 85.0 60.0 1360x768 59.8 1152x864 100.0 85.1 85.0 75.0 75.0 70.0 60.0 1024x768 85.0 75.0 70.1 60.0 832x624 74.6 800x600 85.1 72.2 75.0 60.3 56.2 640x480 85.0 72.8 75.0 59.9 720x400 85.0 640x400 85.1 640x350 85.1 TV1 disconnected (normal left inverted right x axis y axis) Note the * by the 84.9 - this looks weird. I tried xrandr --output LVDS1 --rate 60.0 --auto which got the * to 60.0, but still couldn't get LVDS1 to wake up. IRC log: 12:55 ickle> it looks like the timings for the VGA and LVDS have been swapped. 12:58 ickle> antgel: that xrandr output is screwy, add it to the bug. LVDS shouldn't be running at anything other than 60Hz, whereas it is unusal for VGA to run at a precise 60Hz... Another comment - I tried disabling KMS and it was no better, except I could at least get to virtual consoles. Now trying 2.12 as suggested at http://ikibiki.org/blog/2010/07/04/We_need_you_redux/. Same problem here, however I do not always see a blank screen, sometimes I see a frozen version of the screen just before suspend, and I can see my mouse cursor. Hardware (how s2ram sees it): sys_vendor = "LENOVO" sys_product = "2808D9G" sys_version = "ThinkPad T400s" bios_version = "6HET30WW (1.15 )" Sofware: linux 2.6.32-5 libdrm2 2.4.21 xserver-xorg-server 1.7.7 xserver-xorg-video-intel 2.9.1 and 2.12.0+legacy1 (debian) Here is what I learned from testing: 1. It happens every second try. The first try always works. 2. It does not depend on the suspend method. s2ram or echo "mem" > /sys/power/state both do not work as they should 3. It's the same with and without compositing 4. There is no cure, once it is blank there is no way to make it work other than restarting X 5. xrandr output does not show any difference between before and after suspend 6. however, xrandr no longer works (xrandr --output HDMI1 --off returns error) 7. I can get to virtual consoles just fine 8. It totally crashed my computer once or twice 9. I hate this bug! And now to the obscure: 1. the problem is new to me, very new. I don't know what I could have updated, but I cannot remember, that it happened before today. 2. When this bug got triggered Shorewall will take a log time unloading it's firewall on shutdown. I know, this is crooked. I will attach my acpidump output. Let my know when you need more info. Created attachment 38509 [details]
my acpidump output
One more thing: I can use my desktop just fine, only I don't see anything besides my mouse cursor (the rest is black just or the frozen image). However when I run kwin --replace I see the screen contents again. However, I cannot get kwin to run, it hangs and can only be "kill -9"ed. This is the output I get X Error: BadWindow (invalid Window parameter) 3 Major opcode: 20 (X_GetProperty) Resource id: 0x1c00028 kwin(6547) KWin::Extensions::init: Extensions: shape: 0x "11" composite: 0x "4" render: 0x "a" fixes: 0x "40" Trying to start it again (without --replace) after killing it results in the same error and kwin hanging again or the message (after the error) kwin: unable to claim manager selection, another wm running? (try using --replace) Now guess what happens when I try --replace. Sorry for the noise. It seems the problem, that I described was this one: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595776 And it is fixed now. Mass status change to NEEDINFO based on presence of NEEDINFO keyword. Please reopen if you can still reproduce the bug and are able to provide the information requested, thanks. Timeout. Please do reopen if you can still reproduce the issue and help us diagnose the problem, thanks. (In reply to comment #23) > Timeout. Please do reopen if you can still reproduce the issue and help us > diagnose the problem, thanks. I have a bug that is very similar to this. It seems to be fixed by xrandr --output LVDS1 --brightness 1 I dn't have a huge amount of time/skill to help debugging, but can try. (In reply to comment #24) > (In reply to comment #23) > > Timeout. Please do reopen if you can still reproduce the issue and help us > > diagnose the problem, thanks. > > I have a bug that is very similar to this. It seems to be fixed by > xrandr --output LVDS1 --brightness 1 > > I dn't have a huge amount of time/skill to help debugging, but can try. Do all values of brightness work? i.e. is it just that the backlight isn't being restored upon resume, or is it that the value it gets restored to is broken. Obviously, there are a lot of different bugs that could manifest themselves with a smila symptom, (a black screen after suspend). Not least of which, these bugs are distinct depending on the display adapter being used, (LVDS vs. DisplayPort etc.). I don't think it's useful to continue to reopen the same bug report for effectively indpendent issues, and would personally prefer to track each new reporter's issue as a separate bug report. But Chris seems to be engaging the latest bug reporter here, so I'll leave it to him if he wants to keep this bug open. A month without update from recent reporter, so considering that to be invalid. Please do open a new bug report with all the details required if it persists. |
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.