Ben,
According to Jim Dunham, iSCSI target lead, this is a know problem.
Scheduled for update 5. Bugs: 6480294 and 6563827.
Thanks,
Dan
Ben Rockwood wrote:
I do quite a bit of iSCSI testing and run into the following situation
repeatedly. Here's the scenario:
An iSCSI Target is connected to successfully (usual via send-targets) from a
Nevada system (most recent being snv_65). All ZPools/mounts of the filesystems
on the targets are removed (unmounted/exported). The Target goes away
(reboot/shutdown/whatever). Try to clear the registered targets by cycling the
discovery method.... panic.
Panic is:
::status
debugging crash dump vmcore.3 (64-bit) from aeon
operating system: 5.11 snv_63 (i86pc)
panic message: mutex_enter: bad mutex, lp=ffffff0147ae4b80
owner=3067406b73696428 thread=fffffffed3a820c0
dump content: kernel pages only
::stack
vpanic()
mutex_panic+0x73(fffffffffbc0cbd8, ffffff0147ae4b80)
mutex_vector_enter+0x4d4(ffffff0147ae4b80)
vhci_commoncap+0x15a(fffffffed7710b80, ffffffffc02c3478, 0, 1, 1)
vhci_scsi_setcap+0x23(fffffffed7710b80, ffffffffc02c3478, 0, 1)
scsi_ifsetcap+0x38(fffffffed7710b80, ffffffffc02c3478, 0, 1)
sd_unit_detach+0x486(fffffffec05c9a00)
sddetach+0x19(fffffffec05c9a00, 0)
devi_detach+0x84(fffffffec05c9a00, 0)
detach_node+0x5f(fffffffec05c9a00, 40001)
i_ndi_unconfig_node+0xd2(fffffffec05c9a00, 4, 40001)
i_ddi_detachchild+0x2c(fffffffec05c9a00, 40001)
devi_detach_node+0x73(fffffffec05c9a00, 40001)
ndi_devi_offline+0x17f(fffffffec05c9a00, 1)
i_mdi_devinfo_remove+0x43(fffffffec057dd88, fffffffec05c9a00, 0)
i_mdi_client_free+0x106(fffffffec01f2000, fffffffeca571a80)
mdi_pi_free+0x224(fffffffee3190d00, 0)
iscsi_lun_offline+0x1b0(fffffffec79eb580, fffffffee7c0bd28, 1)
iscsi_lun_destroy+0x29(fffffffec79eb580, fffffffee7c0bd28)
iscsi_sess_destroy+0x40(fffffffecbb1f000)
iscsid_del+0x4f9(fffffffec79eb580, 0, 8, 0)
iscsid_disable_discovery+0x5a(fffffffec79eb580, 8)
iscsi_ioctl+0x14f1(1200000000, 69534315, 8040d1c, 100001, ffffff014971d1c0,
ffffff000498ee9c)
cdev_ioctl+0x48(1200000000, 69534315, 8040d1c, 100001, ffffff014971d1c0,
ffffff000498ee9c)
spec_ioctl+0x86(fffffffed36e55c0, 69534315, 8040d1c, 100001, ffffff014971d1c0,
ffffff000498ee9c)
fop_ioctl+0x37(fffffffed36e55c0, 69534315, 8040d1c, 100001, ffffff014971d1c0,
ffffff000498ee9c)
ioctl+0x16b(4, 69534315, 8040d1c)
sys_syscall32+0x101()
A cleaner procedure would likely being to remove the individual targets from
the initiator than just cycling the discovery.
Based on the stack it looks like this might be a simple bug, its clearly trying
to do the right thing and break down target devices, etc.
benr.
This message posted from opensolaris.org
_______________________________________________
storage-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
--
Dan Maslowski
Sr. Engineering Manager
wk: 303.957.5964
cel: 720.530.8271
_______________________________________________
storage-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
