I have a storage server with snv_134 installed. This has four zfs file systems shared with iscsi that are mounted as zfs volumes on a Sun v480. Everything has been working great for about a month, and all of a sudden the v480 has timeout errors when trying to connect to the iscsi volumes on the storage server. The connection between the two is a gigabit crossover cable, so other network traffic isn''t an issue. HBAs, NICs, and cables in the storage server have been troubleshot and are working normally. The only common element here is the Intel nic in the v480. It seems to work OK otherwise, but it''s the only component in this equation that hasn''t changed. What''s the consensus on NIC configurations for iscsi? Are errors like this common if the MTU is set at the default of 1500? Any and all comments/opinions are welcome. Thanks. -- This message posted from opensolaris.org
> are you using comstar or the old iSCSI target (iscsitadm) to provision targets?I''m using zfs set shareiscsi=on to confugure the logical units and COMSTAR for the rest on the OpenSolaris side. The targets are initiated on Solaris 10 with iscsiadm. This thing was humming right along and all of a sudden it stopped working after a few weeks. The connection is made via gigabit crossover cable using the e1000g driver on both ends. I get endless errors like this: Apr 21 19:58:43 storage scsi: [ID 107833 kern.warning] WARNING: /pci at 0,0/pci8086,340d at 6/pci8086,32c at 0/pci1028,1f04 at 8 (mpt1): Apr 21 19:58:43 storage Disconnected command timeout for Target 27 Apr 21 19:58:45 storage scsi: [ID 365881 kern.info] /pci at 0,0/pci8086,340d at 6/pci8086,32c at 0/pci1028,1f04 at 8 (mpt1): Apr 21 19:58:45 storage Log info 0x31140000 received for target 27. Apr 21 19:58:45 storage scsi_status=0x0, ioc_status=0x8048, scsi_state=0xc Apr 21 19:58:45 storage scsi: [ID 365881 kern.info] /pci at 0,0/pci8086,340d at 6/pci8086,32c at 0/pci1028,1f04 at 8 (mpt1): Apr 21 19:58:45 storage Log info 0x31140000 received for target 27. Apr 21 19:58:45 storage scsi_status=0x0, ioc_status=0x8048, scsi_state=0xc Apr 21 19:58:45 storage scsi: [ID 365881 kern.info] /pci at 0,0/pci8086,340d at 6/pci8086,32c at 0/pci1028,1f04 at 8 (mpt1): Apr 21 19:58:45 storage Log info 0x31140000 received for target 27. Apr 21 19:58:45 storage scsi_status=0x0, ioc_status=0x8048, scsi_state=0xc If anyone can suggest an optimal network setting for this, please chime in. -- This message posted from opensolaris.org
This sounds like http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6894775. It seems this can be avoided by switching to an LSI card that uses mpt_sas. For example, the 9211. However, certain drives, such as the Western Digital WD2002FYPS-01U1B0, can also result in the behavior .>Apr 21 19:58:43 storage scsi: [ID 107833 kern.warning] WARNING: >/pci at 0,0/pci8086,340d at 6/pci8086,32c at 0/pci1028,1f04 at 8 (mpt1): >Apr 21 19:58:43 storage Disconnected command timeout for Target 27 >Apr 21 19:58:45 storage scsi: [ID 365881 kern.info] >/pci at 0,0/pci8086,340d at 6/pci8086,32c at 0/pci1028,1f04 at 8 (mpt1): >Apr 21 19:58:45 storage Log info 0x31140000 received for target 27. >Apr 21 19:58:45 storage scsi_status=0x0, ioc_status=0x8048, >scsi_state=0xc >Apr 21 19:58:45 storage scsi: [ID 365881 kern.info] >/pci at 0,0/pci8086,340d at 6/pci8086,32c at 0/pci1028,1f04 at 8 (mpt1): >Apr 21 19:58:45 storage Log info 0x31140000 received for target 27. >Apr 21 19:58:45 storage scsi_status=0x0, ioc_status=0x8048, >scsi_state=0xc >Apr 21 19:58:45 storage scsi: [ID 365881 kern.info] >/pci at 0,0/pci8086,340d at 6/pci8086,32c at 0/pci1028,1f04 at 8 (mpt1): >Apr 21 19:58:45 storage Log info 0x31140000 received for target 27. >Apr 21 19:58:45 storage scsi_status=0x0, ioc_status=0x8048, >scsi_state=0xc-- Maurice Volaski, maurice.volaski at einstein.yu.edu Computing Support, Rose F. Kennedy Center Albert Einstein College of Medicine of Yeshiva University