#182: panic: ath0=ap + ath1=sta ==> soggy cornflakes
-----------------------------------------+----------------------------------
Reporter: John Denker <[EMAIL PROTECTED]> | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: madwifi: driver | Version: trunk
Resolution: | Keywords:
-----------------------------------------+----------------------------------
Old description:
> ''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.
New description:
''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.
--
Ticket URL: <http://madwifi.org/ticket/182>
Madwifi <http://madwifi.org/>
Multiband Atheros Driver for Wireless Fidelity
