[parisc-linux] Re:[parisc-linux-cvs] linux-2.6 kyle
James Bottomley
James.Bottomley at SteelEye.com
Sun Aug 6 18:31:13 MDT 2006
On Sun, 2006-08-06 at 18:26 +0000, Joel Soete wrote:
> > :_( (I have hoping but) that doesn't fix the soft lockup pb:
> > patst007 login: BUG: soft lockup detected on CPU#0!
> > show_stack(1).
> > Backtrace:
> > [<101560d8>] softlockup_tick+0xd4/0x148
> > [<1013be90>] update_process_times+0x3c/0x88
> > [<101091dc>] timer_interrupt+0xd0/0x1b0
> > [<10156534>] handle_IRQ_event+0x5c/0xa4
> > [<10156614>] __do_IRQ+0x98/0x1d0
> > [<10109960>] do_cpu_irq_mask+0xdc/0x194
> > [<1010c068>] intr_return+0x0/0x1c
> >
> >
> Anyway this time on this 32bit smp kernel I reach to grab some interesting stuff from toc:
> in summary :
> on cpu#0:
> rp ==> _raw_read_lock()
>
> iaoq ==> generic__raw_read_trylock()
>
> GR[26] == arg0 = 00000000104a3e40
>
> while on cpu#1
>
> rp ==> copy_process()
>
> iaoq ==> _raw_write_lock()
>
> GR[26] == arg0 = 00000000104a3e40
Thanks for tracing this down.
This is an almost identical scenario to the one described here:
http://lists.parisc-linux.org/pipermail/parisc-linux-cvs/2005-October/036211.html
Just with slightly different locking semantics.
Could you look at the flags register on CPU#0 and see if interrupts were
disabled while we were trying generic__raw_read_trylock()?
Thanks,
James
More information about the parisc-linux
mailing list