Latest working kernel version: 2.6.27
Earliest failing kernel version: 2.6.28-rc
This appears to be a problem with the rate table; mac80211 is complaining that rate is out of bounds. Indeed it is -1 aka uninitialzed for that combination of band and rate index. I have the following via printk in ath5k_tasklet_rx:
rxs.rate_idx = -1
sc->curband->band = 0 (2 ghz)
rs.rs_rate = 0 <-- that looks wrong
Reported by kerneloops:
WARNING: at /srv/devel/kernel/net/mac80211/rx.c:2203
Modules linked in:
Pid: 0, comm: swapper Not tainted 2.6.28-rc1-wl #46
<IRQ> [<c0170c50>] handle_fasteoi_irq+0x0/0xe0
---[ end trace 8ac847f454371229 ]---
This triggers since 63266a6535... "ath5k: rates cleanup". Particularly in hw_to_driver_rix(), if "something went wrong" it would fall back to the basic rate index of 1, whereas now it will return -1 and trigger the WARN_ON.
Not sure yet whether or not hw rate index of 0 is valid and we just don't know about it, or there's some error condition we aren't catching earlier.
Easiest way to trigger this incidentally is to just run kismet without joining a network. In recent kernels it happens almost immediately, on older stuff it can take up to 15 minutes.
Created attachment 18576 [details]
Fix detection of jumbo frames
More digging and I found that these were jumbo frames, and our code for discarding them was horribly broken. This patch fixes the WARN_ON and replaces it with the intended error message. However there may be a separate bug leading to the fact that we now get tons of these.
Handled-By : Bob Copeland <email@example.com>
Patch : http://lkml.org/lkml/2008/11/2/157
Ignore-Patch : http://lkml.org/lkml/2008/11/2/157
Patch : http://marc.info/?l=linux-kernel&m=122576849517013&w=4
Fixed by: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=c793033945bea23d7a6e0d8d94b2da6603e02af2