Red Hat Bugzilla – Bug 599679
[REGRESSION] acpi-ec-add-delay-before-write patch disrupts ACPI events Clevo M720R
Last modified: 2013-04-05 11:40:55 EDT
The Fedora 13 kernels (188.8.131.52-85 through 184.108.40.206-112) don't seem to generate ACPI events in response to pressing the sleep button or closing the lid. This worked OK with the Fedora 12 series of kernels, in the versions with the multibyte EC access patches applied. (This is somewhat odd since these patches were presumably merged upstream. However, I've got another kernel here which has a patchset based off vanilla 2.6.33. This does work OK without any explicit multibyte EC patches.)
OK, this is actually caused by acpi-ec-add-delay-before-write.patch (a kernel built without it works fine). This is on a Clevo M720R. I'll add a note to this effect on https://bugzilla.kernel.org/show_bug.cgi?id=14733 .
Still present in kernel-220.127.116.11-142.rc1.fc13.x86_64. Is any further info needed to help make this patch work without disrupting operation on my notebook?
Yay, appears to be working again with kernel-18.104.22.168-147.fc13.x86_64. Please don't break it in future! ;)
Ack! Sorry, guys --- false closure on this. kernel-22.214.171.124-147.fc13.x86_64 does NOT fix this issue. What happened is that I warm-booted this kernel from one that works properly, and the sleep button worked.
Cold-booting any current Fedora kernel *after removing the battery briefly* results in a non-functioning lid and sleep button. I still need to drop the delay patch to get things working.
Please alter status as appropriate.
The same with kernel-126.96.36.199-147.fc13.x86_64. On closer inspection, it seems the disruption to ACPI is more widespread than I initially reported. As well as no lid an sleep button events, changes to the power supply state (e.g. plugging in/removing AC adapter) are not detected, either.
Still present with kernel-188.8.131.52-29.fc13.x86_64.
Still present with kernel-184.108.40.206-56.fc13.x86_64.
Still present in kernel-220.127.116.11-46.fc14.
The disruptive patch is still there in kernel-2.6.36-1.fc15, please re-work it so the kernel is both bootable and keeps events on other notebooks.
I have just finished the same debugging that i guess that you concluded.
I am running on a Clevo M767TU
Still present in 18.104.22.168-90.fc14
I guess the trouble with this patch is that it's the lesser of two evils... without it, some machines refuse to boot. I've added the tracker to the kernel.org Bugzilla entry; the devs are aware of our issue, which I think is why the patch has not gone upstream.
Disruptive patch still present in kernel-22.214.171.124-0.fc15.x86_64
I just removed it from f16. For f15, it's a tough call because for people who currently have systems that boot that need it, we would regress for them.
If we can figure out a better approach in f16, we'll backport and then drop this in 15 too.
I upgraded from F15 to F16 some time ago and since that moment my laptop (Acer Aspire 5735Z) has been experiencing problems, unless I appended acpi=off to boot parameters.
After few minuts of use ACPI refuses to work. Neither AC/DC nor battery are recognized, backlight cannot be changed, and dmesg shows a flood of messages containing following information:
ACPI: EC: input buffer is not empty, aborting transaction
ACPI Exception: AE_TIME, Returned by Handler for [EmbeddedControl]
ACPI Error: Method parse/execution failed
Reboot doesn't work and also after powering it off my laptop doesn't want to boot unless I remove the battery for a moment before trying to power it on.
It took me some time to find out if there is a way for my laptop to run without having to have the ACPI system disabled. I was trying out different boot parameters, different kernels from different distributions and then I noticed this bugreport.
I applied changes from this patch to the new kernels 3.1.8 and now 3.1.9 and recompiled them. Since I moved to my recompiled kernel (the only change was this patch) I haven't experienced any of the abovementioned problems anymore.
Is there a chance of readding changes introduced with this patch to Fedora kernels so that they both work for my Acer and don't generate problems with other equipment like Clevo?
I know there are other people affected by this bug in other systems so the most benefits could be achieved by fixing this issue upstream but I don't know whom it should be reported to.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.
(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)
More information and reason for this action is here: