Re: linux-wlan-ng 0.2.5 and linux 2.4.34 panic on disconnect

Hi

Just done a bit more debugging:

I built the same version of kernel, without *any* patches and with the 
"-g" debugging option (I saw this on every gcc line). Rebuilt prism 
driver against this new kernel...

I booted the problem system single user, made sure that our internal 
proprietary module was not loaded and then loaded the prism2_usb driver.

No "ifup wlan0" has been run at this stage.

Here's what I found:

1) Insert WIFI device.

2) Get lots of these in dmesg:

hfa384x_usbin_ctlx(0): Causality violation: please reboot Universe, or 
email [email protected]

hfa384x_usbin_ctlx(0): Causality violation: please reboot Universe, or 
email [email protected]

hfa384x_usbin_ctlx(0): Causality violation: please reboot Universe, or 
email [email protected]

skb_p80211_to_ether: ENCAP frame too large (2940 > 1514)

skb_p80211_to_ether: ENCAP frame too large (2940 > 1514)


3) Pull and reinsert device several time - no crash, but lots of 
whineage in dmesg.

4) "ifup wlan0" to give it a link and an IP - which it gets.

5) Pull device.

6) *Now* we crash the system with the same kernel panic - in an 
interrupt handler, with task "swapper" being the current context.

I still get a hex call trace (no symbol resolution). I don't have my 
mobile phone link cable, so the photo will get taken on Monday.

In the meantime, how do I convert the addresses to symbols or get an 
idea where in the code the panic occurred?

Many thanks indeed for you kind advice.

Tim

Solomon Peachy wrote:
> On Thu, Jan 11, 2007 at 09:30:13PM +0000, Tim Southerwood wrote:
>> Yes - really 2.4.34 :) I have a good reason - it's a black box device
>> and a key device driver is only available on 2.4.
> 
> .. is it binary-only? 
>  
>> Now, I have a little problem - a Dlink USB 802.11b device I have works
>> fine with linux_wlan_ng 0.2.5, compiled on linux 2.4.34 with gcc 3.4.3,
>> (as is the rest of the kernel) all on Redhat 7.3...
> 
> 0.2.7 is available, with a few additional fixes, but I don't think any of them 
> would affect you.
>  
>> ... until I unplug the device that is. Depending on the motherboard (I
>> have 3 systems), either 1 in 2 times, 1 in 6-8 times or apparently never
>> on the 3rd system, when the device is unplugged, a few seconds later the
>> kernel panics in an interrupt handler, usually with the current task
>> being the swapper. I have insufficient debugging enabled and I haven't
>> yet identified which interrupt handler.
> 
>> Now, I apologise, but I haven't yet re-tested with a vanilla kernel
>> (mine is patched in few key areas) nor have I gone to town enabling
>> debugging... These are things I plan to attack tomorrow. I'm a bit green
>> at device driver programming, though I've made a little progress with
>> fixing another driver this week... I'm certainly in a good position to
>> chuck some printk's in to aid debugging...
> 
> Unfortunately, there's not much we can do unless you (at the very least) get a 
> crash dump with resolved symbols; the possible presence of a binary driver and 
> patched-in-unknown-ways kernel also make things a lot more difficult.
> 
> Adding printk's in the driver might make things a lot worse; it may even make the 
> problem go away.  You're better odd doing a debug build, adding '-g' to 
> EXTRA_CFLAGS, and then enabling serial console or take a photo of the crash dump so 
> we can figure out where things are barfing.
> 
>> I've had this device working fine under 2.4.29 (also moderately patched)
>> so I don't believe the hardware is dodgey... Or perhaps I should be
>> looking at the USB host driver instead as it seems system dependant?
> 
> What USB host driver is in use?  usb-ohci, uhci, usb-uhci?
> 
>  - Solomon