<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7233.69">
<TITLE>RE: preempt crash in 2.6.18</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>-----Original Message-----<BR>
From: Vitaly Bordug [<A HREF="mailto:vbordug@ru.mvista.com">mailto:vbordug@ru.mvista.com</A>]<BR>
<BR>
On Sat, 14 Oct 2006 09:14:38 +1000<BR>
Benjamin Herrenschmidt wrote:<BR>
<BR>
> On Sat, 2006-10-14 at 01:21 +0400, Vitaly Bordug wrote:<BR>
> > On Fri, 13 Oct 2006 09:16:52 -0500<BR>
> > Rune Torgersen wrote:<BR>
> ><BR>
> > ><BR>
> > > This is from a Freescale 8265 running 2.6.18<BR>
> > > Anyone have any idea what this is and how to fix it?<BR>
> > ><BR>
> > Yes. Actually, I recall alike thing and used to fix with proper<BR>
> > spin-locking if the cascade PCI irq, which apparently does do_irq<BR>
> > that seems to confuse preempt counters.<BR>
> ><BR>
> > Just a pure guess.<BR>
><BR>
> How so ? Cascades shouldn't do do_IRQ with the new irq code anyway<BR>
> unless this is still arch/ppc, they should do either __do_IRQ or<BR>
> better, generic_handle_irq().<BR>
><BR>
To clarify - I was about __do_IRQ and arch/ppc.<BR>
Anyway, cascade for PCI is the first place I'd give a look.<BR>
<BR>
In our case it turned out to be in the TIPC network code. post_timeout was called and didn't unlock a lock.<BR>
The patch had been in the TIPC tree for abpout 2 days when we saw the problem.<BR>
<BR>
<BR>
--<BR>
Sincerely,<BR>
<BR>
-Vitaly<BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>