Bug 106031 - Regression in 4.2.x: in airplane mode each time I open my laptop lid
Summary: Regression in 4.2.x: in airplane mode each time I open my laptop lid
Alias: None
Product: Drivers
Classification: Unclassified
Component: Platform_x86 (show other bugs)
Hardware: Intel Linux
: P1 normal
Assignee: drivers_platform_x86@kernel-bugs.osdl.org
Depends on:
Reported: 2015-10-16 05:57 UTC by Britt Yazel
Modified: 2022-02-21 21:19 UTC (History)
7 users (show)

See Also:
Kernel Version: 4.2.3
Tree: Mainline
Regression: No

Journalctl output showing the wireless being disabled (85.71 KB, text/plain)
2015-10-16 05:57 UTC, Britt Yazel

Description Britt Yazel 2015-10-16 05:57:40 UTC
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.
Comment 1 Britt Yazel 2015-10-18 09:18:36 UTC
I believe this might have something to do with Darren Hart's pull request: 

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.
Comment 2 Britt Yazel 2015-10-18 09:34:56 UTC
Confirmed. Blacklisting the dell_rbtn module solves this issue
Comment 3 Darren Hart 2015-10-21 08:53:03 UTC
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.
Comment 4 Darren Hart 2015-10-21 09:12:20 UTC
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?
Comment 5 Darren Hart 2015-10-21 09:14:21 UTC
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?
Comment 6 Darren Hart 2015-10-21 09:17:17 UTC
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" ?
Comment 7 Britt Yazel 2015-10-21 19:20:12 UTC
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.
Comment 8 Britt Yazel 2015-10-21 19:36:09 UTC
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
Comment 9 Britt Yazel 2015-10-21 19:38:58 UTC
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"
Comment 10 Darren Hart 2015-10-22 08:12:45 UTC
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.
Comment 11 Britt Yazel 2015-10-22 16:06:28 UTC
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.
Comment 12 Britt Yazel 2015-11-16 06:00:05 UTC
Any chance this fix can make it in for 4.4?
Comment 13 Emmanuel Grumbach 2015-12-10 20:23:26 UTC
same issue on Latitude E5250
Comment 14 Britt Yazel 2016-03-24 16:15:10 UTC
I saw that a big pull request made it for 4.6, any chance a solution to this was in there?
Comment 15 Bruno Pagani 2016-04-20 11:31:18 UTC
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.
Comment 16 Gabriele Mazzotta 2016-05-30 09:36:24 UTC
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.
Comment 17 Britt Yazel 2016-06-02 16:12:38 UTC
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!
Comment 18 Bruno Pagani 2016-06-08 12:34:36 UTC
Can confirm this too. Nice!

Note You need to log in before you can comment on or make changes to this bug.