Bug 14722 - closing and re-opening the lid does not reactivate the backlight
closing and re-opening the lid does not reactivate the backlight
Status: CLOSED CODE_FIX
Product: Drivers
Classification: Unclassified
Component: Video(DRI - Intel)
All Linux
: P1 normal
Assigned To: drivers_video-dri-intel@kernel-bugs.osdl.org
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-12-03 09:55 UTC by Norbert Preining
Modified: 2010-01-13 21:51 UTC (History)
5 users (show)

See Also:
Kernel Version: 2.6.32
Tree: Mainline
Regression: No


Attachments
Patch for lid/lvds against 2.6.32.2 (1.23 KB, patch)
2009-12-28 17:29 UTC, Norbert Preining
Details | Diff

Description Norbert Preining 2009-12-03 09:55:28 UTC
Dear all,

laptop: sony vaio z11
linux 2.6.32
intel graphics card
Debian/unstable up2date
xserver-xorg-video-intel 2.9.1-1
xserver-xorg 7.4-4
KMS enabled in the kernel config file

I was suspecting a problem with suspend, but that actually works when simply calling s2ram -f. But when I close the lid the screen turns black and when I open the lid again it remains black as the night.

I can switch to the console and reboot, but that is suboptimal.

I managed to get backlight back by switching to the console, logging in as root, and calling s2ram -f.

As far as I see in my log file there was:
[  276.793746] [drm] LVDS-8: set mode 1600x900 d
which was when I closed the lid.

After opening nothing happened. I switched to console and called s2ram -f which left another
[  304.672948] [drm] LVDS-8: set mode 1600x900 d
in the syslog and continued with the normal suspend messages

Any idea or suggestions what else I should provide on information?

The tests were run with gnome-power-manager *and* acpid killed (not running), so no scripts or whatsoever should interfere.

All the best

Norbert
Comment 1 Norbert Preining 2009-12-09 15:36:21 UTC
Ok, here are more details. I found out that this happens only with specific X sessions. GNOME session and KDE is bad, twm/lxsession is good.

Further testing revealed that it is KMS related:
2.6.31.5 without KMS works (backlight is back on)
2.6.32 (same kernel) booted with nomodeset works, too!
2.6.32 with mode setting does not work

There is also a bug report in Debian, where I suspected it one of the programs, but it seems unlikely, Debian bug #560158

Hope that one here can at least give a suggestion.

Best

Norbert
Comment 2 ykzhao 2009-12-28 15:52:16 UTC
Hi, Norbert
    Will you please try the following patch on the 2.6.32 kernel and see whether the issue still exists?
    >http://lists.freedesktop.org/archives/intel-gfx/2009-December/005143.html

Thanks.
Comment 3 Norbert Preining 2009-12-28 17:28:21 UTC
(In reply to comment #2)
>     Will you please try the following patch on the 2.6.32 kernel and see
> whether the issue still exists?

Bingo, that patch did the trick. Well, I couldn't apply to to 2.6.32, it didn't apply, but I patched it into the kernel 2.6.32.2 (attached in the next comment) and it worked fine.

Thanks a lot

Norbert
Comment 4 Norbert Preining 2009-12-28 17:29:24 UTC
Created attachment 24329 [details]
Patch for lid/lvds against 2.6.32.2
Comment 5 o. meijer 2009-12-31 13:02:57 UTC
Dear experts,

I have a similar problem with my laptop: The bug does not occur with kernel 2.6.31.9 KMS enabled.

hardware: laptop Compaq 62720S
lspci: 
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)

00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)

OS ubuntu 9.10
kernel 2.6.32.2 KMS enabled
Driver xserver-xorg-video-intel 2:2.9.0-ubuntu2
Xorg 1:7.4+3ubuntu10


Gnome-power-manager settings Suspend when closing lid works fine, on resume the back-light is turned on

Gnome-power-manager settings Blank Screen when closing lid leaves the back-light off after reopening the lid.

