broken TX in HEAD (AR5212)

[Adrian Chadd]

Hiya,

Ok. Please keep me posted.

I've found some annoying behaviours this weekend.

* The rx proc tasklet gets called slightly too often- if an RX
interrupt comes in whilst ath_rx_proc is running, the kernel will
preempt that thread, run ath_intr(), which will reschedule ath_rx_proc
to run. The next time it runs (which will be immediatley after the
previous one finishes), it'll discover there's nothing left in the RX
queue.

That's not too scary; just slightly wasteful.

But the annoying one:

* I'm getting TXEOL interrupts appearing (which is by design, so
that's OK) - but then when the descriptor is checked, the first
descriptor in the list shows up as HAL_EINPROGRESS - and sure enough,
the contents of that descriptor are not yet initialised. Now on my
MIPS boards the descriptors are in KSEG1 - which is supposed to be
unmapped, uncached memory. A subsequent TXEOL (from another descriptor
being pushed into the queue) or TXOK (from that descriptor completing
TX successfully) will kick the queue along.

Now I don't _think_ this is the core problem. I thought it was a
problem before but it's very likely just something that I've noticed
going slightly "odd" when I began digging into it. (Yes, I may have
spent a chunk of yesterday chasing a red herring. Sigh.)

What actually does happen is that hostapd actually boots my station
off because it fails to re-synchronise the group key. When hostapd
decides its time, it regenerates a group key and pushes it out to each
STA. It's done STA-at-a-time - ie, the STA has to ACK the new group
key. I'm seeing hostapd not "see" an ACK and it's thus getting angry
and leaving.

I'm just adding some debugging code to my tree now to see if I can
pinpoint what's going on - whether the frame is going out, whether
it's being successfully transmitted, whether the other end hears it,
whether the receive path is working .. heck, since it's all done via
raw BPF sockets, it may be some BPF related hilarity. :(



Adrian