Antw: Re: Problem with iSCSI connected LTO-2 tape drive

2016-12-14 Thread Ulrich Windl 
>>> Lee Duncan  schrieb am 14.12.2016 um 20:18 in
Nachricht <8286a277-f7fe-4c7d-a944-40034a0b5...@gmail.com>:
> On Dec 12, 2016, at 5:46 AM, Dave partridge 
wrote:
>> 
>> I just ran a Wireshark capture on the target system of the iSCSI session
for 
> a Windows initiator connecting the tape and then issuing an FSF.  I then did

> the same for the Ubuntu open-iscsi initiator.
>> 
>> The capture for the WIndows initiator looks pretty much as I would expect 
> (given my limited knowledge of the iSCSI protocols).
>> 
>> The Ubuntu/open-iscsi capture has all sorts of odd stuff like logins being

> sent to the target every 15 seconds whle the FSF is being processed.  
> Definitely borked I think.
>> 
>> Do any of the open-iscsi folk watch this forum or am I talking to myself?
>> 
>> Dave
> 
> Hi Dave:
> 
> I think you are right — the problem is the timeout.
> 
> The default timeout on many systems (like SUSE that I work on) is set to 60

> seconds for a SCSI command. And it looks like the tape drive took about 82 
> seconds to skip forward a file on your Windows trace.

AFAIK, 60s is the SCSI _disk_ timeout; for tapes the timeout should be
significantly longer (depending on the technology).

> 
> Try setting the timeout to 90 seconds? The open-iscsi README talks about how

> to manually set the system SCSI timeout to longer (since this isn’t an
iSCSI 
> thing).

15 minutes or so?

> 
> Also, you may want to disable the Ping/NOOPs that open-iscsi is setting. 
> This is also discussed in the README file. I’d try setting them both to 0
to 
> get them out of the way. It looks like the tape drive does not respond to
the 
> NOOP ping when it is busy for 80+ seconds skipping forward one file.

Regards,
Ulrich


> 
> — 
> Lee Duncan
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "open-iscsi" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to open-iscsi+unsubscr...@googlegroups.com.
> To post to this group, send email to open-iscsi@googlegroups.com.
> Visit this group at https://groups.google.com/group/open-iscsi.
> For more options, visit https://groups.google.com/d/optout.



-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

[PATCH 5/8] linux: drop __bitwise__ everywhere

2016-12-14 Thread Michael S. Tsirkin 
__bitwise__ used to mean "yes, please enable sparse checks
unconditionally", but now that we dropped __CHECK_ENDIAN__
__bitwise is exactly the same.
There aren't many users, replace it by __bitwise everywhere.

Signed-off-by: Michael S. Tsirkin 
---
 arch/arm/plat-samsung/include/plat/gpio-cfg.h| 2 +-
 drivers/md/dm-cache-block-types.h| 6 +++---
 drivers/net/ethernet/sun/sunhme.h| 2 +-
 drivers/net/wireless/intel/iwlwifi/iwl-fw-file.h | 4 ++--
 include/linux/mmzone.h   | 2 +-
 include/linux/serial_core.h  | 4 ++--
 include/linux/types.h| 4 ++--
 include/scsi/iscsi_proto.h   | 2 +-
 include/target/target_core_base.h| 2 +-
 include/uapi/linux/virtio_types.h| 6 +++---
 net/ieee802154/6lowpan/6lowpan_i.h   | 2 +-
 net/mac80211/ieee80211_i.h   | 4 ++--
 12 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/arch/arm/plat-samsung/include/plat/gpio-cfg.h 
b/arch/arm/plat-samsung/include/plat/gpio-cfg.h
index 21391fa..e55d1f5 100644
--- a/arch/arm/plat-samsung/include/plat/gpio-cfg.h
+++ b/arch/arm/plat-samsung/include/plat/gpio-cfg.h
@@ -26,7 +26,7 @@
 
 #include 
 
-typedef unsigned int __bitwise__ samsung_gpio_pull_t;
+typedef unsigned int __bitwise samsung_gpio_pull_t;
 
 /* forward declaration if gpio-core.h hasn't been included */
 struct samsung_gpio_chip;
diff --git a/drivers/md/dm-cache-block-types.h 
b/drivers/md/dm-cache-block-types.h
index bed4ad4..389c9e8 100644
--- a/drivers/md/dm-cache-block-types.h
+++ b/drivers/md/dm-cache-block-types.h
@@ -17,9 +17,9 @@
  * discard bitset.
  */
 
