Created attachment 345981 [details] dmesg from start-up Description of problem: MacBook Pro (hardware revision 2,2) is not able to connect to WLAN on channel 13. Version-Release number of selected component (if applicable): 2.6.29.4-167.fc11.x86_64 Atheros Communications Inc. AR5008 Wireless Network Adapter [168c:0024] (rev 01) How reproducible: 100% Steps to Reproduce: 1. start-up laptop 2. get a look with NM on available networks 3. see all WLAN's expect the channel 13 one Actual results: Unable to see, and to connect to WLAN on channel 13 Expected results: Able to see and connect to WLAN on channel 13 Additional info: Connection to WLAN expect channel 12/13 are possible without problems.
Created attachment 345982 [details] output of 'iw info' 'iw info' show also not channel 12/13
You may just not be allowed to use these as per your card's regulatory settings programmed into the card's EEPROM. Please try wireless-testing or compat-wireles: http://wireless.kernel.org/en/users/Download
Luis, thanks for helping me with this bug. After reading the bug description again, I see that i missed some important information. I'm able to connect to channel 13 WLAN with Mac OS X. Therefore I'm really sure that the cards EEPROM settings allow this channels. Anyway, I try to get wireless-tesing and compat-wireles to work and get back hopefully with some results. If there anything else for the moment you're are interested in?
No, getting 'iw list' output when you use compat-wireless with wireless-regdb and crda installed will help. That's all we need.
Created attachment 346150 [details] 'iw list' with with_compat-wireless-2009-06-01 I have successfully compiled compat-wireless-2009-06-01. After reload of the ath9k module, the WLAN with Channel 13 are showing up in NM. Also the output of "iw list" shows the channel 12/13, with the old one not does. I'm also able to connect to the WLAN, but after 1 or 2 Minutes the complete system get freeze. Switching to VT1 and also ssh into it are not working. Only a power-off reboot brings the system back. There are no information's in the /var/log/messages. Is there any debug switch that my be helpfully? Or should I open a separate bug for this issue?
Created attachment 346151 [details] Downgrade BUG_ON for rc on ath9k Please try this patch on top of compat-wireless.
Created attachment 346225 [details] messages with kernel warnings Applied on top of compat-wireless with patch -p0 < /home/arxs/Download/rc.patch on file drivers/net/wireless/ath/ath9k/rc.c. After recompile and unload/load of ath9k the system don't freeze, but they appear many kernel warnings with a trace. Please find the attached /var/log/messages.
Created attachment 346337 [details] Lock private rc structure in ath9k Please give this patch a shot instead. I get a lockdep warning on this and I'm trying to cure that getting feedback as to whether it fixes your issue would help.
Created attachment 346504 [details] /var/log/messages after applying patch "Lock private rc structure in ath9k" Recompile compat-wireless-2009-06-01 ath9k with the "Lock private rc structure in ath9k" patch also cause kernel warnings. After load of ath9k and connect to the WLAN the connection is established, I'm able to ping the router, but when the load on the link grow, for example start to browsing the web, a kernel warning appear and the connection get lost and get only back after the reload of ath9k. It a title bit strange that NM show also after a kernel warning a signal strange in the icon and says that we already connected with the WLAN.
Created attachment 346592 [details] Downgrade assert, use lowest rate for now Thanks -- please try this one, we just downgrade the assert and use the lowest rate for now. Unfortunately locking did not seem to resolve the issue anyway.
Created attachment 346600 [details] Slightly modified from the previous patch Please try this patch. if it runs fine please try then with: modprobe ath9k debug=0x00001000 Anyway I think this is a decent work around for now, I'm going to clean that rc.c stuff up, its too convoluted right now.
Trying the patch (attachment id=346600) with compat-wireless as of 2009-06-01 I got this error: compat-wireless-2009-06-05% patch -p1 < ../../rc_4.patch patching file drivers/net/wireless/ath/ath9k/debug.h patching file drivers/net/wireless/ath/ath9k/rc.c /home/arxs/Download/linux_wireless/compat-wireless-2009-06-01/drivers/net/wireless/ath/ath9k/rc.c: In function ‘ath_rc_ratefind_ht’: /home/arxs/Download/linux_wireless/compat-wireless-2009-06-01/drivers/net/wireless/ath/ath9k/rc.c:758: error: ‘struct ath_softc’ has no member named ‘debug’ make[5]: *** [/home/arxs/Download/linux_wireless/compat-wireless-2009-06-01/drivers/net/wireless/ath/ath9k/rc.o] Error 1 make[4]: *** [/home/arxs/Download/linux_wireless/compat-wireless-2009-06-01/drivers/net/wireless/ath/ath9k] Error 2 make[3]: *** [/home/arxs/Download/linux_wireless/compat-wireless-2009-06-01/drivers/net/wireless/ath] Error 2 make[2]: *** [/home/arxs/Download/linux_wireless/compat-wireless-2009-06-01/drivers/net/wireless] Error 2 make[1]: *** [_module_/home/arxs/Download/linux_wireless/compat-wireless-2009-06-01] Error 2 make[1]: Leaving directory `/usr/src/kernels/2.6.29.4-167.fc11.x86_64' make: *** [modules] Error 2 Also problems with compat-wireless as of 2009-06-05 compat-wireless-2009-06-05% patch -p1 < ../../rc_4.patch patching file drivers/net/wireless/ath/ath9k/debug.h patching file drivers/net/wireless/ath/ath9k/rc.c In file included from /home/arxs/Download/linux_wireless/compat-wireless-2009-06-05/drivers/net/wireless/ath/ath9k/hw.c:21: /home/arxs/Download/linux_wireless/compat-wireless-2009-06-05/drivers/net/wireless/ath/ath9k/ath9k.h:469: error: field ‘ops’ has incomplete type make[5]: *** [/home/arxs/Download/linux_wireless/compat-wireless-2009-06-05/drivers/net/wireless/ath/ath9k/hw.o] Error 1 make[4]: *** [/home/arxs/Download/linux_wireless/compat-wireless-2009-06-05/drivers/net/wireless/ath/ath9k] Error 2 make[3]: *** [/home/arxs/Download/linux_wireless/compat-wireless-2009-06-05/drivers/net/wireless/ath] Error 2 make[2]: *** [/home/arxs/Download/linux_wireless/compat-wireless-2009-06-05/drivers/net/wireless] Error 2 make[1]: *** [_module_/home/arxs/Download/linux_wireless/compat-wireless-2009-06-05] Error 2 make[1]: Leaving directory `/usr/src/kernels/2.6.29.4-167.fc11.x86_64' make: *** [modules] Error 2 Maybe it's a lot easier to use git for this, but I'm total screw up with git. Can you give me some hints for how to compiling this successfully? Thanks for your patience with me!
Created attachment 346731 [details] Try #2 at patch What you found was a bug, I forgot to #ifdef out some debug stuff. Try this one.
Created attachment 346732 [details] A lot of rc cleanups You can also this other series of patches. It has the previous patch I just posted along with some other cleanups. Testing appreciated. Keep in mind if you want to enabling debugging you will need to modify config.mk on compat-wireless to enable ath9k debugging: CONFIG_ATH9K_DEBUG=y
Created attachment 346775 [details] dmesg with patch 346732 and ath9k debug=0x00001000 Try the last patch (346732) against compat-wireless-2009-06-01 CONFIG_ATH9K_DEBUG=y set in config.mk to enable debugging. after "make unload" modprobe ath9k debug=0x00001000 again, kernel warnings, but at least, the connection was stable. Sometimes the ping grows up to 4000ms (if a kernel warning appears), but no package get lost. Please find attached the dmesg with the kernel warnings and ath9k module in debug mode.
Created attachment 346987 [details] fix rc assert bug OK drop the patches I've given you so far and try this new one. Its 3 in 1 file. No need to use a debug module parameter as I'm pretty certain where this is happening now. This actually fixes the issue. Please report back.
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
(In reply to comment #16) > Created an attachment (id=346987) [details] > fix rc assert bug > > > OK drop the patches I've given you so far and try this new one. Its 3 in 1 > file. No need to use a debug module parameter as I'm pretty certain where this > is happening now. This actually fixes the issue. > > Please report back. Please apologise for the very late response, but my day job holds my tide at the moment. Anyway, the given patch (id=346987) fix all my problems. After 1 hour playing with big traffic amount on the interface shows up no kernel warning. Thank you very much for you fast and excellent help! -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
For the record F12 doesn't have an issue.
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. 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 '11'. 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 11'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 11 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 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 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.