I have a HP/Compaq nx6110 in which the Lid switch/sensor doesn't work properly anymore in recent kernels. Sometimes it works, sometimes it doesn't. Sometimes it works for the first time and then ignores all further events. 'cat /proc/acpi/event' doesn't show anything when the lid switch is pressed or released. Sometimes, a 'button/lid' event is received when another event is produced, like plugging/unplugging AC power or pressing the power button. '/proc/acpi/button/lid/*/state' remains unchanged, either "open" or "closed", and doesn't reflect the actual state of the switch. Although I don't know exactly what I'm doing, I found that issuing the following two commands generates the missing 'button/lid' event (after closing or opening the lid) and updates its state: echo 1 > /proc/acpi/video/*/DOS echo 0 > /proc/acpi/video/*/DOS That means: I close the lid and nothing happens; then I run these two commands and the button/lid event is generated and the button state is updated. Then I reopen the lid and nothing happens; run the commands again and event/state are ok again. In fact, if I place these commands in a loop and leave it running in the background, the lid switch works as expected, but this probably is abusing something in the ACPI module. My current kernel is 2.6.35 for distro compatibility, but I've also tested with mainline 2.6.37-rc7 [1] and the very same problem exists there. The lid switch worked properly on the VERY OLD Fedora 9 kernel (2.6.25). This behavior started sometime after I moved to Ubuntu in 2009, but I can't remember the specific kernel version. Reports in [2] seems to point that a lot of HP/Compaq models present the same symptoms. This bug is a followup of bug #13263 that was closed due to insufficient data. Find attached the results from 'acpidump'. [1] http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.37-rc7-natty/ [2] https://bugs.launchpad.net/ubuntu/+bug/89860
Created attachment 41842 [details] Results from acpidump
I have same problem with Gigabyte N601. Because /proc/acpi/video is not present in the system I cannot check applicable above workaround or not. $ cat /proc/acpi/button/lib/LID0/state state: closed This result is always equals to "closed". Not depends on real lid state and AC power. Ubuntu 11.04, 2.6.38-9-generic
It's great that kernel bugzilla is back. Juliadno, I suppose the problem still exists in the latest upstream kernel, right? Sergey, I'm not sure you have the same problem. If the problem still exists in the latest upstream kernel, please file a new bug reporter for your problem and attach the acpidump of your laptop as well.
(In reply to comment #3) > Juliadno, > I suppose the problem still exists in the latest upstream kernel, right? Yes, this problem is still present in 3.0.0.14 (Ubuntu 11.10). In fact, a few new video-related bugs appeared for this notebook in other recent kernel versions. It seems that someone is pushing patches to fix video/ACPI compatibility with newer HP/Compaq models, while breaking it for older models. For example, the soft brightness control is not contiguous anymore as of 3.0 series. As you move the brightness control up or down, the actual screen brightness goes crazy, jumping from very low to very high on each step, like if the wrong bits are being set, or if they are inverted. I will open a new bug for this problem later.
Not sure if someone is still looking at this. This looks like a firmware/hardware bug to me. And on why DOS played a role here: from the ACPI table, the _DOS control method will touch C083, which may trigger _L1D to run, and the LID device will be notified there. The real problem is, on LID close, why the hardware doesn't generate any event? Can you please check after you close/open the LID, does the value in /sys/firmware/acpi/interrupts/gpe10 change? Thanks.
gpe10 is always '0 invalid'. but gpe1C changes from '6 enabled' to '12 enabled' on closing lid. My kernel is 3.2.38-generic i386.
(In reply to comment #6) > gpe10 is always '0 invalid'. I think this is a problem. 0x10 is the gpe number for EC, if it is invalid, there is no chance for EC to report event on LID. > > but gpe1C changes from '6 enabled' to '12 enabled' on closing lid. > > My kernel is 3.2.38-generic i386. Can you please try a new kernel, e.g. v3.8 or Linus' git tree? Thanks.
Also I try 3.5.0 (Ubuntu 12.04, lts-quantal package). Same problem. But I will try generic 3.8 kernel as soon as possible.
Please let me know the value of /sys/firmware/acpi/interrupts/gpe10 when you test v3.8, thanks.
Any update? Please also attach dmesg after testing v3.8, thanks.
Created attachment 99261 [details] dmesg of linux-3.8.8 I have run linux-3.8.8. No any changes. gpe10 is invalid.
Hi Sergey, Oh, I just noticed your system is different than the original reporter's, so it's meaningless to check gpe10 here. Please file a new bug about your problem, it doesn't help to track different problems in one bug page, thanks. Please attach acpidump when filing the bug, thanks.
Hi Juliano, Not sure if you are still there. Please kindly check if /sys/firmware/acpi/interrupts/gpe1D changes before/after LID close/open, and before/after you use the echo command. And for the video problem, I checked your DSDT table, it doesn't support video backlight control through ACPI, so it shouldn't be a ACPI/video change that made it not work.
Hi Aaron, I'm out of the country now, so please wait until next weekend, okay? Do you have the commit ID that should have this fixed, or a tag that I should sync at?
(In reply to comment #14) > Hi Aaron, > > I'm out of the country now, so please wait until next weekend, okay? No problem. > > Do you have the commit ID that should have this fixed, or a tag that I should > sync at? Not yet, I'm still trying to understand what is the problem.
Hello Aaron, I just tested 3.9.0, and the problem persists. button/lid events are queued until some other event (battery or ac_adapter) is emitted.
Sorry, I submitted the previous message too soon. /sys/firmware/acpi/interrupts/gpe1D doesn't change when openning or closing the lid, but it increments after I plug or unplug the AC adapter, for example (at which time the queued button/lid event is also emitted).
OK, then this is the problem. According to the BIOS asl code, when LID close/open, the gpe1D should fire and then control method _L1D will notify driver about LID status change. But obviously this doesn't happen. I have no idea what caused this problem, I would think it is related to hardware, but you said fedora 9 works that means it's not a hardware issue...
Hello Aaron, It is certainly not a hardware issue. Windows XP SP2 on the same laptop still suspends properly and immediately when I close the lid. Also, this started when I upgraded from Fedora 9 to Ubuntu 10.10, so I think it wasn't a coincidence. As a developer, I have a hunch that this may be related to initialization code, some bitmask or something else that is accidentally reconfiguring the system, at module startup, to queue these kinds of events. That is just my feeling, I still don't have much confidence on my understanding of this part of the kernel code. I'll try to find a better pair or working/non-working kernel versions (less broad than the current 2.6.25/2.6.35) so we can pinpoint more precisely which commit may have introduced it.
Hi Juliano, Is there any new finding? Thanks.
Hi Aaron, I couldn't find much. I found that 2.6.32 is also broken, but I'm having problems trying older kernels in this laptop. It seems that something changed in LVM and the current binary crashes on older kernels for some reason, so the machine won't boot at all. I would have to reinstall an older distro just to test this. I have a different primary laptop now, this one has become a spare. So I'm not so concerned about this bug now as I was in 2010. I think it would require too much work for too little benefit. If you want, you may close this bug. Thanks!