My laptop fails to restore the display properly when coming out of sleep. The machine is still alive and can be accessed through ssh, and the backlight is still operational (and can be turned on and off by xset dpms force on/off), but the display is black. I have tested VT-switching and plugging in an external monitor through the VGA-connector after resuming, but to no avail. The display doesn't come up at all before 2.6.38 (edp-fixes-2 also works). Possibly relevant lines in dmesg might be: [ 191.775328] ioremap error for 0xc778e000-0xc7791000, requested 0x10, got 0x0 ... [ 194.483452] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id Graphics controller is: 00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 02) (prog-if 00 [VGA controller]) Subsystem: Lenovo Device 3920 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 41 Region 0: Memory at f0000000 (64-bit, non-prefetchable) [size=4M] Region 2: Memory at d0000000 (64-bit, prefetchable) [size=256M] Region 4: I/O ports at 1800 [size=8] Expansion ROM at <unassigned> [disabled] Capabilities: <access denied> Kernel driver in use: i915 Kernel modules: i915 I'm running Ubuntu 10.10 with kernel from torvalds git (currently 2b1caf6ed7b888c95a1909d343799672731651a5). I have also tried installing the x-org edgers ppa with, among other X/mesa-related updates: ii xserver-xorg-video-intel 2:2.14.0+git20110110.fd9235eb-0ubuntu0sarvatt~maverick X.Org X server -- Intel i8xx, i9xx display driver dmesg, lspci, and Xorg.0.log attached. Tell me if I forgot something important.
Created attachment 44722 [details] lspci -vv output
Created attachment 44732 [details] Xorg.0.log
Created attachment 44742 [details] dmesg
Can you please clarify whether resume works with edp-fixes-2 (or drm-intel-next since that branch has now been pulled into -next)? And by sleep you do mean suspend and not DPMS off or a screensaver?
Sorry, edp-fixes-2 has the same problem regarding sleep(/suspend), what works is getting a picture at all after KMS kicks in. And I am indeed talking about suspend. dpms seems to work fine with my current rc1+ kernel, but I'm not completely sure that it worked when I was running edp-fixes-2 (it might have).
I think I may have the same or a similar problem. My system shows a screen but no longer responds after suspend starting in 2.6.38-rc1. For my lshw and dmesg, check bug 27282 (https://bugzilla.kernel.org/show_bug.cgi?id=27282). (no dmesg after resume, since the system no longer reponds.) Let me know if I should open a new bug.
The ioremap error was introduced by commit 6d5bbf00d251cc73223a71422d69e069dc2e0b8d ACPI: Use ioremap_cache(). You have to replace the ioremap call in the i915 driver too. Try the following patch: --- a/drivers/gpu/drm/i915/intel_opregion.c 2011-01-20 10:37:04.000000000 +0100 +++ b/drivers/gpu/drm/i915/intel_opregion.c 2011-01-22 09:47:50.000000000 +0100 @@ -476,7 +476,7 @@ return -ENOTSUPP; } - base = ioremap(asls, OPREGION_SIZE); + base = ioremap_cache(asls, OPREGION_SIZE); if (!base) return -ENOMEM; On my videohardware: 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 03) 00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 03) there was not a black display, but the brightness control stoped working, neither the hotkeys nor the program xbacklight had any effekt. Reinhard
Is that in -rc2 yet or not? I didn't compile it myself. I always test the ubuntu ppa packages. Thanks for the info, but I rather wait for -rc3 in case it's not in rc2 yet.
I applied the patch in #7 on top of -rc2. The ioremap error is gone, but the display is still black. As before, the backlight turns on properly and the computer can be accessed through ssh.
There is another problem with brightness control on my computer. The hotkeys for the brightness controll don't work, but xbacklight does work. On the console I can change the brightness with echo n > /sys/class/backlight/fujitsu-laptop/brightness where n is 1 .. 7. Perhaps you could try that; note that the path behind /sys/class/backlight/ may be different on your computer. The problem concerning the hotkeys was inttroduced by patch 677bd810eedce61edf15452491781ff046b92edc ACPI video: remove output switching control If I press one of the hotkeys, the number of the ACPI interrupts in /proc/interrupts increases, but acpi_listen doesn't show an event.
I just realized that I have no control at all over the backlight in my current kernel except through xset dpms force on/off, and /sys/class/backlight is empty. I'm not sure this is related to my main problem though, the backlight (and hotkeys) seems to work properly both before and after sleep on a kernel built from edp-fixes-2 (even though all the pixels remain black after resuming, of course). I have disabled some drivers between building these kernels in an attempt to speed up compiling so it's remotely possible that I have managed to change or disable something important. I'll try rebuilding a kernel closer to the old config I was using.
Actually, simply closing the lid and opening it again gives the same result as suspending it and resuming again does. Regarding the backlight: a more cautiously configured -rc2 yields no improvement.
The missing ACPI video device sounds like the bug my patch at https://lkml.org/lkml/2011/1/23/92 tries to fix. Please give it a shot, it might fix all your issues.
Thanks, the patch at https://lkml.org/lkml/2011/1/23/92 gives me control over the backlight again. However, the display (the actual pixels, not the backlight) remains black as before.
Have you tried booting with no_console_suspend ?
Ah, a Lenovo LVDS. I have one such beast that will not restore the display without commit 633f2ea26665d37bb3c8ae30799aa14988622653 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Jan 19 13:29:42 2011 +0000 drm/i915: Disable SSC for outputs other than LVDS or DP For CRT and SDVO/HDMI, we need to use a normal, non-SSC, clock and so we must clear any enabling bits left-over from earlier outputs. And also seems to correct the LVDS panel on the Lenovo U160. However, at one point, it did cause an "ERROR failed to disable trancoder". So prolonged testing on top of Jesse's refactored and error-checking CRTC logic is desired. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> on drm-intel-next.
I tried booting with no_console_suspend=1 added, no change as far as I can see. The patch in #16, drm/i915: Disable SSC for outputs other than LVDS or DP , failed to be cherry-picked upon -rc2 so I checked out drm-intel-next (at commit f29a05e33d581750fe31852a46dc7b6136abcf60). The computer now seems to hang on resume before the backlight is even turned on and can't be reached through ssh. Closing the lid and opening it again still produces a blank picture (with backlight, accessible through ssh) however, so chances are it doesn't help. I also tried reverting the patch in #16 to see if it's the cause of the hang, but the computer still hangs on resume so it must be a regression somewhere else. I tried both with and without the ACPI patch referenced in #13, but not the ioremap patch in #7 since that issue seemed to have been addressed already. I'm a bit low on time for further regression testing at the moment.
Created attachment 46822 [details] dmesg of lid close-open with drm.debug=0xf under 2.6.38-rc3+ Hi Chris, Now that you fixed bug 28012 for me, I'm hitting this issue: if I close the lid after bootup (early initramfs phase), the LVDS switches off as it should, and when I open the lid afterwards, the screen comes back perfectly for a second, then the backlight goes off for another second, then the backlight comes back, but with an empty (black) screen this time. The machine stays usable otherwise (blindly). 2.6.32 behaves similarly, except at the end the screen isn't empty but usable. Under 2.6.36 the "no backlight" period after opening the lid is a split-second blink only (which is better, but still an extra -- seemingly unnecessary -- off-on). Your "drm/i915: Disable SSC for outputs other than LVDS or DP" from drm-intel-next doesn't have any effect. The attached dmesg was taken with your "drm/i915: Only bind to function 0 of the PCI device" and Rafael J. Wysocki's attachment 46492 [details] "ACPI / Wakeup: Enable button GPEs unconditionally during initialization" over 2.6.38-rc3.
677bd810eedce61edf15452491781ff046b92edc is the first bad commit commit 677bd810eedce61edf15452491781ff046b92edc Author: Zhang Rui <rui.zhang@intel.com> Date: Mon Dec 6 15:04:21 2010 +0800 ACPI video: remove output switching control Remove the ACPI video output switching control as it never works. With the patch applied, ACPI video driver still catches the video output notification, but it does nothing but raises the notification to userspace. Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com> :040000 040000 9ac302b1e698eb5b382234fde6e69e6438219afb 6be6bdd2ae6a071daa9dd990c582ddfa4b523b3f M Documentation :040000 040000 ccdca0d41938b8312e946cde3c01c59b32d1c17c 4657bd672341c069bb0e7e607a8fa4f52d8a1757 M drivers
If you tracked it down to that very commit, please try whether the patch linked in comment #13 helps. That patch reverts the only part of the commit you bisected to that will affect ACPI behaviour outside of the output switching, that indeed was problematic.
Yes, the partial revert from https://lkml.org/lkml/2011/1/23/92 also helps. /sys/class/backlight is present but empty with or without it. I'm sorry for not checking this earlier: its description mentions backlight problems, but backlight itself was coming back all right for me.
Shouldn't this bug be reassigned to the ACPI component and tagged as a regression to raise awareness amongst the subsystem maintainers?
The patch is already included as a regression-fixing patch in bug 27702 (http://bugzilla.kernel.org/show_bug.cgi?id=27702)
merged in (soon to be) .38-rc6: commit ed764e7ca042dbf4cc1c7f4e12cd842c7789f133 Author: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de> Date: Sat Feb 12 01:40:16 2011 +0100 ACPI / Video: Probe for output switch method when searching video devices.
I have tried -rc6, and I can now indeed control the backlight without any additional patches - which is an improvement. However, this was not the bug I have been trying to report. Pixels on display remain black after resuming from suspend or a simple close/open-lid action. Computer is still alive and accessible through ssh, and backlight is turned on and - with rc6 - controllable. Apologies if I'm using unclear terminology.
I just discovered the lvds_use_ssc parameter, and I can report that booting vanilla -rc6 with i915.lvds_use_ssc=0 consistently fixes both the suspend/resume and lid open/close issues I had. I assume #16 might do something similar, not sure why that didn't seem to work for the open/close case (PEBCAK?). If this is an acceptable fix I guess it should preferably happen automatically, but maybe the issue is tracked elsewhere? Thanks
I have the same problem with both brightness controls (still unresolved) and blank display (with backlight) on resume -- fixed with i915.lvds_use_ssc=0 as David reported. Here's the link to my report on fd.o -- will probably file reports here from now on, this bug tracker seems more active for KMS-related issues. https://bugs.freedesktop.org/show_bug.cgi?id=34437 Likewise, I'd like for this to be auto-detected -- or failing that, the switch should probably be documented; I find nothing about it in the kernel's Documentation folder
(In reply to comment #26) > I just discovered the lvds_use_ssc parameter, and I can report that booting > vanilla -rc6 with i915.lvds_use_ssc=0 consistently fixes both the > suspend/resume and lid open/close issues I had. I assume #16 might do > something > similar, not sure why that didn't seem to work for the open/close case > (PEBCAK?). > David, Is your laptop the Lenovo U160? In which case the fix has been merged in kernel 3.0, so the lvds_use_ssc=0 workaround is no longer required. If it's not, please provide the output of lspci -nnvv so your specific device ID can be blacklisted from using SSC (see the other bug report, https://bugs.freedesktop.org/show_bug.cgi?id=34437 )
(In reply to comment #28) > Is your laptop the Lenovo U160? In which case the fix has been merged in > kernel > 3.0, so the lvds_use_ssc=0 workaround is no longer required. > It is an U160, and the bug appears to be fixed. Thanks.