Description of problem: Wireless hardware switch does not work properly on Dell Latitude 6430u. When the switch in "on" position, both wireless network and bluetooth work. When the switch is in "off" position, bluetooth is disabled but wireless network is not (the wireless card status seems to be independent from switch position). Software switchs both work for bluetooth and wireless network. Version-Release number of selected component (if applicable): $ uname -r 3.8.9-200.fc18.x86_64 How reproducible: Always reproducible (the position of the switch before booting does not affect the described behaviour). Steps to Reproduce: 1. Turn off the wireless hardware switch. 2. Notice that wireless has not been disabled while bluetooth has. Actual results: With the switch in "off" position, bluetooth is disabled while wireless is not. Expected results: With the switch in "off" position, both bluetooth and wireless should be disabled. Additional info: Same with switch on and off: $ lspci 00:00.0 Host bridge: Intel Corporation 3rd Gen Core processor DRAM Controller (rev 09) 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) 00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04) 00:16.0 Communication controller: Intel Corporation 7 Series/C210 Series Chipset Family MEI Controller #1 (rev 04) 00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (rev 04) 00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 (rev 04) 00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller (rev 04) 00:1c.0 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 1 (rev c4) 00:1c.1 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 2 (rev c4) 00:1c.5 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 6 (rev c4) 00:1d.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1 (rev 04) 00:1f.0 ISA bridge: Intel Corporation QM77 Express Chipset LPC Controller (rev 04) 00:1f.2 RAID bus controller: Intel Corporation 82801 Mobile SATA Controller [RAID mode] (rev 04) 00:1f.3 SMBus: Intel Corporation 7 Series/C210 Series Chipset Family SMBus Controller (rev 04) 02:00.0 Network controller: Intel Corporation Centrino Advanced-N 6205 [Taylor Peak] (rev 34) 03:00.0 SD Host controller: O2 Micro, Inc. Device 8221 (rev 05) With switch off: $ rfkill list all 0: phy0: Wireless LAN Soft blocked: no Hard blocked: no With switch on: $ rfkill list all 0: phy0: Wireless LAN Soft blocked: no Hard blocked: no 7: hci0: Bluetooth Soft blocked: no Hard blocked: no
Are you still seeing this with the 3.9.8 or newer kernels?
Same behavior with kernel 3.9.8 $ uname -r 3.9.8-200.fc18.x86_64
Can you attach the output of dmesg when you toggle the switch? Let's start with the iwlwifi driver as a suspect and we can go from there.
This is the dmesg output for a OFF-ON-OFF-ON cycle of the switch $ dmesg [ 611.273242] usb 1-1.4: USB disconnect, device number 6 [ 617.396782] usb 1-1.4: new full-speed USB device number 7 using ehci-pci [ 617.486408] usb 1-1.4: New USB device found, idVendor=413c, idProduct=8197 [ 617.486419] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 617.486425] usb 1-1.4: Product: BCM20702A0 [ 617.486441] usb 1-1.4: Manufacturer: Broadcom Corp [ 617.486446] usb 1-1.4: SerialNumber: 2016D89FB2D0 [ 624.223558] usb 1-1.4: USB disconnect, device number 7 [ 632.220359] usb 1-1.4: new full-speed USB device number 8 using ehci-pci [ 632.310035] usb 1-1.4: New USB device found, idVendor=413c, idProduct=8197 [ 632.310046] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 632.310052] usb 1-1.4: Product: BCM20702A0 [ 632.310056] usb 1-1.4: Manufacturer: Broadcom Corp [ 632.310073] usb 1-1.4: SerialNumber: 2016D89FB2D0
Same here on F19 with same laptop. The laptop was sold with Ubuntu version where the switch was working.
What kernel version is on Ubuntu where the switch works ? Please do dmidecode > dmi.txt and attach dmi.txt file here. Please also provide output of: lsmod | egrep "wmi|rfkill"
My output on Fedora 18 with kernel 3.9.8 is: $ lsmod | egrep "wmi|rfkill" dell_wmi 12681 0 sparse_keymap 13526 1 dell_wmi rfkill 21729 4 cfg80211,bluetooth wmi 18697 1 dell_wmi Find attached the output of dmidecode.
Created attachment 770329 [details] Output of dmidecode on Fedora 18, kernel 3.9.8
@Stanislaw: I was using the 12.04 LTS version pre-installed on the Dell Latitude 6430u. I cannot remember the version but that should be something like 3.2.0-49
I have installed rfkill to see if I can trace the issue but still no clue. $ rfkill list 0: hci0: Bluetooth Soft blocked: yes Hard blocked: no 1: phy0: Wireless LAN Soft blocked: yes Hard blocked: no Then switched ON the wireless: $ rfkill list 0: hci0: Bluetooth Soft blocked: yes Hard blocked: no 1: phy0: Wireless LAN Soft blocked: yes Hard blocked: no Also tried: rfkill event 1374223905.771616: idx 0 type 2 op 0 soft 1 hard 0 1374223905.771644: idx 1 type 1 op 0 soft 1 hard 0 But still no changes on a ON/OFF cycle.
Still having the same behavior with kernel 3.9.10, Fedora 18. $ uname -r 3.9.10-200.fc18.x86_64
Updated to the latest koji build: kernel-3.10.5-201.fc19.x86_64.rpm Still not detecting the switch.
Still same behaviour with: kernel-3.9.11-200.fc18.x86_64 kernel-3.10.6-100.fc18.x86_64 kernel-3.10.7-100.fc18.x86_64 kernel-3.10.9-100.fc18.x86_64.
Still not working on latest kernel: 3.11.2-201.fc19.x86_64
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 18 kernel bugs. Fedora 18 has now been rebased to 3.11.4-101.fc18. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 19, and are still experiencing this issue, please change the version to Fedora 19. If you experience different issues, please open a new bug report for those.
Yes I moved to Fedora 19 and I am still experiencing the same issue. $ uname -r 3.11.4-201.fc19.x86_64
Same issue with latest kernel: $ uname -r 3.11.6-201.fc19.x86_64
(In reply to Fabien Archambault from comment #9) > @Stanislaw: I was using the 12.04 LTS version pre-installed on the Dell > Latitude 6430u. I cannot remember the version but that should be something > like 3.2.0-49 Rfkill probably works on 3.2 and stopped work now due to commit from 3.5: commit a6c2390cd6d2083d27a2359658e08f2d3df375ac Author: Matthew Garrett <mjg> Date: Fri Jun 1 12:46:56 2012 -0400 dell-laptop: Remove rfkill code The interface just doesn't work on some machines, and Dell haven't been able to tell us either which machines those are or what we should be doing instead. This would be fine, except it results in userspace ending up confused and general sadness. So let's just rip it out for now. Signed-off-by: Matthew Garrett <mjg> I'll provide you test kernel with revert of that patch ...
I launched kernel build with patch revert here (compiling now): http://koji.fedoraproject.org/koji/taskinfo?taskID=6205526 Please test it.
Great, it works! :) Tested installing the following packages: kernel-3.11.8-200.bz958826.fc19.x86_64.rpm kernel-devel-3.11.8-200.bz958826.fc19.x86_64.rpm kernel-modules-extra-3.11.8-200.bz958826.fc19.x86_64.rpm The outputs of rfkill with switch in ON position are: $ rfkill list all 0: phy0: Wireless LAN Soft blocked: no Hard blocked: no 1: dell-wifi: Wireless LAN Soft blocked: no Hard blocked: no 2: dell-bluetooth: Bluetooth Soft blocked: no Hard blocked: no 4: hci0: Bluetooth Soft blocked: no Hard blocked: no while the outputs of rfkill with switch in OFF position are: $ rfkill list all 0: phy0: Wireless LAN Soft blocked: no Hard blocked: no 1: dell-wifi: Wireless LAN Soft blocked: no Hard blocked: yes 2: dell-bluetooth: Bluetooth Soft blocked: yes Hard blocked: yes Outputs of dmesg with an OFF->ON->OFF cycle: $ dmesg [ 720.592468] usb 1-1.4: new full-speed USB device number 7 using ehci-pci [ 720.682028] usb 1-1.4: New USB device found, idVendor=413c, idProduct=8197 [ 720.682035] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 720.682039] usb 1-1.4: Product: BCM20702A0 [ 720.682042] usb 1-1.4: Manufacturer: Broadcom Corp [ 720.682045] usb 1-1.4: SerialNumber: 2016D89FB2D0 [ 722.075402] iwlwifi 0000:02:00.0: L1 Enabled; Disabling L0S [ 722.082356] iwlwifi 0000:02:00.0: Radio type=0x1-0x2-0x0 [ 722.164719] IPv6: ADDRCONF(NETDEV_UP): wlp2s0: link is not ready [ 739.455361] usb 1-1.4: USB disconnect, device number 7
Ok, we can add rfkill code back to dell-laptop and use it only for whitelist systems that knot to work . Previously we enabled that by default and disable on blacklisted systems. Fabien, let me know if rfkill works on your laptop with test kernel and please provide dmidecode output if so.
http://koji.fedoraproject.org/koji/taskinfo?taskID=6213194 This kernel include sligtly modified patch. It enable Dell specific rfkill only for "Dell Latitude 6430u" laptop. Let me know if it still works. Fabien, I just reread comment 5 and realized you have exactly the same laptop, hence I don't need dmidecode info from you, fix should work for you as well.
Yes, it still works! :) Same rfkill and dmesg outputs.
I confirm it works! I hope this will be backported into the "normal" updated kernels.
Created attachment 831958 [details] 0001-Revert-dell-laptop-Remove-rfkill-code.patch
Created attachment 831959 [details] 0002-dell-laptop-Only-enable-rfkill-on-Latitudes.patch
Josh, please apply above two patches, two commits from 3.13 that fix this problem (4cc8a57425c623753b10b77b15392e5b83baa5a3 and 2a92551845bbbc8421ba908cd14bbdf065e0f454 ). Matthew Garrett, dell-laptop maintainer, is not enthusiastic regarding adding those to -stable, we have to carry them by ourselves.
Applied, thanks!
Hi, Note: I'm the author of the patches to bring back the Dell rfkill support upstream. (In reply to Josh Boyer from comment #28) > Applied, thanks! Hmm, if we're going to carry these, we should take the entire series from upstream, which also includes a bunch of bug-fixes, and adds a force_rfkill module option which allows non Latitude users to try the rfkill functionality, so that we can hopefully eventually build a better whitelist then just only allowing this on Latitudes. I've tested the entire series thoroughly on 3 different Lattitude models spanning 6 generations of Latitudes, and without the bugfixes this is going to be hit and miss on various models under various circumstances. The entire set can be found here: http://git.linuxtv.org/hgoede/gspca.git/shortlog/refs/heads/usb-next-with-dell-laptop Regards, Hans
Since that was basically a revert, I considered it safe i.e. it would not make things worse that they were before. But yes, dell specific rfkill code was removed on 3.5, hence we can broke something that was working from 3.5 since now. Josh, would you pick up patches from Hans, they are currently applied on 3.13-rc2 ? I can also post them to fedora-kernel-list if needed.
Yeah, I can pick the rest up.
OK, all added now. Thanks Hans and Stanislaw.
kernel-3.11.10-301.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/kernel-3.11.10-301.fc20
Dear Josh, would it be possible for you to submit a kernel update containing this bug-fix also for Fedora 19?
(In reply to Marco Driusso from comment #34) > Dear Josh, would it be possible for you to submit a kernel update containing > this bug-fix also for Fedora 19? Yes, eventually. You'll see a comment similar to comment #33 when it is submitted.
Package kernel-3.11.10-301.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing kernel-3.11.10-301.fc20' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-22818/kernel-3.11.10-301.fc20 then log in and leave karma (feedback).
kernel-3.11.10-301.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
kernel-3.12.5-301.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/kernel-3.12.5-301.fc20
kernel-3.12.5-200.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/kernel-3.12.5-200.fc19
kernel-3.12.5-200.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
kernel-3.12.5-302.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.