More 'resource' problems with "ath0"

[Sam Leffler]

Ross Finlayson wrote:
> 
>> Please do not cross-post.
> 
> My apologies.  Now that it's established that this problem is specific
> to the "ath" driver, and not to more general FreeBSD networking code,
> I'll restrict future postings to "freebsd-mobile" only.
> 
>> The transmit queue is full; you need to understand why.  Basic info
>> includes the card info (dmes|grep ath) and ifconfig output.
> 
> I've seen the problem happen on two different machines, with two
> different interface cards (although both with Atheros chipsets):
> 
> Machine1:
> %dmesg | fgrep ath
> ath_hal: 0.9.16.16 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413)
> ath0: <Atheros 5212> mem 0xe1020000-0xe102ffff irq 10 at device 18.0 on
> pci0
> ath0: Ethernet address: 00:80:48:3c:6c:00
> ath0: mac 10.5 phy 6.1 radio 6.3
> 
> %ifconfig ath0
> ath0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>         inet 66.80.0.4 netmask 0xfffffff0 broadcast 66.80.0.15
>         inet6 fe80::280:48ff:fe3c:6c00%ath0 prefixlen 64 scopeid 0x5
>         ether 00:80:48:3c:6c:00
>         media: IEEE 802.11 Wireless Ethernet autoselect mode 11b <hostap>
>         status: associated
>         ssid LIVE555 channel 3 bssid 00:80:48:3c:6c:00
>         authmode OPEN privacy OFF txpowmax 38 protmode CTS burst
> dtimperiod 1
>         bintval 100
> 
> Machine 2:
> %dmesg|fgrep ath
> ath_hal: 0.9.16.16 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413)
> ath0: <Atheros 5212> mem 0x41400000-0x4140ffff irq 5 at device 9.0 on pci0
> ath0: Ethernet address: 00:13:46:98:3b:13
> ath0: mac 7.9 phy 4.5 radio 5.6
> 
> %ifconfig ath0
> ath0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>         inet 66.80.62.41 netmask 0xfffffff8 broadcast 66.80.62.47
>         inet6 fe80::213:46ff:fe98:3b13%ath0 prefixlen 64 scopeid 0x4
>         ether 00:13:46:98:3b:13
>         media: IEEE 802.11 Wireless Ethernet autoselect mode 11b <hostap>
>         status: associated
>         ssid LIVE555 channel 3 bssid 00:13:46:98:3b:13
>         authmode OPEN privacy OFF txpowmax 36 protmode CTS burst
> dtimperiod 1
>         bintval 100
> 
> 
>>   It usually helps to explain how you make your problem to occur--if
>> you can identify something you are doing.
> 
> No, unfortunately there's nothing specific that seems to reproduce this
> - just some communication to and/or from a remote client.
> 
>>   Past that there are tools in src/tools/tools such as ath/athstats
>> for dumping the driver statistics.
> 
> If there's anything specific that I can run (at the time I see the
> problem) that may help identify the problem, please let me know.
> 

Are any of the stations associated to these systems operating in power
save mode?  Is there some reason you have the cards locked to 11b?  If
not, you should be able to let them operate in 11g.

	Sam