Hide Forgot
Description of problem: My laptop has a hardware switch for the wireless. If the hardware switch is turned off at boot then RHEL6 will not enable the wireless even if I turn the hardware switch on. If the hardware switch _is_ on during boot then I can enable/disable the wireless using the switch and RHEL6 recognizes and reacts to the change. Version-Release number of selected component (if applicable): 2.6.32-19.el6.i686 How reproducible: Always Steps to Reproduce: 1. Turn off laptop 2. Disable wireless using the hardware switch 3. Turn on laptop 4. Turn on wireless using the hardware switch Actual results: Wireless is not enabled. Expected results: Wireless is enabled. Additional info: Using a Dell Latitude D420. lspci: 0c:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02) The iwl3945 module (which I assume is the wireless module) is loaded even when the switch is turned off at boot.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux major release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Major release. This request is not yet committed for inclusion.
The same thing happens on rhel 5.5 Maybe you can try this workaround. - turn on the wireless from the hw switch - right click the networkmanager icon and disable wireless - right click the networkmanager icon and enable wireless Does it find networks after that?
Alternatively "ifconfig wlan0 up" after disabling rfkill...
Please post the output of running "dmesg" immediately after disabling rfkill (i.e. enabling wireless). I don't have an iwl3945-equipped box running RHEL6, but I do have one with F-12. Both the -99.fc12 kernel and the -19.el6 (i.e. stock RHEL6 Beta) kernel running on the F-12 userland work exactly as expected (i.e. disabling rfkill causes NetworkManager to immediately start connecting). This suggests to me that this isn't a kernel issue and therefore that some userland component must be involved. Dan, any suggestions?
Also, please run "rfkill event" and turn the rfkill on and off -- post the output here...thanks!
The problem is intermittent. (In reply to comment #3) > The same thing happens on rhel 5.5 > > Maybe you can try this workaround. > - turn on the wireless from the hw switch > - right click the networkmanager icon and disable wireless > - right click the networkmanager icon and enable wireless > > Does it find networks after that? The wireless option is greyed out. (In reply to comment #4) > Alternatively "ifconfig wlan0 up" after disabling rfkill... # ifconfig wlan0 up SIOCIFFLAGS: Unknown error 132 (In reply to comment #5) > Please post the output of running "dmesg" immediately after disabling rfkill > (i.e. enabling wireless). > > I don't have an iwl3945-equipped box running RHEL6, but I do have one with > F-12. Both the -99.fc12 kernel and the -19.el6 (i.e. stock RHEL6 Beta) kernel > running on the F-12 userland work exactly as expected (i.e. disabling rfkill > causes NetworkManager to immediately start connecting). This suggests to me > that this isn't a kernel issue and therefore that some userland component must > be involved. > > Dan, any suggestions? There is no output in dmesg after I enable wireless.
Created attachment 410566 [details] rfkill output
I tested starting wireless from both a cold boot and a reboot, both failed to enable wireless when rfkill was disabled.
About the workaround I posted: it works on rhel 5.5 and Thinkpad t400
Given that this is a Dell laptop, I think this may be a duplicate of another issue that Matthew already addressed...?
i am more than happy to test any new packages
Is there anything in dmesg when you flick the switch and the wireless fails to wake up?
(In reply to comment #13) > Is there anything in dmesg when you flick the switch and the wireless fails to > wake up? Unfortunately there is not. I booted my laptop up with the switch turned off then ran: $ dmesg > dmesg.off <turned switch on> $ dmesg > dmesg.switched $ diff dmesg.off dmesg.switched # no output I booted my laptop up with the switch turned on then ran: $ dmesg > dmesg.on ( i removed the wireless mac address stuff) < turned switch off > $ dmesg > dmesg.switched.off < turned switch on > $ dmesg > dmesg.switched.off.on I've attached all of the files for reference.
Created attachment 413307 [details] dmesg outputs
Created attachment 413308 [details] dmesg output from bootup with wireless turned off
Created attachment 413309 [details] dmesg output from switching wireless on after being off at bootup
Created attachment 413310 [details] dmesg output from bootup with wireless turned on
Created attachment 413311 [details] dmesg output from switching wireless off after being on at bootup
Created attachment 413312 [details] dmesg output from switching wireless on after being switched off
Ok. In that case I don't think it's in any way related to the platform driver - that can be verified by unloading dell-laptop and checking that the switch still does nothing. Passing back to Linville.
Looks like the iwl3945 firmware isn't loaded if you boot with rfkill on...
(In reply to comment #22) > Looks like the iwl3945 firmware isn't loaded if you boot with rfkill on... Isn't that correct behavior? rfkill on means interface down and we only load firmware when interface comes up. Even so, iwl3945 is supposed to do polling of rfkill register if firmware is not loaded so rfkill status should always be available.
I am looking at comment #8 again and I cannot see how driver can help here since it seems that no matter what the rfkill switch position is the hard rfkill state is always on.
Isn't iwl3945 responsible for setting the hard rfkill state?
Created attachment 414652 [details] Debug rfkill polling It does not seem to be getting anything though. We can try something here to look into what driver is seeing Josh, could you please repeat the "booting with wireless off" test but load the iwl3945 module with "modprobe iwl3945 debug=0x63fff" - this will show us if the polling is picking anything up. In addition to this, please run with the attached patch that will show us if the polling is actually running please note that this will produce a lot of information in your logs since I expect a printout every 2 seconds.
(In reply to comment #26) > Created an attachment (id=414652) [details] > Debug rfkill polling > > It does not seem to be getting anything though. > > We can try something here to look into what driver is seeing > > Josh, could you please repeat the "booting with wireless off" test but load the > iwl3945 module with "modprobe iwl3945 debug=0x63fff" - this will show us if the > polling is picking anything up. In addition to this, please run with the > attached patch that will show us if the polling is actually running please note > that this will produce a lot of information in your logs since I expect a > printout every 2 seconds. Can you give me a quick guide on how to apply that patch? Is it something like: $ wget kernel.srpm $ rpm -Uvh kernel.srpm $ < add patch to build section and .spec file > $ rpmbuild kernel.spec # rpm -Uvh kernel Thanks
yikes ... I don't know how to do this in RedHat. John, could you please help? I'll make notes and will hopefully not need to ask again.
Josh, yes that is the basic process. If you don't already have it, the kernel SRPM is available here: ftp://ftp.redhat.com/pub/redhat/rhel/beta/6/source/SRPMS/kernel-2.6.32-19.el6.src.rpm You probably also want to add a buildid definition in the spec file. There is an example in the comments near the top of the file. Is that information sufficient for you to be able to build a kernel w/ the patch? If not, let me know...
Created attachment 414992 [details] dmesg output from bootup with wireless turned off (In reply to comment #26) > Created an attachment (id=414652) [details] > Debug rfkill polling > > It does not seem to be getting anything though. > > We can try something here to look into what driver is seeing > > Josh, could you please repeat the "booting with wireless off" test but load the > iwl3945 module with "modprobe iwl3945 debug=0x63fff" - this will show us if the > polling is picking anything up. In addition to this, please run with the > attached patch that will show us if the polling is actually running please note > that this will produce a lot of information in your logs since I expect a > printout every 2 seconds. The module was loaded at bootup so I ran: # modprobe -r iwl3945 # modprobe iwl3945 debug=0x63fff Then I tried switching the switch off (enabling wireless) $ dmesg > dmesg.out Switching the switch on and off didn't seem to change the output of dmesg. As you said, there were lots of lines added to dmesg as my system was on.
Strange ... the logs confirm that the driver is not obtaining any change in state of rfkill. Josh, when you switched rfkill back on and off ... did you perhaps do it very quickly? Note that the polling is done every two seconds, so if you swith rfkill on and off again in that time the rfkill change will not be picked up. Also, could you please provide logs with printk timing? You can obtain this when compiling with CONFIG_PRINTK_TIME
Also, 'dmesg -n 8' before the test (just to be sure)?
Created attachment 415658 [details] iwl3945 debugging files. dmesg's at various points and some rfkill logs (In reply to comment #31) > Strange ... the logs confirm that the driver is not obtaining any change in > state of rfkill. > > Josh, when you switched rfkill back on and off ... did you perhaps do it very > quickly? Note that the polling is done every two seconds, so if you swith > rfkill on and off again in that time the rfkill change will not be picked up. > > Also, could you please provide logs with printk timing? You can obtain this > when compiling with CONFIG_PRINTK_TIME I've attached the dmesg logs from my latest test with CONFIG_PRINTK_TIME enabled. I also ran rfkill in case that helps. Sorry it took so long to get this to you, I had some trouble compiling my kernel. Thanks for your help! -josh
(In reply to comment #29) > Josh, yes that is the basic process. If you don't already have it, the kernel > SRPM is available here: > > > ftp://ftp.redhat.com/pub/redhat/rhel/beta/6/source/SRPMS/kernel-2.6.32-19.el6.src.rpm > > You probably also want to add a buildid definition in the spec file. There is > an example in the comments near the top of the file. > > Is that information sufficient for you to be able to build a kernel w/ the > patch? If not, let me know... Sorry, but is there not perhaps a spot where I can just download this kernel source without having to build it? I have not looked into getting a Fedora virtual system yet, seems like this is a priority now. I am unable to reproduce this behavior in our current driver so I would like to see if I can reproduce in this kernel.
(In reply to comment #34) > Sorry, but is there not perhaps a spot where I can just download this kernel > source without having to build it? I have not looked into getting a Fedora > virtual system yet, seems like this is a priority now. Never mind, I found some space on my system in which I can install Fedora.
(In reply to comment #21) > Ok. In that case I don't think it's in any way related to the platform driver - > that can be verified by unloading dell-laptop and checking that the switch > still does nothing. Passing back to Linville. Josh, have you perhaps tried Matthew's suggestion above?
Created attachment 422150 [details] dmesg output of unloading dell-laptop/iwl3945 (In reply to comment #36) > (In reply to comment #21) > > Ok. In that case I don't think it's in any way related to the platform driver - > > that can be verified by unloading dell-laptop and checking that the switch > > still does nothing. Passing back to Linville. > > Josh, have you perhaps tried Matthew's suggestion above? I removed both dell-laptop and iwl3945 then loaded dell-laptop then iwl3945 and was able to use the rfkill switch. There are some weird messages in dmesg but at least one of them was from me running # modprobe iwl3945 dell-laptop -josh
What if you don't reload dell-laptop?
(In reply to comment #38) > What if you don't reload dell-laptop? Here's what I've discovered. If I boot up with the wireless disabled via the hardware switch I can enable my wireless with the following steps: # modprobe -r dell_laptop # modprobe -r iwl3945 <enable wireless with the switch> # modprobe iwl3945 (the firmware is loaded by iwl3945 but wireless still doesn't work) <disable wireless with the switch, wait a couple seconds> <enable wireless with the switch> SUCCESS! I hope this information helps some how.
fwiw there seems to be a similar issue with sony-laptop that can be viewed at https://bugzilla.kernel.org/show_bug.cgi?id=15303
So, where does this leave us?
related link upstream https://bugs.kde.org/show_bug.cgi?id=219703
(In reply to comment #41) > So, where does this leave us? I do not see anything driver can do here ... if driver is left on its own things seem to work. I'd like to defer to Matthew to answer this question ... especially after re-reading his comment #21.
This issue has been proposed when we are only considering blocker issues in the current Red Hat Enterprise Linux release. It has been denied for the current Red Hat Enterprise Linux release. ** If you would still like this issue considered for the current release, ask your support representative to file as a blocker on your behalf. Otherwise ask that it be considered for the next Red Hat Enterprise Linux release. **
Since RHEL 6.2 External Beta has begun, and this bug remains unresolved, it has been rejected as it is not proposed as exception or blocker. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux.
I no longer use this device so this bug can be closed in my opinion.