On 9/20/06, Gavin Maltby <Gavin.Maltby at sun.com> wrote: > > The lack of console response you mention elsewhere *may* be > explained by that putnext() thread. You may simply > have caught a perfectly healthy thread midway through > putnext(), but if it is blocked in there and has been > for a while that could explain some lack of response.
Hmm, it looks like this thread is in the midst of handling network traffic: stack pointer for thread 2a10017dd20: 2a10017c941 000002a10017c9f1 putnext+0x1cc() 000002a10017caa1 tcp_wput_slow+0xec0() 000002a10017cbd1 0() 000002a10017cdc1 putnext+0x1cc() 000002a10017ce71 ip_rput_local+0x998() 000002a10017cf61 ip_rput+0x12c4() 000002a10017d031 putnext+0x1cc() 000002a10017d0e1 hmeread+0x33c() 000002a10017d1b1 hmeintr+0x374() 000002a10017d261 pci_intr_wrapper+0x80() 000002a10017d311 intr_thread+0xa4() 000002a100177101 callout_execute+0x84() WRT the console hang, I'd guess that the zombie state of the console ttymon might be part of the explanation: > ::ps -f ! grep ttymon R 1152 1 1143 1143 0 0x00014208 0000030003f54040 /usr/lib/saf/ttymon Z 1144 1 1144 1144 0 0x80004208 0000030004cf1540 /usr/lib/saf/ttymon -g -h -p server console login: -T sun -d /de > And the zombie state of ttymon is likely a direct result of the zombie state of init: > ::ps -f ! grep init Z 1 0 0 0 0 0x80004208 0000030001b81528 /etc/init - > I've done some bug searches, but the ones I see that look promising were either not reproducible (4040769, 4378228, 4252803) or are in progress with no useful text I can see (6418709). > > > 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? > > Does ::print kthread_t t_disp_time not work on Solaris 8? My memory > of that release is fading. Unfortunately, it doesn't: > 2a10017dd20::print kthread_t t_disp_time mdb: invalid command '::print': unknown dcmd name > Thanks, Chad Mynhier
