> I'm not very familar with mdb. I've tried this: Ah, this looks much better:
root 641 0.0 0.0 7660 2624 ? S Nov 08 2:16 /sbin/zfs receive -dF datapool/share/ (...) # echo "0t641::pid2proc|::walk thread|::findstack -v" | mdb -k stack pointer for thread ffffff09236198e0: ffffff003d9b5670 [ ffffff003d9b5670 _resume_from_idle+0xf1() ] ffffff003d9b56a0 swtch+0x147() ffffff003d9b56d0 cv_wait+0x61(ffffff0a4fbd4228, ffffff0a4fbd40e8) ffffff003d9b5710 dmu_tx_wait+0x80(ffffff0948aa4600) ffffff003d9b5750 dmu_tx_assign+0x4b(ffffff0948aa4600, 1) ffffff003d9b57e0 dmu_free_long_range_impl+0x12a(ffffff0911456d60, ffffff0a4fbd4028, 0, ffffffffffffffff, 0) ffffff003d9b5840 dmu_free_long_range+0x5b(ffffff0911456d60, 53e34, 0, ffffffffffffffff) ffffff003d9b58d0 dmu_object_reclaim+0x112(ffffff0911456d60, 53e34, 13, 1e00, 11, 108) ffffff003d9b5930 restore_object+0xff(ffffff003d9b5950, ffffff0911456d60, ffffff003d9b59c0) ffffff003d9b5a90 dmu_recv_stream+0x48d(ffffff003d9b5be0, ffffff094d089440, ffffff003d9b5ad8) ffffff003d9b5c40 zfs_ioc_recv+0x2c0(ffffff092492b000) ffffff003d9b5cc0 zfsdev_ioctl+0x10b(b600000000, 5a1c, 8044e50, 100003, ffffff0948b60e50, ffffff003d9b5de4) ffffff003d9b5d00 cdev_ioctl+0x45(b600000000, 5a1c, 8044e50, 100003, ffffff0948b60e50, ffffff003d9b5de4) ffffff003d9b5d40 spec_ioctl+0x83(ffffff0921e54640, 5a1c, 8044e50, 100003, ffffff0948b60e50, ffffff003d9b5de4, 0) ffffff003d9b5dc0 fop_ioctl+0x7b(ffffff0921e54640, 5a1c, 8044e50, 100003, ffffff0948b60e50, ffffff003d9b5de4, 0) ffffff003d9b5ec0 ioctl+0x18e(3, 5a1c, 8044e50) ffffff003d9b5f10 sys_syscall32+0x101() Does this maybe ring a bell with someone? -- This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
