Bug 13773 - Dell latitude E4300: sometimes the backlight doesn't come back on after resume
Dell latitude E4300: sometimes the backlight doesn't come back on after resume
Status: CLOSED INVALID
Product: ACPI
Classification: Unclassified
Component: Power-Sleep-Wake
All Linux
: P1 normal
Assigned To: Zhang Rui
:
Depends on:
Blocks: 7216
  Show dependency treegraph
 
Reported: 2009-07-14 22:44 UTC by Lucas Nussbaum
Modified: 2012-11-07 20:09 UTC (History)
8 users (show)

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


Attachments
Output from acpidump (137.05 KB, text/plain)
2010-02-02 20:14 UTC, Samuel Sieb
Details
Output from lspci -vxxx (27.82 KB, text/plain)
2010-02-02 20:15 UTC, Samuel Sieb
Details
My lspci (28.78 KB, text/plain)
2010-03-05 02:52 UTC, ethan.glasser.camp
Details
My acpidump (132.42 KB, text/plain)
2010-03-05 02:52 UTC, ethan.glasser.camp
Details

Description Lucas Nussbaum 2009-07-14 22:44:52 UTC
Hi,

suspend/resume to RAM works fine most of the time on my Dell Latitude E4300. However, sometimes (about 5% of the time), when coming back from suspend, the backlight stays off: the system works fine, but it's obviously difficult to read the screen.

* suspending with the lid open or closed doesn't make any difference, apparently (but it's random, so it's not easy to tell)

* when that happens, suspending/resuming again doesn't solve the problem: I have to shutdown the laptop to get my backlight back

* I've tried upgrading to the latest available BIOS, with no change

* I've asked colleagues who use the same laptop on windows, and they don't have the same problem

* X reports the video card as a:
(II) intel(0): Integrated Graphics Chipset: Intel(R) Mobile Intel® GM45 Express Chipset
(--) intel(0): Chipset: "Mobile Intel® GM45 Express Chipset"

