RE: hmm.... spinlocks..
On 31-Mar-01 Matthew Jacob wrote:
>
> On Fri, 30 Mar 2001, John Baldwin wrote:
>
>>
>> On 30-Mar-01 Matthew Jacob wrote:
>> >
>> >
>> > pic_initialize():
>> > lint0: 0x00010700 lint1: 0x00010400 TPR: 0x0010 SVR: 0x01ff
>> > kernel trap 12 with interrupts disabled
>> > panic: spin lock sched lock held by 0xc7ba8a60 for > 5 seconds
>> > cpuid = 0; lapic.id =
>> > Debugger("panic")
>> >
>> > CPU0 stopping CPUs: 0x0002... stopped.
>> > Stopped at Debugger+0x45: pushl %ebx
>> > db> t
>> > Debugger(c02e3759) at Debugger+0x45
>> > panic(c02e2d60,c02fb929,c7ba8a60,c7ba7b80,fffea000) at panic+0xd0
>> > _mtx_lock_spin(c0357400,0,80246,c02e3a48,2fb) at _mtx_lock_spin+0x6e
>> > wakeup(c3709378,c3709378,c0eec000,c0f71400,c3709454) at wakeup+0x67
>> > bufdone(c3709378,c7fbff40,c0131efb,c3709378,c0f71400) at bufdone+0x385
>> > bufdonebio(c3709378) at bufdonebio+0xe
>> > dadone(c0f5d100,c0f71400) at dadone+0x1f7
>> > camisr(c032a834) at camisr+0x231
>> > ithread_loop(c0b2f080,c7fbffa8) at ithread_loop+0x247
>> > fork_exit(c019898c,c0b2f080,c7fbffa8) at fork_exit+0x83
>> > fork_trampoline() at fork_trampoline+0x8
>>
>> Did you get a crashdump (probably not.) If you look at sched_lock, one of
>> the
>> words will be a pointer to the process owning the lock in question.
>> Unfortunately it's not the first word anymore (something I may change in the
>> future). On the alpha it would be 'sched_lock+48'. The pointer there
>> points
>> to the process owning the lock (and you can look up the process via ps). If
>> you have a crash dump then I have some gdb macros that make it easy to get a
>> backtrace of that process. If not, then, well, it gets harder. :-P Hmm, it
>> might be nice to be able to ask ddb to give a backtrace of any arbitrary
>> process. Maybe I'll add a new command for that..
>>
>> The trick is that we want to know who grabbed sched_lock where and then
>> started
>> spinning with it. Using KTR with KTR_LOCK turned on and using the 'show
>> ktr'
>> command in ddb could also be used to see which process was the last to grab
>> sched_lock and where it was grabbed.
>
> If it happens again, I''ll try. This was, btw, i386.
Oh, duh. Umm, on i386 it's 'sched_lock + 28'.
--
John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
RE: hmm.... spinlocks..
On Fri, 30 Mar 2001, John Baldwin wrote:
>
> On 30-Mar-01 Matthew Jacob wrote:
> >
> >
> > pic_initialize():
> > lint0: 0x00010700 lint1: 0x00010400 TPR: 0x0010 SVR: 0x01ff
> > kernel trap 12 with interrupts disabled
> > panic: spin lock sched lock held by 0xc7ba8a60 for > 5 seconds
> > cpuid = 0; lapic.id =
> > Debugger("panic")
> >
> > CPU0 stopping CPUs: 0x0002... stopped.
> > Stopped at Debugger+0x45: pushl %ebx
> > db> t
> > Debugger(c02e3759) at Debugger+0x45
> > panic(c02e2d60,c02fb929,c7ba8a60,c7ba7b80,fffea000) at panic+0xd0
> > _mtx_lock_spin(c0357400,0,80246,c02e3a48,2fb) at _mtx_lock_spin+0x6e
> > wakeup(c3709378,c3709378,c0eec000,c0f71400,c3709454) at wakeup+0x67
> > bufdone(c3709378,c7fbff40,c0131efb,c3709378,c0f71400) at bufdone+0x385
> > bufdonebio(c3709378) at bufdonebio+0xe
> > dadone(c0f5d100,c0f71400) at dadone+0x1f7
> > camisr(c032a834) at camisr+0x231
> > ithread_loop(c0b2f080,c7fbffa8) at ithread_loop+0x247
> > fork_exit(c019898c,c0b2f080,c7fbffa8) at fork_exit+0x83
> > fork_trampoline() at fork_trampoline+0x8
>
> Did you get a crashdump (probably not.) If you look at sched_lock, one of the
> words will be a pointer to the process owning the lock in question.
> Unfortunately it's not the first word anymore (something I may change in the
> future). On the alpha it would be 'sched_lock+48'. The pointer there points
> to the process owning the lock (and you can look up the process via ps). If
> you have a crash dump then I have some gdb macros that make it easy to get a
> backtrace of that process. If not, then, well, it gets harder. :-P Hmm, it
> might be nice to be able to ask ddb to give a backtrace of any arbitrary
> process. Maybe I'll add a new command for that..
>
> The trick is that we want to know who grabbed sched_lock where and then started
> spinning with it. Using KTR with KTR_LOCK turned on and using the 'show ktr'
> command in ddb could also be used to see which process was the last to grab
> sched_lock and where it was grabbed.
If it happens again, I''ll try. This was, btw, i386.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
RE: hmm.... spinlocks..
On 30-Mar-01 Matthew Jacob wrote:
>
>
> pic_initialize():
> lint0: 0x00010700 lint1: 0x00010400 TPR: 0x0010 SVR: 0x01ff
> kernel trap 12 with interrupts disabled
> panic: spin lock sched lock held by 0xc7ba8a60 for > 5 seconds
> cpuid = 0; lapic.id =
> Debugger("panic")
>
> CPU0 stopping CPUs: 0x0002... stopped.
> Stopped at Debugger+0x45: pushl %ebx
> db> t
> Debugger(c02e3759) at Debugger+0x45
> panic(c02e2d60,c02fb929,c7ba8a60,c7ba7b80,fffea000) at panic+0xd0
> _mtx_lock_spin(c0357400,0,80246,c02e3a48,2fb) at _mtx_lock_spin+0x6e
> wakeup(c3709378,c3709378,c0eec000,c0f71400,c3709454) at wakeup+0x67
> bufdone(c3709378,c7fbff40,c0131efb,c3709378,c0f71400) at bufdone+0x385
> bufdonebio(c3709378) at bufdonebio+0xe
> dadone(c0f5d100,c0f71400) at dadone+0x1f7
> camisr(c032a834) at camisr+0x231
> ithread_loop(c0b2f080,c7fbffa8) at ithread_loop+0x247
> fork_exit(c019898c,c0b2f080,c7fbffa8) at fork_exit+0x83
> fork_trampoline() at fork_trampoline+0x8
Did you get a crashdump (probably not.) If you look at sched_lock, one of the
words will be a pointer to the process owning the lock in question.
Unfortunately it's not the first word anymore (something I may change in the
future). On the alpha it would be 'sched_lock+48'. The pointer there points
to the process owning the lock (and you can look up the process via ps). If
you have a crash dump then I have some gdb macros that make it easy to get a
backtrace of that process. If not, then, well, it gets harder. :-P Hmm, it
might be nice to be able to ask ddb to give a backtrace of any arbitrary
process. Maybe I'll add a new command for that..
The trick is that we want to know who grabbed sched_lock where and then started
spinning with it. Using KTR with KTR_LOCK turned on and using the 'show ktr'
command in ddb could also be used to see which process was the last to grab
sched_lock and where it was grabbed.
--
John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
