On Fri, Jul 3, 2009 at 8:31 PM, Ian Collins<i...@ianshome.com> wrote: > Ian Collins wrote: >> >> I was doing an incremental send between pools, the receive side is locked >> up and no zfs/zpool commands work on that pool. >> >> The stacks look different from those reported in the earlier "ZFS snapshot >> send/recv "hangs" X4540 servers" thread. >> >> Here is the process information from scat (other commands hanging on the >> pool are also in cv_wait): >> > Has anyone else seen anything like this? The box wouldn't even reboot, it > had to be power cycled. It locks up on receive regularly now. > >> SolarisCAT(live/10X)> proc -L 18500 >> addr PID PPID RUID/UID size RSS swresv >> time command >> ================== ====== ====== ========== ========== ======== ======== >> ====== ========= >> 0xffffffc8d1990398 18500 14729 0 5369856 2813952 1064960 >> 32 zfs receive -v -d backup >> >> ==== user (LWP_SYS) thread: 0xfffffe84e0d5bc20 PID: 18500 ==== >> cmd: zfs receive -v -d backup >> t_wchan: 0xffffffffa0ed62a2 sobj: condition var (from >> zfs:txg_wait_synced+0x83) >> t_procp: 0xffffffc8d1990398 >> p_as: 0xfffffee19d29c810 size: 5369856 RSS: 2813952 >> hat: 0xfffffedb762d2818 cpuset: >> zone: global >> t_stk: 0xfffffe8000143f10 sp: 0xfffffe8000143b10 t_stkbase: >> 0xfffffe800013f000 >> t_pri: 59(TS) pctcpu: 0.000000 >> t_lwp: 0xfffffe84e92d6ec0 lwp_regs: 0xfffffe8000143f10 >> mstate: LMS_SLEEP ms_prev: LMS_SYSTEM >> ms_state_start: 15 minutes 4.476756638 seconds earlier >> ms_start: 15 minutes 8.447715668 seconds earlier >> psrset: 0 last CPU: 2 >> idle: 102425 ticks (17 minutes 4.25 seconds) >> start: Thu Jul 2 22:23:06 2009 >> age: 1029 seconds (17 minutes 9 seconds) >> syscall: #54 ioctl(, 0x0) (sysent: genunix:ioctl+0x0) >> tstate: TS_SLEEP - awaiting an event >> tflg: T_DFLTSTK - stack is default size >> tpflg: TP_TWAIT - wait to be freed by lwp_wait >> TP_MSACCT - collect micro-state accounting information >> tsched: TS_LOAD - thread is in memory >> TS_DONT_SWAP - thread/LWP should not be swapped >> pflag: SKILLED - SIGKILL has been posted to the process >> SMSACCT - process is keeping micro-state accounting >> SMSFORK - child inherits micro-state accounting >> >> pc: unix:_resume_from_idle+0xf8 resume_return: addq $0x8,%rsp >> >> unix:_resume_from_idle+0xf8 resume_return() >> unix:swtch+0x12a() >> genunix:cv_wait+0x68() >> zfs:txg_wait_synced+0x83() >> zfs:dsl_sync_task_group_wait+0xed() >> zfs:dsl_sync_task_do+0x54() >> zfs:dmu_objset_create+0xc5() >> zfs:zfs_ioc_create+0xee() >> zfs:zfsdev_ioctl+0x14c() >> genunix:cdev_ioctl+0x1d() >> specfs:spec_ioctl+0x50() >> genunix:fop_ioctl+0x25() >> genunix:ioctl+0xac() >> unix:_syscall32_save+0xbf() >> -- switch to user thread's user stack -- >> >> The box is an x4500, Solaris 10u7. >> > > > -- > Ian. > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss >
I hit this too: 6826836 Fixed in 117 http://opensolaris.org/jive/thread.jspa?threadID=104852&tstart=120 -- Brent Jones br...@servuhome.net _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