Is there something I could try when that happens to debug that problem?
Comment 1 Rafael J. Wysocki 2009-07-15 02:33:45 UTC
Please try a newer kernel, preferably 2.6.31-rc3.
Comment 2 ykzhao 2009-07-21 07:02:04 UTC
Hi, Lucas
    Will you please attach the output of acpidump, lspci -vxxx?
    Will you please check whether there exists the backlight I/F under the /sys/class/backlight/*
    
Thanks.
Comment 3 Lucas Nussbaum 2009-07-21 13:48:08 UTC
Hi,

i'm currently trying 2.6.31-rc2 together with KMS, and so far, I haven't reproduced the problem. However, it has only been 5 days, so I can't say yet whether it really disappeared, or I've just been lucky (since it's random anyway).
Comment 4 ykzhao 2009-07-27 02:41:53 UTC
Hi, Lucas
    As it isn't reproduced on the 2.6.31-rc2 with KMS enabled, this bug will be rejected.
   If it can be reproduced again, please reopen it and attach the output of acpidump, lspci -vxxx.
   Thanks.
Comment 5 Samuel Sieb 2010-02-02 20:14:09 UTC
I'm using kernel 2.6.31.12-174.2.3.fc12.i686.PAE on Fedora and I see this.  I get the backlight back on by hibernating and resume.

There is a backlight interface in /sys.
Comment 6 Samuel Sieb 2010-02-02 20:14:50 UTC
Created attachment 24880 [details]
Output from acpidump
Comment 7 Samuel Sieb 2010-02-02 20:15:23 UTC
Created attachment 24881 [details]
Output from lspci -vxxx
Comment 8 ethan.glasser.camp 2010-03-05 02:51:18 UTC
I'm seeing this too -- just saw it on 2.6.31-19-generic (Kubuntu).
Comment 9 ethan.glasser.camp 2010-03-05 02:52:00 UTC
Created attachment 25361 [details]
My lspci

For good measure, my lspci output
Comment 10 ethan.glasser.camp 2010-03-05 02:52:53 UTC
Created attachment 25362 [details]
My acpidump
Comment 11 ethan.glasser.camp 2010-03-05 03:04:42 UTC
I lack the permission bits to reopen this bug. Can somebody else please do so?

Ethan
Comment 12 Lucas Nussbaum 2010-03-05 06:03:56 UTC
Reopening.

Also, I still seeing this, even if it is a rare event (one in 10 or 20 suspend/resume)
Comment 13 Rafael J. Wysocki 2010-03-05 19:47:42 UTC
Please try this patch: http://patchwork.kernel.org/patch/83479/
Comment 14 Zhang Rui 2010-03-16 06:14:57 UTC
ping Lucas...
Comment 15 Lucas Nussbaum 2010-03-17 22:06:48 UTC
I'm sorry, I'm very busy currently. Can this wait, or is my feedback blocking something?
Comment 16 Zhang Rui 2010-03-18 01:11:46 UTC
well. yes.
Once we look into one bug report, we want to fix it ASAP.
Because we don't want to read from comment #0 again to recall what the problem is, after no response from the bug reporter for a long time.

Usually, we'll reject a bug report if there is no response for more than a month.
But you can re-open it any time if you can provide the info required.

So you can test the patch whenever you're free, even if a month later, (just re-open it and attach the test result). :p
Comment 17 Lucas Nussbaum 2010-03-22 21:48:33 UTC
well, I was hoping that ethan.glasser.camp@gmail.com would test the patch. I actually reopened the bug because he said he was seeing it too.

Anyway, I'm now using the patch, and it works fine so far. It's difficult to say anything conclusive since it only failed about 5% of the time. Feel free to close the bug now, I'll reopen if I reproduce the problem with the patch.
Comment 18 ethan.glasser.camp 2010-03-22 22:01:52 UTC
Hi, sorry I haven't reported back. I had my E4300 stolen, and while a replacement machine is on its way, I haven't had access to one to test it. I will add a comment when I get another machine to play with.

Ethan
Comment 19 Zhang Rui 2010-03-23 01:50:43 UTC
okay. close this bug for now.

please re-open it if you can reproduce the problem in the latest upstream kernel.
Comment 20 Samuel Sieb 2010-06-09 00:00:10 UTC
Has this patch been integrated?  If so, into which version?
I'm using 2.6.33.5-112.fc13.i686.PAE and still see the problem.
Comment 21 Csaba Kertész 2010-07-30 08:19:36 UTC
I have the same problem with Ubuntu Lucid, kernel 2.6.32-24. I will test the mentioned patch, because I can see it is not integrated yet to my downstream kernel.

My observation that mainly the backlit does not come back after resume, if the laptop lid is closed before the suspend operation is not finished yet and the backlit is not switched off by the suspend operations.
Comment 22 Csaba Kertész 2010-07-30 08:22:51 UTC
Sorry for the spamming, but reading back my second section in my previous comment, it is a mess. Let's rewrite it:

"My observation that mainly the backlit does not come back after resume, if the
laptop lid is closed before the suspend is finished and the
backlit is not switched off by the suspend operations."

BTW, I will compile a kernel with the above mentioned patch and test it right now. :)
Comment 23 Csaba Kertész 2010-08-09 07:33:30 UTC
Unfortunately, the patch does not solve the problem. I got it yesterday again.

Can somebody re-open the bug? I can help in testing possible fixes.
Comment 24 Lucas Nussbaum 2010-08-15 19:22:13 UTC
Reopening based on the comment from Csaba Kertész who says he can reproduce the problem with the patch applied, and can help testing possible fixes.

I can also confirm that I'm still seeing that problem with Debian's 2.6.32 kernel. But that kernel doesn't include the above-mentioned patch, so that comment is of little value.

In other news, I tried Debian's 2.6.35 kernel, and the problem with E4300 suspend/resume got worse: now it sometimes fail to suspend (the screen gets all black but still with backlight, but the laptop doesn't suspend). I'm not opening another bug for now, as I wouldn't have time to test possible fixes.
Comment 25 Zhang Rui 2010-09-03 02:15:53 UTC
Hi, Csaba,

sorry for the late response.
will you please try the latest upstream kernel, say 2.6.35 and see if the problem still exists?
Comment 26 Csaba Kertész 2010-09-08 12:10:32 UTC
Ok, thanks!

I installed the 2.6.35-20-generic, upstream version of the kernel in my Ubuntu Lucid. I will let you know about the result of the testing, however, it can take some days/weeks, because it is not so easy to reproduce this problem...
Comment 27 Csaba Kertész 2010-09-08 12:11:33 UTC
Ok, thanks!

I installed the 2.6.35-20-generic, upstream version of the kernel in my Ubuntu Lucid. I will let you know about the result of the testing, however, it can take some days/weeks, because it is not so easy to reproduce this problem...
Comment 28 Samuel Sieb 2010-09-08 22:55:22 UTC
I still had this happen using 2.6.35.4-18.fc14.i686.PAE.
Comment 29 Zhang Rui 2010-09-27 03:06:18 UTC
Csaba and Samuel, what's the model name of your laptop?
I need to make sure you are seeing the same problem.

Lucas, it would be great if you can reproduce the problem in 2.6.35 or newer kernels.
Comment 30 Samuel Sieb 2010-09-27 03:43:21 UTC
It's a Dell Latitude E4300, can't find anything more specific than that.  I'm also seeing occasional hangs on suspend that Lucas mentioned, but that's for a different bug...
Comment 31 Csaba Kertész 2010-09-27 07:11:49 UTC
My model number is exactly the same (Latitude E4300). I tested the 2.6.35 downstream version from Ubuntu and I did not experienced this bug in the last two weeks, but it does not mean anything.

One potentially important thing: I use 64 bit of Ubuntu. My other colleagues with the same laptop do not have any problem with their machine, but they use 32 bit version of Ubuntu.

On the other hand, if somebody would explain a bit more, what can happen, than I could help more. I can compile kernel myself and I can devote a bit of time to hack it, but I am total unaware about this problem. What can be the root? How the backlit can not switch on back? What kind of software means do we have to try to switch on if it is off? E.g restarting the X server or switching between console and graphical mode does not solve the problem for me. The laptop must be restarted to get the backlit on.

Please share if you have any ideas how to start to reproduce/fix this.
Comment 32 Samuel Sieb 2010-09-27 14:29:45 UTC
I'm using the 32-bit kernel and seeing the problem.  Hibernating and resuming gets the screen back because to the hardware it's equivalent to a reboot.  One really strange thing I've noticed is that it seems to be location dependent.  There is one place that I resume that has a very high probability of not turning the screen on.  I'm wondering if there is some connection to the wireless card.  On the other hand I think it still didn't work with the kill switch set to off.  I will try to always resume with the wireless killed and see what happens.
Comment 33 Zhang Rui 2010-09-28 02:01:20 UTC
(In reply to comment #31)
> 
> On the other hand, if somebody would explain a bit more, what can happen, than
> I could help more. I can compile kernel myself and I can devote a bit of time
> to hack it, but I am total unaware about this problem. What can be the root?
> How the backlit can not switch on back?

usually, the graphics driver saves and restores the LCD status.
and this may happen if the graphics driver doesn't restore the status correctly.

> What kind of software means do we have
> to try to switch on if it is off?

as you're using intel graphics, cc jesse, who is an expert on this.

> E.g restarting the X server or switching
> between console and graphical mode does not solve the problem for me. The
> laptop must be restarted to get the backlit on.
> 
> Please share if you have any ideas how to start to reproduce/fix this.
Comment 34 Samuel Sieb 2010-10-06 17:01:18 UTC
Results of my testing.  I always used the kill switch to turn off the wireless before suspending and didn't turn it back on until after resuming.  In the many times I did this, it didn't once fail to turn the backlight on.  So it appears that there is some relation, however strange that may seem.
Comment 35 Csaba Kertész 2010-10-06 19:24:20 UTC
My status: after upgrading to the kernel 2.6.35 in Ubuntu Lucid, the laptop became very unstable. Sometimes it was frozen several times in a day. It is separate problem, however, it made almost impossible to use my laptop as it is. Now, I upgraded to Ubuntu Maverick, which is shipped with this kernel version officially. Also I disabled the Compiz today, which freezes randomly these days for me.

For me, the wireless was always on and the kill switch was switched off in the BIOS of the machine.

Let's see if the problem happens in the future.
Comment 36 Csaba Kertész 2010-10-21 20:20:54 UTC
I installed the newest kernel from here (http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/2010-10-18-maverick/), kinda 2.6.36:

My laptop became stable (suspend/resume and kwin work fine) again, but this bug happened again now!

I logged in to my laptop via ssh and I try to gather as much information as possible and can be useful:

ls /sys/class/backlight/acpi_video0
actual_brightness  brightness  max_brightness  subsystem
bl_power           device      power           uevent

cat /sys/class/backlight/acpi_video0/actual_brightness -> 15
cat /sys/class/backlight/acpi_video0/brightness -> 15
cat /sys/class/backlight/acpi_video0/max_brightness -> 15
cat /sys/class/backlight/acpi_video0/bl_power -> 0
cat /sys/class/backlight/acpi_video0/uevent -> EMPTY

I can write the bl_power node (without any effect) as root, but other nodes give permission denied.

Other subdirectories:

ls /sys/class/backlight/acpi_video0/power
control              runtime_status          wakeup
runtime_active_time  runtime_suspended_time  wakeup_count

cat /sys/class/backlight/acpi_video0/power/control -> auto
cat /sys/class/backlight/acpi_video0/power/runtime_active_time -> 0
cat /sys/class/backlight/acpi_video0/power/runtime_status -> unsupported
cat /sys/class/backlight/acpi_video0/power/runtime_suspended_time -> 0
cat /sys/class/backlight/acpi_video0/power/wakeup -> EMPTY
cat /sys/class/backlight/acpi_video0/power/wakeup_count -> 0

I do not know if it has any problem with this lines in the /var/log/kern.log when waking up from suspend:

...
Oct 21 20:54:12 kecsap-laptop kernel: [155979.680275] PM: Entering mem sleep
Oct 21 20:54:12 kecsap-laptop kernel: [155979.680291] Suspending console(s) (use no_console_suspend to debug)
Oct 21 20:54:12 kecsap-laptop kernel: [155979.680886] sd 0:0:0:0: [sda] Synchronizing SCSI cache
Oct 21 20:54:12 kecsap-laptop kernel: [155979.682713] btusb_intr_complete: hci0 urb ffff8800735443c0 failed to resubmit (1)
Oct 21 20:54:12 kecsap-laptop kernel: [155979.683711] btusb_bulk_complete: hci0 urb ffff880073544c00 failed to resubmit (1)
Oct 21 20:54:12 kecsap-laptop kernel: [155979.684710] btusb_bulk_complete: hci0 urb ffff880073544300 failed to resubmit (1)
Oct 21 20:54:12 kecsap-laptop kernel: [155979.731160] ACPI handle has no context!
Oct 21 20:54:12 kecsap-laptop kernel: [155979.731171] sdhci-pci 0000:02:01.1: PCI INT B disabled
Oct 21 20:54:12 kecsap-laptop kernel: [155979.731182] ACPI handle has no context!
Oct 21 20:54:12 kecsap-laptop kernel: [155979.731301] ehci_hcd 0000:00:1d.7: PCI INT A disabled
Oct 21 20:54:12 kecsap-laptop kernel: [155979.731319] uhci_hcd 0000:00:1d.2: PCI INT C disabled
Oct 21 20:54:12 kecsap-laptop kernel: [155979.731327] uhci_hcd 0000:00:1d.1: PCI INT B disabled
...
Oct 21 20:54:12 kecsap-laptop kernel: [155980.964363] sdhci-pci 0000:02:01.1: restoring config space at offset 0xf (was 0x200
Oct 21 20:54:12 kecsap-laptop kernel: [155980.964408] sdhci-pci 0000:02:01.1: restoring config space at offset 0x4 (was 0x0,
Oct 21 20:54:12 kecsap-laptop kernel: [155980.964422] sdhci-pci 0000:02:01.1: restoring config space at offset 0x3 (was 0x800
Oct 21 20:54:12 kecsap-laptop kernel: [155980.964442] sdhci-pci 0000:02:01.1: restoring config space at offset 0x1 (was 0x210
Oct 21 20:54:12 kecsap-laptop kernel: [155980.964583] PM: early resume of devices complete after 3.162 msecs
Oct 21 20:54:12 kecsap-laptop kernel: [155980.964922] i915 0000:00:02.0: setting latency timer to 64
Oct 21 20:54:12 kecsap-laptop kernel: [155980.984180]  pci0000:00: wake-up capability disabled by ACPI
Oct 21 20:54:12 kecsap-laptop kernel: [155980.984197] e1000e 0000:00:19.0: PME# disabled
Oct 21 20:54:12 kecsap-laptop kernel: [155980.984366] e1000e 0000:00:19.0: irq 40 for MSI/MSI-X
Oct 21 20:54:12 kecsap-laptop kernel: [155980.986628] uhci_hcd 0000:00:1a.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
...

cat /proc/acpi/video/VID/LCD/state
state:     0x0d
query:     0x00

echo 100 > /proc/acpi/video/VID/LCD/brightness

cat /proc/acpi/video/VID/LCD/brightness
levels:  0 6 13 20 26 33 40 46 53 60 66 73 80 86 93 100
current: 100

But nothing changed.

Also I see in the /var/log messages:

...
Oct 18 09:04:31 kecsap-laptop kernel: [    4.508144] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/LNXVIDEO:00/input/input6
Oct 18 09:04:31 kecsap-laptop kernel: [    4.508222] ACPI: Video Device [VID] (multi-head: yes  rom: no  post: no)
Oct 18 09:04:31 kecsap-laptop kernel: [    4.508265] [Firmware Bug]: Duplicate ACPI video bus devices for the same VGA controller, please try module paramete
r "video.allow_duplicates=1"if the current driver doesn't work.
Oct 18 09:04:31 kecsap-laptop kernel: [    4.508465] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0
....
Comment 37 Samuel Sieb 2010-10-21 20:28:51 UTC
If that version fixes the suspend stability issues, I'll have to try it out.

Can you try my workaround and see if it works for you?  Set the wireless kill switch to off before suspending and don't switch it back on until after resume.  See if you still get the backlight problem.  I haven't had it happen since following that procedure.
Comment 38 Csaba Kertész 2010-10-21 20:50:43 UTC
a bit off-topic:
Hi Samuel,

with the 2.6.35, ~ every 3rd suspend attempt was frozen and the compiz or kwin also was frozen ~ once in a day. It was very annoying, after Ubuntu 9.10 (Karmic), my machine become more and more unstable because of the kernel and Xorg.

But now, this backlight problem is the last one currently to have a perfect Linux laptop.

relevant to the bug:

Recently, I re-enabled the wlan kill switch and I keep the wlan off if possible. That is right, the current problem happened when suspending with enabled wlan. However, it does not seem to me too much sense, that the enabled wlan would prevent the backlight to come back sometimes... but I am not a kernel developer or hw engineer. :)
Comment 39 Samuel Sieb 2010-10-21 20:55:47 UTC
With .34, I get occasional suspend hangs, when I tried .35 it was more often.

It's good to hear that the kill switch workaround works for you too.  I agree it's very strange, I was somewhat reluctant to suggest it except that it really seemed to work.  There appears to be some interaction, the question is whether it is hardware or software or both.
Comment 40 Csaba Kertész 2010-10-21 21:45:55 UTC
With an unofficial .35 kernel for Ubuntu Lucid, I had occasional suspend hangs, but with the latest Ubuntu Maverick+.35, the suspend hangs happened every 3rd/4th times.

I would not like to say that your workaround worked for me at this point. I use this stable kernel a few days ago and the backlight problem happened once. It is not a significant result yet.
Comment 41 Zhang Rui 2010-10-22 00:13:41 UTC
does module parameter "video.allow_duplicates=1" help?
Comment 42 Csaba Kertész 2010-10-23 10:48:10 UTC
Hi

unfortunately, the module parameter "video.allow_duplicates=1" did not help, I have just restarted my laptop after the backlight did not come back. :( (But I left the wlan rfkill switch on purposely.)

Now, I will test further with wlan rfkill switched off when going to suspend always.
Comment 43 Csaba Kertész 2010-11-29 10:27:59 UTC
The rfkill switch works for me as a workaround of this bug.
Comment 44 Zhang Rui 2010-12-27 01:12:35 UTC
is the rfkill workaround still needed in the latest upstream kernel, say 2.6.37-rc7?
Comment 45 Samuel Sieb 2011-01-01 19:12:40 UTC
I had it happen again with 2.6.37-rc7.
Comment 46 Csaba Kertész 2011-01-03 13:27:32 UTC
a bit off-topic again:

I disabled the second core of my CPU and my laptop is not frozen any more. Earlier, I had 1-2 freezes/week.

Probably, it does not have too much relevance to the bug report, but who knows...
Comment 47 Csaba Kertész 2011-01-12 15:31:25 UTC
Today, the bug appeared again using the rfkill workaround. :(

So the workaround works ~99.99 % of the cases.
Comment 48 Samuel Sieb 2011-01-13 07:16:03 UTC
It's true.  The workaround works most of the time, but not always.  I'm wondering if the backlight is turned on by the BIOS or the kernel.  Anyone know?
Comment 49 Samuel Sieb 2011-03-04 16:11:09 UTC
Good news!  Since using kernel-PAE-2.6.38-0.rc5.git1.1 and kernel-PAE-2.6.38-0.rc6.git0.1, the backlight has so far always come on when resuming.  I haven't been using the rfkill workaround either.
Comment 50 Csaba Kertész 2011-06-06 15:30:14 UTC
Unfortunately, there is regression again. I upgraded to Ubuntu Natty and this backlit problem has not happened with the original kernel shipped with Natty (2.6.38-8-generic-pae), however, there is an unoffical kernel version from the Ubuntu Kernel team (v2.6.39-rc4):

http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.39-rc4-natty/

With this kernel version, even the "rfkill-switch workaround" does not help, the backlit does not came back after about every third-fourth resume.

:(

Uff.
Comment 51 Zhang Rui 2012-01-18 01:51:50 UTC
It's great that kernel bugzilla is back.

can you please verify if the problem still exists in the latest upstream
kernel?
Comment 52 Samuel Sieb 2012-01-18 02:20:07 UTC
I'm currently on 3.1.9 from Fedora 16.  I haven't had any issues for a very long time.  I just need to remember to give the laptop a few seconds to fully suspend before closing the lid.  A couple of times I rushed it and the backlight didn't come back on.  But every time I give it the few seconds, it always comes back on.
Comment 53 Zhang Rui 2012-05-24 07:21:29 UTC
so I will close this bug.
please feel free to reopen it if you still think this is a problem.
Comment 54 Samuel Sieb 2012-05-24 07:38:05 UTC
Why INVALID?  It was a real problem, but since then kernel changes have made it less of one.
Comment 55 Samuel Sieb 2012-09-01 05:11:29 UTC
It still happens occasionally, but I am not able to reopen this bug.  I'm currently on 3.4.9  I wouldn't be surprised if there's a bios issue involved as well, but if there's anything I can do to help track it down, please let me know.
Comment 56 Samuel Sieb 2012-11-07 20:09:58 UTC
The latest results on this were that the backlight would always be off if I resumed after undocking it.  However, shortly after that started happening, I received a new laptop so this issue is fortunately irrelevant to me now.

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