I've started seeing panics in the fast frames code in FreeBSD-HEAD.
It's quite possible this has been here a while; I've heard rumours
about this dating back to last year.

The reason? Because I was doing iperf tests between
AR5212/AR5413/AR5414 NICs and the HAL/driver enables the fast frames
support. Which was working fine (which I'm honestly shocked about!) -
except that there are two rather grr-y bugs:

* upon a node purge, there's a panic inside m_free() from
ieee80211_ff_node_cleanup(), where it dereferences a pointer
0xdeadc0de. So there's some use-after-free nonsense going
* the TX staging code panics when flushing the staging queue; it
claims the staging queue is empty when it shouldn't be.

The latter is likely due to r227352 - Bernhard and I shuffled the code
around to make the TX AMPDU state be per-TID rather than per-AC. I may
have screwed something up in the mapping and it's checking the wrong
staging queue.

It doesn't show up with the 802.11n NICs because they disable the fast
frames HAL support. (The chips support fast frames just fine, for what
it's worth.)

Anyway. If you've ever seen his panic, please let me know. I'm not
going to disable fast frames; I'm going to try and figure out why it's
busted and then fix it up. Fast frames for legacy atheros cards
speaking to an 802.11n AP is conceptually just fine.

(This just resurrects my desire to extend ath_rate_sample to have a
third packet 'size', for aggregates and fast frames packets..)

freebsd-wireless@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Reply via email to