Re: Atheros problems

On Saturday 21 February 2004 03:24 am, Per Hallström 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 try 
to run on a mixed 11b/11g network.  The slot time and preamble are not being 
handled correctly.  Also for AP operation the 802.11 code doesn't track 
ERP/non-ERP stations and/or long/short preamble usage and doesn't implement 
the protection mechanism required by the 11g spec.  All this has been fixed 
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 expect 
things to also work ok at 5.5 and 11 Mb/s though perhaps the long/short 
preamble and/or slot time are mismatched with the AP.  You might try locking 
the card to 11b with ifconfig ath0 mode 11b; I can't recall if you'll get the 
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 
descriptor to see if the "more bit" is marked indicating multiple descriptors 
were required to receive the frame.  This can happen when garbage data is 
received on a 5212 because PHY error reception is enabled and result in 
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 code 
which isn't going to happen for a while.  If someone else wants to step up 
all the work is available in perforce.

	Sam