Bug 13773

Please try a newer kernel, preferably 2.6.31-rc3.

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.

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).

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.

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.

Created attachment 24880 [details]
Output from acpidump

Created attachment 24881 [details]
Output from lspci -vxxx

I'm seeing this too -- just saw it on 2.6.31-19-generic (Kubuntu).

Created attachment 25361 [details]
My lspci

For good measure, my lspci output

Created attachment 25362 [details]
My acpidump

I lack the permission bits to reopen this bug. Can somebody else please do so?

Ethan

Reopening.

Also, I still seeing this, even if it is a rare event (one in 10 or 20 suspend/resume)

Please try this patch: http://patchwork.kernel.org/patch/83479/

ping Lucas...

I'm sorry, I'm very busy currently. Can this wait, or is my feedback blocking something?

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

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.

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

okay. close this bug for now.

please re-open it if you can reproduce the problem in the latest upstream kernel.

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.

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.

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. :)

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.

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.

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?

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...

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...

I still had this happen using 2.6.35.4-18.fc14.i686.PAE.

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.

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...

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.

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.

(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.

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.

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.

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
....

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.

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. :)

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.

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.

does module parameter "video.allow_duplicates=1" help?

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.

The rfkill switch works for me as a workaround of this bug.

is the rfkill workaround still needed in the latest upstream kernel, say 2.6.37-rc7?

I had it happen again with 2.6.37-rc7.

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...

Today, the bug appeared again using the rfkill workaround. :(

So the workaround works ~99.99 % of the cases.

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?

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.

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.

It's great that kernel bugzilla is back.

can you please verify if the problem still exists in the latest upstream
kernel?

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.

so I will close this bug.
please feel free to reopen it if you still think this is a problem.

Why INVALID?  It was a real problem, but since then kernel changes have made it less of one.

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.

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.