Bug 71221
| Summary: | ACPI events stop working after a few minutes | ||
|---|---|---|---|
| Product: | ACPI | Reporter: | AnAkkk (anakin.cs) |
| Component: | Other | Assignee: | drivers_platform_x86 (drivers_platform_x86) |
| Status: | CLOSED INVALID | ||
| Severity: | normal | CC: | aaron.lu, alan, jlee, jwrdegoede, lenb |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 3.14-rc4 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: | kernel log | ||
KDE doesn't detect anymore that I'm on battery either if I unplug the cable, might be related. Ok, this actually isn't related to 3.14-rc4, I've tried an older kernel and the issue is the same. It worked fine until a few days ago, so I have no idea what happened.
The "unknown key" errors are actually normal, I checked older kernel logs and I had them as well, and the key was working fine.
This error shows up every time on boot, seem related:
Error for wireless request "Set Power Management" (8B2C) :
SET failed on device wlp3s0 ; Operation not supported.
Wireless is no longer turned on when the computer starts, it used to be.
And upower no longer detects when I plug out the power cord and my laptop is on battery, unless I restart it (systemctl restart upower.service).
Ok, I think that the older kernel (3.13.5, which isn't that old) I tested on, had the same commit that caused these issues. I've started bisecting and it now works fine. I'll continue tomorrow to find out the bad commit. Well this makes no sense, sometimes it works, sometimes it doesn't. Actually, it seem to work for a few seconds after my desktop show up (battery events, wireless key and brightness key show up in acpi_listen) and then it just stops working. I disabled my display manager (KDM) and just tried in a VT, and the events are just not captured. It works fine for some events such as volume up/down Fn keys. I've tried restarting acpid, didn't change anything. I've tried with 3.14-rc3 where it used to work fine, and the issue is the same. I have no idea how to debug this now. I've tried with 3.12.1, the issue is the same: it works for a while, everything show up in acpi_listen, and then it just stops working, the acpi events are no longer sent. My computer keeps overheating since I have this problem, I guess it affects my fan as well. I've tried on an old OpenSuse live cd: same issue. I've been using linux for a few years now, and never had this issue until now. Everything works fine under Windows 7. Well I'm not sure why you've changed regression to Yes, as it doesn't seem like one after all, considering I could reproduce the issue on older kernels (3.12, and my opensuse livecd was 3.7). It seems to be some sort of race condition I guess, I just have no idea why it started happening a few days ago and everything has always worked fine before. Since my last message I've reinstalled 3.14-rc4, haven't had any issues so far, and now I'm on 3.14-rc5, no issues either, but I suspect that it'll come back from time to time. Is there anything I can do to provide some debug info when the issue shows up again? ACPI does not have any part in your regular keys on your keyboard. If those are not working, then you are having a keyboard or input layer issue. The simplest way to test the acpi input flow is probably to use the power button, since it always should provoke an ACPI event (and you should see the ACPI line in /proc/interrupts increment each time you press it.) Does your power button reliably work in the latest kernel, and also the previous kernels where you are having all of these issues? The backlight and brightness keys do produce an acpi event in acpi_listen though. When they weren't working, these events were not produced. Do you mean that my DE (KDE) might be doing something with the keys, so they end up not showing up in acpi_listen ? What about the battery acpi events (switching from battery to AC or AC to battery not being detected) ? Currently, everything works, and I have not changed anything: backlight keys, wireless keys, power button and switching battery/AC do increment the count in /proc/interrupts. Considering the issue is quite random, I'm pretty sure it'll come back sooner or later. I'm still on 3.14-rc5, and it works fine on 3.13.5 as well. Yesterday, I had the issues on this later one, and I just can't reproduce them now. Hi AnAkkk, (In reply to AnAkkk from comment #4) > Well this makes no sense, sometimes it works, sometimes it doesn't. > Actually, it seem to work for a few seconds after my desktop show up > (battery events, wireless key and brightness key show up in acpi_listen) and > then it just stops working. > Please add acer-wmi driver to the blacklist of modprobe, e.g. /etc/modprobe.d/blacklist Then we can check does this issue caused by acer-wmi? (In reply to Lee, Chun-Yi from comment #10) > Hi AnAkkk, > > (In reply to AnAkkk from comment #4) > > Well this makes no sense, sometimes it works, sometimes it doesn't. > > Actually, it seem to work for a few seconds after my desktop show up > > (battery events, wireless key and brightness key show up in acpi_listen) > and > > then it just stops working. > > > > Please add acer-wmi driver to the blacklist of modprobe, > e.g. /etc/modprobe.d/blacklist > > Then we can check does this issue caused by acer-wmi? Will do. Won't that have side effects though ? I remember blacklisting it once to try to solve backlight issues, and I needed to press twice my wireless key every time before it made any effect. (In reply to AnAkkk from comment #11) > (In reply to Lee, Chun-Yi from comment #10) > > Hi AnAkkk, > > > > (In reply to AnAkkk from comment #4) > > > Well this makes no sense, sometimes it works, sometimes it doesn't. > > > Actually, it seem to work for a few seconds after my desktop show up > > > (battery events, wireless key and brightness key show up in acpi_listen) > and > > > then it just stops working. > > > > > > > Please add acer-wmi driver to the blacklist of modprobe, > > e.g. /etc/modprobe.d/blacklist > > > > Then we can check does this issue caused by acer-wmi? > > Will do. Won't that have side effects though ? I remember blacklisting it > once to try to solve backlight issues, and I needed to press twice my > wireless key every time before it made any effect. Yes, it possible have side effect, but at least we can test your wireless key should works. Well, I have only been able to reproduce the issue on my OpenSUSE livecd so far...which runs kernel 3.7. I doubt I'll be able to blacklist acer-wmi on a live cd though ? Ok, I'm blind, there was actually a place to enter modprobe.blacklist=acer_wmi. I can confirm my wireless key works after blacklisting it (I have to press it twice though). But: - The wireless key doesn't make any acpi event in acpi_listen (is this normal? it usually does when it works fine) - Battery/AC state change is still not detected (no event in acpi_listen either) - Backlight keys not working either (no event in acpi_listen either, and yes I made sure to only have /sys/class/backlight/intel_backlight by setting acpi_osi=Linux and acpi_backlight=vendor) 1 Looks like on all kernels you have tested, this bug can occur randomly, right? 2 Did you try another distro's live cd? 1. Indeed, but it seems to happens 100% of the time on that live cd. 2. No, but I'll do with a more up to date one. I haven't tried yet with another live cd, but I've just had the issue again with 3.14-rc7. First time it happens in 3 weeks. Restarted my computer 3 times, the issue is still here. I haven't changed anything. It's really weird, it doesn't happen in weeks and now it happens every time? I still have the problem 95% of the time since a few days ago. My PC keeps overheating, I don't think it's fan related after all but it's due to the CPU frequency scaling which I guess is managed by ACPI, and it doesn't downclock when my CPU is too hot. *Seem* to work on an Ubuntu 14.04 live cd. I have only tried twice though, so maybe it could still break in some conditions. Or maybe it's related to some kernel options that Arch has and Ubuntu hasn't. It's been happening 100% of the time for the past month on my Arch install. The issue stopped after I disabled the laptop mode tools and dkms systemd services a few weeks ago. I reenabled the dkms systemd service, and now the issue is back after a reboot. How could the dkms service cause acpi events to not work? Or this is still some weird "race condition", as the dkms service delays boot somehow. Hi AnAkkk, The dkms service is likely building and installing some broken out of tree driver which is making a mess of things. Can you check if you've anything installed which is actually using dkms ? Regards, Hans Hi, Thanks for the reply. I only have the nvidia driver and virtualbox which use dkms. I reenabled it so I wouldn't need to do a "dkms autoinstall" every time I have a kernel update. The modules were already built at the time I reenabled dkms though, and there were no kernel updates, so I guess dkms shouldn't have tried to compile anything? Best regards, AnAkkk Hi, (In reply to AnAkkk from comment #23) > Hi, > > Thanks for the reply. > > I only have the nvidia driver and virtualbox which use dkms. I reenabled it > so I wouldn't need to do a "dkms autoinstall" every time I have a kernel > update. > > The modules were already built at the time I reenabled dkms though, and > there were no kernel updates, so I guess dkms shouldn't have tried to > compile anything? I don't know dkms very well, but maybe if the service is not enabled the drivers also won't get loaded, or atleast the virual box one won't get loaded (I believe the nvidia driver will load the driver itself if not already done). Either way if you're using those kernel drivers, and things break with them and not without them then there is nothing the Linux kernel community can do, go complain to nvidia and / or virtual box. Regards, Hans Thanks. I had no idea that dkms was trying to load the modules after compiling/installing them (ArchLinux wiki doesn't seem to mention it), but you're right, I checked the script and it does try to load them as well. I think I actually found out the issue: I had both virtualbox-host-dkms and virtualbox-guest-dkms packages installed, and this is a host machine. dkms was trying to load the guest ones as well, and it seems like they were responsible for breaking ACPI. I have uninstalled the package and it seems to work fine with dkms enabled now. Sorry for wasting your time. I can't explain why I had the issue on my openSUSE Live CD though, I doubt they have these virtualbox guest modules on it, but who knows. I'll close this bug. |
Created attachment 127571 [details] kernel log After upgrading to 3.14-rc4, my wireless key no longer works. This is what shows up in dmesg: 52.674581] atkbd serio0: Unknown key pressed (translated set 2, code 0x93 on isa0060/serio0). [ 52.674589] atkbd serio0: Use 'setkeycodes e013 <keycode>' to make it known. [ 52.679232] atkbd serio0: Unknown key released (translated set 2, code 0x93 on isa0060/serio0). [ 52.679235] atkbd serio0: Use 'setkeycodes e013 <keycode>' to make it known. My backlight keys no longer work either. I could fix them by using video.use_native_backlight=1 since 3.13, which only leaves intel_backlight in /sys/class/backlight. It still does that, but the keys have no effect, and there is no error message. I've tried to use acpi_osi=!Windows 2012 but that didn't change anything. Everything was working fine on 3.14-rc3. I have an Acer Aspire 5742G laptop.