[PROBLEM] Soft lockup on Linux 2.6.27, 2 patches, Cell/PPC64
Geert Uytterhoeven
Geert.Uytterhoeven at sonycom.com
Wed Oct 15 23:05:17 EST 2008
On Wed, 15 Oct 2008, Benjamin Herrenschmidt wrote:
> On Wed, 2008-10-15 at 13:46 +0200, Geert Uytterhoeven wrote:
> > On Wed, 15 Oct 2008, Benjamin Herrenschmidt wrote:
> > > > > Well, at the time of the sample, the other CPU indeed -seems- to be in
> > > > > an IRQ disabled section yes.
> > > >
> > > > This is not really a sample. The hardirqs enable/disable is actually tracked
> > > > using the TRACE_{EN,DIS}ABLE_INTS macros.
> > >
> > > That's what I meant. IE. the hardirq state was updated by the stuck CPU
> > > but sampled by the non-stuck one. ie. the non-stuck one could have
> > > sampled a transcient value where it happened to have hard irq
> > > disabled...
> >
> > These states are per_cpu.
>
> I know, but that doesn't prevent another CPU from peeking at them :-)
> The question is, was the message printed by the CPU that locked up or by
> the other one that detected the lockup ?
It's printed by the spinlock debug code, i.e. by the CPU that wants to take the
spinlock (in this case the spinlock for the BKL).
> > They do call TRACE_DISABLE_INTS, which records the interrupt being disabled.
> > So this makes the actual state recording useless...
>
> Well, they record that when they disable it. They don't enable it. Can
> you find a spot where the IRQ is enabled and it's not recorded or a case
> where it's not disabled and recorded as disabled ?
I guess it's auto-enabled when the decrementer interrupt handler exits?
So shouldn't there be a `bl trace_hardirqs_on' somewhere?
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven at sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
More information about the Linuxppc-dev
mailing list