Dianogsing a hard lockup

Dianogsing a hard lockup

[Jan Engelhardt]

Hi list,


some time after I load drivers (any, rt2500 or via ndiswrap) for a 
rt2500-based wlan card, the box locks up hard. Sysrq does not work, so I 
suppose it is during irq-disabled context. How could I find out where this 
happens?


Jan Engelhardt
-- 

Re: Dianogsing a hard lockup

[Robert Hancock]

Jan Engelhardt wrote:
> Hi list,
> 
> 
> some time after I load drivers (any, rt2500 or via ndiswrap) for a 
> rt2500-based wlan card, the box locks up hard. Sysrq does not work, so I 
> suppose it is during irq-disabled context. How could I find out where this 
> happens?
> 
> 
> Jan Engelhardt

Try nmi_watchdog=1 on the kernel command line. That may get you a stack 
trace for the lockup.

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/

Re: Dianogsing a hard lockup

[Lee Revell]

On Sat, 2005-12-17 at 17:09 +0100, Jan Engelhardt wrote:
> Hi list,
> 
> 
> some time after I load drivers (any, rt2500 or via ndiswrap) for a 
> rt2500-based wlan card, the box locks up hard. Sysrq does not work, so I 
> suppose it is during irq-disabled context. How could I find out where this 
> happens?


First, stick to rt2500 as you won't get help with binary only drivers
here.

Try to reproduce the problem from the console, you're more likely to get
a usable Oops.

Check the driver code & make sure it can't get stuck looping in the
interrupt handler due to an unhandled IRQ.  Add printks.

Finally report it to the rt2500 maintainer.

Lee

Re: Dianogsing a hard lockup

[Jan Engelhardt]

Hi list,

>> some time after I load drivers (any, rt2500 or via ndiswrap) for a 
>> rt2500-based wlan card, the box locks up hard. Sysrq does not work, so I 
>> suppose it is during irq-disabled context. How could I find out where this 
>> happens?
>
>First, stick to rt2500 as you won't get help with binary only drivers
>here.
>Check the driver code & make sure it can't get stuck looping in the
>interrupt handler due to an unhandled IRQ.  Add printks.

It happens with both, and that's why I think this is not a problem
with the rt2500 driver(s), but somewhere else in the kernel. But I do
not know where, because it is a lot bigger than the rt code base.

>Try to reproduce the problem from the console, you're more likely to get
>a usable Oops.
>
I did, it just locks. No reaction to Sysrq+T/+P, which is the "hard"
in "hard lockup".



Jan Engelhardt
-- 

RE: Dianogsing a hard lockup

[Roger Heflin]

 

> -----Original Message-----
> From: linux-kernel-owner@vger.kernel.org 
> [mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Lee Revell
> Sent: Saturday, December 17, 2005 12:41 PM
> To: Jan Engelhardt
> Cc: Linux Kernel Mailing List
> Subject: Re: Dianogsing a hard lockup
> 
> On Sat, 2005-12-17 at 17:09 +0100, Jan Engelhardt wrote:
> > Hi list,
> > 
> > 
> > some time after I load drivers (any, rt2500 or via ndiswrap) for a 
> > rt2500-based wlan card, the box locks up hard. Sysrq does 
> not work, so 
> > I suppose it is during irq-disabled context. How could I find out 
> > where this happens?
> 
> 
> First, stick to rt2500 as you won't get help with binary only 
> drivers here.
> 
> Try to reproduce the problem from the console, you're more 
> likely to get a usable Oops.
> 
> Check the driver code & make sure it can't get stuck looping 
> in the interrupt handler due to an unhandled IRQ.  Add printks.
> 
> Finally report it to the rt2500 maintainer.

Jan,

I got the rt2500usb driver to blow up nicely if I used the
default ieee* routines from the kernel and not the ones that
came with the rt2500 drivers, you might want to verify which
ieee* that you are using.  Using the ones that came with the
rt2500 seem to work, or at least not crash the kernel out.

                          Roger

RE: Dianogsing a hard lockup

[Jan Engelhardt]

>I got the rt2500usb driver to blow up nicely if I used the
>default ieee* routines from the kernel and not the ones that
>came with the rt2500 drivers, you might want to verify which
>ieee* that you are using.  Using the ones that came with the
>rt2500 seem to work, or at least not crash the kernel out.

The rt2500-1.1.0-b3 (not the same as rt2500pci!) package does not include 
its own ieee tree yet, so that can't be the issue. Anyway, I tried the card 
in on a different box, and it worked there. Strange enough that it's 
always the motherboard which fails it. The one where it does not work is a 
VIA something motherboard with an AMD K6-2/500 CPU. 


Jan Engelhardt
-- 
| Alphagate Systems, http://alphagate.hopto.org/
| jengelh's site, http://jengelh.hopto.org/

Re: Dianogsing a hard lockup

[Jan Engelhardt]

Hi,

> Try nmi_watchdog=1 on the kernel command line. That may get you a stack trace
> for the lockup.

That does not seem to work.
APIC is enabled, but the kernel reports "No local APIC present or hardware 
disabled". /proc/interrupts only lists XT PICs, and the NMI counter in 
interrupts is also 0.


Jan Engelhardt
-- 

Re: Dianogsing a hard lockup

[Jan Engelhardt]

>Hi,
>
>> Try nmi_watchdog=1 on the kernel command line. That may get you a stack trace
>> for the lockup.
>
>That does not seem to work.
>APIC is enabled, but the kernel reports "No local APIC present or hardware 
>disabled". /proc/interrupts only lists XT PICs, and the NMI counter in 
>interrupts is also 0.

So, here's a potential answer to my own problem: the mainboard is crap.
0000:00:00.0 Host bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3] 
(rev 04)
0000:00:07.0 ISA bridge: VIA Technologies, Inc. VT82C596 ISA [Mobile South] 
(rev 23)



Jan Engelhardt
--