Hi,
I wrote yesterday in indiana-discuss:
> I am currently working on an issue which somehow looks similar on an snv_98
> quad
> core Xeon machine:
>
> * various zfs snapshot -r cron jobs were all waiting for devfsadm:
> [...]
> * syseventd didn't immediately respond to SIGTERM (but after some time)
>
> * metaset -s <set> -r hanging (could not get a usable core file of this one)
>
> * Access on /devices hanging
I've only started crash dump analysis of this issue (could only spend about
half
an hour) and this very much looks like a metaset / fmd deadlock at first sight.
I'll check for documented bugs and open one if none exists. I would very much
appreciate any pointers to known issues.
This issue is reproducible.
I am crossposting this:
- to indiana-discuss to give an update on my post from yesterday
- to storage-discuss because it's probably the appropriate alias
Will continue the thread on storage-discuss (Reply-To)
Details:
thread ffffff01dd6c5500 is waiting for rwlock md_unit_array_rw
0xffffffffc01393a0
last ran: 4 days 17 hours 16 mins 21 secs ago
md_unit_array_rw is owned by thread ffffff01e2e347e0
there are thread waiting for md_unit_array_rw
ADDR OWNER/COUNT FLAGS WAITERS
ffffffffc01393a0 ffffff01e2e347e0 B101 ffffff01dd6c5500 (R)
| |
WRITE_LOCKED ------+ |
HAS_WAITERS --------+
metaset -s <set> -r :
R 22132 18369 18369 1194 0 0x4a004900 ffffff01da0a56f0 metaset
T 0xffffff01e2e347e0 <TS_SLEEP>
> 0xffffff01e2e347e0::findstack
stack pointer for thread ffffff01e2e347e0: ffffff000821c7f0
[ ffffff000821c7f0 _resume_from_idle+0xf1() ]
ffffff000821c830 swtch+0x17f()
ffffff000821c860 cv_wait+0x61()
ffffff000821c8a0 ndi_devi_enter+0x72()
ffffff000821c900 ddi_remove_minor_node+0x2b()
ffffff000821c950 md_remove_minor_node+0x51()
ffffff000821ca10 reset_stripe+0x68()
ffffff000821ca40 stripe_halt+0xa0()
ffffff000821ca80 md_halt_set+0x153()
ffffff000821cac0 release_set+0x5d()
ffffff000821cba0 md_base_ioctl+0x1caf()
ffffff000821cc30 md_admin_ioctl+0x46()
ffffff000821ccb0 mdioctl+0x143()
ffffff000821ccf0 cdev_ioctl+0x48()
ffffff000821cd30 spec_ioctl+0x86()
ffffff000821cdb0 fop_ioctl+0x7b()
ffffff000821cec0 ioctl+0x174()
ffffff000821cf10 _sys_sysenter_post_swapgs+0x14b()
fmd:
R 265 1 265 265 0 0x42000000 ffffff01d002b310 fmd
[...]
T 0xffffff01dd6c5500 <TS_SLEEP>
> 0xffffff01dd6c5500::findstack
stack pointer for thread ffffff01dd6c5500: ffffff000985f710
[ ffffff000985f710 _resume_from_idle+0xf1() ]
ffffff000985f750 swtch+0x17f()
ffffff000985f7f0 turnstile_block+0x752()
ffffff000985f860 rw_enter_sleep+0x21d()
ffffff000985f8f0 mdprop_op+0x8f()
ffffff000985f9a0 di_getprop_add+0x7b()
ffffff000985fa70 di_getprop+0x243()
ffffff000985fae0 di_copynode+0x3e9()
ffffff000985fb40 di_copytree+0xc5()
ffffff000985fbf0 di_snapshot+0x17a()
ffffff000985fc20 di_snapshot_and_clean+0x1f()
ffffff000985fcb0 di_ioctl+0x458()
ffffff000985fcf0 cdev_ioctl+0x48()
ffffff000985fd30 spec_ioctl+0x86()
ffffff000985fdb0 fop_ioctl+0x7b()
ffffff000985fec0 ioctl+0x174()
ffffff000985ff10 _sys_sysenter_post_swapgs+0x14b()
If this does ring a bell for anyone, please let me know.
Thank you, Nils
Nils
_______________________________________________
storage-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
