When I want to change the backlight level, I use the command: echo -n [level] > /sys/class/backlight/acpi_video0/brightness But the actual backlight level often does not change, if I run this command several times, it will works, but only after a certain time (so 10 times the commands in 3 seconds does not work better than 4 in 3 seconds) Reading the 'actual_brightness' can sometimes change the actual brightness (according to the last value written in 'brightness'). Expecting result: the actual real backlight level change when writting to '/sys/class/backlight/acpi_video0/brightness' This bug can cause the kernel to disable backlight management when it check if the _BQC acpi method return an index (2 to 13 or something like that) or a level (0 to 100). When this bug occur at boot time, the kernel do that: set the backlight level to max, ie 100 get the backlight level, at this time, the real backlight level can change to the lowest level (for me it's 30) and the function that retrieve the result of the _BQC method return 30. The kernel compare levels and as 30 != 100, assume the returned value is an index. Then the kernel tries to set the level to a invalid value and cause the backlight management to be disabled. When the backlight management is disabled, there is nothing in the /sys/class/backlight folder. The code doing that is in drivers/acpi/video.c when executing: result = acpi_video_device_lcd_set_level(device, max_level); [...] result = acpi_video_device_lcd_get_level_current(device, &level, 0); [...] br->flags._BQC_use_index = (level == max_level ? 0 : 1); [...] level = br->levels[level_old]; <-- at this time, level_old is not in the range of the array as it's > 30, thus reading an invalid value (but does not crash) I tested several kernel version and discovered that this bug occur at least since kernel version 2.6.38. Kernel 2.6.34.14 works fine, the backlight is working as expected. 2.6.35 and 2.6.37.6 is hanging at boot, when populating /dev. 3.7 does not work, same problem as stated here. When the kernel 2.6.35 or 2.6.37.6 is hanging, after some times (or because I pressed the power button ?), udev tries to kill modprobe processes (but can't). ACPI is mentionned in something like 'ACPI0001'. This hang already occured for the newer kernel (>2.6.38) but I can't at this time say if it's from the same cause.
Created attachment 93871 [details] kern.log boot messages with _BCM error This is boot messages when the backlight management is disabled and so /sys/class/backlight folder is empty
Created attachment 93881 [details] dmesg with added debug output all added debug output messages begin with "ACPI: Debug_Custom" and tell what function is called about lcd backlight. acpi_video_init_brightness(), level[....]=... tell the available levels acpi_video_device_lcd_get_level_current()=... tell the return value of function acpi_video_device_lcd_get_level_current acpi_video_device_lcd_set_level(...) tell the function call 'level' argument used to change the backlight level acpi_video_init_brightness(), set_max_level and get_max_level are when the acpi_video_init_brightness function checks if _BQC return an index
Created attachment 93891 [details] dmesg output with custom and acpi debug Custom debug begin with "ACPI: Debug_Custom:" and are the same messages as in attachement id 93881 "dmesg with added debug output" The kernel was boot with these debug parameters: acpi.debug_level=0xFFF acpi.debug_layer=0x80
Created attachment 93901 [details] debug output when changing backlight from level 5 to 10, #1 This is only the dmesg ouput after that: dmesg -C #clear kernel log buffer echo -n 10 > /sys/class/backlight/acpi_video0/backlight dmesg > dmesg_lv5_to_10_bugged Before that, I executed "echo -n 5 > /sys/class/backlight/acpi_video0/backlight" until it really works and actual_brightness was 5. This is the result of the first execution of "echo -n 10 > /sys/class/backlight/acpi_video0/backlight" which did not change the real backlight level. (Only acpi debug output)
Created attachment 93911 [details] debug output when changing backlight from level 5 to 10, #2 This is only the dmesg ouput after that: dmesg -C #clear kernel log buffer echo -n 10 > /sys/class/backlight/acpi_video0/backlight dmesg > dmesg_lv5_to_10_bugged2 There is no command executed between this and the attachment "93901: debug output when changing backlight from level 5 to 10, #1" This is the result of the first execution of "echo -n 10 > /sys/class/backlight/acpi_video0/backlight" which did not change the real backlight level. (Only acpi debug output)
Created attachment 93921 [details] debug output when changing backlight from level 5 to 10, #3: backlight level really changed This is only the dmesg ouput after that: dmesg -C #clear kernel log buffer echo -n 10 > /sys/class/backlight/acpi_video0/backlight dmesg > dmesg_lv5_to_10_ok There is no command executed between this and the attachment "93911: debug output when changing backlight from level 5 to 10, #2" This is the result of the third execution of "echo -n 10 > /sys/class/backlight/acpi_video0/backlight" which changed the real backlight level. (Only acpi debug output)
Comment #5 (https://bugzilla.kernel.org/show_bug.cgi?id=54261#c5) has an error: >This is the result of the first execution of "echo -n 10 > /sys/class/backlight/acpi_video0/backlight" which did not change the real backlight level. This is the second execution of this command.
Created attachment 93931 [details] DSDT.dsl
Looks like the _BQC control method doesn't behave correctly: it should return 100 but returned 30, and cause acpi video driver thinks the _BQC uses index instead of value, and when set level it will use 30 as index and get a crazy level value. I don't see there is any code logic change for acpi video driver in 2.6.34 compared with the current mainline kernel, perhaps some ACPICA change made the _BQC control method fail. Can you please attach a similar dmesg as comment #2 for 2.6.34? Thanks.
Created attachment 94771 [details] Kernel 2.6.34.14: dmesg output when hanging at boot (right after /dev population) Kernel 2.6.34.14 was sometimes hanging at boot. After some time, udevd outputs some messages: udevd[number]: timeout : killing '/sbin/modprobe -b acpi:HPQ0004' [number] udevd[number]: timeout : killing '/sbin/modprobe -b wmi:<guid number>' [number] and after, linux continue to boot ignoring these errors. So I was able to start single user mode and ouput dmesg buffer. This buffer size is 138MB uncompressed with full acpi debug output and added message (all beginning with "Debug_Custom")
Created attachment 94781 [details] Kernel 2.6.34.14: dmesg output with custom debug info only (normal boot, no hang) All custom debug lines begin with "Debug_Custom" ACPI debug is disabled here
Created attachment 94791 [details] Kernel 2.6.34.14: dmesg output when changing brightness level to 5 This is the output of: "dmesg -C && echo -n 5 > /sys/class/backlight/acpi_video0/brightness && dmesg" ACPI debug is disabled here
Created attachment 94801 [details] Kernel 2.6.34.14: dmesg output when changing brightness level to 10 (from 5) This is the output of: "dmesg -C && echo -n 10 > /sys/class/backlight/acpi_video0/brightness && dmesg" ACPI debug is disabled here This command was done after attachement #94791. #94791 was done before #94781 Note about the kernel 2.6.34.14 hang: the hang occured one time before these bightness level changes commands, rebooting "fixed" the issue. So attachement #94771 is the output of dmesg at boot when the hang occured, after having done other attachements about kernel 2.6.34.14
Created attachment 94811 [details] Kernel 2.6.34.14: dmesg output when changing brightness level from 10 to 5 with full acpi debug This is the output of: "dmesg -C && echo -n 5 > /sys/class/backlight/acpi_video0/brightness && dmesg" ACPI debug is enabled here This command was done after the one for attachement #94801
Created attachment 94821 [details] Kernel 2.6.34.14: dmesg output when changing brightness level from 5 to 10 with full acpi debug This is the output of: "dmesg -C && echo -n 10 > /sys/class/backlight/acpi_video0/brightness && dmesg" ACPI debug is enabled here This command was done after attachment #94811 [details]
Dmesg output about disconnected usb device should be ignored (as some messages have been included in some attachments) All these messages like this should be ignored: [ 262.647468] usb 2-1: USB disconnect, address 5 [ 264.204064] usb 2-1: new low speed USB device using ohci_hcd and address 6 [ 264.373150] usb 2-1: New USB device found, idVendor=045e, idProduct=00cb [ 264.373159] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 264.373166] usb 2-1: Product: Microsoft Basic Optical Mouse v2.0 [ 264.373172] usb 2-1: Manufacturer: Microsoft [ 264.383790] input: Microsoft Microsoft Basic Optical Mouse v2.0 as /devices/pci0000:00/0000:00:12.0/usb2/2-1/2-1:1.0/input/input16 [ 264.384051] generic-usb 0003:045E:00CB.0005: input,hidraw0: USB HID v1.11 Mouse [Microsoft Microsoft Basic Optical Mouse v2.0 ] on usb-0000:00:12.0-1/input0 The backlight bug occurs even if the mouse that cause these messages is really not connected
About the hang that occurs sometimes at boot: This hang is the same as I mentionned in my original post here: >When the kernel 2.6.35 or 2.6.37.6 is hanging, after some times (or because I >pressed the power button ?), udev tries to kill modprobe processes (but >can't). >ACPI is mentionned in something like 'ACPI0001'. This hang already occured for >the newer kernel (>2.6.38) but I can't at this time say if it's from the same >cause. But I was not enough waiting. After 120 seconds, linux continues to start (but was really hanging when trying to start cpu-freq modules, later in the boot process. So I started in single user mode) >Kernel 2.6.34.14 was sometimes hanging at boot. After some time, udevd outputs >some messages: >udevd[number]: timeout : killing '/sbin/modprobe -b acpi:HPQ0004' [number] >udevd[number]: timeout : killing '/sbin/modprobe -b wmi:<guid number>' >[number] Sometimes, acpi:HPQ0004 is acpi:PNP0A06 instead, but it can probably be something else at other boots. When this hang occurs, linux does not handle the fan as it should, normally, the fan speed is software regulated. There is still a hardware logic that speed up the fan at max speed if the CPU temperature is too high (about 80°C). I think this is a proof that the acpi part managing fan speed was not working. The same behaviour occurs when Windows checks the file system, I don't think the Windows ACPI driver is running at this time (nor other unimportant drivers, they are started after boot time chkdsk)
Thank you Alexis for the test result. Hi Lv, The problem is, in previous kernel, after evaluate _BCM with param 100, the subsequent call to _BQC will return 100 as expected; but newer kernels will return 30, which is wrong. Can you please take a look? Thanks.
The behavior of _BCM changes in a big way if the "Windows 2006" string is set: in WCOS: If (\_OSI ("Windows 2006")) { Store (0x06, WOSI) } Method (_BCM, 1, Serialized) { If (LLess (\WCOS (), 0x06)) {
Yes, but I already tested all combination of OSI strings. In fact, I don't think the _BCM function is the problem (at least not directly, maybe some function called by it), the bug of _BCM method occur when linux try to pass an invalid parameter as backlight level, this parameter has to be in _BCL since _BCM loop on this array until it find the needed index. But as the parameter is not in the array, the index goes out of _BCL bounds causing the bug that makes backlight management disabled. The problem I'm facing is that _BCM does not cause immediate change of real backlight level, and _BQC sometimes cause the real backlight level to change, it should only return the current level, not change it. Attachment #2 [details] shows this error: >ACPI: Debug_Custom: acpi_video_device_lcd_get_level_current()=30 >ACPI: Debug_Custom: acpi_video_init_brightness(), get_max_level()=30 >ACPI: Debug_Custom: acpi_video_init_brightness(), >set_level(18446744073523392192) >ACPI: Debug_Custom: acpi_video_device_lcd_set_level(-186159424) >ACPI Exception: AE_AML_PACKAGE_LIMIT, Index (0x000000000000000D) is beyond end > of object (20110623/exoparg2-418) >ACPI Error: Method parse/execution failed [\_SB_.PCI0.PEGP.IGFX.LCD_._BCM] > (Node f543c920), AE_AML_PACKAGE_LIMIT (20110623/psparse-536) >ACPI Error: Evaluating _BCM failed (20110623/video-376) As you can see, the value 18446744073523392192 is not a valid backlight level, causing _BCM method to loop on the _BCL array without finding the correct index and going out of bounds. This value is the value of br->levels[level_old]; with level_old equal to 30 (the value returned by _BQC, it should return 100. The backlight level during backlight init change from max level (100) to minimum (30) when this bug occur) As the levels[] array has less than 30 elements, levels[30] is out of bound and read a wrong value in memory (18446744073523392192 for this example)
Sorry for the link mistake about attachment 2 [details], I was meaning the 2nd attachment of this bug, so Attachment #93881 [details] (dmesg with added debug output)
Yes, apparently any input to _BCM needs to be adjusted such that it exactly matches one of the values that appear in the list returned by _BCL.
(In reply to comment #19) > The behavior of _BCM changes in a big way if the "Windows 2006" string is > set: > > in WCOS: > If (\_OSI ("Windows 2006")) > { > Store (0x06, WOSI) > } > > Method (_BCM, 1, Serialized) > { > If (LLess (\WCOS (), 0x06)) > { As Alexis has said, linux kernel v2.6.34 has no problem, while v2.6.38 has. And we have already windows 2006 defined in v2.6.34. So this OSI thing should not be the problem here.
(In reply to comment #22) > Yes, apparently any input to _BCM needs to be adjusted such that it exactly > matches one of the values that appear in the list returned by _BCL. The problem is: in v2.6.34, after we set brightness level to 100 through _BCM, the subsequent call to _BQC will return 100, which is correct; while in kernel v2.6.38+, after we set brightness level to 100 through _BCM, the subsequent call to _BQC will return 30, which is wrong. The call sequence in acpi video driver doesn't change, only the value returned change, and caused acpi video driver mis-behave afterwards. So let's figure out first why _BQC would returned 30 after we set the value to 100 through _BCM. And since previous kernel has no such problem, I tend to think this might be a ACPICA problem?
The problem where _BQC return 30 occur "randomly", not every time (about 50% of the time), I also think it's a ACPICA problem, or maybe a change in the order of initialized ACPI component.
Hi Alexis, I've just posted a patch to enhance the quirk detect of broken _BQC, though you should have another problem, but I think that patch can be used to work around this problem. So can you please give it a test? Thanks. The patch is here: https://patchwork.kernel.org/patch/2402511/
BTW, the patch applies on top of Rafael's linux-next tree: http://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git linux-next
Hi Alex, Any update?
(In reply to comment #28) > Hi Alex, > > Any update? Sorry I was a bit busy these days ... I tried on monday to clone the git tree, but I failed. How I can clone the correct git tree ? I didn't find information about this type of linux tree.
Get the tree like this: $ git clone http://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git $ cd linux-pm $ git checkout linux-next $ git am patch_in_comment#26 If you already have a linux git tree, you can use --reference to speed up the clone: $ git clone --reference path_to_existing_linux_git_tree http://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git Thanks.
Created attachment 99141 [details] [DBG PATCH] ACPI: Add facility to honor Linux _OSI groups I'm not sure if this can fix your issue, but since "Windows 2006" _OSI is checked in the ACPI namespace, could you please give this patch a try? Apply it then boot with kernel parameters: acpi_osi=honor acpi_osi="Windows 2006" and boot with kernel parameters: acpi_osi=honor acpi_osi="!Windows 2006" to see if one of them can work for you.
Sorry, I made a mistake here. You should try the following kernel parameters: acpi_osi=honor acpi_osi=honor acpi_osi="Microsoft Windows" acpi_osi=honor acpi_osi="Windows 2006" They will cause WCOS return 0x00, 0x01, 0x06. You issue might be solved by one of this command line.
Created attachment 99461 [details] Minimized DSDT Minimized DSDT (targeted methods are _BCM/_BCL/_BQC) that might be useful for the developers.
Ok I will test these patch today or tomorrow as cloning the tree takes times on my internet connection.
(In reply to comment #26) > Hi Alexis, > > I've just posted a patch to enhance the quirk detect of broken _BQC, though > you > should have another problem, but I think that patch can be used to work > around > this problem. So can you please give it a test? Thanks. > > The patch is here: > https://patchwork.kernel.org/patch/2402511/ This patch seems to work, no problem occurred when I tested this patch. At boot, if the brightness level was not the highest level, it change to max level and boot continue. After that I am able to change the backlight level using /sys/class/backlight/acpi_video0/ (although it still doesn't change every time I issue a write in /sys/class/backlight/acpi_video0/brightness with a new level) I tested several boot backlight level, and at each time when linux boot, the backlight level change to max level (if the screen was already at max level, it does not change), so all seems to work correctly.
(In reply to comment #32) > Sorry, I made a mistake here. > You should try the following kernel parameters: > > acpi_osi=honor > acpi_osi=honor acpi_osi="Microsoft Windows" > acpi_osi=honor acpi_osi="Windows 2006" > > They will cause WCOS return 0x00, 0x01, 0x06. > You issue might be solved by one of this command line. Using the patch and any of these parameters didn't make any difference about the backlight. The DSDT seems to just use the latest tested OSI string, that is Windows 2006, the kernel behavior should not cause problems about that I think. Aaron, I retest several time using the kernel with your patch, the backlight level changed to max level one time, but this didn't cause the backlight mangement to be disabled. I was able to change it using /sys/class/backlight/acpi_video0/*, so your patch seems to work correctly about not using wrong assumption about how BQC works. During some test with acpi_osi=honor, the kernel hanged several times (about 70% of the time), same symptoms as previous mentioned hangs (comment #10). Normally, this bug occur almost never with my current kernel, but this time it occured too, after a boot into Windows, I could boot up correctly. After digging in the attachment, it seems that it's a deadlock on semaphore f7401820 that cause this hang.
(In reply to comment #35) > This patch seems to work, no problem occurred when I tested this patch. > At boot, if the brightness level was not the highest level, it change to max > level and boot continue. After that I am able to change the backlight level > using /sys/class/backlight/acpi_video0/ (although it still doesn't change > every > time I issue a write in /sys/class/backlight/acpi_video0/brightness with a > new > level) That patch is not supposed to solve such problems, and actually, I'm not sure if we can solve it: the _BCM control method will call \_SB.SSMI to do the real backlight control, where it touched some io port that I've no idea of what they are. These are not spec defined, so we have no way of debugging there. > > I tested several boot backlight level, and at each time when linux boot, the > backlight level change to max level (if the screen was already at max level, > it > does not change), so all seems to work correctly. Thanks for the testing, and yes, this is the expected behaviour. Since _BQC is now broken on your system(maybe it is due to ACPICA), we don't know the initial backlight level now, so we will simply set the level to max during init.
(In reply to comment #36) > Aaron, I retest several time using the kernel with your patch, the backlight > level changed to max level one time, but this didn't cause the backlight > mangement to be disabled. I was able to change it using > /sys/class/backlight/acpi_video0/*, so your patch seems to work correctly > about > not using wrong assumption about how BQC works. Yes, that's what the patch is for: it doesn't make assumption that once the returned brightness is not what we have just set, it must be using index for _BQC. Now we will simply clear the capability of _BQC, meaning for all later operations, we will not ask firmware to report backlight level through _BQC, we know what it is(since only we will set the level). > > During some test with acpi_osi=honor, the kernel hanged several times (about > 70% of the time), same symptoms as previous mentioned hangs (comment #10). > Normally, this bug occur almost never with my current kernel, but this time > it > occured too, after a boot into Windows, I could boot up correctly. After > digging in the attachment, it seems that it's a deadlock on semaphore > f7401820 > that cause this hang. This doesn't matter much for this bug, but Lv may want to debug it further.
(In reply to comment #36) > > You should try the following kernel parameters: > > > > acpi_osi=honor > > acpi_osi=honor acpi_osi="Microsoft Windows" > > acpi_osi=honor acpi_osi="Windows 2006" > > > > They will cause WCOS return 0x00, 0x01, 0x06. > > You issue might be solved by one of this command line. > Using the patch and any of these parameters didn't make any difference about > the backlight. > The DSDT seems to just use the latest tested OSI string, that is Windows > 2006, > the kernel behavior should not cause problems about that I think. This is because ACPICA returns "supported" to all _OSI strings so that it results in WCOS returning 0x06 and the patch changes this behaviour by overriding the _OSI return values in the Linux OSL layer. > During some test with acpi_osi=honor, the kernel hanged several times (about > 70% of the time), same symptoms as previous mentioned hangs (comment #10). > Normally, this bug occur almost never with my current kernel, but this time > it > occured too, after a boot into Windows, I could boot up correctly. After > digging in the attachment, it seems that it's a deadlock on semaphore > f7401820 > that cause this hang. This sounds like an ACPICA bug or an EC driver bug as there are EC related ASL codes in the minimized DSDT. This bug can be closed as there is a fix now working. And I will keep my eyes on it to confirm other issues. Thanks for your testing.
(In reply to comment #38) > This doesn't matter much for this bug, but Lv may want to debug it further. This sounds like DSDT issues. Linux just hangs on never tested ASL codes - where OSPM replies "not supported" to all Windows operating system vendor strings. I may not pay too much time working on this, but will try to confirm if there is an ACPICA bug causing the wrong _BQC returns. But EC driver and vendor graphics driver may also be the root cause. This bug might be closed as there is a working fix now for this issue. :-)
Yes the hang bug may be another bug also related to specific hardware behavior (but as it rarely happen, this bug is not a problem) Anyway the working patch is sufficient as it allow backlight level to be set even when it does not change properly at boot, and thus it's possible to set another level after. Thanks for your work on this bug :)
commit a50188dae3089dcd15a6ae793528c157680891f1 Author: Aaron Lu <aaron.lu@intel.com> Date: Mon Apr 22 14:08:32 2013 +0200 acpi: video: enhance the quirk detect logic of _BQC Entered ACPI maintainer's tree.
commit a50188dae3089dcd15a6ae793528c157680891f1 Author: Aaron Lu <aaron.lu@intel.com> Date: Mon Apr 22 14:08:32 2013 +0200 acpi: video: enhance the quirk detect logic of _BQC Entered Linus' tree.