Date: Sun, 22 Feb 2004 11:16:57 -0800 From: Sam Leffler <sam@errno.com> To: Per =?iso-8859-1?q?Hallstr=F6m?= <spoofed@student.vxu.se>, freebsd-current@freebsd.org Subject: Re: Atheros problems Message-ID: <200402221116.57424.sam@errno.com> In-Reply-To: <7BB962D6-6460-11D8-B1A9-000A958608AA@student.vxu.se> References: <7BB962D6-6460-11D8-B1A9-000A958608AA@student.vxu.se>
next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday 21 February 2004 03:24 am, Per Hallstr=F6m wrote: > Hi everyone (hope this is the right list to send this to), > I am having various problems with the ath(4) driver. The first problem > I noted was that the card was unable to run at full speed (54 Mbps). I > first though that the problem was that the access point couldn't handle > both the 11g client and my 11b laptop. However, I put my laptop to > sleep and had the same problem. Further, a third machine on the network > (11g) works fine and reports that it is connected at 54 Mbps. There are bugs in the existing code for 11g support that appear when you tr= y=20 to run on a mixed 11b/11g network. The slot time and preamble are not bein= g=20 handled correctly. Also for AP operation the 802.11 code doesn't track=20 ERP/non-ERP stations and/or long/short preamble usage and doesn't implement= =20 the protection mechanism required by the 11g spec. All this has been fixed= =20 in my perforce branch but remains to be merged into current. > > Before I go on I should add that the access point is about 5 meters > from the computer having problems. With my 11b equipped laptop > mentioned above I can be outside the house, 80 m (250 feet or so) away, > and still have OK signal strength. According to wicontrol(8), the > signal is not terrible, the noise is fine but the quality is worse: > # wicontrol ath0 > ... > Comms quality/signal/noise: [ 0 97 0 ] > ... > > The "errors" I get when connecting to a network is something like: > ath_rate_ctl: 54M -> 48M (0 ok, 6 err, 6 retr) > ath_rate_ctl: 48M -> 36M (0 ok, 3 err, 3 retr) > ... > ath_rate_ctl: 11M -> 9M (7 ok, 9 err, 15 retr) > ath_rate_ctl: 9M -> 6M (1 ok, 17 err, 18 retr) > ath_rate_ctl: 6M -> 5M (3 ok, 10 err, 13 retr) > ath_rate_ctl: 5M -> 2M (14 ok, 3 err, 15 retr) > > After a little while it seem to remain quite stable at 1 or 2 Mbps. > However, whenever any kind of network activity occurs, there will be a > lot of "ath_start: out of xmit buffers" (am I supposed to do some kind > of tuning?). Sometimes the connections will come alive again, and > sometimes they will simply be dropped. I will also see a lot of "short > packet 14" errors: > # dmesg | grep -c "ath_rx_proc: short packet 14" > 896 When you're operating at 1 or 2 Mb/s you're using 11b operation. I'd expe= ct=20 things to also work ok at 5.5 and 11 Mb/s though perhaps the long/short=20 preamble and/or slot time are mismatched with the AP. You might try lockin= g=20 the card to 11b with ifconfig ath0 mode 11b; I can't recall if you'll get t= he=20 correct slot time/preamble operation. > > No other equipment is complaining, and I don't think there is any kind > of bad equipment emitting crap packets or anything like that. There is > no packet loss or low speed transfers between the other hosts on the > network, and not a single kind of weirdness is reported on them either. > > But, not only do I have short packets, I also have long ones. :) I am > getting reports that there are oversized frames: > ath0: discard oversize frame (ether type 7dc flags 3 len 2026 > max > 1514) > ath0: discard oversize frame (ether type 800 flags 3 len 2018 > max > 1514) > ath0: discard oversize frame (ether type f3b0 flags 3 len 2018 > max > 1514) > Yet another issue that I've fixed. The existing code isn't checking the rx= =20 descriptor to see if the "more bit" is marked indicating multiple descripto= rs=20 were required to receive the frame. This can happen when garbage data is=20 received on a 5212 because PHY error reception is enabled and result in=20 issues like this. > All the output and the attached files are captured/downloaded over the > network, so everything still "works". Sometimes the SSH session simply > stops working, but it often comes to live again (and that is when I see > a lot of whining about errors). Pretty often when scanning after a > network (which happens many times/hour), it will simply scan by the > right channel once, twice or more times before joining the network > again. It will then always drop down to 11 Mbps, or less, before any > successful data transmission can happen. > > If more information can be helpful, please let me know. Thanks. I don't think more info is the needed, just time to merge+test cod= e=20 which isn't going to happen for a while. If someone else wants to step up= =20 all the work is available in perforce. Sam
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200402221116.57424.sam>