Created attachment 146721 [details] acpidump On HP Compaq 6510b notebook, Intel IGP GMA X3100, the FN Keys for brightness are rendered useless after a fresh boot with 3.16 and 3.16.1. Other FN-keys seem to work fine (e.g. the one for Standby/STR). I'm on Arch x64 - downgrading to kernel 3.15.8 fixes the issue. After a standby(STR) however the keys work! Just not after a fresh boot. video.use_native_backlight=0 does not change that, same behaviour. I'm using Cinnamon as a DE without acpid. If I start acpid and track the keys with acpi_listen, there is no response at all. I should also point out that this laptop is from 2007 (BIOS from 2009), so "Win8 compatibility" should not be an issue? It was built for Vista... ;-) Please tell me what you need to debug it, I'll happily provide anything you need.
Created attachment 146731 [details] dmesg
Can you please check if 3.17-rc2 has this problem too?
Hi Rafael, yes, the issue persists with mainline 3.17-rc2. STR still solves the problem - after wakeup, keys work as they are supposed to.
We have a couple of fixes queued up for 3.17-rc3. Please wait until that is out and see if the problem is still there. Alternatively, you can try the linux-next branch of the linux-pm git tree: git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git linux-next that contains all of these fixes already. If that still doesn't work, please bisect changes between 3.15 and 3.16, as it is difficult to say what the root cause is from the symptoms.
From the acpidump, the backlight hotkey is from GPE02, maybe check this value after a fresh boot is useful: $ cat /sys/firmware/acpi/interrupts/gpe02
OK, I'm on rc3 now, no improvement. I still guess it's a driver that is not correctly initialized after boot, but becomes correctly initialized again after STR. But I'm no kernel hacker. gpe02 reports after fresh boot: 10 enabled after STR: 13 enabled I don't know what that means though :)
Ah, the first value seems to be a counter. After a fresh boot, it is always 10 (and won't increase when pressing the keys). After STR, it seems to count correctly.
Exactly the same bug as described by Carsten, again an HP, 8510p from '08. Tried a few boot param with no success. I know they worked for some people. 3.15.5 and 3.15.8 worked, 3.16.1 works after suspend but not right after boot. I will be happy to provide any additional info.
Can you please do a "git checkout d34afa9de444", build a kernel from that and see if it works?
Any update on the bisect or the commit mentioned in comment #9?
As I said, I don't really know how to bisect changes, I'm no kernel hacker. I tried compiling the kernel with the checkout mentioned (following https://wiki.archlinux.org/index.php/Kernels/Compilation/Traditional ), but "make modules_install" fails. Again, I'm a n00b at this.. Any chance I could just test it with 3.17-rc5 if the changes will be in there? That would be much easier for me...
(In reply to Carsten from comment #7) > Ah, the first value seems to be a counter. After a fresh boot, it is always > 10 (and won't increase when pressing the keys). After STR, it seems to count > correctly. does the counter always work in 3.15.5?
(In reply to x3ask from comment #8) > Exactly the same bug as described by Carsten, again an HP, 8510p from '08. > Tried a few boot param with no success. I know they worked for some people. > 3.15.5 and 3.15.8 worked, 3.16.1 works after suspend but not right after > boot. > I will be happy to provide any additional info. Can you perform a git bisect for this issue? For the regressions, this might be the fastest way.
(In reply to Carsten from comment #11) > As I said, I don't really know how to bisect changes, I'm no kernel hacker. > I tried compiling the kernel with the checkout mentioned (following > https://wiki.archlinux.org/index.php/Kernels/Compilation/Traditional ), but > "make modules_install" fails. Again, I'm a n00b at this.. > > Any chance I could just test it with 3.17-rc5 if the changes will be in > there? That would be much easier for me... Well, I'm not an ACPI video expert. But I can help to check this issue from GPE's perspective. I wonder if this is caused by unwanted GPE disabling. First, I need you to confirm that other GPEs can still arrive: For example, checking whether EC GPE can arrive or power cord status can change: $ cat /sys/firmware/acpi/interrupts/gpe16 $ cat /sys/class/power_supply/<DEVICE_NODE_NAME>/online then pluging/unplugging power cord several times. $ cat /sys/firmware/acpi/interrupts/gpe16 $ cat /sys/class/power_supply/<DEVICE_NODE_NAME>/online DEVICE_NODE_NAME will vary platform by platform, on my platform, it is ACAD. And we can confirm that it is an ACPI0003 device by doing: $ cat /sys/class/power_supply/<DEVICE_NODE_NAME>/device/modalias Please upload the output here. Currently, all _Lxx/_Exx/_Qxx methods are evaluated using a single work queue. So if some evaluations are blocked, your platform will be suffering from GPE disabling. Second, I need to confirm that the GPE is disabled in the register level. Could you try this branch: $ git clone https://github.com/zetalog/linux $ git checkout debug-82451 Then compiling and booting this kernel using your old kernel configuration. After a fresh boot, perform the following command again: $ cat /sys/firmware/acpi/interrupts/gpe02 This branch contains useful patches to dump GPE hardware register values, which could help to confirm if the GPE02 is disabled on your platform. Third, well, let me ask you to do this after the previous test. :-) Thanks in advance. Best regarfds -Lv
(In reply to Lv Zheng from comment #14) Sorry for the noise, let me add some information. ... > DEVICE_NODE_NAME will vary platform by platform, on my platform, it is > ACAD. I checked your DSDT, it should be C239 on your platform. > After a fresh boot, perform the following command again: > $ cat /sys/firmware/acpi/interrupts/gpe02 > This branch contains useful patches to dump GPE hardware register values, > which could help to confirm if the GPE02 is disabled on your platform. Also please upload the output here. Thanks -Lv
please attach the output of "ls /sys/bus/*/drivers/" and "ls /sys/bus/*/drivers/*" in both your good and bad kernel.
(In reply to Zhang Rui from comment #16) > please attach the output of "ls /sys/bus/*/drivers/" and "ls > /sys/bus/*/drivers/*" in both your good and bad kernel. http://pastebin.mozilla.org/6506911 bad kernel before/after suspend Can I downgrade to 3.15.8 without removing virtualbox?
(In reply to Carsten from comment #11) > As I said, I don't really know how to bisect changes, I'm no kernel hacker. > I tried compiling the kernel with the checkout mentioned (following > https://wiki.archlinux.org/index.php/Kernels/Compilation/Traditional ), but > "make modules_install" fails. Again, I'm a n00b at this.. > > Any chance I could just test it with 3.17-rc5 if the changes will be in > there? That would be much easier for me... This sounds like a problem of your module scripts. You can try to a tricky kernel build by disabling the modules. You can do the following things: 1. Type "make menuconfig", and unselect the following menu item: [ ] Enable loadable module support 2. Type "make" 3. Type "sudo make install" 4. If this generated an item in the grub configuration (/boot/grub/menu.lst or /boot/grub/grub.cfg) with an initrd entry and your kernel failed to boot because this file doesn't exist, you could simply copy an existing initrd file from /boot to prepare a fake one for it. Hope with this, you can try the comment 9 or a "git bisect".
Created attachment 150441 [details] Output of comment 17 I downloaded it from http://pastebin.mozilla.org/6506911 and uploaded it here for consistencies.
ping...
I sent Lv an email to avoid spam a while ago, but I got no answer. I did the first test, and from what I understand is that my system does not suffer from GPE disabling. Therefore, I didn't test building a kernel again as this takes a lot of time - or do I still need to try that? I'll attach the outputs and the output of "ls /sys/bus/*/drivers/" on the bad kernel now.
Created attachment 152081 [details] tests
Created attachment 152091 [details] content of /sys/bus/*/drivers/
(In reply to Carsten from comment #22) > Created attachment 152081 [details] > tests Thanks for your testing. So we confirmed that this bug is not an IOAPIC bug but possibly an ACPI bug. From this test result, we can see that the SCI is enabled. So we have to guess that the GPE02 is disabled after boot and can only get re-enabled again after STR. But the following line is meaningless for confirming whether GPE02 is disabled: 10 enabled The "enabled" status here just means OSPM has tried to enable this GPE, making his enabling count greater than 0, but it could still be disabled due to various reasons. That's why we need the 2nd test. The repo mentioned contains enhancement for ACPI GPE implementation. The output of the GPE file will be changed to: 1211 !EN !STS enabled The EN shows the value of GPE register value of enabling. ! means "not enabled", the STS shows the value of GPE register value of signaling. ! means "not signaled". We need these 2 values to make sure this is an ACPI bug. Best regards
please make sure your kernel is built with CONFIG_ACPI_DEBUG=y, and then reboot your kernel with boot option "acpi.debug_level=0x88000004, acpi.debug_layer=0x04". please attach the output of "cat /proc/interrupts" both before and after pressing the hotkey, and attach the dmesg output after pressing the hotkey, for both good and bad kernel.
I will try to build a kernel with config_acpi, I don't have the "good" kernel anymore. Login brightness fn still broken with linux 3.17
please make sure your kernel is built with CONFIG_ACPI_DEBUG=y.
any update on this one? are you able to build the kernel?
Created attachment 159341 [details] kernel build fail Sorry for the lack of updates. As with 3.17.4 on Arch, the workaround with STR (resume) won't even work anymore - keys are completely dead now and only work prior to boot. The kernel still won't build for me. See attached log. I just copied the standard arch linux config and included the debug line you specified during make.
Hi, I'm not sure if ACPI debug is enabled on the kernel. If not, you need to enable it and re-build kernel. But if it's already enabled, please try to boot the kernel with the following command line "acpi.debug_layer=0x6 acpi.debug_level=0x0C200A05" and post the dmesg output of the boot log here. Thanks and best regards -Lv
(In reply to Carsten from comment #0) > I'm using Cinnamon as a DE without acpid. If I start acpid and track the > keys with acpi_listen, there is no response at all. > in both 3.15 and 3.16 kernel? (In reply to Carsten from comment #31) > Created attachment 159341 [details] > kernel build fail > > Sorry for the lack of updates. > As with 3.17.4 on Arch, the workaround with STR (resume) won't even work > anymore - keys are completely dead now and only work prior to boot. > > The kernel still won't build for me. See attached log. > I just copied the standard arch linux config and included the debug line you > specified during make. can you please try the latest kernel? If there is any build error caused by driver, just compile it out as a short solution.
we do need a customized kernel with debug output for further debugging.
Carsten, as the problem is a model specific issue and we don't have the hardware to reproduce locally, thus we do need your help for debugging the issue. If you're not able to provide the requested information, I'm afraid we can do nothing here but closing the bug report.
I have same hardware HP-Compaq 6510b and same problem. I have dmesg of 3.18.4 kernel with ACPI DEBUG and append: acpi.debug_layer=0x6 acpi.debug_level=0x0C200A05 http://perso.crans.org/~bebert/ck/dmesg I hope it will help you... Thanks
(In reply to Bertrand Vieille from comment #36) > I have same hardware HP-Compaq 6510b and same problem. > I have dmesg of 3.18.4 kernel with ACPI DEBUG and append: > acpi.debug_layer=0x6 acpi.debug_level=0x0C200A05 > > http://perso.crans.org/~bebert/ck/dmesg > > I hope it will help you... The boot log is zapped due to the size of the logging buffer and the plenty of IO accesses. I only learned one thing that this is a global lock enabled system. Is it possible to obtain a full boot log by enlarging the logging buffer? For example, using the following kernel boot parameter: log_buf_len=1M or something similar. Please also upload the lsmod output here. If you are able to re-compile the kernel, make sure to disable the GPIO subsystem: CONFIG_GPIOLIB=n. Thanks and best regards -Lv
> The boot log is zapped due to the size of the logging buffer and the plenty > of IO accesses. > I only learned one thing that this is a global lock enabled system. > Is it possible to obtain a full boot log by enlarging the logging buffer? > For example, using the following kernel boot parameter: log_buf_len=1M or > something similar. This one seems to be complete but 30M!! http://perso.crans.org/~bebert/ck/dmesg > Please also upload the lsmod output here. $ lsmod Module Size Used by fuse 74932 0 > If you are able to re-compile the kernel, make sure to disable the GPIO > subsystem: CONFIG_GPIOLIB=n. $ grep GPIOLIB /boot/config CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y # CONFIG_GPIOLIB is not set My kernel config: http://perso.crans.org/~bebert/ck/config-HP6510b Thanks
(In reply to Bertrand Vieille from comment #38) > > The boot log is zapped due to the size of the logging buffer and the plenty > > of IO accesses. > > I only learned one thing that this is a global lock enabled system. > > Is it possible to obtain a full boot log by enlarging the logging buffer? > > For example, using the following kernel boot parameter: log_buf_len=1M or > > something similar. > > This one seems to be complete but 30M!! > http://perso.crans.org/~bebert/ck/dmesg > > > > Please also upload the lsmod output here. > > $ lsmod > Module Size Used by > fuse 74932 0 > > > If you are able to re-compile the kernel, make sure to disable the GPIO > > subsystem: CONFIG_GPIOLIB=n. > > $ grep GPIOLIB /boot/config > CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y > # CONFIG_GPIOLIB is not set > > My kernel config: > http://perso.crans.org/~bebert/ck/config-HP6510b > > Thanks I'm investigating the GPE02_EN register accesses in this log. According to FADT: [050h 0080 4] GPE0 Block Address : 00001028 [05Ch 0092 1] GPE0 Block Length : 08 [0DCh 0220 12] GPE0 Block : [Generic Address Structure] [0DCh 0220 1] Space ID : 01 [SystemIO] [0DDh 0221 1] Bit Width : 40 [0DEh 0222 1] Bit Offset : 00 [0DFh 0223 1] Encoded Access Width : 00 [Undefined/Legacy] [0E0h 0224 8] Address : 0000000000001028 So the GPE0_STS address is 0x1028 and GPE0_EN address is 0x102C. To enable GPE02, Linux should set 0x04 mask in 0x102C. To disable GPE02, Linux should clear 0x04 mask in 0x102C. I'm checking the 0x102C hardware writes, but got confused by some of the records. Could you please upload an acpidump output so that I can make sure the platform is same? Thanks and best regards -Lv
(In reply to Lv Zheng from comment #39) > Could you please upload an acpidump output so that I can make sure the > platform is same? Here is my acpidump: http://perso.crans.org/~bebert/ck/acpidump I hope it will help you. Thanks and best regards, BV
I did see many GPE02 invoked. We can check this by filtering the log with "Read registers for GPE 00-07" or "from 0000000000001028", the value of 0x04 is a GPE02 indication. Line 318338: [ 21.493893] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 318457: [ 42.543919] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 318574: [ 42.547523] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 318631: [ 42.550090] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 318742: [ 83.067976] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 318858: [ 83.071765] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 318981: [ 107.810142] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 319106: [ 107.814060] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 319229: [ 150.781365] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 319345: [ 150.785267] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 319468: [ 175.012893] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 319590: [ 175.016725] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 319713: [ 216.028408] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 319833: [ 216.032257] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 319956: [ 238.788084] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 320078: [ 238.791836] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 320201: [ 280.188866] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 320313: [ 280.192722] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 320436: [ 304.649652] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 320551: [ 304.653408] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 320674: [ 346.188363] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 320794: [ 346.192215] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 320917: [ 371.661154] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 321039: [ 371.664924] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 321091: [ 371.665331] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 321214: [ 414.211591] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 321335: [ 414.215346] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 321458: [ 437.329406] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 321579: [ 437.333163] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 321702: [ 478.866397] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 321814: [ 478.870314] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 321937: [ 505.190597] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 322055: [ 505.194360] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 322107: [ 505.194765] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 322230: [ 544.907677] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 322355: [ 544.911452] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 322478: [ 569.105406] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 322599: [ 569.109256] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 322722: [ 609.183500] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 322838: [ 609.187409] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 322961: [ 635.613588] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 323082: [ 635.617348] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 323205: [ 675.602925] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 323317: [ 675.606682] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 323440: [ 701.913519] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 323561: [ 701.917364] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 323684: [ 743.004579] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 323807: [ 743.008346] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 323930: [ 769.936687] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 324047: [ 769.940267] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 324099: [ 769.942781] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 324175: [ 811.682789] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 324289: [ 811.686588] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 324412: [ 837.231204] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 324533: [ 837.235119] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 324656: [ 876.872178] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 324777: [ 876.875950] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 324900: [ 903.877085] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 325012: [ 903.880831] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 325135: [ 943.817914] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 325255: [ 943.821675] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 325378: [ 971.690620] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 325574: [ 1010.960411] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 325694: [ 1010.964258] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 325817: [ 1037.889497] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 325931: [ 1037.894991] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 326062: [ 1066.887240] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 327987: [ 1074.927768] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 328811: [ 1076.488482] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) Line 328891: [ 1079.610061] hwregs-0192 hw_read : Read: 00000004 width 8 from 0000000000001028 (SystemIO) The first GPE02 handling process is: acp_ev_sci_xrupt_handler (GPE02): Line 318324: [ 21.493790] evsci-0117 ev_sci_xrupt_handler : ----Entry Line 318342: [ 21.493925] evgpe-0427 ev_gpe_detect : Read registers for GPE 00-07: Status=04, Enable=47, RunEnable=47, WakeEnable=00 Line 318349: [ 21.493980] hwregs-0243 hw_write : Wrote: 00000043 width 8 to 000000000000102C (SystemIO) disable GPE02 Line 318409: [ 21.494148] ev_sci_xrupt_handler : Line 318356: [ 21.494018] ev_asynch_execute_gpe_: ----Entry Line 318423: [ 21.494444] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 318424: [ 21.494494] evgpe-0598 ev_asynch_execute_gpe_: ----Exit- Line 318442: [ 21.496097] hwregs-0243 hw_write : Wrote: 00000047 width 8 to 000000000000102C (SystemIO) enable GPE02 It looks the GPE02 is now dispatched as GPE_DISPATCH_NOTIFY not GPE_DISPATCH_METHOD, that's why the _L02 is not invoked. I checked all _PRW, and didn't see the reason why it is DISPATCH_NOTIFY now. Someone familiar with the ACPI enumeration should take over this bug instead of me. I didn't see a reason why the count is 0. Thanks and best regards -Lv
Hi, Sorry for the mistake. I checked TZ0, it seems in SSDT3, there is such a method: Method (C3A9, 0, Serialized) { Notify (\_TZ.TZ0, 0x80) } Which get invoked by the _L02: Method (_L02, 0, NotSerialized) // _Lxx: Level-Triggered GPE { Store (0x00, \_SB.C003.C004.C0DB) Store (\_SB.C05F, Local0) If (Local0) { Store (0x00, \_SB.C05F) If (LEqual (Local0, 0x01)) { C1BA () } If (LAnd (LGreaterEqual (Local0, 0x04), LLessEqual (Local0, 0x05))) { \_SB.C2BD.C2BE (Local0, 0x00) } If (LEqual (Local0, 0x07)) { Acquire (\_TZ.C237, 0xFFFF) Or (\_TZ.C238, 0x01, \_TZ.C238) Release (\_TZ.C237) \_TZ.C3A9 (If (LEqual (Local0, 0x03)) ^^^^ { C1B9 (0x87) }) } If (LEqual (Local0, 0x02)) { C1B9 (0x86) } } } It looks the _L02 is invoked by the GPE dispatcher and you should see GPE02 count increased. Could you confirm the count via /sys/firmware/acpi/interrupts/gpe02 after the boot? Thanks and best regards -Lv
One more thing need to be mentioned here: For backlight control, we should see C1B9 invoked: Line 16647: C1B9 (0x87) Line 16653: C1B9 (0x86) It finally notify C1AD with 0x86/0x87: Method (C1B9, 1, Serialized) { If (And (Arg0, 0x80)) { Notify (\_SB.C003.C098.C1AD, Arg0) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ } Else { If (LEqual (And (\_SB.C05A, 0x04), 0x00)) { \_SB.C003.C098.C168 () } } } While I didn't see C1AD is notified: Line 16800: [ 2.148572] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [C132] (Device) Value 0x00 (Bus Check) Node ffff88012b024028 Line 318423: [ 21.494444] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 318543: [ 42.544419] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 318554: [ 42.545369] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 318827: [ 83.068474] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 318838: [ 83.069447] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 319075: [ 107.810635] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 319086: [ 107.811587] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 319314: [ 150.781876] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 319325: [ 150.782852] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 319559: [ 175.013399] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 319570: [ 175.014337] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 319802: [ 216.028921] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 319813: [ 216.029896] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 320047: [ 238.788578] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 320058: [ 238.789524] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 320282: [ 280.189372] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 320293: [ 280.190348] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 320520: [ 304.650153] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 320531: [ 304.651107] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 320763: [ 346.188862] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 320774: [ 346.189837] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 321008: [ 371.661647] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 321019: [ 371.662594] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 321304: [ 414.212091] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 321315: [ 414.213065] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 321548: [ 437.329899] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 321559: [ 437.330849] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 321783: [ 478.866901] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 321794: [ 478.867878] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 322024: [ 505.191088] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 322035: [ 505.192037] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 322324: [ 544.908177] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 322335: [ 544.909153] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 322568: [ 569.105900] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 322579: [ 569.106852] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 322807: [ 609.184013] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 322818: [ 609.184986] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 323051: [ 635.614082] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 323062: [ 635.615029] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 323286: [ 675.603429] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 323297: [ 675.604403] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 323530: [ 701.914026] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 323541: [ 701.914975] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 323776: [ 743.005081] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 323787: [ 743.006057] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 324016: [ 769.937188] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 324027: [ 769.938142] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 324258: [ 811.683287] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 324269: [ 811.684264] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 324502: [ 837.231696] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 324513: [ 837.232645] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 324746: [ 876.872691] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 324757: [ 876.873669] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 324981: [ 903.877581] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 324992: [ 903.878535] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 325224: [ 943.818410] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 325235: [ 943.819385] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 325472: [ 971.691117] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 325483: [ 971.692066] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 325663: [ 1010.960907] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 325674: [ 1010.961883] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 325900: [ 1037.889993] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 325911: [ 1037.890948] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 326134: [ 1066.946619] Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 326167: [ 1066.946981] Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 328050: [ 1075.419991] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 328857: [ 1076.489244] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 Line 328962: [ 1079.610360] evmisc-0171 ev_queue_notify_reques: Dispatching Notify on [TZ0_] (Thermal) Value 0x80 (Status Change) Node ffff88012b044230 I can only see C132 and TZ0 notified. Thanks and best regards -Lv
(In reply to Lv Zheng from comment #42) > Could you confirm the count via /sys/firmware/acpi/interrupts/gpe02 after > the boot? The value of the counter is not zero. This counter is increasing when system is up. I don't use hibernation/suspend. It's a fresh boot (unplugged, no battery). bertrand@bertrand:~$ cat /sys/firmware/acpi/interrupts/gpe02 12 enabled bertrand@bertrand:~$ uptime 17:23:14 up 1 min, 2 users, load average: 0,32, 0,11, 0,03 bertrand@bertrand:~$ cat /sys/firmware/acpi/interrupts/gpe02 26 enabled bertrand@bertrand:~$ uptime 17:25:58 up 4 min, 2 users, load average: 0,03, 0,07, 0,02 bertrand@bertrand:~$ cat /sys/firmware/acpi/interrupts/gpe02 32 enabled bertrand@bertrand:~$ uptime 17:28:02 up 6 min, 3 users, load average: 0,15, 0,07, 0,02 bertrand@bertrand:~$ cat /sys/firmware/acpi/interrupts/gpe02 38 enabled bertrand@bertrand:~$ uptime 17:28:43 up 7 min, 2 users, load average: 0,13, 0,08, 0,02 bertrand@bertrand:~$ Thanks for your job Bertrand Vieille
OK, so this is not a GPE issue. According to _L02: The handler writes 0x00 to \_SB.C003.C004.C0DB and reads the event type from \_SB.C05F. Both C0DB and C05F are SystemMemory registers. The event types are as follows: 0x01: LID event, because C098 is notified and C098._INI invoked _LID. 0x04, 0x05: WMI event, because C2BD is notified and C2BD._HID is PNP0C14. 0x07: thermal event, because the TZ0 is notified and TZ0 is a ThermalZone. 0x02: backlight event, because the C1AD is notified and C1AD contains _BCL. We just haven't seen 0x02 to be returned by the C05F register. Are you still suffering from the brightness FN key problems? Thanks and best regards -Lv
(In reply to Lv Zheng from comment #45) > Are you still suffering from the brightness FN key problems? I stil have the problem. FN Brightness UP or DOWN have not effect. Acpi_listen doesn't say anything when I press these keys and brightness doesn't change. The only thing is detected is in dmesg Invalid keycode. But all Fn Keys have the same invalid keycode. Thanks, Bertrand Vieille
Same here with Kernel 3.18.5 acpi_listen does not say anything; keys have no effect.
This is what I can do so far. Let me hand the bug back to ones who know more than me about backlight and thermal. Thanks and best regards -Lv
There is nothing more I can think of, please do a git bisect to find the offending commit.
I can test some kernels, but I don't know how to do a git bisect. Can you explain me how I must do ? Thanks Bertrand Vieille
Please use git to clone Linus' tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git Then find a kernel version N such that N works and N+1 doesn't. Then start the bisect process as described here: http://git-scm.com/docs/git-bisect There are other tutorials on git bisect, feel free to find one that most suits you. Thanks.
(In reply to Aaron Lu from comment #51) Here is the result of kernel bisect. bertrand@bertrand:~$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git linux.git Clonage dans 'linux.git'... remote: Counting objects: 4043526, done. remote: Compressing objects: 100% (77508/77508), done. remote: Total 4043526 (delta 56861), reused 0 (delta 0) Réception d'objets: 100% (4043526/4043526), 930.80 MiB | 33.00 KiB/s, fait. Résolution des deltas: 100% (3320016/3320016), fait. Vérification de la connectivité... fait. Extraction des fichiers: 100% (48948/48948), fait. bertrand@bertrand:~$ cd linux.git bertrand@bertrand:~/linux.git$ git bisect start bertrand@bertrand:~/linux.git$ git bisect good v3.15 bertrand@bertrand:~/linux.git$ git bisect bad v3.16-rc1 Bisecting: 6037 revisions left to test after this (roughly 13 steps) [aaeb2554337217dfa4eac2fcc90da7be540b9a73] Merge branch 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media into next Buttons works with acpi_listen but no effect bertrand@bertrand:~/linux.git$ git bisect good aaeb2554337217dfa4eac2fcc90da7be540b9a73 Bisecting: 3023 revisions left to test after this (roughly 12 steps) [16b9057804c02e2d351e9c8f606e909b43cbd9e7] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs Nothing works bertrand@bertrand:~/linux.git$ git bisect bad 16b9057804c02e2d351e9c8f606e909b43cbd9e7 Bisecting: 1444 revisions left to test after this (roughly 11 steps) [82abb273d838318424644d8f02825db0fbbd400a] Merge branch 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus Buttons works with acpi_listen but no effect bertrand@bertrand:~/linux.git$ git bisect good 82abb273d838318424644d8f02825db0fbbd400a Bisecting: 712 revisions left to test after this (roughly 10 steps) [d1e1cda862c16252087374ac75949b0e89a5717e] Merge tag 'nfs-for-3.16-1' of git://git.linux-nfs.org/projects/trondmy/linux-nfs Buttons works with acpi_listen but no effect bertrand@bertrand:~/linux.git$ git bisect good d1e1cda862c16252087374ac75949b0e89a5717e Bisecting: 395 revisions left to test after this (roughly 9 steps) [23d4ed53b7342bf5999b3ea227d9f69e75e5a625] Merge branch 'for-linus' of git://git.kernel.dk/linux-block Nothing works bertrand@bertrand:~/linux.git$ git bisect bad 23d4ed53b7342bf5999b3ea227d9f69e75e5a625 Bisecting: 158 revisions left to test after this (roughly 7 steps) [09567e7fd44291bfc08accfdd67ad8f467842332] powerpc/mm: Check paca psize is up to date for huge mappings Everythings works bertrand@bertrand:~/linux.git$ git bisect good 09567e7fd44291bfc08accfdd67ad8f467842332 Bisecting: 79 revisions left to test after this (roughly 6 steps) [f1900c79633e9ed757319e63aefb8e29443ea35e] Merge MTD pullreq from 3.15-rc5 Everythings works bertrand@bertrand:~/linux.git$ git bisect good f1900c79633e9ed757319e63aefb8e29443ea35e Bisecting: 48 revisions left to test after this (roughly 5 steps) [c5aec4c76af1a2d89ee2f2d4d5463b2ad2d85de5] Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc Nothing works bertrand@bertrand:~/linux.git$ git bisect bad c5aec4c76af1a2d89ee2f2d4d5463b2ad2d85de5 Bisecting: 15 revisions left to test after this (roughly 4 steps) [4738d8aabe89d237f30a28c65f61391a1435e3a7] platform: x86: dell-smo8800: Dell Latitude freefall driver (ACPI SMO8800/SMO8810) Buttons works with acpi_listen but no effect bertrand@bertrand:~/linux.git$ git bisect good 4738d8aabe89d237f30a28c65f61391a1435e3a7 Bisecting: 7 revisions left to test after this (roughly 3 steps) [a0347f20aaacc96a203c9609877ecc77093cbe30] rtc: s5m: consolidate two device type switch statements Buttons works with acpi_listen but no effect bertrand@bertrand:~/linux.git$ git bisect good a0347f20aaacc96a203c9609877ecc77093cbe30 Bisecting: 2 revisions left to test after this (roughly 2 steps) [2937f5efa5754754daf46de745f67350f7f06ec2] Merge branch 'for_linus' of git://cavan.codon.org.uk/platform-drivers-x86 Nothing works bertrand@bertrand:~/linux.git$ git bisect bad 2937f5efa5754754daf46de745f67350f7f06ec2 Bisecting: 2 revisions left to test after this (roughly 1 step) [9ee4d7a6538308a7681b638d2f35f2a301420355] Merge branch 'akpm' (patches from Andrew Morton) Buttons works with acpi_listen but no effect git bisect good 9ee4d7a6538308a7681b638d2f35f2a301420355 Bisecting: 0 revisions left to test after this (roughly 1 step) [f82bdd0d77b6bf0dea08a1d957ab45d503f328b1] hp-wmi: Enable hotkeys on some systems Nothing works bertrand@bertrand:~/linux.git$ git bisect bad f82bdd0d77b6bf0dea08a1d957ab45d503f328b1 Bisecting: 0 revisions left to test after this (roughly 0 steps) [8b9dd4fab26a0f328420cbda0845a325f45bcd92] thinkpad_acpi: Add mappings for F9 - F12 hotkeys on X240 / T440 / T540 Buttons works with acpi_listen but no effect bertrand@bertrand:~/linux.git$ git bisect good 8b9dd4fab26a0f328420cbda0845a325f45bcd92 f82bdd0d77b6bf0dea08a1d957ab45d503f328b1 is the first bad commit commit f82bdd0d77b6bf0dea08a1d957ab45d503f328b1 Author: Kyle Evans <kvans32@gmail.com> Date: Mon Jun 9 12:26:06 2014 -0500 hp-wmi: Enable hotkeys on some systems This is a third attempt to enable these buttons. The new variable being commit 997daa1bd9aca412ab97955a35b26c460c0ec7a4 (i.e. hp-wmi: detect "2009 BIOS or later"). Older systems that do not have the 2009 BIOS query method respond with a dummy value, in this case 4. Using that, we can target a fairly narrow group of systems. i.e. old enough to not have HPWMI_FEATURE_QUERY 0xd, but new enough to have HPWMI_BIOS_QUERY 0x9. This group may be further limited if some systems respond with something other than 4 to non-existant feature queries. Signed-off-by: Kyle Evans <kvans32@gmail.com> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com> :040000 040000 38c8028493cec3eb4dad4c2081d4e1633f08f365 936bfd904a8d6431adddf610a70ad913cc0ebe46 M drivers The problem of Fn-Keys is due to this commit : f82bdd0d77b6bf0dea08a1d957ab45d503f328b1 I will do again for the effects of theses keys, the bug is due to 2 commits, I have only identified one of them. BV
Here is the result of my second kernel bisect. bertrand@bertrand:~/linux.git$ git bisect start Extraction des fichiers: 100% (25290/25290), fait. La position précédente de HEAD était 8b9dd4f... thinkpad_acpi: Add mappings for F9 - F12 hotkeys on X240 / T440 / T540 Basculement sur la branche 'master' Votre branche est à jour avec 'origin/master'. bertrand@bertrand:~/linux.git$ git bisect good v3.15 bertrand@bertrand:~/linux.git$ git bisect bad v3.16-rc1 Bisecting: 6037 revisions left to test after this (roughly 13 steps) [aaeb2554337217dfa4eac2fcc90da7be540b9a73] Merge branch 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media into next Buttons works with acpi_listen but no effect bertrand@bertrand:~/linux.git$ git bisect bad aaeb2554337217dfa4eac2fcc90da7be540b9a73 Bisecting: 2542 revisions left to test after this (roughly 12 steps) [5142c33ed86acbcef5c63a63d2b7384b9210d39f] Merge tag 'staging-3.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging into next Everything works bertrand@bertrand:~/linux.git$ git bisect good 5142c33ed86acbcef5c63a63d2b7384b9210d39f Bisecting: 1236 revisions left to test after this (roughly 10 steps) [b05d59dfceaea72565b1648af929b037b0f96d7f] Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm into next Everything works bertrand@bertrand:~/linux.git$ git bisect good b05d59dfceaea72565b1648af929b037b0f96d7f Bisecting: 705 revisions left to test after this (roughly 9 steps) [16088cb6c02d0b766b9b8d7edff98da7f1c93205] ASoC: Fix wrong argument for card remove callbacks Everything works bertrand@bertrand:~/linux.git$ git bisect good 16088cb6c02d0b766b9b8d7edff98da7f1c93205 Bisecting: 351 revisions left to test after this (roughly 9 steps) [15b588303155b22edd559672905db8e59a44ef9a] Merge tag 'fbdev-omap-3.16' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux into next Buttons works with acpi_listen but no effect bertrand@bertrand:~/linux.git$ git bisect bad 15b588303155b22edd559672905db8e59a44ef9a Bisecting: 179 revisions left to test after this (roughly 8 steps) [42a09284fab8abc15c8554f2e2aa2368161c77c6] Merge branch 'pm-devfreq' Buttons works with acpi_listen but no effect bertrand@bertrand:~/linux.git$ git bisect bad 42a09284fab8abc15c8554f2e2aa2368161c77c6 Bisecting: 107 revisions left to test after this (roughly 7 steps) [729ddb657f6a47a2cb6e495f1ff68fff622c758a] ACPICA: Namespace: Remove _PRP method support. Everything works bertrand@bertrand:~/linux.git$ git bisect good 729ddb657f6a47a2cb6e495f1ff68fff622c758a Bisecting: 53 revisions left to test after this (roughly 6 steps) [864e055f44a5701cb033bf3afa2b6cc37ddba678] Merge branch 'acpi-lpss' Everything works bertrand@bertrand:~/linux.git$ git bisect good 864e055f44a5701cb033bf3afa2b6cc37ddba678 Bisecting: 25 revisions left to test after this (roughly 5 steps) [e81a0e771c10de86fdb52c6baf534ff5fdeec72c] Merge branch 'acpi-thermal' Buttons works with acpi_listen but no effect bertrand@bertrand:~/linux.git$ git bisect bad e81a0e771c10de86fdb52c6baf534ff5fdeec72c Bisecting: 14 revisions left to test after this (roughly 4 steps) [0e36d43c9c87554cdb18aa865eec9edccda17324] Merge branch 'acpica' Everything works bertrand@bertrand:~/linux.git$ git bisect good 0e36d43c9c87554cdb18aa865eec9edccda17324 Bisecting: 7 revisions left to test after this (roughly 3 steps) [bee564430feec1175ee64bcfd4913cacc519f817] nouveau: Don't check acpi_video_backlight_support() before registering backlight Buttons works with acpi_listen but no effect bertrand@bertrand:~/linux.git$ git bisect bad bee564430feec1175ee64bcfd4913cacc519f817 Bisecting: 3 revisions left to test after this (roughly 2 steps) [1b7f37e1276bee9043d35a4b39ef2f43d3b2e133] ACPI / video: Add an acpi_video_unregister_backlight function Buttons works with acpi_listen but no effect ertrand@bertrand:~/linux.git$ git bisect bad 1b7f37e1276bee9043d35a4b39ef2f43d3b2e133 Bisecting: 0 revisions left to test after this (roughly 1 step) [99678ed73a50d2df8b5f3c801e29e9b7a3e5aa85] ACPI / video: Don't register acpi_video_resume notifier without backlight devices Buttons works with acpi_listen but no effect bertrand@bertrand:~/linux.git$ git bisect bad 99678ed73a50d2df8b5f3c801e29e9b7a3e5aa85 Bisecting: 0 revisions left to test after this (roughly 0 steps) [886129a8eebebec260165741fe31421482371006] ACPI / video: change acpi-video brightness_switch_enabled default to 0 Buttons works with acpi_listen but no effect bertrand@bertrand:~/linux.git$ git bisect bad 886129a8eebebec260165741fe31421482371006 886129a8eebebec260165741fe31421482371006 is the first bad commit commit 886129a8eebebec260165741fe31421482371006 Author: Hans de Goede <hdegoede@redhat.com> Date: Tue May 6 14:46:23 2014 +0200 ACPI / video: change acpi-video brightness_switch_enabled default to 0 acpi-video is unique in that it not only generates brightness up/down keypresses, but also (sometimes) actively changes the brightness itself. This presents an inconsistent kernel interface to userspace, basically there are 2 different scenarios, depending on the laptop model: 1) On some laptops a brightness up/down keypress means: show a brightness osd with the current brightness, iow it is a brightness has changed notification. 2) Where as on (a lot of) other laptops it means a brightness up/down key was pressed, deal with it. Most of the desktop environments interpret any press as in scenario 2, and change the brightness up / down as a response to the key events, causing it to be changed twice, once by acpi-video and once by the DE. With the new default for video.use_native_backlight we will be moving even more laptops over to behaving as in scenario 2. Making the remaining laptops even more of a weird exception. Also note that it is hard to detect scenario 1 properly in userspace, and AFAIK none of the DE-s deals with it. Therefor this commit changes the default of brightness_switch_enabled to 0 making its behavior consistent with all the other backlight drivers. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Aaron Lu <aaron.lu@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> :040000 040000 5bbac8c4f3e9fd5421daf84289004c32c3217f2a 82c99a358bda6360f845b6063182d3e707ff90f0 M Documentation :040000 040000 81ed56a41130bbbea980620114ff11e3bb23ee63 a9870ba1d046bde69796060304c78dfbb1d00a1f M drivers The lack of effect for Fn-Key Brightness is due to this commit : 886129a8eebebec260165741fe31421482371006 I will test reverse these 2 commits. Thanks
Sorry for this noise, the second problem can be solved by: append="video.brightness_switch_enabled=1" in lilo.conf The only problem is the commit f82bdd0d77b6bf0dea08a1d957ab45d503f328b1 Thanks BV
Thanks for the bisect! And it really looks like relevant. Unfortunately, the commit author Kyle doesn't register an account here so I cannot assign this bug to him, I'll write an email about this with you CC-ed.
Mail sent: http://article.gmane.org/gmane.linux.drivers.platform.x86.devel/6720
Could an affected user provide an EC dump from a 3.15 kernel? Or, just the contents of register 0xe6.
I use a 3.19 kernel with patch to revert commit f82bdd0d77b6bf0dea08a1d957ab45d503f328b1 (it works fine) do you prefer 3.15 kernel or 3.19 patched kernel ? Can you explain me how I can do an EC dump ? or how i can give you the contents of register 0xe6 ? Thanks for your job, -- BV
3.19 without the patch is good. Try this: http://smackerelofopinion.blogspot.com/2011/06/dumping-contents-of-embedded-contoller.html If that doesn't work we can write a small patch to hp-wmi.c that will call ec_read and printk the data to dmesg.
Created attachment 171761 [details] patch trial
Kyle, Thanks for your patch, but it doesn't work ;-( root@bertrand:~# modprobe ec_sys root@bertrand:~# mount -t debugfs nodev /sys/kernel/debug root@bertrand:~# od -t x1 /sys/kernel/debug/ec/ec0/io 0000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * 0000200 00 00 04 00 11 01 00 05 03 c0 12 ff ff fa 0f ff 0000220 ff 01 00 00 ff 5c 2b 00 00 02 ff ff ff e2 0a e1 0000240 0a 15 05 8f 00 49 2e 6a 0f 6b 0f 71 0f 32 03 ff 0000260 ff 53 05 ff ff 64 00 80 00 64 00 ff ff 00 00 ff 0000300 ff ff ff ff ff ff ff ff ff 94 5d 26 34 03 53 ff 0000320 ff 4c 49 4f 4e 00 32 32 02 ff ff ff ff ff ff ff 0000340 3f 0c ff 00 00 d4 6e 00 00 00 00 00 00 00 00 00 0000360 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0000400 root@bertrand:~# cat /proc/ioports | grep EC 0062-0062 : EC data 0066-0066 : EC cmd Thanks for your job, BV
Created attachment 171901 [details] patch trial 2 I forgot the dump using that method doesn't print 0xe6. This will print the value to dmesg. I made a mistake on the unit type. It should work now, as long as query returns something other than 0.
err, brain fart 0xe6 in octal is 346, which is 6e in your dump. Anyway, I was just trying to verify that it's not 0 on a working kenrel.
Kyle, Thanks, your patch works. With your patch my Fn-Keys works. In dmesg, I have: bertrand@bertrand:~$ dmesg |grep hp_wmi [ 1.586483] hp_wmi: 0xe6=0x0 [ 1.587636] hp_wmi: query 0x9 returned error 0x5 bertrand@bertrand:~$ But everything works. For me, the bug can be closed if your patch is accepted in mainline kernel. Thanks for your job. Thanks to all contributors !! BV
Created attachment 172461 [details] patch trial 3 That patch is no good, I goofed by changing value from int to u8. Fortunately, there are two functions, 0xb & 0x13 that are on newer systems than your's. 0xb simply sends 1 to the buffer, so it is a good feature query.
Thanks, your new patch works fine !! I hope it works on all systems... BV
Yes, so do I. Sorry for the inconvenience. I've sent the patch to you and the mailing list for approval. Feel free to add your tested-by sig if you know how. Thank you for helping.
I have encountered this same issue on my HP Compaq 6710b. Can anyone confirm whether the patch has been merged into the mainline yet? If so, which version? I have first encountered this issue when upgrading to mint 17.2, which uses kernel version 3.16.0-38. I have since tried kernel version 3.19.0-22 as well (the highest version currently available in the mint-update tool), and neither of them solve this issue for me. Reverting to 3.13.0-57 works fine.
(In reply to Ian from comment #68) > I have encountered this same issue on my HP Compaq 6710b. Can anyone confirm > whether the patch has been merged into the mainline yet? If so, which > version? The patch is not yet merget in mainline kernel. Applying the patch to 4.1.3 works fine. I hope Kyle Evans patch will be accepted in mainline kernel. Bertrand Vieille
> The patch is not yet merget in mainline kernel. > > Applying the patch to 4.1.3 works fine. > > > I hope Kyle Evans patch will be accepted in mainline kernel. > > Bertrand Vieille Thank you for your reply. In that case I will hold off on versions past >3.16 and monitor this list until the patch has been merged.
Being reviewed on list now. Minor corrections requested.