Hardware Environment: Maxdata Pro8000X notebook, others A similar problem has been reported by several people on the acpi-devel list, all with different hardware AFAIK. Somewere between 2.6.7 and 2.6.9 handling of Emebdded Controller's _Qxx queries has changed, resulting in recent kernels losing some and mixing up other events. Pressing a certain key (i.e. Fn+F1: sleep button) should normally be associated with triggering a corresponding _Qxx method (_Q0A for the laptop in question). However, on newer kernels, the behaviour is erratic. For example, pressing Fn+F1 for the first time doesn't trigger any methods (though the SCI is delivered). This continues for a couple of keypresses. Another example, Fn+F4 and F5 (brightness down and up, _Q0D and _Q0E respectively). While pressing Fn+F4 for a couple of times does eventually run _Q0D and the brightness decreases, immediately switching to Fn+F5 still runs _Q0D (decrease) for a couple of times, only to execute _Q0E (increase) on the next keypresses. For the record, the pattern of the mix-up shows that the events are not simply cached or delayed. Furthermore, this happens to all events involving EC queries (power button, battery events), not only the ones mentioned. I'm puzzled as to how to debug this further, please ask for any additional info that might be helpful.
Created attachment 4487 [details] DSDT
I think I have a very similar problem, but I discovered some kind of regularity. I copy and paste the message I sent to lkml: When I press the suspend key on my Vaio FX701, nothing happens. It should trigger an ACPI event that, caught by acpid, run the suspend script (which show a confirmation window); and so worked in 2.6.7. Now, the really strange thing: if I press it 8 times in a row, then the event arrives. It's as if the events are queued in a 8-depth queue. If now I cancel suspend, and press another special key, like the combination to switch video output to the external VGA, all the "queued" suspend-event do arrive... this happens with the two "display switch" key, and the "suspend" key. There is no interaction with, for example, lid close event which works as should. I'm stymied. If anyone can help me with this, or simply tell me how to have more data on this, I will try to obtain all the data I can. I'm using a vanilla 2.6.11-rc1, which config is available here: http://www.dea.icai.upco.es/romano/linux/config-2.6.11rc1.txt
I was doing a bit more experiment, trying to understand the problem. I discovered two things: - although it is true that there is that strange "8 event queue", the event shows up after a while (from seconds to minutes); - you can have the event by simply pressing the sleep button and then executing 7 times "acpi -V". More puzzled than ever.
I can confirm that the problem continues with -rc5. By the way, there is a complete system description for my laptop configuration (still related to 2.6.11-rc1) here http://www.dea.icai.upco.es/romano/linux/config.txt
Current (-rc5) configuration uploaded http://www.dea.icai.upco.es/romano/linux/vaio-conf/laptop-config.html
The patch at http://bugzilla.kernel.org/show_bug.cgi?id=3851#c52 is worthy testing, if you have EC related issue.
*** This bug has been marked as a duplicate of 3851 ***
Please try to enable preempt. This possibly is the in_atomic() issue that akpm mentioned in acpi-dev list. A similar bug is Bug 4150.
Mr Luming Yu, I can confirm that the patch at http://bugzilla.kernel.org/show_bug.cgi?id=3851#c52 fixes my problem. I had to change the statement end: to end: ; in line 519 of ev.c otherwise my gcc barfed (gcc 3.4.1) but now he bug is fixed, thank you very much. I have not tried with preempt.