Re: open-iscsi against sun storage tek 2500 fails: 1011 error.
Mike, we are happy: no more packets lost. Now the dmesg shows: scsi2 : iSCSI Initiator over TCP/IP scsi 2:0:0:0: Direct-Access SUN LCSM100_I 0735 PQ: 0 ANSI: 5 sd 2:0:0:0: Attached scsi generic sg1 type 0 sd 2:0:0:0: [sdb] 2147483648 512-byte logical blocks: (1.09 TB/1.00 TiB) scsi 2:0:0:31: Direct-Access SUN Universal Xport 0735 PQ: 0 ANSI: 5 scsi 2:0:0:31: Attached scsi generic sg2 type 0 sd 2:0:0:0: [sdb] Write Protect is off sd 2:0:0:0: [sdb] Mode Sense: 77 00 10 08 sd 2:0:0:0: [sdb] Write cache: enabled, read cache: enabled, supports DPO and FUA sdb: unknown partition table sd 2:0:0:0: [sdb] Attached SCSI disk GFS2: gfs2 mount does not exist So, we are going to install the package: sys-cluster/gfs-kernel, but an error appears: see http://bugs.gentoo.org/show_bug.cgi?id=310689 Oriol -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en. attachment: oriol_morell.vcf
Re: open-iscsi against sun storage tek 2500 fails: 1011 error.
Mike, any suggestion? thxs. Oriol Oriol Morell wrote: Mike, we have done the following two commands. Please find attached the output files. tcpdump -i eth0 tcp port 3260 and host 192.168.192.136 -w /root/tcpdumpIPandPort3260.dump tcpdump -i eth0 host 192.168.192.136 -w /root/tcpdumpIPandNada.dump Checking these files with wireshark, an error found is "TCP Previous segment lost iscsi-target". It looks like a network problem. dmesg: scsi1 : iSCSI Initiator over TCP/IP scsi 1:0:0:0: Direct-Access SUN LCSM100_I 0735 PQ: 0 ANSI: 5 sd 1:0:0:0: Attached scsi generic sg1 type 0 sd 1:0:0:0: [sdb] 2147483648 512-byte logical blocks: (1.09 TB/1.00 TiB) scsi 1:0:0:31: Direct-Access SUN Universal Xport 0735 PQ: 0 ANSI: 5 scsi 1:0:0:31: Attached scsi generic sg2 type 0 sd 1:0:0:0: [sdb] Write Protect is off sd 1:0:0:0: [sdb] Mode Sense: 77 00 10 08 sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, supports DPO and FUA sdb: connection1:0: detected conn error (1011) connection1:0: detected conn error (1020) connection1:0: detected conn error (1020) sd 1:0:0:0: timing out command, waited 180s sd 1:0:0:0: [sdb] Unhandled error code sd 1:0:0:0: [sdb] Result: hostbyte=DID_TRANSPORT_DISRUPTED driverbyte=DRIVER_OK sd 1:0:0:0: [sdb] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 end_request: I/O error, dev sdb, sector 0 Buffer I/O error on device sdb, logical block 0 connection1:0: detected conn error (1020) device eth0 left promiscuous mode connection1:0: detected conn error (1020) sd 1:0:0:0: [sdb] Unhandled error code sd 1:0:0:0: [sdb] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK sd 1:0:0:0: [sdb] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 end_request: I/O error, dev sdb, sector 0 Buffer I/O error on device sdb, logical block 0 unable to read partition table sd 1:0:0:0: [sdb] READ CAPACITY(16) failed sd 1:0:0:0: [sdb] Result: hostbyte=DID_TRANSPORT_FAILFAST driverbyte=DRIVER_OK sd 1:0:0:0: [sdb] Sense not available. sd 1:0:0:0: [sdb] READ CAPACITY failed sd 1:0:0:0: [sdb] Result: hostbyte=DID_TRANSPORT_FAILFAST driverbyte=DRIVER_OK sd 1:0:0:0: [sdb] Sense not available. sd 1:0:0:0: [sdb] Asking for cache data failed sd 1:0:0:0: [sdb] Assuming drive cache: write through sd 1:0:0:0: [sdb] Attached SCSI disk Oriol Mike Christie wrote: On 03/12/2010 02:57 PM, Mike Christie wrote: It seems like the target is not liking something we are doing. Could you take a trace with wireshark/ethereal so we can see what the last iscsi pdu that was sent to the target. -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en. attachment: oriol_morell.vcf
Re: open-iscsi against sun storage tek 2500 fails: 1011 error.
On 03/11/2010 07:25 AM, Oriol Morell wrote: Mike, in the var-log-messages we can see the following error but not all the time: 589125 Mar 11 12:39:48 kabuki07 kernel: connection1:0: detected conn error (1020) This (1020) just means the target dropped the connection on us. 589126 Mar 11 12:39:49 kabuki07 iscsid: Kernel reported iSCSI connection 1:0 error (1020) state (3) 589127 Mar 11 12:39:52 kabuki07 iscsid: connection1:0 is operational after recovery (1 attempts) We were able to reconnect right way. 589128 Mar 11 12:40:35 kabuki07 kernel: INFO: task async/0:2554 blocked for more than 120 seconds. This means it might have been happening a lot because some IO has not completed for over two minutes.. 589129 Mar 11 12:40:35 kabuki07 kernel: echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. ... kernel_thread_helper+0x0/0x10* 589161 Mar 11 12:40:43 kabuki07 kernel: connection1:0: detected conn error (1020) Target dropped connection on us a again. 589162 Mar 11 12:40:44 kabuki07 kernel: sd 1:0:0:0: timing out command, waited 180s Yeah, it looks like we have been retrying this command a couple times and the problem kept happening. The scsi layer eventually says enough and fails the command after retrying for 180 secs. So this is also why you see that stack trace and the message about the blocked task for more than 120 secs. 589163 Mar 11 12:40:44 kabuki07 kernel: sd 1:0:0:0: [sdb] Unhandled error code 589164 Mar 11 12:40:44 kabuki07 kernel: sd 1:0:0:0: [sdb] Result: hostbyte=DID_TRANSPORT_DISRUPTED driverbyte=DRIVER_OK 589165 Mar 11 12:40:44 kabuki07 kernel: sd 1:0:0:0: [sdb] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 589166 Mar 11 12:40:44 kabuki07 kernel: end_request: I/O error, dev sdb, sector 0 Cmd is failed. 589167 Mar 11 12:40:44 kabuki07 kernel: Buffer I/O error on device sdb, logical block 0 589168 Mar 11 12:40:44 kabuki07 kernel: unable to read partition table It seems like the target is not liking something we are doing. The target logs do not help me much. I looked through them, but I am not sure what they are telling me. The storagetek guys would need to decipher them for us. -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Re: open-iscsi against sun storage tek 2500 fails: 1011 error.
On 03/12/2010 02:57 PM, Mike Christie wrote: It seems like the target is not liking something we are doing. Could you take a trace with wireshark/ethereal so we can see what the last iscsi pdu that was sent to the target. -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Re: open-iscsi against sun storage tek 2500 fails: 1011 error.
Title: Sun StorageTek Configuration Service Mike, in the var-log-messages we can see the following error but not all the time: 589125 Mar 11 12:39:48 kabuki07 kernel: connection1:0: detected conn error (1020) 589126 Mar 11 12:39:49 kabuki07 iscsid: Kernel reported iSCSI connection 1:0 error (1020) state (3) 589127 Mar 11 12:39:52 kabuki07 iscsid: connection1:0 is operational after recovery (1 attempts) 589128 Mar 11 12:40:35 kabuki07 kernel: INFO: task async/0:2554 blocked for more than 120 seconds. 589129 Mar 11 12:40:35 kabuki07 kernel: "echo 0 /proc/sys/kernel/hung_task_timeout_secs" disables this message. 589130 Mar 11 12:40:35 kabuki07 kernel: async/0 D 0002 0 2554 2 0x 589131 Mar 11 12:40:35 kabuki07 kernel: 88007fa16000 0046 812dd177 589132 Mar 11 12:40:35 kabuki07 kernel: 88007f42acf8 dd78 880037bd1fd8 589133 Mar 11 12:40:35 kabuki07 kernel: 000117c0 000117c0 880037b8 880037b80268 589134 Mar 11 12:40:35 kabuki07 kernel: Call Trace: 589135 Mar 11 12:40:35 kabuki07 kernel: [812dd177] ? submit_bio+0x9b/0xa2 589136 Mar 11 12:40:35 kabuki07 kernel: [810bfd55] ? block_read_full_page+0x242/0x261 589137 Mar 11 12:40:35 kabuki07 kernel: [8106e270] ? sync_page+0x0/0x45 589138 Mar 11 12:40:35 kabuki07 kernel: [814c85f4] ? io_schedule+0x3e/0x54 589139 Mar 11 12:40:35 kabuki07 kernel: [8106e2b1] ? sync_page+0x41/0x45 589140 Mar 11 12:40:35 kabuki07 kernel: [814c89c8] ? __wait_on_bit+0x41/0x70 589141 Mar 11 12:40:35 kabuki07 kernel: [8106e43f] ? wait_on_page_bit+0x6b/0x71 589142 Mar 11 12:40:35 kabuki07 kernel: [81045618] ? wake_bit_function+0x0/0x23 589143 Mar 11 12:40:35 kabuki07 kernel: [8106e45e] ? wait_on_page_read+0x19/0x34 589144 Mar 11 12:40:35 kabuki07 kernel: [810e9bd5] ? read_dev_sector+0x2a/0x8f 589145 Mar 11 12:40:35 kabuki07 kernel: [810eb023] ? sun_partition+0x23/0x1f4 589146 Mar 11 12:40:35 kabuki07 kernel: [810eaf03] ? sgi_partition+0x1f/0x11c 589147 Mar 11 12:40:35 kabuki07 kernel: [810ea749] ? rescan_partitions+0x15b/0x34a 589148 Mar 11 12:40:35 kabuki07 kernel: [810c29b5] ? __blkdev_get+0x265/0x350 589149 Mar 11 12:40:35 kabuki07 kernel: [810c214b] ? bdget+0x10c/0x113 589150 Mar 11 12:40:35 kabuki07 kernel: [810e9d0c] ? register_disk+0xd2/0x12c 589151 Mar 11 12:40:35 kabuki07 kernel: [812e3a70] ? add_disk+0xb0/0x108 589152 Mar 11 12:40:35 kabuki07 kernel: [81388b56] ? sd_probe_async+0x119/0x1d7 589153 Mar 11 12:40:35 kabuki07 kernel: [81049dc6] ? async_thread+0x0/0x218 589154 Mar 11 12:40:35 kabuki07 kernel: [81049ed2] ? async_thread+0x10c/0x218 589155 Mar 11 12:40:35 kabuki07 kernel: [81030012] ? default_wake_function+0x0/0x9 589156 Mar 11 12:40:35 kabuki07 kernel: [81049dc6] ? async_thread+0x0/0x218 589157 Mar 11 12:40:35 kabuki07 kernel: [81045219] ? kthread+0x79/0x81 589158 Mar 11 12:40:35 kabuki07 kernel: [81002e64] ? kernel_thread_helper+0x4/0x10 589159 Mar 11 12:40:35 kabuki07 kernel: [810451a0] ? kthread+0x0/0x81 589160 Mar 11 12:40:35 kabuki07 kernel: [81002e60] ? kernel_thread_helper+0x0/0x10 589161 Mar 11 12:40:43 kabuki07 kernel: connection1:0: detected conn error (1020) 589162 Mar 11 12:40:44 kabuki07 kernel: sd 1:0:0:0: timing out command, waited 180s 589163 Mar 11 12:40:44 kabuki07 kernel: sd 1:0:0:0: [sdb] Unhandled error code 589164 Mar 11 12:40:44 kabuki07 kernel: sd 1:0:0:0: [sdb] Result: hostbyte=DID_TRANSPORT_DISRUPTED driverbyte=DRIVER_OK 589165 Mar 11 12:40:44 kabuki07 kernel: sd 1:0:0:0: [sdb] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 589166 Mar 11 12:40:44 kabuki07 kernel: end_request: I/O error, dev sdb, sector 0 589167 Mar 11 12:40:44 kabuki07 kernel: Buffer I/O error on device sdb, logical block 0 589168 Mar 11 12:40:44 kabuki07 kernel: unable to read partition table Oriol Oriol Morell wrote: Mike, you'll find attached in this email the information we can get from the storage tek 2500. Can u see something suspicious? thx. Oriol Mike Christie wrote: On 03/09/2010 07:05 AM, Oriol Morell wrote: Hello Mike, we have applied the following lines, but the problem persists. Please check info placed in this email. Mar 9 08:29:15 kabuki07 kernel: connection1:0: detected conn error (1020) Sort of a new problem maybe. It looks like the target is dropping the connection on us here. It might be that the target thinks we have screwed something up. Do you see anything in the target logs? Maybe something about a protocol violation or something about a bad pdu or bad command or something being formatted incorrectly? Events on Storage System unlabeled
Re: open-iscsi against sun storage tek 2500 fails: 1011 error.
Hello Mike, we have applied the following lines, but the problem persists. Please check info placed in this email. Oops, this is a mistake. Do not set the abort timeout to zero. Set these: node.conn[0].timeo.noop_out_interval = 0 node.conn[0].timeo.noop_out_timeout = 0 To make them stick you have to set them in iscsid.conf then rerun discovery then relogin, or you can run iscsiadm -m node -T your_target -o update -n node.conn[0].timeo.noop_out_interval -v 0 iscsiadm -m node -T your_target -o update -n node.conn[0].timeo.noop_out_timeout -v 0 Oriol kabuki07 open-iscsi-2.0-871 # iscsiadm -m host -P 4 iSCSI Transport Class version 2.0-870 version 2.0-871 Host Number: 2 State: running Transport: tcp Initiatorname: (null) IPaddress: 192.168.192.22 HWaddress: (null) Netdev: (null) * Sessions: * Target: iqn.1986-03.com.sun:2510.600a0b800049cc7a4a0d4c7b Current Portal: 192.168.192.136:3260,2 Persistent Portal: 192.168.192.136:3260,2 ** Interface: ** Iface Name: default Iface Transport: tcp Iface Initiatorname: iqn.2010-03.kabuki07:openiscsi-68d8cacb96efe440162d3567ebde79e2 Iface IPaddress: 192.168.192.22 Iface HWaddress: (null) Iface Netdev: (null) SID: 2 iSCSI Connection State: LOGGED IN iSCSI Session State: LOGGED_IN Internal iscsid Session State: NO CHANGE Negotiated iSCSI params: HeaderDigest: None DataDigest: None MaxRecvDataSegmentLength: 262144 MaxXmitDataSegmentLength: 65536 FirstBurstLength: 8192 MaxBurstLength: 262144 ImmediateData: Yes InitialR2T: Yes MaxOutstandingR2T: 1 Attached SCSI devices: scsi2 Channel 00 Id 0 Lun: 0 Attached scsi disk sdb State: running scsi2 Channel 00 Id 0 Lun: 31 kabuki07 open-iscsi-2.0-871 # kabuki07 open-iscsi-2.0-871 # iscsiadm -m host -P 3 Host Number: 2 State: running Transport: tcp Initiatorname: (null) IPaddress: 192.168.192.22 HWaddress: (null) Netdev: (null) * Sessions: * Target: iqn.1986-03.com.sun:2510.600a0b800049cc7a4a0d4c7b Current Portal: 192.168.192.136:3260,2 Persistent Portal: 192.168.192.136:3260,2 ** Interface: ** Iface Name: default Iface Transport: tcp Iface Initiatorname: iqn.2010-03.kabuki07:openiscsi-68d8cacb96efe440162d3567ebde79e2 Iface IPaddress: 192.168.192.22 Iface HWaddress: (null) Iface Netdev: (null) SID: 2 iSCSI Connection State: LOGGED IN iSCSI Session State: LOGGED_IN Internal iscsid Session State: NO CHANGE Negotiated iSCSI params: HeaderDigest: None DataDigest: None MaxRecvDataSegmentLength: 262144 MaxXmitDataSegmentLength: 65536 FirstBurstLength: 8192 MaxBurstLength: 262144 ImmediateData: Yes InitialR2T: Yes MaxOutstandingR2T: 1 kabuki07 open-iscsi-2.0-871 # iscsiadm -m session -P 1 Target: iqn.1986-03.com.sun:2510.600a0b800049cc7a4a0d4c7b Current Portal: 192.168.192.136:3260,2 Persistent Portal: 192.168.192.136:3260,2 ** Interface: ** Iface Name: default Iface Transport: tcp Iface Initiatorname: iqn.2010-03.kabuki07:openiscsi-68d8cacb96efe440162d3567ebde79e2 Iface IPaddress: 192.168.192.22 Iface HWaddress: (null) Iface Netdev: (null) SID: 2 iSCSI Connection State: LOGGED IN iSCSI Session State: LOGGED_IN Internal iscsid Session State: NO CHANGE kabuki07 open-iscsi-2.0-871 # iscsiadm -m host -P 1 Host Number: 2 State: running Transport: tcp Initiatorname: (null) IPaddress: 192.168.192.22 HWaddress: (null) Netdev: (null) var/log/messages Mar 9 08:28:23 kabuki07 kernel: scsi1 : iSCSI Initiator over TCP/IP Mar 9 08:28:23 kabuki07 kernel: scsi 1:0:0:0: Direct-Access SUN LCSM100_I 0735 PQ: 0 ANSI: 5 Mar 9 08:28:23 kabuki07 kernel: sd 1:0:0:0: Attached scsi generic sg1 type 0 Mar 9 08:28:23 kabuki07 kernel: sd 1:0:0:0: [sdb] 2147483648 512-byte logical blocks: (1.09 TB/1.00 TiB) Mar 9 08:28:23 kabuki07 kernel: scsi 1:0:0:31: Direct-Access SUN Universal Xport 0735 PQ: 0 ANSI: 5 Mar 9 08:28:23 kabuki07 kernel: scsi 1:0:0:31: Attached scsi generic sg2 type 0 Mar 9 08:28:23 kabuki07 kernel: sd 1:0:0:0: [sdb] Write Protect is off Mar 9 08:28:23 kabuki07 kernel: sd 1:0:0:0: [sdb] Mode Sense: 77 00 10 08 Mar 9 08:28:23 kabuki07 kernel: sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, supports DPO and FUA Mar 9 08:28:24 kabuki07 iscsid: connection1:0 is operational now Mar 9 08:29:15 kabuki07 kernel: sdb: Mar 9 08:29:15 kabuki07 kernel: connection1:0: detected conn error (1020) Mar 9 08:29:16 kabuki07 iscsid: Kernel reported iSCSI connection 1:0 error (1020) state (3) Mar 9 08:29:19 kabuki07 iscsid: connection1:0 is operational after recovery (1 attempts) Mar 9 08:30:10 kabuki07 kernel: connection1:0: detected conn error (1020) Mar 9 08:30:10 kabuki07 kernel: sd 1:0:0:0: [sdb] Unhandled error code Mar 9 08:30:10
Re: open-iscsi against sun storage tek 2500 fails: 1011 error.
On 03/09/2010 07:05 AM, Oriol Morell wrote: Hello Mike, we have applied the following lines, but the problem persists. Please check info placed in this email. Mar 9 08:29:15 kabuki07 kernel: connection1:0: detected conn error (1020) Sort of a new problem maybe. It looks like the target is dropping the connection on us here. It might be that the target thinks we have screwed something up. Do you see anything in the target logs? Maybe something about a protocol violation or something about a bad pdu or bad command or something being formatted incorrectly? -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Re: open-iscsi against sun storage tek 2500 fails: 1011 error.
On 03/08/2010 05:03 AM, Oriol Morell wrote: Mar 5 14:42:30 kabuki07 connection1:0: ping timeout of 15 secs expired, recv timeout 15, last rx 4294949516, last ping 4294953266, now 4294957016 If the target does not support nops you can turn them off by setting node.conn[0].timeo.noop_out_timeout = 0 node.session.err_timeo.abort_timeout = 0 Oops, this is a mistake. Do not set the abort timeout to zero. Set these: node.conn[0].timeo.noop_out_interval = 0 node.conn[0].timeo.noop_out_timeout = 0 To make them stick you have to set them in iscsid.conf then rerun discovery then relogin, or you can run iscsiadm -m node -T your_target -o update -n node.conn[0].timeo.noop_out_interval -v 0 iscsiadm -m node -T your_target -o update -n node.conn[0].timeo.noop_out_timeout -v 0 then logout and login again. What is your kernel version and are you using the iscsi modules that come with that kernel or the ones from open-iscsi.org? The kernel used is linux-2.6.33-gentoo. We have not change nothing in the kernel, so I suppose modules from open-iscsi are not used in case the gentoo kernel is not included. Where can we get the correct modules from open-iscsi for the kernel 2.6.33? I hope this could be the solution. 2.6.33 is current. -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Re: open-iscsi against sun storage tek 2500 fails: 1011 error.
Mike, we have upgrade to open-iscsi-2.0.871.3, and the files belonging to this package are the following ones (does not includes the modules of open-iscsi): kabuki07 ~ # equery files open-iscsi * Searching for open-iscsi ... * Contents of sys-block/open-iscsi-2.0.871.3: /etc /etc/conf.d /etc/conf.d/iscsid /etc/init.d /etc/init.d/iscsid /etc/iscsi /etc/iscsi/ifaces /etc/iscsi/ifaces/iface.example /etc/iscsi/initiatorname.iscsi.example /etc/iscsi/iscsid.conf /usr /usr/sbin /usr/sbin/iscsi-iname /usr/sbin/iscsi_discovery /usr/sbin/iscsiadm /usr/sbin/iscsid /usr/sbin/iscsistart /usr/share /usr/share/doc /usr/share/doc/open-iscsi-2.0.871.3 /usr/share/doc/open-iscsi-2.0.871.3/README.bz2 /usr/share/doc/open-iscsi-2.0.871.3/THANKS.bz2 /usr/share/doc/open-iscsi-2.0.871.3/test /usr/share/doc/open-iscsi-2.0.871.3/test/README.bz2 /usr/share/doc/open-iscsi-2.0.871.3/test/regression.dat.bz2 /usr/share/doc/open-iscsi-2.0.871.3/test/regression.sh.bz2 /usr/share/man /usr/share/man/man8 /usr/share/man/man8/iscsi_discovery.8.bz2 /usr/share/man/man8/iscsiadm.8.bz2 /usr/share/man/man8/iscsid.8.bz2 /var /var/db /var/db/iscsi /var/db/iscsi/.keep_sys-block_open-iscsi-0 kabuki07 ~ # Oriol Oriol Morell wrote: Hello, Mike Christie wrote: On 03/05/2010 08:16 AM, Oriol wrote: Hello there, we are using Open-iscsi 2.0.871-r1 against Sun Storage Tek 2500, in a Gentoo Linux Amd 64, but the following error appears: "detected conn error (1011)". After checking everything, we can not find the problem. Are you just logging in? Are you doing any IO at the time? Just logging. Nothing else. >From the logs it looks like there is no IO for a while, so the iscsi layer sends a nop just to make sure the target is still there. Mar 5 14:42:15 kabuki07 connection1:0: iscsi_sw_tcp_xmit xmit 48 bytes It gets sent here. Mar 5 14:42:30 kabuki07 connection1:0: ping timeout of 15 secs expired, recv timeout 15, last rx 4294949516, last ping 4294953266, now 4294957016 But then 15 secs have passed and we have not got a response or any IO for that matter. So the iscsi layer thinks the target is gone or the connection is bad, so logs the session out and logs in again. If the target does not support nops you can turn them off by setting node.conn[0].timeo.noop_out_timeout = 0 node.session.err_timeo.abort_timeout = 0 I have already try it , and the situation is the same. What is your kernel version and are you using the iscsi modules that come with that kernel or the ones from open-iscsi.org? The kernel used is linux-2.6.33-gentoo. We have not change nothing in the kernel, so I suppose modules from open-iscsi are not used in case the gentoo kernel is not included. Where can we get the correct modules from open-iscsi for the kernel 2.6.33? I hope this could be the solution. Thanks for replying. Oriol -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en. attachment: oriol_morell.vcf
Re: open-iscsi against sun storage tek 2500 fails: 1011 error.
Hello again, after checking more docs, we have downgraded the kernel to linux-2.6.30-gentoo-r9, in order to have really a kernel to support open-iscsi. Besides, the tar file open-iscsi-2.0-871.tar.gz has been downloaded from www.open-iscsi.org. After decompressing, serveral directoris appears. Then do we have just to copy de files placed in the kernel subdirectory to the kernel in /usr/src/linux/drivers/scsi/ and then just compile the kernel? Thanks. Oriol Oriol Morell wrote: Mike, we have upgrade to open-iscsi-2.0.871.3, and the files belonging to this package are the following ones (does not includes the modules of open-iscsi): kabuki07 ~ # equery files open-iscsi * Searching for open-iscsi ... * Contents of sys-block/open-iscsi-2.0.871.3: /etc /etc/conf.d /etc/conf.d/iscsid /etc/init.d /etc/init.d/iscsid /etc/iscsi /etc/iscsi/ifaces /etc/iscsi/ifaces/iface.example /etc/iscsi/initiatorname.iscsi.example /etc/iscsi/iscsid.conf /usr /usr/sbin /usr/sbin/iscsi-iname /usr/sbin/iscsi_discovery /usr/sbin/iscsiadm /usr/sbin/iscsid /usr/sbin/iscsistart /usr/share /usr/share/doc /usr/share/doc/open-iscsi-2.0.871.3 /usr/share/doc/open-iscsi-2.0.871.3/README.bz2 /usr/share/doc/open-iscsi-2.0.871.3/THANKS.bz2 /usr/share/doc/open-iscsi-2.0.871.3/test /usr/share/doc/open-iscsi-2.0.871.3/test/README.bz2 /usr/share/doc/open-iscsi-2.0.871.3/test/regression.dat.bz2 /usr/share/doc/open-iscsi-2.0.871.3/test/regression.sh.bz2 /usr/share/man /usr/share/man/man8 /usr/share/man/man8/iscsi_discovery.8.bz2 /usr/share/man/man8/iscsiadm.8.bz2 /usr/share/man/man8/iscsid.8.bz2 /var /var/db /var/db/iscsi /var/db/iscsi/.keep_sys-block_open-iscsi-0 kabuki07 ~ # Oriol Oriol Morell wrote: Hello, Mike Christie wrote: On 03/05/2010 08:16 AM, Oriol wrote: Hello there, we are using Open-iscsi 2.0.871-r1 against Sun Storage Tek 2500, in a Gentoo Linux Amd 64, but the following error appears: "detected conn error (1011)". After checking everything, we can not find the problem. Are you just logging in? Are you doing any IO at the time? Just logging. Nothing else. From the logs it looks like there is no IO for a while, so the iscsi layer sends a nop just to make sure the target is still there. Mar 5 14:42:15 kabuki07 connection1:0: iscsi_sw_tcp_xmit xmit 48 bytes It gets sent here. Mar 5 14:42:30 kabuki07 connection1:0: ping timeout of 15 secs expired, recv timeout 15, last rx 4294949516, last ping 4294953266, now 4294957016 But then 15 secs have passed and we have not got a response or any IO for that matter. So the iscsi layer thinks the target is gone or the connection is bad, so logs the session out and logs in again. If the target does not support nops you can turn them off by setting node.conn[0].timeo.noop_out_timeout = 0 node.session.err_timeo.abort_timeout = 0 I have already try it , and the situation is the same. What is your kernel version and are you using the iscsi modules that come with that kernel or the ones from open-iscsi.org? The kernel used is linux-2.6.33-gentoo. We have not change nothing in the kernel, so I suppose modules from open-iscsi are not used in case the gentoo kernel is not included. Where can we get the correct modules from open-iscsi for the kernel 2.6.33? I hope this could be the solution. Thanks for replying. Oriol -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en. attachment: oriol_morell.vcf
open-iscsi against sun storage tek 2500 fails: 1011 error.
Hello there, we are using Open-iscsi 2.0.871-r1 against Sun Storage Tek 2500, in a Gentoo Linux Amd 64, but the following error appears: detected conn error (1011). After checking everything, we can not find the problem. We can connect to the nas using: iscsiadm -m node -T iqn.1986-03.com.sun: 2510.600a0b800049cc7a4a0d4c7b -p 192.168.192.136:3260 -l In the following lines, you wil find two executions of iscsiadm -m session -P 3 and the output of var-log-messages. Some help will be great ;) kabuki07 ~ # iscsiadm -m session -P 3 iSCSI Transport Class version 2.0-870 version 2.0-871 Target: iqn.1986-03.com.sun:2510.600a0b800049cc7a4a0d4c7b Current Portal: 192.168.192.136:3260,2 Persistent Portal: 192.168.192.136:3260,2 ** Interface: ** Iface Name: default Iface Transport: tcp Iface Initiatorname: iqn. 2010-03.kabuki07:openiscsi-68d8cacb96efe440162d3567ebde79e2 Iface IPaddress: 192.168.192.22 Iface HWaddress: (null) Iface Netdev: (null) SID: 2 iSCSI Connection State: LOGGED IN iSCSI Session State: LOGGED_IN Internal iscsid Session State: NO CHANGE Negotiated iSCSI params: HeaderDigest: None DataDigest: None MaxRecvDataSegmentLength: 262144 MaxXmitDataSegmentLength: 65536 FirstBurstLength: 8192 MaxBurstLength: 262144 ImmediateData: Yes InitialR2T: Yes MaxOutstandingR2T: 1 Attached SCSI devices: Host Number: 2 State: running scsi2 Channel 00 Id 0 Lun: 0 Attached scsi disk sdb State: running scsi2 Channel 00 Id 0 Lun: 31 kabuki07 ~ # iscsiadm -m session -P 3 iSCSI Transport Class version 2.0-870 version 2.0-871 Target: iqn.1986-03.com.sun:2510.600a0b800049cc7a4a0d4c7b Current Portal: 192.168.192.136:3260,2 Persistent Portal: 192.168.192.136:3260,2 ** Interface: ** Iface Name: default Iface Transport: tcp Iface Initiatorname: iqn. 2010-03.kabuki07:openiscsi-68d8cacb96efe440162d3567ebde79e2 Iface IPaddress: 192.168.192.22 Iface HWaddress: (null) Iface Netdev: (null) SID: 2 iSCSI Connection State: TRANSPORT WAIT iSCSI Session State: FAILED Internal iscsid Session State: REOPEN Negotiated iSCSI params: HeaderDigest: None DataDigest: None MaxRecvDataSegmentLength: 262144 MaxXmitDataSegmentLength: 65536 FirstBurstLength: 8192 MaxBurstLength: 262144 ImmediateData: Yes InitialR2T: Yes MaxOutstandingR2T: 1 Attached SCSI devices: Host Number: 2 State: running scsi2 Channel 00 Id 0 Lun: 0 Attached scsi disk sdb State: blocked scsi2 Channel 00 Id 0 Lun: 31 Mar 5 14:42:11 kabuki07 [811b87a8] ? add_disk+0xb0/0x108 Mar 5 14:42:11 kabuki07 [8125c036] ? sd_probe_async +0x119/0x1d7 Mar 5 14:42:11 kabuki07 [81049dc6] ? async_thread+0x0/0x218 Mar 5 14:42:11 kabuki07 [81049ed2] ? async_thread+0x10c/ 0x218 Mar 5 14:42:11 kabuki07 [81030012] ? default_wake_function +0x0/0x9 Mar 5 14:42:11 kabuki07 [81049dc6] ? async_thread+0x0/0x218 Mar 5 14:42:11 kabuki07 [81045219] ? kthread+0x79/0x81 Mar 5 14:42:11 kabuki07 [81002e64] ? kernel_thread_helper +0x4/0x10 Mar 5 14:42:11 kabuki07 [810451a0] ? kthread+0x0/0x81 Mar 5 14:42:11 kabuki07 [81002e60] ? kernel_thread_helper +0x0/0x10 Mar 5 14:42:15 kabuki07 connection1:0: iscsi_check_transport_timeouts Sending nopout as ping Mar 5 14:42:15 kabuki07 connection1:0: iscsi_check_transport_timeouts Setting next tmo 4294957016 Mar 5 14:42:15 kabuki07 connection1:0: iscsi_tcp_task_init mtask deq [itt 0x1d] Mar 5 14:42:15 kabuki07 connection1:0: iscsi_sw_tcp_send_hdr_prep digest disabled Mar 5 14:42:15 kabuki07 session1: iscsi_prep_mgmt_task mgmtpdu [op 0x0 hdr-itt 0x401d datalen 0] Mar 5 14:42:15 kabuki07 connection1:0: iscsi_tcp_segment_done copied 0 0 size 48 xmit Mar 5
Re: open-iscsi against sun storage tek 2500 fails: 1011 error.
On 03/05/2010 08:16 AM, Oriol wrote: Hello there, we are using Open-iscsi 2.0.871-r1 against Sun Storage Tek 2500, in a Gentoo Linux Amd 64, but the following error appears: detected conn error (1011). After checking everything, we can not find the problem. Are you just logging in? Are you doing any IO at the time? From the logs it looks like there is no IO for a while, so the iscsi layer sends a nop just to make sure the target is still there. Mar 5 14:42:15 kabuki07 connection1:0: iscsi_sw_tcp_xmit xmit 48 bytes It gets sent here. Mar 5 14:42:30 kabuki07 connection1:0: ping timeout of 15 secs expired, recv timeout 15, last rx 4294949516, last ping 4294953266, now 4294957016 But then 15 secs have passed and we have not got a response or any IO for that matter. So the iscsi layer thinks the target is gone or the connection is bad, so logs the session out and logs in again. If the target does not support nops you can turn them off by setting node.conn[0].timeo.noop_out_timeout = 0 node.session.err_timeo.abort_timeout = 0 What is your kernel version and are you using the iscsi modules that come with that kernel or the ones from open-iscsi.org? -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
