Bug 13689

Summary: ACPI: EC: input buffer is not empty, aborting transaction
Product: ACPI Reporter: Norman Haag (haag_norman)
Component: ECAssignee: Alexey Starikovskiy (astarikovskiy)
Severity: high CC: acpi-bugzilla, alinfal, astarikovskiy, awalton, bv3000, chinmaykamat, clemplantier, federico.chia, lenb, pablo.martin-gomez, tomek, zdravko_s_s
Priority: P1    
Hardware: IA-32   
OS: Linux   
Kernel Version: Subsystem:
Regression: No Bisected commit-id:
Attachments: acpidump (with fixed kernel)
dmesg (without fix but debug enabled)
dmesg (with fix)
check status register
dmesg (applied patch1 - comment #7)
messages (patch1, debugmessages enabled)
boot.msg (patch1, debugmessages enabled)
messages (patch1 and fix, debugmessages enabled)
dmesg (acpi_burst_enable commented out)
move query enabling to after address read
dmesg (patch2 - comment #20)

Description Norman Haag 2009-07-01 22:16:49 UTC

on my new Dell Studio 1555 I got the following issue:

On a fresh boot I'm able to change brightness via brightnesskeys and ac-adapter is detected properly, but as soon as the following error appears:

ACPI: EC: input buffer is not empty, aborting transaction

brightness control is no longer possible. Even the detection whether an ac-adapter or not is attached fails.

I found that commenting the "goto end;" in ec.c (see below) workarounds this problem. It may be something similar like the MSI Force-Polling. Maybe you could find some better fix for that issue (I'm not that kernel-specialist at all :) )

Best Regards
Norman Haag

static int acpi_ec_transaction(struct acpi_ec *ec, struct transaction *t,
                               int force_poll)                           
        int status;                                                      
        u32 glk;                                                         
        if (!ec || (!t) || (t->wlen && !t->wdata) || (t->rlen && !t->rdata))
                return -EINVAL;                                             
        if (t->rdata)                                                       
                memset(t->rdata, 0, t->rlen);                               
        if (ec->global_lock) {                                              
                status = acpi_acquire_global_lock(ACPI_EC_UDELAY_GLK, &glk);
                if (ACPI_FAILURE(status)) {                                 
                        status = -ENODEV;                                   
                        goto unlock;                                        
        if (ec_wait_ibf0(ec)) {                                             
                pr_err(PREFIX "input buffer is not empty, "                 
                                "aborting transaction--\n");                
                status = -ETIME;                                            
                //goto end;                                                 

        status = acpi_ec_transaction_unlocked(ec, t, force_poll);
        if (ec->global_lock)                                     
        return status;                                           
Comment 1 Norman Haag 2009-07-01 22:17:39 UTC

Using openSuSE 11.1 (but this is not a suse related problem)
Comment 2 Alexey Starikovskiy 2009-07-01 22:49:59 UTC
Please attach the output from acpidump and dmesg.
Please uncomment "#define DEBUG" in ec.c and attach dmesg with debugging information with and without your changes.
There is spec saying that driver should start transaction only if EC is ready ("input buffer full" flag is cleared). Your changes essentially drop this rule, so we must make sure that EC expects this.
Comment 3 Norman Haag 2009-07-03 10:20:04 UTC
Created attachment 22186 [details]
acpidump (with fixed kernel)
Comment 4 Norman Haag 2009-07-03 10:28:21 UTC
Created attachment 22187 [details]
dmesg (without fix but debug enabled)
Comment 5 Norman Haag 2009-07-03 10:32:01 UTC
Created attachment 22188 [details]
dmesg (with fix)
Comment 6 Norman Haag 2009-07-03 10:33:03 UTC
Here is your requested data. Don't worry about the "--" at the end of the errormessage. I just put that in ec.c to see if my changes are applied.
Comment 7 Alexey Starikovskiy 2009-07-07 17:43:28 UTC
Created attachment 22249 [details]
check status register

Please check if this patch too helps your system.
It is dangerous to disable input buffer check for all transactions, when you seem to need it only once at driver init.
Comment 8 Norman Haag 2009-07-07 20:27:49 UTC
Created attachment 22250 [details]
dmesg (applied patch1 - comment #7)

applied your patch but it didn't fix the problem. same situation as before: as soon as the error appears brightness control is gone
Comment 9 Norman Haag 2009-07-07 20:31:14 UTC
I think it isn't a problem in initialization, because the bug also appears at runtime.
Comment 10 Alexey Starikovskiy 2009-07-07 21:15:58 UTC
Norman, please uncomment "#define DEBUG" at the beginning of drivers/acpi/ec.c --this is the only debug option I'm interested in. Please post dmesg with this debug info and with/without patches. Please also enable printing of timestamps.
Comment 11 Norman Haag 2009-07-07 21:31:09 UTC
(In reply to comment #10)
> Norman, please uncomment "#define DEBUG" at the beginning of
> drivers/acpi/ec.c
> --this is the only debug option I'm interested in. Please post dmesg with
> this
> debug info and with/without patches. Please also enable printing of
> timestamps.

actually i enabled DEBUG with patch1 applied and . do i have to set additional make-parameters?
Comment 12 Alexey Starikovskiy 2009-07-07 21:44:09 UTC
with enabled "#define DEBUG" driver starts to print protocol info as in acpi_ec_read_status()/acpi_ec_read_data(). All your dmesg files don't have a string of such protocol output. May be DYNAMIC_DEBUG kernel config option somehow interferes -- make sure you have it disabled.
Comment 13 Norman Haag 2009-07-08 22:48:35 UTC
Created attachment 22277 [details]
messages (patch1, debugmessages enabled)
Comment 14 Norman Haag 2009-07-08 22:51:29 UTC
Created attachment 22278 [details]
boot.msg (patch1, debugmessages enabled)

Finally here's my messages with patch1 (comment #7). I also attached my boot.msg, because the error occoured during boottime.

I'll also add my messages with debugmessages and my fix tomorrow.
Comment 15 Norman Haag 2009-07-16 19:19:20 UTC
Created attachment 22379 [details]
messages (patch1 and fix, debugmessages enabled)

the missing data. kernelmessages with patch1 and fix applied. sorry for the long time it took, but i didnt have much time these days.
Comment 16 Norman Haag 2009-07-28 18:37:41 UTC
Comment 17 Norman Haag 2009-08-02 14:42:00 UTC
bump bump
Comment 18 Alexey Starikovskiy 2009-08-02 21:58:03 UTC
Could you please check if disabling acpi_ec_burst_enable() function call in drivers/acpi/ec.c:630 helps?
From the log you've submitted it looks like query command (0x84) is issued quite often by driver and in some cases it causes input buffer stall in EC...
Comment 19 Norman Haag 2009-08-03 10:24:39 UTC
Created attachment 22583 [details]
dmesg (acpi_burst_enable commented out)

Commenting acpi_burst_enable out does not help. Same behaviour as before.
Comment 20 Alexey Starikovskiy 2009-08-03 12:33:08 UTC
Created attachment 22586 [details]
move query enabling to after address read

please check this patch too
Comment 21 Norman Haag 2009-08-03 20:04:48 UTC
Created attachment 22594 [details]
dmesg (patch2 - comment #20)

Patch2 doesn't help too. (patch from comment #20)
Comment 22 Norman Haag 2009-08-12 15:54:06 UTC
Thomas Reiniger mentiones at Novell Bugreport:

You may want to try a kernel from here:
There have been some fixes in the EC area. This is also a 2.6.27 kernel and
should at some time get the official 11.1 update kernel.
-> Also re-assigning this to Alexey, our EC expert.
Comment 23 Norman Haag 2009-08-22 14:51:50 UTC
Currently running the kernel and the problem still exists.

The NB also has the ability (in Windows) to disable charging of the battery on next reboot. Maybe this is something related to that issue.
Comment 24 Alexey Starikovskiy 2009-08-22 15:09:58 UTC
did you try kernel without pae?
Comment 25 Clément Plantier 2009-08-28 16:36:13 UTC

FYI, I'm experiencing the same problem with the same machine (Dell Studio 1555). 
The brightness control works fine during a little while, then I got the "ACPI: EC: input buffer is not empty, aborting transaction" message in dmesg, and the brightness control is no longer working.

Also I'm running the Debian packaged kernel "linux-image-2.6.30-1-686-bigmem (2.6.30-6)".
Comment 26 A. Walton 2009-08-29 15:41:59 UTC
Another update, Studio 1555, still present in 2.6.31:
[ 2256.160102] ACPI: EC: input buffer is not empty, aborting transaction

Ubuntu Linux 2.6.31-8-generic #28-Ubuntu SMP Thu Aug 27 14:43:30 UTC 2009 i686 GNU/Linux
Comment 27 Federico Chiacchiaretta 2009-09-13 14:10:52 UTC
Hi all,
I was experiencing the same behaviour has described before, but I found a way to make it working.
Among BIOS options of my Dell studio 1555 there is one to choose the default behaviour of multimedia keys (i.e. "Multimedia keys first" vs "Function keys first"); if I set this option to "Multimedia keys first" changing brightness works as well as detection of ac_adapter events.
The downside is that to use shortcuts like Alt+F4 I actually have to press Alt+Fn+F4, which is hard to get used to.
Comment 28 Norman Haag 2009-09-13 15:22:26 UTC
That would be really confusing. Maybe theres some relation to the Fn-Key-Down detection. Going to prove that these days
Comment 29 Federico Chiacchiaretta 2009-09-13 15:35:40 UTC
I just noticed that after some time of usage the same ACPI error appears in dmesg, and brightness control and ac_adapter events stop working. Sorry for previous post, I actually didn't get anything better.
Comment 30 Federico Chiacchiaretta 2009-09-29 13:28:50 UTC
Hi all,
I have an update: currently with kernel I got brightness control and ac_adapter events working by appending noapic option at kernel command line. After almost 4 hours of usage I got no "ACPI: EC: input buffer is not empty, aborting transaction" error in dmesg, while without noapic error appeared at boot time or shortly after. Hope this can help.
Comment 31 zdravko_s_s 2009-10-19 13:03:16 UTC
Some update. Under Windows in the event viewer I can see that I receive the following message a couple of times a day:
: The embedded controller (EC) did not respond within the specified timeout period. This may indicate that there is an error in the EC hardware or firmware or that the BIOS is accessing the EC incorrectly. You should check with your computer manufacturer for an upgraded BIOS. In some situations, this error may cause the computer to function incorrectly.

Don't know whether this is connected. Maybe it is a BIOS problem?
Comment 32 Antonio 2009-10-30 00:54:29 UTC
I'm still getting this problem whilst using Ubuntu Karmic on the Dell Laptop. Very rarely can I change the screens brightness
Comment 33 Federico Chiacchiaretta 2009-11-22 16:25:54 UTC
A quick update: just installed kernel 2.6.32-rc8 from http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.32-rc8/ (AFAIK this is vanilla kernel compiled for ubuntu) and the problem is finally fixed.
Comment 34 Pablo Martin-Gomez 2009-11-29 18:56:34 UTC
I've tested with a Fedora 2.6.32-rc8 kernel, and it eventually seems to be fixed (well, after one hour of uptime, no "ACPI: EC: input buffer is not empty, aborting transaction" appears)
Comment 35 tomek 2009-12-02 14:31:01 UTC
I confirm:
 * this bug still occurs on Dell Studio 1555 on Ubuntu Karmic with kernel 2.6.31-15 (from ubuntus repo)
 * it seems to be fixed on 2.6.32-rc8 from http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.32-rc8/
Comment 36 Alexey Starikovskiy 2009-12-24 11:44:46 UTC
Marking as fixed. Please re-open if problem appears again.
Comment 37 Len Brown 2010-01-15 21:27:04 UTC
per comment #33, comment #34 and comment #35,
this seems to be gone in linux-2.6.32
Comment 38 AlbanK 2010-04-25 10:27:15 UTC
In my Ubuntu 9.10 Karmic Koala an update from to 2.6.32 from http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.32-rc8/ resolved the problem ( brightness and fn keys and acp too) in Notebook Dell Studio 1555.