Ongoing problems with the "ath" interface - is any relief in sight??

[Ross Finlayson]

>BTW, the fact the subsequent reset failed with error 3 (HAL_EIO in ah.h)
>indicates you've got something more going on.  But since you didn't
>provide any details on what you're doing it's hard to say if you've got
>a hardware problem.  Presumably you've done basic things like swap out
>parts and/or try to reproduce the problem in a controlled environment.

Yes, I have seen these errors occur on two separate systems, with two 
different types of WiFi network hardware (but both using Atheros 
chips):

kernel: ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, 
RF2413, RF5413)
kernel: ath0: <Atheros 5212> mem 0xe1020000-0xe102ffff irq 10 at 
device 18.0 on pci0
kernel: ath0: Ethernet address: 00:80:48:3c:6c:00
kernel: ath0: mac 10.5 phy 6.1 radio 6.3

kernel: ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, 
RF2413, RF5413)
kernel: ath0: <Atheros 5212> mem 0x41400000-0x4140ffff irq 5 at 
device 9.0 on pci0
kernel: ath0: Ethernet address: 00:13:46:98:3b:13
kernel: ath0: mac 7.9 phy 4.5 radio 5.6


>  > "stuck beacon" means the tx dma of the beacon frame failed to complete
>>  in a full beacon interval.  Diagnosing such a problem requires
>>  understanding why dma failed to complete.  This usually involves
>>  checking the dma descriptor for clues and/or looking at other
>>  h/w-related state.  If you have a "memory smash" then you will see it in
>>  the descriptor contents--but I doubt it.  In my experience this problem
>>  is usually caused by feeding bogus data to the dma engine that causes it
>>  to lockup but the problem in general is very complicated and not
>  > something I can diagnose remotely.


Is there any patch that I could make to the code that could provide 
(for you) more informative error output when these errors occur?

	Ross.