Bug 606249
| Summary: | Intel Wireless 4965 AG or AGN Fails in Fedora 13 | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Matt Healy <matt> | ||||||||
| Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> | ||||||||
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
| Severity: | medium | Docs Contact: | |||||||||
| Priority: | low | ||||||||||
| Version: | 13 | CC: | anton, dougsland, gansalmon, itamar, jfeeney, jonathan, kernel-maint, linville, madhu.chinakonda, nobody+PNT0273897, reinette.chatre, ricardomgf, rs | ||||||||
| Target Milestone: | --- | ||||||||||
| Target Release: | --- | ||||||||||
| Hardware: | i686 | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2011-06-27 18:40:22 UTC | Type: | --- | ||||||||
| 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
Matt Healy
2010-06-21 08:46:00 UTC
Please attach the output of running 'rfkill event' and then manipulating the rfkill switch on the laptop. If there are both a physical switch (e.g. a slider along the front edge) and a "soft" switch (e.g. a key or a combination of keys on the keyboard) then please included both sets of manipulations and indicates which part of the output from rfkill corresponds to which manipulation. Matthew and Reinette, any idea why we are seeing so many variations on this theme lately? Created attachment 425765 [details]
Output of "/sbin/rfkill event"
Output of "rfkill event" attached. Manipulating the physical wireless switch on the laptop produces no output at all in "rfkill event". There is no software switch for wireless on this hardware. Can you repeat the test with hp-wmi unloaded? Created attachment 426106 [details]
/sbin/rfkill event with hp_wmi unloaded
I have removed hp_wmi and again performed /sbin/rfkill event (output attached). The output is different to earlier, but toggling the hardware switch produces no further output. Could you please try the following: - set up your system not to load hp_wmi at all ... you can do this by blacklisting it in your modprobe files - ensure driver is compiled with debug support (CONFIG_IWLWIFI_DEBUG) and load driver module with "modprobe iwlagn debug=0x63fff" Please send debugging output when you repeat the above tests. Created attachment 426409 [details]
/sbin/rfkill event with hp_wmi blacklisted and iwlagn loaded with debug
Hello, Following the above steps has got the wireless connection working perfectly. Thank you for your help with this and hope this allows you to fix the bug. Let me know if you need any further testing done. Regards Matt The log you provide does not contain any driver debugging ... but I do not believe just enabling driver debugging will just make things work so I assume it was the action of blacklisting hp_wmi. John ... I don't know what to say ... here it the third case now where getting the platform driver out of the way makes rfkill work. Any chance that one of your platform folks can take a look at this? Reinette, I'm inclined to agree that it seems like something has 'gone pear-shaped' (is that the right expression?) with platform drivers and rfkill. FWIW, there doesn't seem to be much activity in net/rfkill/. As for platform folks, Matthew is on the Cc: list already. Hopefully he has some insight? Reinette, John,
I have an HP-dv2625 laptop. Under F10 I had no problem whatsoever with the Intel Pro 4965. The card was recognized and activated without any problems or human intervention at boot-time.
I installed F13 on an external USB drive (leaving F10 on the internal drive) and came across the problem with the 4965.
So, I rebooted with F10 (from the internal drive) and to my surprise the wireless card was NOT activated and the hardware switch led remained orange. Rebooted again with F10, and again no wireless and an orange led. So I turned off the switch and then on again and voilá the led turned blue and the wireless was activated. I then disconnected the USB external drive, rebooted with F10 and now to activate the wireless card I had to cycle off-on the hardware switch. I did NOT have to do this switch cycling in F10 BEFORE installing F13. Could it be that F13 messed up something WITHIN the card firmware itself?
So, I started googling and came across this bug report. I booted the laptop with F13 (from the external drive), followed the steps (i.e. blacklisting the hp-wmi module and rebooting) and the switch led remained orange. So, I cycled the switch and the led immediately turned blue and got a working wireless card.
In summary:
1. Before installing F13, in F10 I did NOT have to cycle the wireless hardware switch to activate the wireless card. Now, after installing F13 on the external drive, I have to cycle the switch even when I boot with F10 from the internal drive.
2. Blacklisting the hp-wmi module did in fact solve the problem in F13 (albeit I have to cycle the wireless hardware switch to get the wireless card working).
Just wanted to share my experience with you in hope that it might help you debug and fix the problem.
Best Regards,
Ricardo
P.S. Booting with the wireless hardware switch in the ON position:
Before cycling the switch, "rfkill list" shows:
0: phy0: Wireless LAN
Soft blocked no
Hard blocked yes
After cycling the switch it shows:
0: phy0: Wireless LAN
Soft blocked no
Hard blocked no
1: hci0: Bluetooth
Soft blocked no
Hard blocked no
Notice how cycling the switch ALSO activates bluetooth (which was not activated before cycling the switch)
With respect to "rfkill event", just issuing the command (without moving the switch) results in:
1280859054.384801: idx 0 type 1 op 0 soft 0 hard 1
Moving the switch to the OFF position does NOT result in any output.
Moving back the switch to the ON position results in:
1280859079.096430: idx 0 type 1 op 2 soft 0 hard 0
1280859079.964645: idx 1 type 2 op 0 soft 0 hard 0
1280859079.967222: idx 1 type 2 op 2 soft 0 hard 0
I'd like to mention that I'm experiencing issues similar to Ricardo - recently I had to boot my laptop back in to Windows Vista and the wireless failed to work at all (it worked prior to my upgrade from Fedora 12 to Fedora 13). I could not find any way in Vista to activate the wireless - it was as if the laptop did not have a wireless card. Toggling the hardware switch had no effect on the WiFi (although Vista was able to activate and deactivate Bluetooth - just no WiFi). I have no idea how to retrieve debugging information about the card in Windows Vista and whether it would be any help to you. Regards, Matt Add me to the list too... wireless was working out of the box on F11, but not after I installed f13. The only difference is that my laptop is not an hp, so hp-wmi wasn't loaded and I didn't have to blacklist it. I did have to cycle the keyboard radio switch, though. This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed. |