Hi, Gavin, Thanks for the reply.
On 9/18/06, Gavin Maltby <Gavin.Maltby at sun.com> wrote: > > I'd start by looking at what threads are on cpu (::cpuinfo) and which have > been on cpu recently (t_disp_time relative to panic_lbolt and panic_lbolt64). > Also look for any kernel stacks waiting for locks - ie ending around > mutex_vector_enter; similarly for threads ending in sema_p/sema_wait and in > rw_rdlock, rw_wrlock etc. > Hmm, ::cpuinfo doesn't seem to be useful in this case, as it looks like the CPU is only handling the 'sync': > ::cpuinfo ID ADDR FLG NRUN BSPL PRI RNRN KRNRN SWITCH THREAD PROC 0 1041b778 1d 0 0 -1 no no t-5 000002a10001fd20 (idle) 2 01991530 1b 0 0 169 no no t-30 000002a100177d20 sched > 000002a100177d20::findstack stack pointer for thread 2a100177d20: 2a100176f01 000002a100176fb1 prom_enter_mon+0x38() 000002a100177081 debug_enter+0x15c() 000002a100177151 abort_seq_softintr+0x7c() 000002a100177311 intr_thread+0xa4() 000002a1000131b1 disp_getwork+0xa4() 000002a100013261 idle+0xac() 000002a100013311 thread_start+4() > As for which threads have been on CPU recently: Is there some way to look at t_disp_time on a Solaris 8 server other than dumping memory starting at the kthread_t pointer and knowing the offset within the structure? As for kernel stacks waiting for locks: Here are the functions the threads are sitting in: 1 disp_getwork+0xa4() 1 intr_thread+0xa4() 2 cv_wait_sig+0x180() 3 cv_wait_sig_swap+0x194() 1 do_scrub_ecache_line+0x8c() 1 sema_p+0x138() 1 current_thread+0x44() 1 cpu_pause+0x7c() 2 cv_timedwait+0x98() 1 putnext+0x1cc() 1 prom_rtt() 1 prom_enter_mon+0x38() 63 cv_wait+0x38() So there's one thread sitting in sema_p(), but it's the seg_pasync_thread() thread: > 2a100007d20::findstack stack pointer for thread 2a100007d20: 2a100007181 [ 000002a100007181 sema_p+0x138() ] 000002a100007231 seg_pasync_thread+0x104() 000002a100007311 thread_start+4() > And from looking at seg_pasync_thread(), I'd guess that this is a normal state. Thanks, Chad Mynhier
