Date: Sat, 8 Dec 2012 01:24:04 -0800 From: Adrian Chadd <adrian@freebsd.org> To: freebsd-wireless@freebsd.org Subject: Hm, somehow the fast frames code is broken (surprise) Message-ID: <CAJ-Vmok2TNPvg0Ogtz0LfWLTXkVw_GE%2B7TPn51gKLvGiUZgGPQ@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
Hi, 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..) Adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmok2TNPvg0Ogtz0LfWLTXkVw_GE%2B7TPn51gKLvGiUZgGPQ>