Hello, I'm interested to see if anybody has a working configuration for open-iscsi initiator with a wasabi storage builder target.
We have a few Wasabi Storage Builder 1.6 targets, which we've used for years with linux-iscsi and core-iscsi initiators. Recently we decided to repurpose them, and use a newer OS for the initiator role. Unfortunately, we can't seem to get it going properly. The targets are detected correctly, we're able to see the target LUNs, but any attempt to write more than a few megabytes of data fails. Initially the target would show us: --- thread main:target.c:kq_conn:1610: ***ERROR*** Detected packet with illegal packet size 16777215 (max is 8192) from iqn.2008-06.draugluin,i,00023d060000 to iqn.2000-05.com.wasabisystems.storagebuilder:iscsi-6-0,t,0032 cid 0 PDU was number 77 on the connection, and started at byte 12352 --- Setting this option helped a little bit, but now we get kernel bug errors: node.conn[0].iscsi.MaxRecvDataSegmentLength = 8192 Here's our current config: --- node.name = iqn.2000-05.com.wasabisystems.storagebuilder:iscsi-6-0 node.tpgt = 1 node.startup = automatic iface.hwaddress = default iface.iscsi_ifacename = default iface.net_ifacename = default iface.transport_name = tcp node.discovery_address = 10.0.0.16 node.discovery_port = 3260 node.discovery_type = send_targets node.session.initial_cmdsn = 0 node.session.initial_login_retry_max = 4 node.session.cmds_max = 128 node.session.queue_depth = 32 node.session.auth.authmethod = None node.session.timeo.replacement_timeout = 120 node.session.err_timeo.abort_timeout = 10 node.session.err_timeo.reset_timeout = 30 node.session.iscsi.InitialR2T = No node.session.iscsi.ImmediateData = Yes node.session.iscsi.FirstBurstLength = 262144 node.session.iscsi.MaxBurstLength = 16776192 node.session.iscsi.DefaultTime2Retain = 0 node.session.iscsi.DefaultTime2Wait = 0 node.session.iscsi.MaxConnections = 1 node.session.iscsi.MaxOutstandingR2T = 1 node.session.iscsi.ERL = 0 node.conn[0].address = 10.0.0.16 node.conn[0].port = 3260 node.conn[0].startup = manual node.conn[0].tcp.window_size = 524288 node.conn[0].tcp.type_of_service = 0 node.conn[0].timeo.logout_timeout = 15 node.conn[0].timeo.login_timeout = 15 node.conn[0].timeo.auth_timeout = 45 node.conn[0].timeo.active_timeout = 5 node.conn[0].timeo.idle_timeout = 60 node.conn[0].timeo.ping_timeout = 5 node.conn[0].timeo.noop_out_interval = 10 node.conn[0].timeo.noop_out_timeout = 15 node.conn[0].iscsi.MaxRecvDataSegmentLength = 8192 node.conn[0].iscsi.HeaderDigest = None,CRC32C node.conn[0].iscsi.DataDigest = None node.conn[0].iscsi.IFMarker = No node.conn[0].iscsi.OFMarker = No --- Logs on the initiator side logs showed us initially: --- Jun 26 11:06:09 draugluin iscsid: Nop-out timedout after 15 seconds on connection 2:0 state (3). Dropping session. Jun 26 11:06:09 draugluin iscsid: Nop-out timedout after 15 seconds on connection 3:0 state (3). Dropping session. Jun 26 11:06:09 draugluin iscsid: Nop-out timedout after 15 seconds on connection 1:0 state (3). Dropping session. Jun 26 11:06:10 draugluin iscsid: connection3:0 is operational after recovery (1 attempts) Jun 26 11:06:10 draugluin iscsid: connection2:0 is operational after recovery (1 attempts) Jun 26 11:06:10 draugluin iscsid: connection1:0 is operational after recovery (1 attempts) Jun 26 11:06:18 draugluin iscsid: Nop-out timedout after 15 seconds on connection 6:0 state (3). Dropping session. Jun 26 11:06:19 draugluin iscsid: connection6:0 is operational after recovery (1 attempts) Jun 26 11:06:25 draugluin iscsid: Nop-out timedout after 15 seconds on connection 5:0 state (3). Dropping session. Jun 26 11:06:25 draugluin iscsid: connection5:0 is operational after recovery (1 attempts) Jun 26 11:06:45 draugluin iscsid: Nop-out timedout after 15 seconds on connection 6:0 state (3). Dropping session. Jun 26 11:06:45 draugluin iscsid: connection6:0 is operational after recovery (1 attempts) --- Right now writing any larger amount of data [more than a few kilobytes] results in: --- Jun 26 14:55:33 draugluin kernel: ======================= Jun 26 14:55:33 draugluin kernel: BUG: workqueue leaked lock or atomic: scsi_wq_5/0x00000001/5316 Jun 26 14:55:33 draugluin kernel: last function: iscsi_xmitworker+0x0/0x584 [libiscsi] Jun 26 14:55:33 draugluin kernel: [<c013229c>] run_workqueue+0xcf/0x114 Jun 26 14:55:33 draugluin kernel: [<c0132a5e>] worker_thread+0x0/0xca Jun 26 14:55:33 draugluin kernel: [<c0132b1a>] worker_thread+0xbc/0xca Jun 26 14:55:33 draugluin kernel: [<c01351b9>] autoremove_wake_function+0x0/0x33 Jun 26 14:55:33 draugluin kernel: [<c0132a5e>] worker_thread+0x0/0xca Jun 26 14:55:33 draugluin kernel: [<c01350f2>] kthread+0x38/0x5e Jun 26 14:55:33 draugluin kernel: [<c01350ba>] kthread+0x0/0x5e Jun 26 14:55:33 draugluin kernel: [<c0106117>] kernel_thread_helper+0x7/0x10 Jun 26 14:55:33 draugluin kernel: ======================= --- We're using OpenSUSE 10.3 with open-iscsi-2.0.866-15.2 and 2.6.22.18-0.2-default SMP i686 kernel. [OpenSUSE 11 with open-iscsi-2.0.869-8.1 had another set of issues, we couldn't even login properly]. I would appreciate any suggestions as to how to get the initiator working with these targets. sincerely, -- Dominik L. Borkowski - Senior Systems Administrator Virginia Bioinformatics Institute - www.vbi.vt.edu --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/open-iscsi -~----------~----~----~----~------~----~------~--~---
