Bug 481259
Summary: | ath9k - bit rate is always reported as 1 Mb/s | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Michal Jaegermann <michal> |
Component: | kernel | Assignee: | John W. Linville <linville> |
Status: | CLOSED NEXTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | 10 | CC: | dcbw, kernel-maint, mcgrof, quintela |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2009-06-02 13:03:08 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: |
Description
Michal Jaegermann
2009-01-23 06:11:45 UTC
Dan, is this a break-down between wireless-tools and the kernel? This is reported against rawhide, but the kernel version above is from F-10. Can you try this with a rawhide kernel? > This is reported against rawhide, but the kernel version above is from F-10. Oops! Sorry. Bugzilla interfaces strike again. > Can you try this with a rawhide kernel? Hm, this is really an F10 installation and there are limits to which I can mess with it. If dependencies are not too onerous ... > Can you try this with a rawhide kernel?
OK, I tried with kernel-2.6.29-0.78.rc3.git5.fc11.i686
'iwlist wlan0 rate' here prints
wlan0 unknown bit-rate information.
Current Bit Rate=54 Mb/s
"Unknown" but I think that correct. :-) Also iwconfig and NM information display report 54 Mb/s.
Unfortunately rfkill switch still does not work with this kernel. Bummer, but this is another issue. I guess that I will revert to f10 kernels for now.
Especially that I immediately got a number "possible circular locking dependency detected" traces.
That is back to 1 Mb/s with kernel 2.6.27.15-170.2.22.fc10.i686 from koji although it shows a correct 54 Mb/s with 2.6.29-0.22.rc4.git1.fc10.i686 from koji too. Besides /sys/class/rfkill/ bits look definitely saner with the later kernel even if I cannot get rfkill working with any kernel so far. :-( (eeepc 1002HA). I can confirm this issue with 2.6.27 in F10. Fixed with 2.6.29-rc6 from koji. ASUS notebook. Can you try a 2.6.29-based F10 kernel? http://koji.fedoraproject.org/koji/buildinfo?buildID=92572 > Can you try a 2.6.29-based F10 kernel? I did and reported results in comment #4 on 2009-02-04. That worked fine (as some other things which are broken in 2.6.27 - see bug 485322). Ok, I see...Michal, thanks...Michael, please try the kernel in comment 7... :-) kernel 2.6.29-0.53.rc7.fc10.i686 adds a new twist to to game which I do not remember seeing with 2.6.29-0.22.rc4.git1.fc10.i686. Namely when a wireless connection is established then bitrates reported by NM panel, 'iwconfig wlan0' or 'iwlist wlan0 rate' are correct although the last one prints that as: wlan0 unknown bit-rate information. Current Bit Rate=54 Mb/s OTOH with an ethernet cable connected too I will see after a while wlan0 unknown bit-rate information. Current Bit Rate=1 Mb/s and that means that a wireless connection really "dead", i.e. if I will unplug a cable then typing "on the other end" brings no reaction. Still if left alone then after a short while this connection is back in action with a reported bit-rate again at 54 Mb/s. No other indications anywhere else that something may be amiss beyond that bit-rate. Maybe it was like that before but I simply failed to notics as "1 Mb/s" was reported always? At least with 2.6.27 kernels. With 2.6.29-0.53.rc7.fc10.i686 there also seem to be much more troublesome to restore a connection after, say, wifi antenna was turned off and on again. I may need to retype an AP password although it did not change at all and it would be accepted from a keyring if that would be after a reboot with antenna on. Please keep in mind using wireless-tools is the wrong utility for checking MCS rates, work now supports reporting MCS rates with mac80211 11n based drivers however right now ath9k reports its MCS rate index from an array and not the actual MCS rate. But you can use debugfs to check the actual rate list, including PER (packet error rate). sudo mount -t debugfs debugfs /debug cat /debug/ath9k/phy0/rcstat Work to change the rate reported by ath9k is using nl80211 requires a bit more work, but wireless-tools won't ever get that information anyway. In order for Network Manager to make use of this new feature it would also have to start speaking nl80211. You may want to try with the latest ath9k: http://wireless.kernel.org/en/users/Drivers/ath9k#Getthelatestath9kdriver Also be sure to check out and install iw: http://wireless.kernel.org/en/users/Documentation/iw Like I said then, if you are using an 802.11n AP then wireless-tools won't understand the rate used. What type of connection are you establishing with your AP? > Please keep in mind using wireless-tools is the wrong utility for checking MCS > rates The original report said "That is clearly bogus" and talked about different rate reports including NetworkManager information display. OTOH, as already noted in preceding comments, with 2.6.29-... kernels this "wrong utility", and NetworkManager too, display what looks like real rates which change depending on circumstances. > if you are using an 802.11n AP ... AP is a few years old and so predates 802.11n draft. I do not think that it is able to talk this way. My comment was about MCS rates which would only happen if you are using an 802.11n AP. But you are not. What do you mean by "wifi antenna was turned off and on again". If you connect an Ethernet cable I believe by default Network Manager will prefer that over wireless so at that point hopefully the last sent and received wireless frames will have been management frames to create a disassociation. 802.11 management frames are sent at the lowest supported bitrate which would be 1Mbit/s and would explain your observations. > What do you mean by "wifi antenna was turned off and on again". There is a keyboard switch on then netbook in question. It does not work "as a system installed" but it can be made to work. It generates some event which allows to turn off and on wifi. Another possibility is to echo 0 or 1 to /sys/class/rfkill/rfkill0/state. When wifi was switched off and later switched on again it appears that there is a trouble to get an association going again. You may see: .... wlan0: direct probe to AP 00:13:10:1b:6f:68 try 1 wlan0: direct probe to AP 00:13:10:1b:6f:68 try 1 wlan0: direct probe to AP 00:13:10:1b:6f:68 try 2 wlan0: direct probe to AP 00:13:10:1b:6f:68 try 3 wlan0: direct probe to AP 00:13:10:1b:6f:68 timed out wlan0: direct probe to AP 00:13:10:1b:6f:68 try 1 wlan0: direct probe to AP 00:13:10:1b:6f:68 try 1 wlan0: direct probe to AP 00:13:10:1b:6f:68 try 2 wlan0: direct probe to AP 00:13:10:1b:6f:68 try 3 wlan0: direct probe to AP 00:13:10:1b:6f:68 timed out ..... and after a number of tries: wlan0: direct probe to AP 00:13:10:1b:6f:68 timed out wlan0: deauthenticating by local choice (reason=3) ADDRCONF(NETDEV_UP): wlan0: link is not ready or similar things. Disabling wifi in NM, and enabling it again, usually allows to get out of this. > If you connect an Ethernet cable I believe by default Network Manager will > prefer that over wireless It indeed used to behave that way. It appears that it is somewhat ambiguous in F10 and both connections can be active at the same time. That can be easily verified. > ... and would explain your observations. Not when an etherned cable is unplugged. See, for example, a comment #4 and comment #10. With 2.6.27-... kernels this is _always_ 1 Mb/s. OK thanks -- that is called an rfkill switch, it will not disable your antennas, it will tell your hardware to kill your radio, to turn it off. You may want to check to see if you see the same issues with using rfkill on newer FC kernels. If you want to stick to your current kernel and help debug issues on it please disable network manager, pkill wpa_supplicant and then simply try running things manually. This may help too: http://wireless.kernel.org/en/users/Documentation/Reporting_bugs If you are using the latest and greatest (wireless-testing or compat-wireless) you can simply send your feedback on issues to the ath9k mailing list. http://wireless.kernel.org/en/users/Drivers/ath9k#Mailinglist Please be sure to use a subject like "won't reconnect after using rfkill" It would certainly help if you help test this with wireless-testing. > OK thanks -- that is called an rfkill switch ... Yes, I know how it is called. If you are talking about turning on/off radio or antenna this comes to the same thing. > You may want to check to see if you see the same issues with using rfkill on > newer FC kernels. A behaviour is the same in all 2.6.27...fc10 and 2.6.29...fc10 kernels, up to and including 2.6.29-0.54.rc7.git3.fc10.i686, which I tried. I mean here both a behaviour of rfkill and its effects on ath9k driver. > This may help too: See bug #485322. Nothing changed there so far. Moreover whatever one can find on http://people.freedesktop.org/~hughsient/quirk/quirk-keymap-index.html does not seem to be applicable (but this is straying from the original bug report). OK, I may look at filing another one about reconnection issues but with rfkill on a funk I was not in a great hurry. This bug report was about bit rate reporting. Is this still an issue? Did you try wireless-testing? > Is this still an issue? See comment #4. It still applies, and subsequent ones, in full. If I will use one of 2.6.29-... kernels from updates-testing then rates are showing up correctly. If you will use released kernels, still at 2.6.27 level, then the only rate displayed is 1 Mb/sec. Please close this bug, even if we could fix it I don't think the patch would get merged as it wouldn't fix a bug report or oops, or regression. |