Re: CFT: new ath hal

Wilko Bulte wrote:
> On Wed, Dec 06, 2006 at 04:17:59PM -0800, Sam Leffler wrote..
>> Wilko Bulte wrote:
>>> On Wed, Dec 06, 2006 at 11:28:15AM -0800, Sam Leffler wrote..
>>>> I've placed a new hal out for testing.  I'd like to commit it after more
>>>> folks work with it so feedback would be helpful.
>>>>
>>>> http://people.freebsd.org/~sam/ath_hal-20061205.tgz
>>>>
>>>> There are numerous small bugs fixed in this version but the main change
>>>> is a split of the descriptor state so that s/w state can be placed in
>>>> cached memory when h/w state is in uncached memory.  This results in
>>>> noticeable performance gains on certain architectures.
>>>>
>>>> To use this hal you must patch the driver and rate control modules with
>>>> this:
>>>>
>>>> http://people.freebsd.org/~sam/ath-20061205.patch
>>> Seems to work fine on my laptop:
>>>
>>> ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413)
>>> ath0: <Atheros 5212> mem 0xd0210000-0xd021ffff at device 4.0 on pci2
>>> ath0: using obsoleted if_watchdog interface
>>> ath0: Ethernet address: 00:80:48:7e:16:96
>>> ath0: mac 7.8 phy 4.5 radio 5.6
>>>
>>> Anything special you want to have tested?  I use this laptop daily
>>> so it will see 'runtime' anyway..
>> I mostly care about regressions.  The code base has been stable for a
>> while so it's unlikely you'll see any obvious differences.
> 
> Well.. I now found an obvious difference.  I tried playing some avi files
> from a filesystem mounted via NFS.  With the previous hal etc this
> runs streaming video (ok, very seldom there is a small hiccup).  With the
> latest hal & patch I cannot get streaming avi play at all.  All of
> this is with identical hardware, and keeping the laptop and AP at the same
> locations.  Things like scp report the same speeds for both old and new 
> hal/driver.
> 
> What I found interesting is the beaconing difference.  No idea if this
> is related.
> 
> Working:
> 
> wb_at_chuck ~: athstats 
> 64678 tx management frames
> 16 tx frames discarded prior to association
> 49 tx stopped 'cuz no xmit buffer
> 3268 tx failed 'cuz bogus xmit rate
> 14 tx frames with rts enabled
> 64680 tx frames with an alternate rate
> 463 tx frames with 11g protection
> 2644 rx failed 'cuz of FIFO overrun
> 1 rx failed 'cuz frame too short
> 64531 rx management frames
> 2324 beacons transmitted
> 25 periodic calibration failures
> 610 rate control raised xmit rate
> 5 rate control dropped xmit rate
> 4 switched default/rx antenna
> 1 tx used alternate antenna
> Antenna profile:
> [2] tx      145 rx        1
> [3] tx    64548 rx    67527
> 
> Not working:
> 
> wb_at_chuck ~: athstats   
> 23 interrupts coalesced
> 7562 tx management frames
> 16 tx frames discarded prior to association
> 49 tx stopped 'cuz no xmit buffer
> 610 tx failed 'cuz bogus xmit rate
> 14 tx frames with rts enabled
> 7564 tx frames with an alternate rate
> 56 tx frames with 11g protection
> 1585 rx failed 'cuz of FIFO overrun
> 7515 rx management frames
> 1822627093 beacons transmitted
> 24 periodic calibration failures
> 377 rate control raised xmit rate
> 2 rate control dropped xmit rate
> 1 tx used alternate antenna
> Antenna profile:
> [2] tx       16 rx        0
> [3] tx     7561 rx     9385
> wb_at_chuck ~: 
> 

So somehow your ap appears to be sending beacon frames continuously;
very odd. What was the previous hal version that worked (ap side only)
and how is the ap setup.  Just to be sure please provide the mac+phy
revs for the card in the ap machine.

I'm guessing this is a soekris box based on the # of FIFO overrun
errors?  Your original response referred to a laptop.

	Sam