Bug 13689
| Summary: | ACPI: EC: input buffer is not empty, aborting transaction | ||
|---|---|---|---|
| Product: | ACPI | Reporter: | Norman Haag (haag_norman) |
| Component: | EC | Assignee: | Alexey Starikovskiy (astarikovskiy) |
| Status: | CLOSED PATCH_ALREADY_AVAILABLE | ||
| 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: | 2.6.27.23-0.1-pae | 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) |
||
Btw: Using openSuSE 11.1 (but this is not a suse related problem) 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.
Created attachment 22186 [details]
acpidump (with fixed kernel)
Created attachment 22187 [details]
dmesg (without fix but debug enabled)
Created attachment 22188 [details]
dmesg (with fix)
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. 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.
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 I think it isn't a problem in initialization, because the bug also appears at runtime. 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. (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? 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. Created attachment 22277 [details]
messages (patch1, debugmessages enabled)
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. 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.
bump bump bump 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... Created attachment 22583 [details]
dmesg (acpi_burst_enable commented out)
Commenting acpi_burst_enable out does not help. Same behaviour as before.
Created attachment 22586 [details]
move query enabling to after address read
please check this patch too
Created attachment 22594 [details] dmesg (patch2 - comment #20) Patch2 doesn't help too. (patch from comment #20) Thomas Reiniger mentiones at Novell Bugreport: You may want to try a kernel from here: ftp://ftp.suse.com/pub/projects/kernel/kotd/SLE11_BRANCH 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. Currently running the 2.6.27.31-4-pae 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. did you try kernel without pae? Hi, 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)". 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 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. That would be really confusing. Maybe theres some relation to the Fn-Key-Down detection. Going to prove that these days 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. Hi all, I have an update: currently with kernel 2.6.31.1 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. 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? I'm still getting this problem whilst using Ubuntu Karmic on the Dell Laptop. Very rarely can I change the screens brightness 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. 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) 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/ Marking as fixed. Please re-open if problem appears again. per comment #33, comment #34 and comment #35, this seems to be gone in linux-2.6.32 closed In my Ubuntu 9.10 Karmic Koala an update from 2.6.31.20 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. |
Hi 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); mutex_lock(&ec->lock); 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); end: if (ec->global_lock) acpi_release_global_lock(glk); unlock: mutex_unlock(&ec->lock); return status; }