First, let me say that madwifi-ng seems to be nicely thought out and headed in the right direction. In particular, using separate ath[n] devices for ap functions, sta functions, and raw dump functions is nice.
Alas, I have what appears to be a 100% reproducible method for producing a kernel panic. A script to demonstrate the bug can be found at
http://www.av8n.com/computer/wifi-bugs/crashme
which calls
http://www.av8n.com/computer/wifi-bugs/wifi-up
All it does is bring up two VAPs, namely ath0 (in ap mode) and ath1 (in sta mode). As far as I know, I was following the instructions as given in "man wlanconfig". (In any case, it shouldn't cause a panic, whether the instructions were followed or not.)
If you have trouble reproducing the bug, and you think it would help for me to copy down all the details of the register dump and traceback, I will do so on request. I'm not including it here, because of the effort involved; I don't have a serial console (or even a serial port) on the machine I'm using. It's a Thinkpad T42p with built-in 802.11a/b/g. I can tell you that the top of the traceback is in the madwifi modules.
Other details of interest include:
++ svn info
Path: .
URL: http://svn.madwifi.org/trunk
Repository UUID: 0192ed92-7a03-0410-a25b-9323aeb14dbd
Revision: 1346
Node Kind: directory
Schedule: normal
Last Changed Author: proski
Last Changed Rev: 1346
Last Changed Date: 2005-11-23 18:07:30 -0500 (Wed, 23 Nov 2005)
++ uname -a
Linux salvia 2.6.14.2 #6 PREEMPT Tue Nov 22 23:58:25 EST 2005 i686 GNU/Linux
++ lspci -vv | tail
0000:02:02.0 Ethernet controller: Atheros Communications, Inc. AR5212 802.11abg NIC (rev 01)
Subsystem: Unknown device 17ab:8331
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 168 (2500ns min, 7000ns max), Cache Line Size: 0x08 (32 bytes)
Interrupt: pin A routed to IRQ 11
Region 0: Memory at c0210000 (32-bit, non-prefetchable) [size=64K]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=2 PME-
Note: invoke the script as "crashme 0 1" to bring up ath0 and ath1 and exhibit the bug; interestingly, bring up either one separately (crashme 0 or crashme 1) does not cause a panic, so far as I've seen.
Sometimes the panic seems to occur immediately, and sometimes it seems to be delayed a half-second or so; I conjecture it may be tied to the amount of network traffic.