2.6.30-rc7-00149-g3218911 #151 SMP Sun May 31 16:37:42 EEST 2009 x86_64 Intel(R) Core(TM)2 CPU L7400 @ 1.50GHz GenuineIntel GNU/Linux driver iwl3945: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection Switching rfkill switch on and off doesn't work anymore, even removing iwl3945 module and readding still reports: iwl3945 0000:03:00.0: Radio Frequency Kill Switch is On: Kill switch must be turned off for wireless networking to work.
Boot with rfkill switch on: [ 16.310071] iwl3945 0000:03:00.0: Radio Frequency Kill Switch is On: [ 16.310076] Kill switch must be turned off for wireless networking to work. [ 35.453015] iwl3945 0000:03:00.0: firmware: requesting iwlwifi-3945-2.ucode [ 35.986784] iwl3945 0000:03:00.0: loaded firmware version 15.32.2.9 [ 35.987061] iwl3945 0000:03:00.0: Radio disabled by SW RF kill (module parameter) Now I turn rfkill switch off - ie wireless on: [ 279.910063] usb 5-1: new full speed USB device using uhci_hcd and address 3 [ 280.063654] usb 5-1: configuration #1 chosen from 1 choice Nothing happens: plaes@chi ~ $ /sbin/iwlist wlan0 scan wlan0 Failed to read scan data : Network is down chi ~ # iwconfig wlan0 wlan0 IEEE 802.11abg ESSID:"" Mode:Managed Frequency:2.412 GHz Access Point: Not-Associated Tx-Power=0 dBm Retry min limit:7 RTS thr:off Fragment thr:off Encryption key:off Power Management:off Link Quality:0 Signal level:0 Noise level:0 Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 When issuing wlan0 up command... chi ~ # ifconfig wlan0 up SIOCSIFFLAGS: No such device ...dmesg shows this: [ 407.213173] iwl3945 0000:03:00.0: Radio disabled by SW RF kill (module parameter) Now, when removing the module: chi ~ # rmmod iwl3945 [ 456.182632] iwl3945 0000:03:00.0: PCI INT A disabled Readd the module (rfkill switch is off - ie radio should work): chi ~ # modprobe iwl3945 [ 486.334431] iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux, 1.2.26ks [ 486.334435] iwl3945: Copyright(c) 2003-2009 Intel Corporation [ 486.334550] iwl3945 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 [ 486.334572] iwl3945 0000:03:00.0: setting latency timer to 64 [ 486.377028] iwl3945 0000:03:00.0: Tunable channels: 13 802.11bg, 23 802.11a channels [ 486.377034] iwl3945 0000:03:00.0: Detected Intel Wireless WiFi Link 3945ABG [ 486.377209] iwl3945 0000:03:00.0: irq 30 for MSI/MSI-X [ 486.378994] phy1: Selected rate control algorithm 'iwl-3945-rs' [ 490.385951] iwl3945 0000:03:00.0: firmware: requesting iwlwifi-3945-2.ucode [ 490.395500] iwl3945 0000:03:00.0: loaded firmware version 15.32.2.9 [ 490.395729] iwl3945 0000:03:00.0: Radio disabled by SW RF kill (module parameter) <-- FAIL!!! Now turn on the rfkill switch again: [ 689.954103] usb 5-1: USB disconnect, address 3 [ 689.955023] btusb_intr_complete: hci0 urb ffff8800ab85f600 failed to resubmit (19) [ 689.955034] btusb_bulk_complete: hci0 urb ffff8800ab85f480 failed to resubmit (19) [ 689.956022] btusb_bulk_complete: hci0 urb ffff8800ab85f540 failed to resubmit (19) [ 689.956478] btusb_send_frame: hci0 urb ffff8800b2e456c0 submission failed [ 690.701088] iwl3945 0000:03:00.0: Radio Frequency Kill Switch is On: [ 690.701093] Kill switch must be turned off for wireless networking to work. And off again: [ 713.910063] usb 5-1: new full speed USB device using uhci_hcd and address 4 [ 714.063800] usb 5-1: configuration #1 chosen from 1 choice
(reassigned to network-wireless) You say it "doesn't work any more". So which kernel version(s) worked OK? Thanks.
(In reply to comment #2) > You say it "doesn't work any more". So which kernel version(s) worked OK? I really don't recall whether this has actually worked before...
Just for the record, do you have an "options iwl3945 disable=1" line in /etc/modprobe.conf or one of the files in /etc/modprobe.d? From inspection, the other thing that might cause that "Radio disabled by SW RF kill (module parameter)" line in dmesg looks to be some sort of message from the firmware -- hopefully the Intel team knows about what might cause that... :-)
(In reply to comment #4) > Just for the record, do you have an "options iwl3945 disable=1" line in > /etc/modprobe.conf or one of the files in /etc/modprobe.d? No, checked it (to be sure), also looked into udev stuff, also nothing. I doubt this "disable=1" gets added by modprobe/insmod as wireless works fine when booting without rfkill switch on.
Before we point to rfkill itself, which state is iwl3945 sending to rfkill? All I see is a log where iwl3945 indicates it has disabled the radio because of the switch. So what state is the switch actually in?
(In reply to comment #6) > Before we point to rfkill itself, which state is iwl3945 sending to rfkill? Where can I get this information? > All I see is a log where iwl3945 indicates it has disabled the radio because > of > the switch. So what state is the switch actually in? When I boot, the physical switch ie - hardware radio switch is off (rfkill on), then I turned hardware switch for radio on (rfkill off). Also, confusing thing is that in dmesg iwl3945 only mentions SW Kill switch (software), but never HW or hardware switch. PS. The machine is Lenovo x60s.
(In reply to comment #7) > (In reply to comment #6) > > Before we point to rfkill itself, which state is iwl3945 sending to rfkill? > Where can I get this information? No idea, I've added Zhu Yi as CC of this bug. Perhaps he has an idea. > > All I see is a log where iwl3945 indicates it has disabled the radio > because of > > the switch. So what state is the switch actually in? > > When I boot, the physical switch ie - hardware radio switch is off (rfkill > on), > then I turned hardware switch for radio on (rfkill off). Tes, But I don't see the message where the module indicates this change.
adding Reinette
Priit, Could you please rerun your tests with rfkill debugging enabled? Please ensure driver is compiled with debug support (CONFIG_IWLWIFI_DEBUG) and then load driver with "modprobe iwl3945 debug=0x20000). Thank you
Startup - rfkill on [ 14.213534] iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux, 1.2.26kds [ 14.213538] iwl3945: Copyright(c) 2003-2009 Intel Corporation [ 14.213686] iwl3945 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 [ 14.213702] iwl3945 0000:03:00.0: setting latency timer to 64 [ 14.271562] iwl3945 0000:03:00.0: Tunable channels: 13 802.11bg, 23 802.11a channels [ 14.271568] iwl3945 0000:03:00.0: Detected Intel Wireless WiFi Link 3945ABG [ 14.271746] iwl3945 0000:03:00.0: irq 30 for MSI/MSI-X [ 14.282644] phy0: Selected rate control algorithm 'iwl-3945-rs' [ 14.283469] ieee80211 phy0: U iwl_rfkill_init Initializing RFKILL. [ 14.283478] ieee80211 phy0: U iwl_rfkill_soft_rf_kill we received soft RFKILL set to state 0 [ 14.283482] ieee80211 phy0: U iwl_radio_kill_sw_disable_radio Manual SW RF KILL set to: RADIO OFF [ 14.283527] ieee80211 phy0: U iwl_rfkill_init RFKILL initialization complete. 2 sec delay?? [ 16.283073] iwl3945 0000:03:00.0: Radio Frequency Kill Switch is On: [ 16.283077] Kill switch must be turned off for wireless networking to work. ... [ 35.376247] iwl3945 0000:03:00.0: firmware: requesting iwlwifi-3945-2.ucode [ 35.955649] iwl3945 0000:03:00.0: loaded firmware version 15.32.2.9 [ 35.955924] iwl3945 0000:03:00.0: Radio disabled by SW RF kill (module parameter) Turned rfkill off - ie broadcast on. [ 246.160054] usb 5-1: new full speed USB device using uhci_hcd and address 3 # Bluetooth [ 246.316276] usb 5-1: configuration #1 chosen from 1 choice # Bluetooth [ 246.701079] ieee80211 phy0: U iwl_bg_rf_kill Can not turn radio back on - disabled by SW switch # FAIL :) Removed the module: [ 426.904810] iwl3945 0000:03:00.0: PCI INT A disabled # Load the module: `modprobe iwl3945 debug=0x20000` [ 466.287704] iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux, 1.2.26kds [ 466.287709] iwl3945: Copyright(c) 2003-2009 Intel Corporation [ 466.287824] iwl3945 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 [ 466.287846] iwl3945 0000:03:00.0: setting latency timer to 64 [ 466.328116] iwl3945 0000:03:00.0: Tunable channels: 13 802.11bg, 23 802.11a channels [ 466.328120] iwl3945 0000:03:00.0: Detected Intel Wireless WiFi Link 3945ABG [ 466.328314] iwl3945 0000:03:00.0: irq 30 for MSI/MSI-X [ 466.329521] phy1: Selected rate control algorithm 'iwl-3945-rs' [ 466.330569] ieee80211 phy1: U iwl_rfkill_init Initializing RFKILL. [ 466.330579] ieee80211 phy1: U iwl_rfkill_soft_rf_kill we received soft RFKILL set to state 0 [ 466.330584] ieee80211 phy1: U iwl_radio_kill_sw_disable_radio Manual SW RF KILL set to: RADIO OFF [ 466.330626] ieee80211 phy1: U iwl_rfkill_init RFKILL initialization complete. [ 470.310128] iwl3945 0000:03:00.0: firmware: requesting iwlwifi-3945-2.ucode [ 470.320380] iwl3945 0000:03:00.0: loaded firmware version 15.32.2.9 [ 470.320625] iwl3945 0000:03:00.0: Radio disabled by SW RF kill (module parameter) When I checked the debugging info of the machine started with rfkill off there are two interesting lines about EEPROM which don't show up when machine started with rfkill on: [ 14.176631] iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux, 1.2.26kds [ 14.176635] iwl3945: Copyright(c) 2003-2009 Intel Corporation [ 14.176789] iwl3945 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 [ 14.176806] iwl3945 0000:03:00.0: setting latency timer to 64 [ 14.233775] iwl3945 0000:03:00.0: Tunable channels: 13 802.11bg, 23 802.11a channels [ 14.233781] iwl3945 0000:03:00.0: Detected Intel Wireless WiFi Link 3945ABG [ 14.233959] iwl3945 0000:03:00.0: irq 30 for MSI/MSI-X [ 14.237503] phy0: Selected rate control algorithm 'iwl-3945-rs' [ 14.238321] ieee80211 phy0: U iwl_rfkill_init Initializing RFKILL. [ 14.238359] ieee80211 phy0: U iwl_rfkill_init RFKILL initialization complete. ... [ 34.930040] iwl3945 0000:03:00.0: firmware: requesting iwlwifi-3945-2.ucode [ 35.208238] iwl3945 0000:03:00.0: loaded firmware version 15.32.2.9 [ 35.208734] ieee80211 phy0: U iwl3945_nic_config SW RF KILL supported in EEPROM. [ 35.208741] ieee80211 phy0: U iwl3945_nic_config HW RF KILL supported in EEPROM. [ 35.252885] Registered led device: iwl-phy0::radio [ 35.252973] Registered led device: iwl-phy0::assoc [ 35.253029] Registered led device: iwl-phy0::RX [ 35.253065] Registered led device: iwl-phy0::TX
What userspace wifi apps are you running (like network manager etc.)? From the logs it seems that userspace triggers a software (SW) rfkill when you enable hardware (HW) rfkill. This is ok, but it does not clear the SW rfkill when the HW rfkill is cleared. So, when the driver detects HW rfkill is disabled it tries to restore state but cannot because SW rfkill is still enabled. We need to find out where the SW rfkill comes from ... could you please repeat the test without your userspace wifi app running?
(In reply to comment #12) > What userspace wifi apps are you running (like network manager etc.)? yes, NetworkManager > We need to find out where the SW rfkill comes from ... could you please > repeat > the test without your userspace wifi app running? Now this is with NetworkManager disabled, killswitch on [ 14.867223] iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux, 1.2.26kds [ 14.867227] iwl3945: Copyright(c) 2003-2009 Intel Corporation [ 14.867378] iwl3945 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 [ 14.867394] iwl3945 0000:03:00.0: setting latency timer to 64 [ 14.922768] iwl3945 0000:03:00.0: Tunable channels: 13 802.11bg, 23 802.11a channels [ 14.922773] iwl3945 0000:03:00.0: Detected Intel Wireless WiFi Link 3945ABG [ 14.922948] iwl3945 0000:03:00.0: irq 30 for MSI/MSI-X [ 14.930218] phy0: Selected rate control algorithm 'iwl-3945-rs' [ 14.931030] ieee80211 phy0: U iwl_rfkill_init Initializing RFKILL. [ 14.931039] ieee80211 phy0: U iwl_rfkill_soft_rf_kill we received soft RFKILL set to state 0 [ 14.931043] ieee80211 phy0: U iwl_radio_kill_sw_disable_radio Manual SW RF KILL set to: RADIO OFF [ 14.931085] ieee80211 phy0: U iwl_rfkill_init RFKILL initialization complete. ... [ 16.931055] iwl3945 0000:03:00.0: Radio Frequency Kill Switch is On: [ 16.931060] Kill switch must be turned off for wireless networking to work. Turned radio on/Killswitch off: [ 161.660053] usb 5-1: new full speed USB device using uhci_hcd and address 3 [ 161.813568] usb 5-1: configuration #1 chosen from 1 choice [ 162.704075] ieee80211 phy0: U iwl_bg_rf_kill Can not turn radio back on - disabled by SW switch ... weird 30 second lag? [ 194.735379] iwl3945 0000:03:00.0: firmware: requesting iwlwifi-3945-2.ucode [ 194.842860] iwl3945 0000:03:00.0: loaded firmware version 15.32.2.9 [ 194.843104] iwl3945 0000:03:00.0: Radio disabled by SW RF kill (module parameter) Removed module... [ 218.052360] iwl3945 0000:03:00.0: PCI INT A disabled Loaded module again, with options: debug=0x20000 disable=0 [ 242.932932] iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux, 1.2.26kds [ 242.932937] iwl3945: Copyright(c) 2003-2009 Intel Corporation [ 242.933049] iwl3945 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 [ 242.933072] iwl3945 0000:03:00.0: setting latency timer to 64 [ 242.978060] iwl3945 0000:03:00.0: Tunable channels: 13 802.11bg, 23 802.11a channels [ 242.978066] iwl3945 0000:03:00.0: Detected Intel Wireless WiFi Link 3945ABG [ 242.978241] iwl3945 0000:03:00.0: irq 30 for MSI/MSI-X [ 242.980358] phy1: Selected rate control algorithm 'iwl-3945-rs' [ 242.981974] ieee80211 phy1: U iwl_rfkill_init Initializing RFKILL. [ 242.981985] ieee80211 phy1: U iwl_rfkill_soft_rf_kill we received soft RFKILL set to state 0 [ 242.981989] ieee80211 phy1: U iwl_radio_kill_sw_disable_radio Manual SW RF KILL set to: RADIO OFF [ 242.982043] ieee80211 phy1: U iwl_rfkill_init RFKILL initialization complete. ... again 30 seconds? [ 272.460428] iwl3945 0000:03:00.0: firmware: requesting iwlwifi-3945-2.ucode [ 272.468097] iwl3945 0000:03:00.0: loaded firmware version 15.32.2.9 [ 272.468299] iwl3945 0000:03:00.0: Radio disabled by SW RF kill (module parameter) So kill SW kill switch setting is stuck also without NetworkManager.
What platform is this? Do you know which platform driver is used by it (drivers/platform/x86)?
(In reply to comment #14) > What platform is this? Do you know which platform driver is used by it > (drivers/platform/x86)? I don't understand your question about platform: amd64/x86-64 or thinkpad_acpi And some relevant stuff from .config: CONFIG_X86_PLATFORM_DEVICES=y CONFIG_THINKPAD_ACPI=y CONFIG_THINKPAD_ACPI_HOTKEY_POLL=y CONFIG_ACPI_WMI=y
Pulled latest Linus' tree (2.6.30-05415-g03347e2) and now it works. I'm suspecting that it was Johannes' rfkill rewrite that fixed it :)
That's good to know, but not good for users of .30... Wonder what we can do for them though, we can hardly push the rewrite into -stable!
I am suspecting that thinkpad_acpi is sending SW rfkill when it sets HW rfkill but not clearing SW rfkill when it clears HW rfkill. This is what is happening from driver's perspective. I have not looked into it deeper.
Priit, I cannot understand what is going on just by looking at the thinkpad_acpi code. Could you please run it after compiling it with CONFIG_THINKPAD_ACPI_DEBUG and load it with dbg_level=0xffff ? I am also adding Henrique to help us debug this one. Henrique, what we are seeing is that when HW rfkill is enabled the driver gets both a HW and SW rfkill enable. When HW rfkill is disabled after that, only the HW rfkill is cleared and driver still thinks SW rfkill is enabled. Is this something that can be traced with thinkpad_acpi?
ThinkPad-ACPI has no provisions to control WLAN devices, Lenovo and IBM removed that on the T2x or somesuch, when they went mini-PCI (and later on, mini-PCIe). I do know where the bit to do it is in NVRAM, but the firmware support is not there on any thinkpad made since the T2x AFAIK. However, thinkpad-acpi _can_ monitor the HW rf-kill switch, which it does, and it does issue EV_SW SW_RFKILL_ALL 1/0 (event type "switch", event "switch rfkill_all") through its input device when that switch changes state (as well as on module load, when the input device is opened by someone, and during resume). An SW_RFKILL_ALL event could certainly cause either userspace or rfkill-input to SW-kill radios (the reasoning behind it being that the hardware switch might not control all radios directly). So, while thinkpad-acpi cannot be the one doing sw-rfkill on the wlan device, it can be the source of the event that is triggering the misbehavior of something else. If it is rfkill-input, you can tell it to reenable all radios when it gets an SW_RFKILL_ALL 1 (1 is radios on, 0 is radios off for that event), but that is its default mode of operation anyway. from rfkill_input.c: module_param_named(master_switch_mode, rfkill_master_switch_mode, uint, 0); MODULE_PARM_DESC(master_switch_mode, "SW_RFKILL_ALL ON should: 0=do nothing; 1=restore; 2=unblock all"); The default is to UNBLOCK_ALL, though, so maybe you don't have rfkill-input loaded, or something is screwing with that default. You might want to check that.
(In reply to comment #17) > That's good to know, but not good for users of .30... Wonder what we can do > for > them though, we can hardly push the rewrite into -stable! Is it actually worth fixing? It works in newer kernel (I assume most of distros will jump into it ASAP because of kernel modesetting), and it isn't a regression (hopefully it has been broken since the beginning). Just how many people do you expect to see who start up their (thinkpad/lenovo) laptop with rfkill enabled and their wireless will not work? Can I close this bug report, so people can spend their time working on much cooler stuff? :) In case there might still be a bug left in thinkpad_acpi's rfkill handling, then shall we move on to another bug?
Priit, This seems to be a duplicate of an issue tracked in the Redhat bugzilla - see https://bugzilla.redhat.com/show_bug.cgi?id=498622. The patch there is against 2.6.29, but can easily be ported to 2.6.30 by changing the functions modified from iwl3945_... to iwl_... This patch has not been pushed upstream. Is it possible for you to test that patch? If you have moved on already, please close this bug.
To admin: In comment #21 the user proposed to close this bug as this is an issue that can be avoided by users and this issue is also not present in kernels 2.6.31 and up due to the rfkill rewrite. Since then the user stopped responding to requests for information (asked more than a month ago). Can this bug be closed?