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 _______________________________________________ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
