Bug 106031
| Summary: | Regression in 4.2.x: in airplane mode each time I open my laptop lid | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Britt Yazel (bwyazel) |
| Component: | Platform_x86 | Assignee: | drivers_platform_x86 (drivers_platform_x86) |
| Status: | CLOSED CODE_FIX | ||
| Severity: | normal | CC: | arvidjaar, bruno.n.pagani, dvhart, fgsedgwick, gabriele.mzt, linville, shiv |
| Priority: | P1 | ||
| Hardware: | Intel | ||
| OS: | Linux | ||
| Kernel Version: | 4.2.3 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: | Journalctl output showing the wireless being disabled | ||
I believe this might have something to do with Darren Hart's pull request: https://lkml.org/lkml/2015/6/30/475 As I have a dell laptop and it is a airplane mode issue, and it just started in 4.2, attributing it to the new dell-rbtn driver seems logical. Can we attach Darren Hart to this bug? I believe there is something a bit off with the new driver that is auto-airplane moding me when I open the laptop lid, whether I like it or not. Confirmed. Blacklisting the dell_rbtn module solves this issue I'm reviewing with the dell-rbtn driver author, Pali Rohár <pali.rohar@gmail.com> on the platform-drivers-x86 mailing list. Thanks for reporting. Britt, when does key e00e (from your log) get emitted? Is that from the lid opening and closing, or are you pressing one of the other hotkeys on the XPS 13 laptop? Britt, the dell-rbtn driver is meant to support a TOGGLE or a SLIDER radio button. Does the XPS 13 have either of these? If so, in the event of a slider, which position is it in? Britt, and finally, if you raise your loglevel to 7, do you see any messages from the dell-rbtn driver? Such as "Unknown device type" or "Cannot enable device" ? Hi, I am not sure how to check on that key, but I have an airplane mode toggle that is on the key "f2" that I had been using to quickly turn my wireless back on after being put into airplane mode by the lid opening. The XPS13 does not have any wireless slider, just the f2 button toggle. Looking at my journalctl output with loglevel 7, I cannot find any messages from dell_rbtn. All that I was able to find that might be important is: /usr/lib/gdm/gdm-x-session[710]: (II) XINPUT: Adding extended input device "DELL Wireless hotkeys" (type: KEYBOARD, id 14) /usr/lib/gdm/gdm-x-session[710]: (**) Option "xkb_layout" "us" /usr/lib/gdm/gdm-x-session[710]: (II) input device 'DELL Wireless hotkeys', /dev/input/event5 is tagged by udev as: Keyboard /usr/lib/gdm/gdm-x-session[710]: (II) input device 'DELL Wireless hotkeys', /dev/input/event5 is a keyboard Ok, the e00e key can not be my F2 key. Checking in the log after reopening my screen and having airplane mode toggled on (and not yet pressing f2), and had those same 3 instances of the "unknown key e00e". And when pressing the f2 key, I got a message saying "wifi now enabled by radio killswitch" Thanks Britt, The log confirms this is using the TOGGLE type (instead of the SLIDER) type, which means we're using the input subsystem, rather than the rfkill subsystem. That's helpful. We have confirmed the e00e key is unrelated (it appears to be a battery event that Dell hasn't provided us documentation for, despite repeated requests). The problem appears to be that some dell laptops emit the radio TOGGLE event on resume, and some do not. So what appears to be happening is yours does emit the toggle event, which the dell-rbtn driver just passes on to the input subsystem, and the userspace daemons interpret that as pressing the toggle button and then enter airplane mode. We're working on a solution that accommodates this variability in the Dell firmware. Thank you very much for looking into this! That is strange that it would trigger this event on resume. The weird thing is that it seems to be only resumes triggered by screen opening, as if I suspend the computer and wake it up without closing the screen I do not trigger the airplane mode. Any chance this fix can make it in for 4.4? same issue on Latitude E5250 I saw that a big pull request made it for 4.6, any chance a solution to this was in there? There is a bunch of affected users on Arch: https://bugs.archlinux.org/task/46465 That includes me, original reporter over there. If there is any supplemental information we can provide (details about affected platforms…), please ask. Commit ff8651237f39cea60dc89b2d9f25d9ede3fc82c0 ("dell-rbtn: Ignore ACPI notifications if device is suspended") should fix this.
This commit will be applied to all the stable trees affected by the bug.
Testing with 4.6.1 and this issue appears to be fixed. I don't see any more need to keep blacklisting dell_rbtn. Cheers devs! Can confirm this too. Nice! |
Created attachment 190301 [details] Journalctl output showing the wireless being disabled This is the first kernel version in which I have encountered this issue on my dell XPS 13 with Intel centrino wireless 7260 running Archlinux x64 with Gnome 3.18. The issue is that whenever I close my laptop lid and reopen it, my laptop is in airplane mode. However putting my computer into hibernate and waking it up does not put it into airplane mode, and when first starting my computer the wireless works great. It is something coupled to the screen closing and opening. Similarly, when I switch to the 4.1.x LTS kernel, I do not have this issue, and my wireless autoconnects right when opening my lid, as it should. Here is my wireless card information: 02:00.0 Network controller: Intel Corporation Wireless 7260 (rev 6b) Subsystem: Intel Corporation Dual Band Wireless-AC 7260 Flags: bus master, fast devsel, latency 0, IRQ 46 Memory at f0400000 (64-bit, non-prefetchable) [size=8K] Capabilities: [c8] Power Management version 3 Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [40] Express Endpoint, MSI 00 Capabilities: [100] Advanced Error Reporting Capabilities: [140] Device Serial Number 5c-51-4f-ff-ff-f9-a8-17 Capabilities: [14c] Latency Tolerance Reporting Capabilities: [154] Vendor Specific Information: ID=cafe Rev=1 Len=014 <?> Kernel driver in use: iwlwifi Kernel modules: iwlwifi I have also attached a cropped Journalctl in reverse chronological order showing the time at which the wireless gets completely disabled.