Re: [Madwifi-users] [BUG] panic in BSD branch under load with SMP and WEP
Status: Beta
Brought to you by:
otaku
Menu
▾
▴
Re: [Madwifi-users] [BUG] panic in BSD branch under load with SMP and WEP
|
From: Andrew B. <an...@cs...> - 2005-05-30 23:27:37
|
Hello again,
I now have a full backtrace. Details as before (quoted below), although I'm
now using WPA instead of plain WEP.
Also, this didn't happen when the system was loaded, so it seems it's just a
bug in the transmit path. On the other hand, I can't see much of a pattern to
the four backtraces I've now collected, the previous three seem to involve
much more of the system than this one, which is just a direct UDP transmit
from a user's socket call. Maybe there's a race with SMP, and someone is
trashing an important data structure.
I'll try running without SMP for a while and see if it recurs. Is anyone else
running on SMP and seeing panics?
Andrew
Unable to handle kernel NULL pointer dereference at virtual address 00000010
printing eip:
e0233830
*pde = 00000000
Oops: 0000 [#1]
PREEMPT SMP
Modules linked in: nfsd exportfs lockd sunrpc wlan_tkip af_packet ipv6 ide_cd
CPU: 1
EIP: 0060:[<e0233830>] Tainted: PF
EFLAGS: 00010202 (2.6.8-2-686-smp)
EIP is at zz0e373a4d+0x68/0x130 [ath_hal]
eax: 00000001 ebx: ded8da4c ecx: c0041071 edx: 000c14b7
esi: ded8d918 edi: 00000000 ebp: 00000000 esp: dedf3aa0
ds: 007b es: 007b ss: 0068
Process named (pid: 2011, threadinfo=dedf2000 task=deb95110)
Stack: 01001580 00000000 00000000 de6ad8dc de6ac000 00000800 000000dc e02716f5
ded88000 ded8da4c 00000000 00000000 ded8d918 00000800 000000a2 0000000b
00000004 00000000 00000009 0000001e 000000fa 00000000 00000001 e0244a60
Call Trace:
[<e02716f5>] ath_tx_start+0x7b5/0xbe0 [ath_pci]
[<e026d4b3>] ath_start+0x183/0x700 [ath_pci]
[<c02456c0>] qdisc_restart+0x160/0x230
[<c023541f>] dev_queue_xmit+0x26f/0x350
[<c02558b1>] ip_finish_output+0xd1/0x210
[<c0256a6b>] ip_generic_getfrag+0x4b/0xc0
[<c0257977>] ip_push_pending_frames+0x2d7/0x460
[<c02570ff>] ip_append_data+0x61f/0x7e0
[<c02762fc>] udp_push_pending_frames+0x16c/0x2a0
[<c0276852>] udp_sendmsg+0x3d2/0x760
[<c0233365>] put_cmsg+0xa5/0xd0
[<c027f31d>] inet_sendmsg+0x4d/0x60
[<c022b23d>] sock_sendmsg+0x9d/0xc0
[<c011bd1b>] load_balance_newidle+0x3b/0xc0
[<c023183c>] verify_iovec+0x3c/0xa0
[<c022ce8f>] sys_sendmsg+0x18f/0x1f0
[<c011c561>] __wake_up_common+0x41/0x70
[<c017dbe0>] inode_update_time+0xd0/0xe0
[<c016df29>] pipe_writev+0x269/0x320
[<c016e018>] pipe_write+0x38/0x40
[<c01ba182>] copy_from_user+0x42/0x70
[<c022d332>] sys_socketcall+0x242/0x260
[<c01061fb>] syscall_call+0x7/0xb
Code: 8b 57 10 81 e2 ff 7f 00 00 89 54 24 08 8b 53 10 81 e2 ff 7f
<0>Kernel panic: Fatal exception in interrupt
In interrupt handler - not syncing
NB: the module list was truncated, lsmod at boot says:
nfsd exportfs lockd sunrpc wlan_tkip af_packet ipv6 ide_cd cdrom pcspkr tsdev
mousedev evdev psmouse floppy ath_pci ath_rate_amrr wlan ath_hal tg3
firmware_class ehci_hcd uhci_hcd usbcore pci_hotplug capability commoncap
genrtc ext3 jbd mbcache ide_generic siimage piix ide_disk ide_core sd_mod
ata_piix libata scsi_mod unix font vesafb cfbcopyarea cfbimgblt cfbfillrect
On Thu, 26 May 2005 11:47 am, Andrew Baumann wrote:
> I'm getting a repeatable panic in the BSD branch, which doesn't occur in
> the HEAD (I prefer using BSD because it seems to cope better with the poor
> signal quality I have). This is on the stock debian 2.6.8-2-686-smp kernel,
> when doing large file transfers over the wireless interface.
>
> The dmesg output at load time is:
> ath_hal: 0.9.14.9 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413)
> wlan: 0.8.5.0-BSD (EXPERIMENTAL)
> ath_rate_amrr: 0.1
> ath_pci: 0.9.5.0-BSD (EXPERIMENTAL)
> ACPI: PCI interrupt 0000:04:01.0[A] -> GSI 17 (level, low) -> IRQ 177
> Build date: May 25 2005
> Debugging version (IEEE80211)
> ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
> ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps
> 24Mbps 36Mbps 48Mbps 54Mbps
> ath0: turboG rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
> ath0: H/W encryption support: WEP AES AES_CCM TKIP
> ath0: mac 5.9 phy 4.3 radio 4.6
> ath0: Use hw queue 1 for WME_AC_BE traffic
> ath0: Use hw queue 0 for WME_AC_BK traffic
> ath0: Use hw queue 2 for WME_AC_VI traffic
> ath0: Use hw queue 3 for WME_AC_VO traffic
> ath0: Use hw queue 8 for CAB traffic
> ath0: Use hw queue 9 for beacons
> Debugging version (ATH)
> ath0: Atheros 5212: mem=0xdfaf0000, irq=177
>
> I also get these two warnings when doing "iwpriv ath0 authmode 2" to enable
> WEP, but the same occurs on the HEAD so I guess they are benign:
> ath0 (WE) : Buffer for request SIOCGIWPRIV too small (16<60)
> ath0 (WE) : Buffer for request SIOCGIWPRIV too small (32<60)
>
> I have some photos of the panic (it's happened three times now) here:
> http://ab.id.au/madwifi_panic/
>
> When I get around to it I'll recompile with kernel debugging output and see
> if I can get something more useful, but I was hoping this report might help
> someone already. Let me know if you need any more info.
>
> Cheers,
> Andrew
|