Bug 4124

Summary:	EC confusion, wrong _Qxx methods executed
Product:	ACPI	Reporter:	Karol Kozimor (sziwan)
Component:	Other	Assignee:	acpi_other
Status:	REJECTED DUPLICATE
Severity:	high	CC:	romano.giannetti
Priority:	P2
Hardware:	i386
OS:	Linux
Kernel Version:	2.6.9, 2.6.11-rc2-bk4	Subsystem:
Regression:	---	Bisected commit-id:
Attachments:	DSDT

Description Karol Kozimor 2005-01-29 09:07:31 UTC

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.

Comment 1 Karol Kozimor 2005-01-29 09:11:17 UTC

Created attachment 4487 [details]
DSDT

Comment 2 Romano Giannetti 2005-02-15 04:36:26 UTC

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

Comment 3 Romano Giannetti 2005-02-16 02:53:53 UTC

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.

Comment 4 Romano Giannetti 2005-02-28 01:13:16 UTC

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

Comment 5 Romano Giannetti 2005-02-28 09:30:40 UTC

Current (-rc5) configuration uploaded
http://www.dea.icai.upco.es/romano/linux/vaio-conf/laptop-config.html

Comment 6 Luming Yu 2005-03-11 00:45:22 UTC

The patch at http://bugzilla.kernel.org/show_bug.cgi?id=3851#c52 is worthy 
testing, if you have EC related issue.

Comment 7 Luming Yu 2005-03-14 18:44:02 UTC


*** This bug has been marked as a duplicate of 3851 ***

Comment 8 Shaohua 2005-03-14 23:10:47 UTC

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.

Comment 9 Romano Giannetti 2005-03-18 03:13:28 UTC

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.