-typedef dm_block_t __bitwise__ dm_oblock_t;
-typedef uint32_t __bitwise__ dm_cblock_t;
-typedef dm_block_t __bitwise__ dm_dblock_t;
+typedef dm_block_t __bitwise dm_oblock_t;
+typedef uint32_t __bitwise dm_cblock_t;
+typedef dm_block_t __bitwise dm_dblock_t;
 
 static inline dm_oblock_t to_oblock(dm_block_t b)
 {
diff --git a/drivers/net/ethernet/sun/sunhme.h 
b/drivers/net/ethernet/sun/sunhme.h
index f430765..4a8d5b1 100644
--- a/drivers/net/ethernet/sun/sunhme.h
+++ b/drivers/net/ethernet/sun/sunhme.h
@@ -302,7 +302,7 @@
  * Always write the address first before setting the ownership
  * bits to avoid races with the hardware scanning the ring.
  */
-typedef u32 __bitwise__ hme32;
+typedef u32 __bitwise hme32;
 
 struct happy_meal_rxd {
hme32 rx_flags;
diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-fw-file.h 
b/drivers/net/wireless/intel/iwlwifi/iwl-fw-file.h
index 1ad0ec1..84813b5 100644
--- a/drivers/net/wireless/intel/iwlwifi/iwl-fw-file.h
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-fw-file.h
@@ -228,7 +228,7 @@ enum iwl_ucode_tlv_flag {
IWL_UCODE_TLV_FLAGS_BCAST_FILTERING = BIT(29),
 };
 
-typedef unsigned int __bitwise__ iwl_ucode_tlv_api_t;
+typedef unsigned int __bitwise iwl_ucode_tlv_api_t;
 
 /**
  * enum iwl_ucode_tlv_api - ucode api
@@ -258,7 +258,7 @@ enum iwl_ucode_tlv_api {
 #endif
 };
 
-typedef unsigned int __bitwise__ iwl_ucode_tlv_capa_t;
+typedef unsigned int __bitwise iwl_ucode_tlv_capa_t;
 
 /**
  * enum iwl_ucode_tlv_capa - ucode capabilities
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 0f088f3..36d9896 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -246,7 +246,7 @@ struct lruvec {
 #define ISOLATE_UNEVICTABLE((__force isolate_mode_t)0x8)
 
 /* LRU Isolation modes. */
-typedef unsigned __bitwise__ isolate_mode_t;
+typedef unsigned __bitwise isolate_mode_t;
 
 enum zone_watermarks {
WMARK_MIN,
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index 5d49488..5def8e8 100644
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -111,8 +111,8 @@ struct uart_icount {
__u32   buf_overrun;
 };
 
-typedef unsigned int __bitwise__ upf_t;
-typedef unsigned int __bitwise__ upstat_t;
+typedef unsigned int __bitwise upf_t;
+typedef unsigned int __bitwise upstat_t;
 
 struct uart_port {
spinlock_t  lock;   /* port lock */
diff --git a/include/linux/types.h b/include/linux/types.h
index baf7183..d501ad3 100644
--- a/include/linux/types.h
+++ b/include/linux/types.h
@@ -154,8 +154,8 @@ typedef u64 dma_addr_t;
 typedef u32 dma_addr_t;
 #endif
 
-typedef unsigned __bitwise__ gfp_t;
-typedef unsigned __bitwise__ fmode_t;
+typedef unsigned __bitwise gfp_t;
+typedef unsigned __bitwise fmode_t;
 
 #ifdef CONFIG_PHYS_ADDR_T_64BIT
 typedef u64 phys_addr_t;
diff --git a/include/scsi/iscsi_proto.h b/include/scsi/iscsi_proto.h
index c1260d8..df156f1 100644
--- a/include/scsi/iscsi_proto.h
+++ b/include/scsi/iscsi_proto.h
@@ -74,7 +74,7 @@ static inline int iscsi_sna_gte(u32 n1, u32 n2)
 #define zero_data(p) {p[0]=0;p[1]=0;p[2]=0;}
 
 /* initiator tags; opaque for target */
-typedef uint32_t __bitwise__ itt_t;
+typedef uint32_t __bitwise itt_t;
 /*

Re: [4.10, panic, regression] iscsi: null pointer deref at iscsi_tcp_segment_done+0x20d/0x2e0

2016-12-14 Thread Dave Chinner 
On Thu, Dec 15, 2016 at 09:24:11AM +1100, Dave Chinner wrote:
> Hi folks,
> 
> Just updated my test boxes from 4.9 to a current Linus 4.10 merge
> window kernel to test the XFS merge I am preparing for Linus.
> Unfortunately, all my test VMs using iscsi failed pretty much
> instantly on the first mount of an iscsi device:
> 
> [  159.372704] XFS (sdb): EXPERIMENTAL reverse mapping btree feature enabled. 
> Use at your own risk!
> [  159.374612] XFS (sdb): Mounting V5 Filesystem
> [  159.425710] XFS (sdb): Ending clean mount
> [  160.274438] BUG: unable to handle kernel NULL pointer dereference at 
> 000c
> [  160.275851] IP: iscsi_tcp_segment_done+0x20d/0x2e0

FYI, crash is here:

(gdb) l *(iscsi_tcp_segment_done+0x20d)
0x81b950bd is in iscsi_tcp_segment_done 
(drivers/scsi/libiscsi_tcp.c:102).
97  iscsi_tcp_segment_init_sg(struct iscsi_segment *segment,
98struct scatterlist *sg, unsigned int offset)
99  {
100 segment->sg = sg;
101 segment->sg_offset = offset;
102 segment->size = min(sg->length - offset,
103 segment->total_size - 
segment->total_copied);
104 segment->data = NULL;
105 }
106 

So it looks to be sg = NULL, which means there's probably an issue
with the scatterlist...

-Dave.

> [  160.276565] PGD 336ed067 [  160.276885] PUD 31b0d067
> PMD 0 [  160.277309]
> [  160.277523] Oops:  [#1] PREEMPT SMP
> [  160.278004] Modules linked in:
> [  160.278407] CPU: 0 PID: 16 Comm: kworker/u2:1 Not tainted 4.9.0-dgc #18
> [  160.279224] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> Debian-1.8.2-1 04/01/2014
> [  160.280314] Workqueue: iscsi_q_2 iscsi_xmitworker
> [  160.280919] task: 88003e28 task.stack: c908
> [  160.281647] RIP: 0010:iscsi_tcp_segment_done+0x20d/0x2e0
> [  160.282312] RSP: 0018:c9083c38 EFLAGS: 00010206
> [  160.282980] RAX:  RBX: 880039061730 RCX: 
> 
> [  160.283854] RDX: 1e00 RSI:  RDI: 
> 880039061730
> [  160.284738] RBP: c9083c90 R08: 0200 R09: 
> 05a8
> [  160.285627] R10: 9835607d R11:  R12: 
> 0200
> [  160.286495] R13:  R14: 8800390615a0 R15: 
> 880039061730
> [  160.287362] FS:  () GS:88003fc0() 
> knlGS:
> [  160.288340] CS:  0010 DS:  ES:  CR0: 80050033
> [  160.289113] CR2: 000c CR3: 31a8d000 CR4: 
> 06f0
> [  160.290084] Call Trace:
> [  160.290429]  ? inet_sendpage+0x4d/0x140
> [  160.290957]  iscsi_sw_tcp_xmit_segment+0x89/0x110
> [  160.291597]  iscsi_sw_tcp_pdu_xmit+0x56/0x180
> [  160.292190]  iscsi_tcp_task_xmit+0xb8/0x280
> [  160.292771]  iscsi_xmit_task+0x53/0xc0
> [  160.293282]  iscsi_xmitworker+0x274/0x310
> [  160.293835]  process_one_work+0x1de/0x4d0
> [  160.294388]  worker_thread+0x4b/0x4f0
> [  160.294889]  kthread+0x10c/0x140
> [  160.295333]  ? process_one_work+0x4d0/0x4d0
> [  160.295898]  ? kthread_create_on_node+0x40/0x40
> [  160.296525]  ret_from_fork+0x25/0x30
> [  160.297015] Code: 43 18 00 00 00 00 e9 ad fe ff ff 48 8b 7b 30 e8 da e7 ca 
> ff 8b 53 10 44 89 ee 48 89 df 2b 53 14 48 89 43 30 c7 43 40 00 00 00 00 <8b
> [  160.300674] RIP: iscsi_tcp_segment_done+0x20d/0x2e0 RSP: c9083c38
> [  160.301584] CR2: 000c
> 
> 
> Known problem, or something new?
> 
> Cheers,
> 
> Dave.
> -- 
> Dave Chinner
> da...@fromorbit.com
> 

-- 
Dave Chinner
da...@fromorbit.com

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: iscsistart -N skips offload NICs causing boot to fail on debian

2016-12-14 Thread Andrew Patterson 
On 12/09/2016 03:33 PM, Mike Christie wrote:
> On 12/08/2016 10:55 AM, andrew.patter...@hpe.com wrote:
>> I am trying to get iSCSI boot working on a debian-based system
>> using built-in uEFI iSCSI initiator firmware and broadcom
>> NICs (bnx2x).
>>
>> The debian initramfs uses the ibft support in iscsistart to log
>> into the root volume. The initramfs script uses iscsistart -N to
>> bring up the NICs before logging in with iscsstart -b. This
>> process works fine when using non-offload NICs, but fails when
>> using NICs using the bnx2, bnx2x, cxgb3, and cxgb4 drivers due to
>> the following code in
>> utils/fwparam_ibft/fw_entry.c:fw_setup_nics():
>>
>> list_for_each_entry(context, , list) {   
>> /* if it is a offload nic ignore it */
>> if (!net_get_transport_name_from_netdev(context->iface,
>> transport))
>> continue
>>
>>
>> Which does a lookup in the table in usr/iscsi_net_util.c
>>
>> static struct iscsi_net_driver net_drivers[] = {
>> {"cxgb3", "cxgb3i" },
>> {"cxgb4", "cxgb4i" },
>> {"bnx2", "bnx2i" },
>> {"bnx2x", "bnx2i"},
>> {NULL, NULL}
>> };
>>
>>
>> to see if -N should skip this NIC.  I cannot determine the reason
>> for this check. Do iscsi offload NICs not need to be configured
>> for boot? The current code causes iscsi boots to fail. I removed the
>> check and booting works fine.
>>
> 
> If you use the ibft net info for the nic, what do you use for the iscsi
> offload engine?

I am not configuring it at boot (at least not yet). I haven't tried
using the boot support in the NIC firmware yet, just the uEFI iSCSI firmware
which will work with any NIC.

Do they both have the same IP, and are you creating boot
> iscsi sessions through the offload engine?

I am not using offload yet. But I will probably need to get this working next.


> 
> cxgb*i is able to share the net info. The normal old nic engine and
> iscsi engine are able to use the same IP. That originally was not
> supposed to be allowed upstream, but it got in.
> 
> bnx2* is (or at least was when we wrote that code) not able to share the
> net info. The nic and iscsi engines need different IPs.

That makes some sense. The firmware has two different MAC addresses,
one for the NIC and one for iSCSI.

> 
> So to cover both types we just use the ibft net info for the iscsi
> offload engines.
> 
> In the version of the code you are using is OFFLOAD_BOOT_SUPPORTED
> defined in open-iscsi/usr/iface.c or not?

Version 2.0.874. OFFLOAD_BOOT_SUPPORTED is in the code but not defined.

> 
> If it's not defined and you modified the code like you described, then I
> think you would use the ibft info to setup the normal old nic, and then
> you would end up creating a boot session using software iscsi.

Yes, I believe that is the result I am getting.

I am not
> 100% sure about this last statement. I cannot remember and just looked
> at the code for a couple minutes.
>

I will try defining OFFLOAD_BOOT_SUPPORTED to see if that brings up the NIC.

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

iscsistart -N skips offload NICs causing boot to fail on debian

2016-12-14 Thread andrewdanpatterson 
I am trying to get iSCSI boot working on a debian-based system
using built-in uEFI iSCSI initiator firmware and broadcom
NICs (bnx2x).

The debian initramfs uses the ibft support in iscsistart to log
into the root volume. The initramfs script uses iscsistart -N to
bring up the NICs before logging in with iscsstart -b. This
process works fine when using non-offload NICs, but fails when
using NICs using the bnx2, bnx2x, cxgb3, and cxgb4 drivers due to
the following code in
utils/fwparam_ibft/fw_entry.c:fw_setup_nics():

list_for_each_entry(context, , list) {
> /* if it is a offload nic ignore it */
> if (!net_get_transport_name_from_netdev(context->iface,
> transport))
> continue
>

Which does a lookup in the table in usr/iscsi_net_util.c

static struct iscsi_net_driver net_drivers[] = {
> {"cxgb3", "cxgb3i" },
> {"cxgb4", "cxgb4i" },
> {"bnx2", "bnx2i" },
> {"bnx2x", "bnx2i"},
> {NULL, NULL}
> };
>

to see if -N should skip this NIC.  I cannot determine the reason
for this check. Do iscsi offload NICs not need to be configured
for boot? The current code causes iscsi boots to fail. I removed the
check and booting works fine.

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

[4.10, panic, regression] iscsi: null pointer deref at iscsi_tcp_segment_done+0x20d/0x2e0

2016-12-14 Thread Dave Chinner 
Hi folks,

Just updated my test boxes from 4.9 to a current Linus 4.10 merge
window kernel to test the XFS merge I am preparing for Linus.
Unfortunately, all my test VMs using iscsi failed pretty much
instantly on the first mount of an iscsi device:

[  159.372704] XFS (sdb): EXPERIMENTAL reverse mapping btree feature enabled. 
Use at your own risk!
[  159.374612] XFS (sdb): Mounting V5 Filesystem
[  159.425710] XFS (sdb): Ending clean mount
[  160.274438] BUG: unable to handle kernel NULL pointer dereference at 
000c
[  160.275851] IP: iscsi_tcp_segment_done+0x20d/0x2e0
[  160.276565] PGD 336ed067 [  160.276885] PUD 31b0d067
PMD 0 [  160.277309]
[  160.277523] Oops:  [#1] PREEMPT SMP
[  160.278004] Modules linked in:
[  160.278407] CPU: 0 PID: 16 Comm: kworker/u2:1 Not tainted 4.9.0-dgc #18
[  160.279224] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Debian-1.8.2-1 04/01/2014
[  160.280314] Workqueue: iscsi_q_2 iscsi_xmitworker
[  160.280919] task: 88003e28 task.stack: c908
[  160.281647] RIP: 0010:iscsi_tcp_segment_done+0x20d/0x2e0
[  160.282312] RSP: 0018:c9083c38 EFLAGS: 00010206
[  160.282980] RAX:  RBX: 880039061730 RCX: 
[  160.283854] RDX: 1e00 RSI:  RDI: 880039061730
[  160.284738] RBP: c9083c90 R08: 0200 R09: 05a8
[  160.285627] R10: 9835607d R11:  R12: 0200
[  160.286495] R13:  R14: 8800390615a0 R15: 880039061730
[  160.287362] FS:  () GS:88003fc0() 
knlGS:
[  160.288340] CS:  0010 DS:  ES:  CR0: 80050033
[  160.289113] CR2: 000c CR3: 31a8d000 CR4: 06f0
[  160.290084] Call Trace:
[  160.290429]  ? inet_sendpage+0x4d/0x140
[  160.290957]  iscsi_sw_tcp_xmit_segment+0x89/0x110
[  160.291597]  iscsi_sw_tcp_pdu_xmit+0x56/0x180
[  160.292190]  iscsi_tcp_task_xmit+0xb8/0x280
[  160.292771]  iscsi_xmit_task+0x53/0xc0
[  160.293282]  iscsi_xmitworker+0x274/0x310
[  160.293835]  process_one_work+0x1de/0x4d0
[  160.294388]  worker_thread+0x4b/0x4f0
[  160.294889]  kthread+0x10c/0x140
[  160.295333]  ? process_one_work+0x4d0/0x4d0
[  160.295898]  ? kthread_create_on_node+0x40/0x40
[  160.296525]  ret_from_fork+0x25/0x30
[  160.297015] Code: 43 18 00 00 00 00 e9 ad fe ff ff 48 8b 7b 30 e8 da e7 ca 
ff 8b 53 10 44 89 ee 48 89 df 2b 53 14 48 89 43 30 c7 43 40 00 00 00 00 <8b
[  160.300674] RIP: iscsi_tcp_segment_done+0x20d/0x2e0 RSP: c9083c38
[  160.301584] CR2: 000c


Known problem, or something new?

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: Problem with iSCSI connected LTO-2 tape drive

2016-12-14 Thread Lee Duncan 
On Dec 12, 2016, at 5:46 AM, Dave partridge  wrote:
> 
> I just ran a Wireshark capture on the target system of the iSCSI session for 
> a Windows initiator connecting the tape and then issuing an FSF.  I then did 
> the same for the Ubuntu open-iscsi initiator.
> 
> The capture for the WIndows initiator looks pretty much as I would expect 
> (given my limited knowledge of the iSCSI protocols).
> 
> The Ubuntu/open-iscsi capture has all sorts of odd stuff like logins being 
> sent to the target every 15 seconds whle the FSF is being processed.  
> Definitely borked I think.
> 
> Do any of the open-iscsi folk watch this forum or am I talking to myself?
> 
> Dave

Hi Dave:

I think you are right — the problem is the timeout.

The default timeout on many systems (like SUSE that I work on) is set to 60 
seconds for a SCSI command. And it looks like the tape drive took about 82 
seconds to skip forward a file on your Windows trace.

Try setting the timeout to 90 seconds? The open-iscsi README talks about how to 
manually set the system SCSI timeout to longer (since this isn’t an iSCSI 
thing).

Also, you may want to disable the Ping/NOOPs that open-iscsi is setting. This 
is also discussed in the README file. I’d try setting them both to 0 to get 
them out of the way. It looks like the tape drive does not respond to the NOOP 
ping when it is busy for 80+ seconds skipping forward one file.

— 
Lee Duncan

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.