[OmniOS-discuss] device probe related command timeouts
John Barfield
john.barfield at bissinc.com
Wed Jan 4 21:09:58 UTC 2017
It actually finally completed. Doing it again with the proper PID as suggested provides the following:
root at PRD-GIP-cpls-san1:/export/home/jbarfield# ps aux | grep diskinfo
root 19448 0.0 0.0 7024 3820 pts/1 S 15:10:12 0:00 diskinfo
root 19452 0.0 0.0 2252 1292 pts/2 S 15:10:16 0:00 grep diskinfo
root at PRD-GIP-cpls-san1:/export/home/jbarfield# pstack 19448
19448: diskinfo
----------------- lwp# 1 --------------------------------
----------------- lwp# 2 --------------------------------
fee1f46e door (0, 0, 0, fe75ee00, f5f00, a)
fee05dd8 door_create_func (0, 0, 0, 0) + 4a
fee19d6b _thrp_setup (fe650240) + 88
fee19f00 _lwp_start (fe650240, 0, 0, 0, 0, 0)
----------------- lwp# 3 --------------------------------
fee19f59 lwp_park (0, 0, 0)
fee13f98 cond_wait_queue (813e560, 813e570, 0, 0, 0, 3) + 6a
fee14610 __cond_wait (813e560, 813e570, 0, 8147c88, fe9f8000, 0) + 8f
fee14664 cond_wait (813e560, 813e570, 0, fe9e49b9) + 2e
fe9e49fc subscriber_event_handler (8147c88, 0, 0, 0) + 51
fee19d6b _thrp_setup (fe650a40) + 88
fee19f00 _lwp_start (fe650a40, 0, 0, 0, 0, 0)
root at PRD-GIP-cpls-san1:/export/home/jbarfield# mdb -k
Loading modules: [ unix genunix specfs dtrace mac cpu.generic uppc pcplusmp scsi_vhci zfs sata sd ip hook neti sockfs arp usba uhci stmf stmf_sbd md lofs mpt_sas random idm ipc nfs ptm crypto cpc kvm ufs logindmux nsmb smbsrv ]
> ::0t19448::pid2proc | ::walk thread | ::findstack -v
mdb: syntax error near ":"
> 0t19448::pid2proc | ::walk thread | ::findstack -v
stack pointer for thread ffffff2490590000: ffffff010a286750
[ ffffff010a286750 _resume_from_idle+0xf4() ]
ffffff010a286780 swtch+0x141()
ffffff010a2867c0 sema_p+0x1c7(ffffff26e094b600)
ffffff010a286800 biowait+0xa4(ffffff26e094b540)
ffffff010a2868d0 scsi_uscsi_handle_cmd+0x127(c100000d40, 1, ffffff24907f3da8, fffffffff7b159b0, 0, ffffff27c23171e8)
ffffff010a286960 sd_ssc_send+0x136(ffffff24227d4e00, ffffff010a286970, 80000000, 1, 0)
ffffff010a286a30 sd_send_scsi_TEST_UNIT_READY+0x121(ffffff24227d4e00, 1)
ffffff010a286b40 sd_get_media_info_com+0xaf(c100000d40, ffffff010a286b50, ffffff010a286b54, ffffff010a286b58, 0)
ffffff010a286ba0 sd_get_media_info+0x41(c100000d40, 8047330, 100005)
ffffff010a286c80 sdioctl+0xc57(c100000d40, 42a, 8047330, 100005, ffffff24930f7580, ffffff010a286e68)
ffffff010a286cc0 cdev_ioctl+0x39(c100000d40, 42a, 8047330, 100005, ffffff24930f7580, ffffff010a286e68)
ffffff010a286d10 spec_ioctl+0x60(ffffff2492b62d80, 42a, 8047330, 100005, ffffff24930f7580, ffffff010a286e68, 0)
ffffff010a286da0 fop_ioctl+0x55(ffffff2492b62d80, 42a, 8047330, 100005, ffffff24930f7580, ffffff010a286e68, 0)
ffffff010a286ec0 ioctl+0x9b(3, 42a, 8047330)
ffffff010a286f10 _sys_sysenter_post_swapgs+0x149()
stack pointer for thread ffffff24907e6060: ffffff0107e53d50
[ ffffff0107e53d50 _resume_from_idle+0xf4() ]
ffffff0107e53d80 swtch+0x141()
ffffff0107e53db0 shuttle_swtch+0x203(fffffffffbd11090)
ffffff0107e53e50 door_return+0x214(0, 0, 0, 0, fe75ee00, f5f00)
ffffff0107e53ec0 doorfs32+0x180(0, 0, 0, fe75ee00, f5f00, a)
ffffff0107e53f10 _sys_sysenter_post_swapgs+0x149()
stack pointer for thread ffffff249198c020: ffffff010a032c50
[ ffffff010a032c50 _resume_from_idle+0xf4() ]
ffffff010a032c80 swtch+0x141()
ffffff010a032d10 cv_wait_sig_swap_core+0x1b9(ffffff249198c20e, ffffff249198c210, 0)
ffffff010a032d30 cv_wait_sig_swap+0x17(ffffff249198c20e, ffffff249198c210)
ffffff010a032dc0 cv_waituntil_sig+0xbd(ffffff249198c20e, ffffff249198c210, 0, 0)
ffffff010a032e70 lwp_park+0x15e(0, 0)
ffffff010a032ec0 syslwp_park+0x63(0, 0, 0)
ffffff010a032f10 _sys_sysenter_post_swapgs+0x149()
> 0t19448::pid2proc | ::walk thread | ::ps -f
S PID PPID PGID SID UID FLAGS ADDR NAME
S 0 0 0 283935560 0 0xffffff01 ffffff2490590000
S 0 0 0 283935560 0 0xffffff01 ffffff24907e6060
S 0 0 0 283935560 0 0xffffff01 ffffff249198c020
>
On 1/4/17, 3:05 PM, "Joshua M. Clulow" <josh at sysmgr.org> wrote:
On 4 January 2017 at 12:57, John Barfield <john.barfield at bissinc.com> wrote:
> root at PRD-GIP-cpls-san1:/export/home/jbarfield# pstack 18919
> 18919: sudo diskinfo
> fee8e665 pollsys (8047b50, 2, 0, 0)
> fee264af pselect (6, 8089c30, 8089c50, fef06320, 0, 0) + 1bf
> fee267b8 select (6, 8089c30, 8089c50, 0, 0, 0) + 8e
> 08055f64 sudo_execute (807c960, 8047ce8, 41e, c0) + 4ba
> 080606f8 run_command (807c960, 807c9c0, 8047d88, 805dff9) + 4c
> 0805e03f main (8047d7c, fef076a8, 8047db4, 8054cc3, 2, 8047dc0) + 681
> 08054cc3 _start (2, 8047e7c, 8047e81, 0, 8047e8a, 8047e95) + 83
I think you've grabbed the "sudo" process, rather than the child
"diskinfo" process. If you use "ptree" on the pid first, you'll be
able to see the full tree of processes.
Cheers.
--
Joshua M. Clulow
UNIX Admin/Developer
http://blog.sysmgr.org
More information about the OmniOS-discuss
mailing list