Key-combination <control Alt F2> followed by <control Alt F7> turns the backlight on again. (with an error-message of OSD “Could not switch the monitor configuration Could not set the configuration for CRCT 58”

Applying the patch mentioned in this bug report does not solve it.


Dmesg with patch applied, after reopening:

[   86.309548] [drm] TV-14: set mode NTSC 480i 0

[   86.701531] [drm] TV-14: set mode NTSC 480i 0

[   92.561859] [drm] TV-14: set mode NTSC 480i 0

[   92.741765] [drm] TV-14: set mode NTSC 480i 0

[   93.912065] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung

[   93.912087] render error detected, EIR: 0x00000000

[   93.912093] i915: Waking up sleeping processes

[   93.912171] [drm:i915_wait_request] *ERROR* i915_wait_request returns -5 (awaiting 8163 at 8157)

[   94.848086] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung

[   94.848098] render error detected, EIR: 0x00000000

[   94.848103] i915: Waking up sleeping processes

[   94.848151] [drm:i915_wait_request] *ERROR* i915_wait_request returns -5 (awaiting 8216 at 8211)

[   95.772068] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung

[   95.772079] render error detected, EIR: 0x00000000

[   95.772084] i915: Waking up sleeping processes

[   95.772127] [drm:i915_wait_request] *ERROR* i915_wait_request returns -5 (awaiting 8224 at 8219)

[   96.697063] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung

[   96.697074] render error detected, EIR: 0x00000000

[   96.697078] i915: Waking up sleeping processes

[   96.697116] [drm:i915_wait_request] *ERROR* i915_wait_request returns -5 (awaiting 8232 at 8227)

[   97.616091] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung

[   97.616102] render error detected, EIR: 0x00000000

[   97.616107] i915: Waking up sleeping processes

[   97.616208] [drm:i915_wait_request] *ERROR* i915_wait_request returns -5 (awaiting 8238 at 8233)

[   97.616984] [drm:i915_gem_execbuffer] *ERROR* Execbuf while wedged

[   97.617306] [drm:i915_gem_execbuffer] *ERROR* Execbuf while wedged

[  100.842346] [drm] LVDS-8: set mode 1280x800 1d


Dmesg without patch applied, after reopening:

[   62.301282] [drm] TV-14: set mode NTSC 480i 0

[   80.718217] [drm] TV-14: set mode NTSC 480i 0

[   80.898149] [drm] TV-14: set mode NTSC 480i 0

[   82.044081] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung

[   82.044098] render error detected, EIR: 0x00000000

[   82.044103] i915: Waking up sleeping processes

[   82.044130] [drm:i915_wait_request] *ERROR* i915_wait_request returns -5 (awaiting 6924 at 6920)

[   82.964084] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung

[   82.964095] render error detected, EIR: 0x00000000

[   82.964101] i915: Waking up sleeping processes

[   82.964187] [drm:i915_wait_request] *ERROR* i915_wait_request returns -5 (awaiting 6937 at 6929)

[   82.964338] [drm:i915_gem_execbuffer] *ERROR* Execbuf while wedged

[   82.964573] [drm:i915_gem_execbuffer] *ERROR* Execbuf while wedged

[   82.965279] [drm:i915_gem_execbuffer] *ERROR* Execbuf while wedged

[   83.888064] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung

[   83.888076] render error detected, EIR: 0x00000000

[   83.888081] i915: Waking up sleeping processes

[   83.888125] [drm:i915_wait_request] *ERROR* i915_wait_request returns -5 (awaiting 6959 at 6947)

[   84.516065] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung

[   84.516076] render error detected, EIR: 0x00000000

[   84.516081] i915: Waking up sleeping processes

[   84.516347] [drm:i915_wait_request] *ERROR* i915_wait_request returns -5 (awaiting 6976 at 6964)

[   85.436075] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung

[   85.436085] render error detected, EIR: 0x00000000

[   85.436091] i915: Waking up sleeping processes

[   85.436115] [drm:i915_wait_request] *ERROR* i915_wait_request returns -5 (awaiting 6991 at 6987)

[   85.842339] [drm] LVDS-8: set mode 1280x800 1d

Kind regards,

Otto
Comment 6 ykzhao 2010-01-02 13:56:43 UTC
Hi, Meijor
    It seems that you have a differen bug. Will you please open a new bug?Please boot the system with the boot option of "drm.debug=0x06" attach the following output
    1. Xorg.0.log
    2. the output of dmesg after adding the boot option of "drm.debug=0x06". The output of dmesg after close and reopen the LID
    3. acpidump (The pmtools-2007116 dump tool can be found in http://www.lesswatts.org/projects/acpi/utilities.php)

It will be great if you can boot the system with "nomodeset" and do the following test.
    a. kill the process using the /proc/acpi/event( use the command of "lsof /proc/acpi/event" to get the process ID)
    b. cat /proc/acpi/event >lid_result
    c. close and reopen the LID several times
    d. press "ctrl + c" and attach the output of lid_result.

Thanks.
Comment 7 o. meijer 2010-01-06 15:42:14 UTC
I reported a new bug
http://bugzilla.kernel.org/show_bug.cgi?id=14997
Comment 8 Rafael J. Wysocki 2010-01-13 21:51:05 UTC
Fixed by commit a2565377a5c31e25c77c7cabaf6752abe9a2d83a .

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