Bug 958826
Summary: | wireless hardware switch not working properly | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Marco Driusso <marcodriusso> | ||||||||
Component: | kernel | Assignee: | Stanislaw Gruszka <sgruszka> | ||||||||
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
Severity: | unspecified | Docs Contact: | |||||||||
Priority: | unspecified | ||||||||||
Version: | 19 | CC: | gansalmon, hdegoede, itamar, jonathan, jwboyer, kernel-maint, madhu.chinakonda, marbolangos, marcodriusso, mjg59 | ||||||||
Target Milestone: | --- | ||||||||||
Target Release: | --- | ||||||||||
Hardware: | x86_64 | ||||||||||
OS: | Linux | ||||||||||
Whiteboard: | |||||||||||
Fixed In Version: | kernel-3.12.5-302.fc20 | Doc Type: | Bug Fix | ||||||||
Doc Text: | Story Points: | --- | |||||||||
Clone Of: | Environment: | ||||||||||
Last Closed: | 2013-12-10 06:54:46 UTC | Type: | Bug | ||||||||
Regression: | --- | Mount Type: | --- | ||||||||
Documentation: | --- | CRM: | |||||||||
Verified Versions: | Category: | --- | |||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||
Embargoed: | |||||||||||
Attachments: |
|
Description
Marco Driusso
2013-05-02 13:27:04 UTC
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. |