Eric Saxe wrote:
You mean, the a13fade0 was unpinned due to block on a mutex, and it
was in turnstile before.
Later, it was placed into run queue, because the the mutex was
released by other ?
The clock interrupt was at some pointer pinning a13f7de0 (the priority
105 thread). When it passivated because
the adaptive mutex it wanted was already held, it became a regular
thread (a13fade0), scheduled just like everyone else.
It waited in the sleep queue until the lock was dropped, at which
point clock became runnable, and was then
enqueued in CPU 0's run queue.
Good explanation, thanks! :-)
But you mentioned "it waited in the sleep queue until the lock was
dropped", but as far as I know, the thread should be in turnstile to
wait a mutex,
and only if thread wait a condition variable, it would be in the sleep
queue.
I just get it from book, I'm not sure, do you treat it as the same
thing(turnstile and sleep queue)?
If it's a true, why it was not executed onproc immediately? Because
it's have highest pri in the run queue.
You can check t_flag for the priority 105 thread, but I think it's
because of this code in kpreempt():
http://src.opensolaris.org/source/xref/loficc/crypto/usr/src/uts/i86pc/os/trap.c#1440
So kpreempt() doesn't do much if it's an interrupt thread....likely
because it's assumed interrupts are short. :)
OK, thanks for your hints. I'll check it.
The status of a13fade0 thread is run, and I think while system
panic, the deadman should be running on CPU0.
How can I find the stack of deadman? I know it should be high
level interrupt, but I can't get any infomation from cpu_t
cpu_intr_stack:
a13fade0 is priority 109, which is PIL 10. This is clock. The
deadman cyclic fires at PIL 14, and it will pin whatever thread
is running on the CPU. Because you panicked on CPU 0, this is where
the deadman cyclic must have fired.
Thanks for your explanation. Yes, deadman paniced on the CPU0, I know
that via output of ::msgbuf.
But, as far as I known, the stack of hight level interrupts(PIL>10)
should be pointed by cpu_intr_stack.
I'm tried to get the stack of deadman by using cpu_intr_stack, it
should work, but why I failed?
It looks like cpu_intr_stack is used to preserve the interrupt stack
when we panic, but I would have to dig
further to know more....
It should be, you can refer to below code, it show that high level
interrupts use cpu_intr_stack as stack pointer:
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/i86pc/ml/interrupt.s#704
704 /
705 / Handle high-level nested interrupt on separate interrupt stack
706 /
707 testl $CPU_INTR_ACTV_HIGH_LEVEL_MASK, %esi
708 jnz onstack /* already on interrupt stack */
709 movl %esp, %eax
710 movl CPU_INTR_STACK(%ebx), %esp /* get on interrupt
stack */
711 pushl %eax /* save the thread stack pointer */
I looked in cbe.c at cbe_set_level(). The low, lock, and high levels,
correspond to CBE_LOW_PIL, CBE_LOCK_PIL, and
CBE_HIGH_PIL, which are defined in the architecture specific clock.h.
Actually, it looks like CBE_LOW_PIL is 1 on
SPARC and 2 on x86.
OK, I see. Thanks a lot!
Sure. Thanks for the great question. By the way, I believe what you
are seeing here is:
6498937 system hang while doing MAX and snoop through bge
Yes, our team's test suite found this bug, but we really need to locate
it belong to which subsystem. You know, sometimes, it's not easy to us. :-)
--
Cheers,
----------------------------------------------------------------------
Oliver Yang | OPG Engineering Operation | [EMAIL PROTECTED] | x82229
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
