Bug 27312 - Failure to restore laptop display after sleep
Summary: Failure to restore laptop display after sleep
Status: RESOLVED CODE_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: Video(DRI - Intel) (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: drivers_video-dri-intel@kernel-bugs.osdl.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-01-21 23:49 UTC by David Hedberg
Modified: 2021-06-03 06:09 UTC (History)
10 users (show)

See Also:
Kernel Version: 2.6.38-rc1+
Tree: Mainline
Regression: No


Attachments
lspci -vv output (10.72 KB, text/plain)
2011-01-21 23:51 UTC, David Hedberg
Details
Xorg.0.log (27.52 KB, text/plain)
2011-01-21 23:51 UTC, David Hedberg
Details
dmesg (67.18 KB, text/plain)
2011-01-21 23:52 UTC, David Hedberg
Details
dmesg of lid close-open with drm.debug=0xf under 2.6.38-rc3+ (77.44 KB, text/plain)
2011-02-08 01:25 UTC, Ferenc Wágner
Details

Description David Hedberg 2011-01-21 23:49:07 UTC
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.
Comment 1 David Hedberg 2011-01-21 23:51:14 UTC
Created attachment 44722 [details]
lspci -vv output
Comment 2 David Hedberg 2011-01-21 23:51:50 UTC
Created attachment 44732 [details]
Xorg.0.log
Comment 3 David Hedberg 2011-01-21 23:52:40 UTC
Created attachment 44742 [details]
dmesg
Comment 4 Chris Wilson 2011-01-21 23:56:50 UTC
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?
Comment 5 David Hedberg 2011-01-22 00:04:45 UTC
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).
Comment 6 Dennis Jansen 2011-01-22 14:30:44 UTC
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.
Comment 7 Reinhard Karcher 2011-01-22 14:48:43 UTC
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
Comment 8 Dennis Jansen 2011-01-22 15:53:55 UTC
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.
Comment 9 David Hedberg 2011-01-22 16:33:43 UTC
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.
Comment 10 Reinhard Karcher 2011-01-22 18:04:24 UTC
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.
Comment 11 David Hedberg 2011-01-22 19:09:46 UTC
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.
Comment 12 David Hedberg 2011-01-22 23:54:15 UTC
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.
Comment 13 Michael Karcher 2011-01-23 21:00:15 UTC
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.
Comment 14 David Hedberg 2011-01-23 23:57:49 UTC
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.
Comment 15 Dennis Jansen 2011-01-24 06:34:40 UTC
Have you tried booting with no_console_suspend ?
Comment 16 Chris Wilson 2011-01-24 14:19:25 UTC
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.
Comment 17 David Hedberg 2011-01-24 20:43:02 UTC
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.
Comment 18 Ferenc Wágner 2011-02-08 01:25:31 UTC
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.
Comment 19 Ferenc Wágner 2011-02-08 18:58:19 UTC
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
Comment 20 Michael Karcher 2011-02-08 19:14:10 UTC
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.
Comment 21 Ferenc Wágner 2011-02-08 19:28:06 UTC
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.
Comment 22 Ferenc Wágner 2011-02-09 16:04:24 UTC
Shouldn't this bug be reassigned to the ACPI component and tagged as a regression to raise awareness amongst the subsystem maintainers?
Comment 23 Michael Karcher 2011-02-09 17:07:34 UTC
The patch is already included as a regression-fixing patch in bug 27702
(http://bugzilla.kernel.org/show_bug.cgi?id=27702)
Comment 24 Florian Mickler 2011-02-20 00:08:11 UTC
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.
Comment 25 David Hedberg 2011-02-23 08:55:26 UTC
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.
Comment 26 David Hedberg 2011-02-24 12:49:02 UTC
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
Comment 27 Michel Alexandre Salim 2011-03-19 01:33:30 UTC
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
Comment 28 Michel Alexandre Salim 2011-08-18 10:49:36 UTC
(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 )
Comment 29 David Hedberg 2012-01-27 06:20:16 UTC
(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.

Note You need to log in before you can comment on or make changes to this bug.