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
