Bug 43168
Summary: | Brightness unchangeable Toshiba Satellite C660D-10P | ||
---|---|---|---|
Product: | ACPI | Reporter: | fireandfuel |
Component: | Power-Video | Assignee: | Zhang Rui (rui.zhang) |
Status: | CLOSED CODE_FIX | ||
Severity: | normal | CC: | decathorpe, emil.l.velikov, florian, kernel, lamarque, lenb, linux, rui.zhang, stefanhetzwaantje, stratovarius_tt, tiziano |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://bugs.launchpad.net/ubuntu/+source/linux/+bug/989634 | ||
Kernel Version: | 3.2.0-24-generic | Subsystem: | |
Regression: | Yes | Bisected commit-id: | |
Attachments: |
acpi dump (as text)
PATCH to check why ACPI video probing fails complete dmesg log after applying patch Patch: still use ACPI backlight control if _DOS doesn't exist do not evaluate _DOS for platforms that do not have it |
Description
fireandfuel
2012-04-27 19:29:00 UTC
> 3.0.0-17-generic works
> 3.2.0-24-generic fails
so if you just restore the working kernel
without making any other changes to the system,
then this works again?
Can you reproduce this with an upstream kernel?
If yes, can you bisect where this broke?
(In reply to comment #1) > > 3.0.0-17-generic works > > 3.2.0-24-generic fails > > so if you just restore the working kernel > without making any other changes to the system, > then this works again? I have installed both kernels on my system; I simply start 3.0.0-17-generic kernel without other changes and brightness change works. > Can you reproduce this with an upstream kernel? > If yes, can you bisect where this broke? I already reproduced this bug with upstream kernel 3.4-rc4, but I don't know how to bisect where this broke. could you please attach the acpidump output of your laptop? could you please verify if this is a duplicate of bug 43221? Say, does reverting commit ea9f8856bd6d4ed45885b06a338f7362cd6c60e5 help? Created attachment 73236 [details]
acpi dump (as text)
(In reply to comment #3) > could you please verify if this is a duplicate of bug 43221? > Say, does reverting commit ea9f8856bd6d4ed45885b06a338f7362cd6c60e5 help? That's the first time I have to build a kernel. I need some time to learn the kernel configuration & build basics. Hopefully I can tell you at weekend whether reverting commit ea9f8856bd6d4ed45885b06a338f7362cd6c60e5 helps. (In reply to comment #3) > could you please verify if this is a duplicate of bug 43221? > Say, does reverting commit ea9f8856bd6d4ed45885b06a338f7362cd6c60e5 help? Yes, it helps (after 3 hours waiting for the kernel and modules to compile); backlight control is working after reverting commit ea9f8856bd6d4ed45885b06a338f7362cd6c60e5. So it looks like this bug is a duplicate of bug 43221. *** Bug 43221 has been marked as a duplicate of this bug. *** Created attachment 73359 [details]
PATCH to check why ACPI video probing fails
please apply this patch on top of the latest upstream kernel and attach the dmesg output after boot.
Created attachment 73371 [details]
complete dmesg log after applying patch
Backlight control works on Linux 3.4.0 within a running x.org server, but not on ttys.
I'm confused. (In reply to comment #9) > Backlight control works on Linux 3.4.0 within a running x.org server, but not > on ttys. is this true in 3.2 kernel? ls /sys/class/backlight, do you see the same thing in 3.0, 3.2 and 3.4 kernel? (In reply to comment #10) > I'm confused. > > (In reply to comment #9) > > Backlight control works on Linux 3.4.0 within a running x.org server, but > not > > on ttys. > > is this true in 3.2 kernel? No. Backlight control completely doesn't work in 3.2. > ls /sys/class/backlight, do you see the same thing in 3.0, 3.2 and 3.4 > kernel? /sys/class/backlight folder is different in the 3 kernel versions. 3.4 & 3.2: acpi_video0 -> ../../devices/pci0000:00/0000:00:01.0/0000:01:05.0/backlight/acpi_video0 toshiba -> ../../devices/LNXSYSTM:00/device:00/TOS1900:00/backlight/toshiba 3.0: acpi_video0 -> ../../devices/pci0000:00/0000:00:01.0/0000:01:05.0/backlight/acpi_video0 I can confirm this bug, as I experience the exact same problem. The same commit also appears to be what caused the problem. I applied the patch from #8, and these are the messages I got: [ 1.220528] Video Debug: acpi_video_bus_start_devices failed [ 1.220822] video: probe of LNXVIDEO:01 failed with error -5 If useful, please let know if I should attach the output of acpidump and/or whatever else you may need. (In reply to comment #12) > I can confirm this bug, as I experience the exact same problem. The same > commit > also appears to be what caused the problem. > > I applied the patch from #8, and these are the messages I got: > > [ 1.220528] Video Debug: acpi_video_bus_start_devices failed > [ 1.220822] video: probe of LNXVIDEO:01 failed with error -5 > > If useful, please let know if I should attach the output of acpidump and/or > whatever else you may need. My apologies, I missed a line from the dmesg output. Here are the three that appear to be directly related: [ 1.220394] Video Debug: Failed to evaluate _DOS [ 1.220528] Video Debug: acpi_video_bus_start_devices failed [ 1.220822] video: probe of LNXVIDEO:01 failed with error -5 *** Bug 43310 has been marked as a duplicate of this bug. *** Created attachment 73576 [details]
Patch: still use ACPI backlight control if _DOS doesn't exist
Hi, guys,
please make sure the patch attached fixes the problem for you, without reverting commit ea9f8856bd6d4ed45885b06a338f7362cd6c60e5
I applied the supplied patch to the mainline kernel and brightness controls work just fine again. I confirm that the patch in comment #15 fixes this problem in my notebook (Sager np7652, ATI HD4570) with kernel 3.4.2. I updated my system to kernel 3.4 and applied the patch in comment #15 and everything works fine again. @Zhang Rui: Is it possible to port this patch back to kernel 3.2 and 3.3? (In reply to comment #15) > Created an attachment (id=73576) [details] > Patch: still use ACPI backlight control if _DOS doesn't exist > > Hi, guys, > please make sure the patch attached fixes the problem for you, without > reverting commit ea9f8856bd6d4ed45885b06a338f7362cd6c60e5 This patch does indeed fix my problem, with no visible side-effects. Thank you. The (In reply to comment #15) > Created an attachment (id=73576) [details] > Patch: still use ACPI backlight control if _DOS doesn't exist > > Hi, guys, > please make sure the patch attached fixes the problem for you, without > reverting commit ea9f8856bd6d4ed45885b06a338f7362cd6c60e5 The patch restores backlight control for my Sony VAIO VPC-E, too. It fixes the bug when using kernel 3.5rc2 as well. *** Bug 43581 has been marked as a duplicate of this bug. *** Zhang Rui The patch does not appear to be present in 3.4 or master branch. Can you please confirm if it's queued up. Thanks The original reporter The patch that caused the regression (ea9f885) was introduced during the 3.4 development cycle. Therefore you are experiencing another bug with the 3.2 kernel, consider opening another bug about it Regards Emil Created attachment 74281 [details]
do not evaluate _DOS for platforms that do not have it
Hi, guys,
could you please test this patch and see if it works as well?
I think this one is better and I hope to push it upstream ASAP.
I applied the patch against mainline kernel git and it works just fine. > I applied the patch against mainline kernel git and it works just fine.
The new patch works for me, too.
It works in my notebook too. Rui, Is it possible that Windows compatibility w/ the ACPI video driver varies with windows _OSI level? In any case, this patch addresses the regression, and is applied. A patch referencing this bug report has been merged in Linux v3.5-rc5: commit b03738430c7537d5f87948e0b35d8aaf2688c6b4 Author: Zhang Rui <rui.zhang@intel.com> Date: Wed Jun 20 09:48:43 2012 +0800 ACPI video: Still use ACPI backlight control if _DOS doesn't exist |