[Madwifi-users] [BUG] Kernel trap in interrupt handler

[David G. <dav...@bt...>]

I have a wireless network using WRAP boards and Senao 5343 cards.  In managed
mode they seem to work fine, but in Managed mode they trap in an interrupt 
handler.  This is causing me real distress - not to mention embarrassment, the 
end user had to be persuaded to consider an open source solution.

The trap is:-

Initializing random number generator...Unable to handle kernel NULL pointer 
dereference at virtual address 000001f8
 printing eip:
c02221b4
*pde = 00000000
Oops: 0000 [#1]
Modules linked in: ath_pci ath_rate_onoe wlan ath_hal eeprom lm77 i2c_sensor 
scx200_acb i2c_core yenta_socket scx200_wdt rtc unix
CPU:    0
EIP:    0060:[<c02221b4>]    Tainted: PF  VLI
EFLAGS: 00010293   (2.6.9)
EIP is at skb_release_data+0x34/0xa0
eax: c10af1e0   ebx: 00000000   ecx: c10af1e0   edx: 000001f8
esi: c39f9540   edi: c10bc800   ebp: c3f16000   esp: c38f1934
ds: 007b   es: 007b   ss: 0068
Process S55urandom (pid: 874, threadinfo=c38f0000 task=c3e7c560)
Stack: c39f9540 c38a63c0 c022222b c39f9540 00000000 c02222c8 c39f9540 c3f163f0
       c4848519 c39f9540 c38a8000 c3f163f0 c3f16000 c3f163f0 c3f16000 c1224bc0
       c48486b4 c3f16000 c3f16f14 c3f16000 c3f16efc c3f16000 c3f16ee4 c3f16000
Call Trace:
 [<c022222b>] kfree_skbmem+0xb/0x20
 [<c02222c8>] __kfree_skb+0x88/0x100
 [<c4848519>] ath_tx_processq+0x169/0x250 [ath_pci]
 [<c48486b4>] ath_tx_tasklet_q0123+0x44/0x90 [ath_pci]
 [<c01165db>] tasklet_action+0x3b/0x60
 [<c01163e3>] __do_softirq+0x83/0xa0
 [<c0116427>] do_softirq+0x27/0x30
 [<c01059e5>] do_IRQ+0xc5/0xe0
.....

I have a test rig, but unfortunately this does not show the problem, but both
the APs in the field exhibit the symptom.  The client machines do not.

I have tried two CVS snapshots (I am running Debian unstable, kernel 2.6.9 and
I created .deb files from the CVS snapshots), one from 2004Dec02 and the 
other from 2004Dec22.

>>>>>>>>>>>>>>>>>>>>>>
UPDATE.  I did some more experimenting, and found a difference between
the field units and the ones on the bench.  The SSID was different, and in 
fact of a different length.  The bench one was simple and short, the field 
ones were 30 and 32 characters long.  When I changed the bench ones to
the longer of the two field ones, it trapped in the manner above.  So it 
looks as though somewhere is overrunning a buffer when a long SSID is
used at an AP, quite possibly somewhere in interrupt handling but not
necessarily.  As I understand it SSIDs are allow to be up to (and including)
32 characters long.
>>>>>>>>>>>>>>>>>>>>>>

Anyone got any ideas, I am getting desparate.

David