[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