Hide Forgot
Description of problem: I can't get my wifi working after booting with rf kill switch on and turning it off afterwards. Module iwl3945 has to be reloaded for wifi to work again. Version-Release number of selected component (if applicable): kernel-2.6.29.1-111.fc11.x86_64 How reproducible: always Steps to Reproduce: 1. turn rf killswitch on 2. reboot 3. turn rf killswitch off 4. try to up the interface (ip l set up dev wlan0) Actual results: wlan0 device is not working kernel thinks module has been disabled. from /var/log/messages (after the "ip l set up dev wlan0" command) kernel: iwl3945: Radio disabled by SW RF kill (module parameter) Expected results: working wlan interface after rf killswitch is turned off Additional info: It works as expected with vanilla kernel 2.6.29.2.
I forgot to mention my hw: Lenovo T61 03:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02)
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
If you unload iwl3945 module using rmmod and then load it again using modprobe, wireless card starts to work, at least for me on Lenovo R61. There just needs to be a way to make system do that automatically after switching killswitch.
Thanks for reply. I know this workaround and am glad there is a way to make my wireless work. But I'd rather see a clean fix than hard-wiring a workaround into the system. Especially when this behaviour is caused by some of fedora patches (upstream kernel worked fine).
I've noticed that my workaround doesn't work in all cases.
In rfkill subsystem switch has tree states HARD_BLOCK, SOFT_BLOCK and UNBLOCKED and can be only in one state at the same time. In iwl3945 driver are separate switches (bits) STATUS_RF_KILL_SW, STATUS_RF_KILL_HW, radio transmitter can be enabled only if both of these bits are clear. What happens: - during boot rfkill change state from UNBLOCK to SOFT_BLOCK and then again to UNBLOCK - if rfkill move to SOFT_BLOCK it set STATUS_RF_KILL_SW in driver and clear it when change to UNBLOCK - if iwl3945 driver initialize during SOFT_BLOCK and laptop killswitch is on, it change set STATUS_RF_KILL_HW and rfkill state to HARD_BLOCK (using rfkill_force_state()) - rfkill wants to change to UNBLOCK but the state is now HARD_BLOCK - so give up - killswitch on laptop change to off, iwl3945 clear STATUS_RF_KILL_HW - iwl3945 still has set STATUS_RF_KILL_SW, so not enable radio Problem not happens if during rfkill UNBLOCK->SOFT_BLOCK->UNBLOCK sequence iwl3945 driver is not initializing it's owns RF KILL internals or laptop killswitch is off. Bug can be observed in fedora due to backported linux-2.6-iwl3945-report-killswitch-changes-even-if-the-interface-is-down.patch It is also present in mainline 2.6.30 and fixed in 2.6.31-rc1 because of rewrite of rfkill subsystem in: commit 19d337dff95cbf76edd3ad95c0cee2732c3e1ec5 Author: Johannes Berg <johannes> Date: Tue Jun 2 13:01:37 2009 +0200 rfkill: rewrite After commit rfkill subsystem is mach more sane implemented and HW/SW switches are represented as separate bits line in iwl3945 dirver.
Created attachment 350247 [details] Proposed fix. This is workaround/fix of problem. In iwl3945 we disable SW switch regardless of HW switch state. We also report SW state before HW state to move rfkill subsystem to SOFT_BLOCK rather than HARD_BLOCK.
I do basic tests the patch on my laptop and generally it works. I not tested it with suspend (as KDE Hibernete button in F11 seems not work for me :-( ) Below is link to kernel with fix: http://koji.fedoraproject.org/koji/taskinfo?taskID=1446949
*** Bug 505456 has been marked as a duplicate of this bug. ***
Fedora 11 now is switching to 2.6.30 kernel. Sadly on vanilla 2.6.30.4 the rfkill with iwl3945 driver perform even worse. On my laptop after turning killswitch on and off wifi not work. Have to not use rfkill switch at all to make wifi working.
I'm closing this bug since is fixed in kernel 2.6.30.6, and F11 ships now 2.6.30.8 .
Fix confirmed, thanks.