Hello Mike,
Am Samstag, 6. Oktober 2012 05:15:11 UTC+2 schrieb Mike Christie:
On Oct 5, 2012, at 2:39 PM, squadra j...@internetx.de javascript:
wrote:
Hi,
from time to time i see connection errors like this to our equallogic
6100xv / 4100e stack.
ct 5 21:22:20 xxx kernel: connection4
the server works and the multipath connections are 2 of 2.
Some ideas?
Best Regards.
El viernes, 5 de octubre de 2012 21:39:37 UTC+2, squadra escribió:
Hi,
from time to time i see connection errors like this to our equallogic
6100xv / 4100e stack.
ct 5 21:22:20 xxx kernel: connection4:0
On Oct 5, 2012, at 3:39 PM, squadra wrote:
Hi,
from time to time i see connection errors like this to our equallogic 6100xv
/ 4100e stack.
ct 5 21:22:20 xxx kernel: connection4:0: detected conn error (1020)
Oct 5 21:22:21 xxx iscsid: Kernel reported iSCSI connection 4:0 error (1020
On Oct 5, 2012, at 2:39 PM, squadra j...@internetx.de wrote:
Hi,
from time to time i see connection errors like this to our equallogic 6100xv
/ 4100e stack.
ct 5 21:22:20 xxx kernel: connection4:0: detected conn error (1020)
Do you see something before this? Maybe something about
I seem to be getting this over and over again in the logs:
Jun 12 09:13:40 example-server kernel: connection0:0: iscsi: detected conn
error (1011)
Jun 12 09:13:40 example-server iscsid: Kernel reported iSCSI connection 0:0
error (1011) state (3)
Jun 12 09:13:43 example-server iscsid:
On 06/12/2012 11:18 AM, awiddersh...@hotmail.com wrote:
I seem to be getting this over and over again in the logs:
Jun 12 09:13:40 example-server kernel: connection0:0: iscsi: detected conn
error (1011)
1011 is just a generic error code meaning there was a connection
problem. We do not
This indicates something went screwy. The kernel has that el5 string, so
are you using Centos or RHEL? If so what is the iscsi tools version
It is RHEL5 and the tools are as follows:
iscsi-initiator-utils-6.2.0.872-13.el5
Is there anything else in the log before or after that? Something about
On 06/12/2012 11:33 AM, awiddersh...@hotmail.com wrote:
This indicates something went screwy. The kernel has that el5 string, so
are you using Centos or RHEL? If so what is the iscsi tools version
It is RHEL5 and the tools are as follows:
iscsi-initiator-utils-6.2.0.872-13.el5
Is
On 06/12/2012 11:41 AM, Mike Christie wrote:
On 06/12/2012 11:33 AM, awiddersh...@hotmail.com wrote:
This indicates something went screwy. The kernel has that el5 string, so
are you using Centos or RHEL? If so what is the iscsi tools version
It is RHEL5 and the tools are as follows:
On 06/12/2012 11:45 AM, Mike Christie wrote:
On 06/12/2012 11:41 AM, Mike Christie wrote:
On 06/12/2012 11:33 AM, awiddersh...@hotmail.com wrote:
This indicates something went screwy. The kernel has that el5 string, so
are you using Centos or RHEL? If so what is the iscsi tools version
It
Awesome. I'll do that and hopefully everything is happy afterward including
these random connection issues.
--
You received this message because you are subscribed to the Google Groups
open-iscsi group.
To view this discussion on the web visit
On 06/12/2012 11:55 AM, Mike Christie wrote:
On 06/12/2012 11:45 AM, Mike Christie wrote:
On 06/12/2012 11:41 AM, Mike Christie wrote:
On 06/12/2012 11:33 AM, awiddersh...@hotmail.com wrote:
This indicates something went screwy. The kernel has that el5 string, so
are you using Centos or
On 06/12/2012 12:09 PM, Mike Christie wrote:
On 06/12/2012 11:55 AM, Mike Christie wrote:
On 06/12/2012 11:45 AM, Mike Christie wrote:
On 06/12/2012 11:41 AM, Mike Christie wrote:
On 06/12/2012 11:33 AM, awiddersh...@hotmail.com wrote:
This indicates something went screwy. The kernel has that
Understood.
--
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
On 09/08/2011 07:23 AM, Ankit Jain wrote:
On Thu, Sep 8, 2011 at 2:26 PM, Aastha Mehta aasth...@gmail.com wrote:
Sorry, please ignore the previous patch. There was some minor error in that.
Re-attaching the patch here.
+#includestdio.h
+#includestdlib.h
+#includestring.h
+#include
Yeah, I am fine with adding the GPL2 headers. Thanks for the merging.
Regards,
Aastha.
On 4 October 2011 06:44, Mike Christie micha...@cs.wisc.edu wrote:
On 09/08/2011 07:23 AM, Ankit Jain wrote:
On Thu, Sep 8, 2011 at 2:26 PM, Aastha Mehta aasth...@gmail.com wrote:
Sorry, please ignore
this group at
http://groups.google.com/group/open-iscsi?hl=en.
From 22ca358914d43a489f23b4004c7743a7b28d0ae9 Mon Sep 17 00:00:00 2001
From: Aastha Mehta aasth...@gmail.com
Date: Thu, 8 Sep 2011 22:25:44 -0700
Subject: [PATCH 1/1] added code to display verbose messages on session connection errors
Sorry, please ignore the previous patch. There was some minor error in that.
Re-attaching the patch here.
Thanks,
Aastha.
On 8 September 2011 01:44, Aastha Mehta aasth...@gmail.com wrote:
Hi,
Thanks for the feedback. I have included changes mentioned by different
people. Attaching patch
On Thu, Sep 8, 2011 at 2:26 PM, Aastha Mehta aasth...@gmail.com wrote:
Sorry, please ignore the previous patch. There was some minor error in that.
Re-attaching the patch here.
+#includestdio.h
+#includestdlib.h
+#includestring.h
+#include iscsi_if.h
+#includekern_error_table.h
+#define
On Thu, Sep 8, 2011 at 2:26 PM, Aastha Mehta aasth...@gmail.com wrote:
Sorry, please ignore the previous patch. There was some minor error in that.
Re-attaching the patch here.
+#includestdio.h
+#includestdlib.h
+#includestring.h
+#include iscsi_if.h
+#includekern_error_table.h
+#define
Aastha Mehta aasth...@gmail.com schrieb am 03.09.2011 um 07:50 in
Nachricht
caex9m45bx_tzjconvwdobqjjqzmuqqfpufc8rgjxdk+n52-...@mail.gmail.com:
Hi,
Thanks for the suggestions. There is already an enumeration of the error
codes given in the iscsi_if.h. The #defines cannot use the same
On 08/31/2011 11:57 AM, Aastha Mehta wrote:
Hello,
Attached is the patch for the first kernel TODO item in the TODO list
circulated earlier. I could not send the patch through git send-email, so
have attached it here.
Thanks,
Aastha.
- You do not need the changes to
Hi,
I have not done any changes to prom_lex.c. The diff shows something because
of difference in the two git sources downloaded. How do I drop the changes?
Will git diff --check suffice?
Please confirm if I should #define the error messages or not. If yes, will
macro name pattern like
Before I patch again, would like to show you the files. Have added a default
case in the err_code_to_string() function. Also removed the extra err_string
variable I used previously in the function. Each case now directly returns
the appropriate message from the table directly, as no other work is
Aastha Mehta aasth...@gmail.com schrieb am 31.08.2011 um 18:57 in
Nachricht
CAEx9m44_UGavmNQ-Z8gdutsk-ZRSFZ+nKeBG+YGSK=vxdnn...@mail.gmail.com:
Hello,
Attached is the patch for the first kernel TODO item in the TODO list
circulated earlier. I could not send the patch through git
Hi,
Thanks for the suggestions. There is already an enumeration of the error
codes given in the iscsi_if.h. The #defines cannot use the same names, but
it can be done with slightly different names.
So I shall modify the following things in the code -
1. #define the error messages and use those
2.
/group/open-iscsi?hl=en.
From ef75092e47544e126b259114ce87cdf395ca3d9d Mon Sep 17 00:00:00 2001
From: Aastha Mehta aasth...@gmail.com
Date: Mon, 29 Aug 2011 10:18:17 -0700
Subject: [PATCH 1/1] added code to display verbose messages on session connection errors
---
usr/Makefile |2
Hi all,
I just noticed that I've botched up header digests with the latest
update for SLES10 SP3. So if you got trouble connecting and get
loads of 'iscsi: detected conn error (1011)' please switch off
header digests.
I'm working on fixing this and will let you know once the issue is
fixed.
On 12/20/2010 09:56 AM, Hannes Reinecke wrote:
Hi all,
I just noticed that I've botched up header digests with the latest
update for SLES10 SP3. So if you got trouble connecting and get
loads of 'iscsi: detected conn error (1011)' please switch off
header digests.
I'm working on fixing
FYI, to disbale connection load balancing on equallogics, you run...
Login into the array as grpadmin; at the CLI prompt, type this
command:
CLI grpparams conn-balancing disable
This command can be done w/o a reboot or restart of the arrays and
becomes effective immediately on all members in
Oops, I should have added, in our testing, disabling the conn-
balancing made no difference with respect to throughput/IO numbers...
On May 26, 10:00 am, Taylor taylor.lew...@gmail.com wrote:
FYI, to disbale connection load balancing on equallogics, you run...
Login into the array as grpadmin;
On 24 May 2010 at 9:06, Taylor wrote:
Adjusting node.conn[0].timeo.noop_out_interval and
node.conn[0].timeo.noop_out_timeout to 0
didn't seem to make a difference. But increasing the value of /sys/
block/sd#/device/timeout from 30 to a higher number, like 360, seems
to have improved
Yeah, and netstat -in does show a few RX-ERR on the two 10 Gig NICs we
are connecting to the iSCSI san with.
So I don't know if thats because of the extremely high IO load. i.e.,
iostat is reporting 600,000 Kbytes/sec in writes across 4 LUNs during
our heavy testing.
--
You received this
On 05/24/2010 11:22 PM, Taylor wrote:
Yes, when I get to office tomorrow I can attach screen output of make
fail, as well as support info with equallogic.
I guess to a different point, I understand if we are just killing the
disk that can cause problems, but how can I set it up so that IO is
Ok, will find out about the equallogic setting. So if we are using
dm-multipath, we should not set those noop values to 0, but possibly
increase them for high IO loads?
On Tue, May 25, 2010 at 2:47 PM, Mike Christie micha...@cs.wisc.edu wrote:
On 05/24/2010 11:22 PM, Taylor wrote:
Yes, when I
On 05/25/2010 04:15 PM, Taylor wrote:
So far blowing away SUSE 11 and installing OpenSuse has resolved the
Just so you know , the SUSE developers are good at keeping SLES up to
date and even have fixes that are not yet upstream, so it is sometimes
best to just get their newest SLES kernels.
Thanks for the suggestions, I did change the io scheduler to make sure
it was same as other server we were testing on.
Not using iptables, and cpu frequency scaling or whatever its called
is not enabled.
To us this looks like an issue with worse network performance with later
kernels. The kernel
Adjusting node.conn[0].timeo.noop_out_interval and
node.conn[0].timeo.noop_out_timeout to 0
didn't seem to make a difference. But increasing the value of /sys/
block/sd#/device/timeout from 30 to a higher number, like 360, seems
to have improved things...
Is that something you would expect? Do
On 05/24/2010 11:06 AM, Taylor wrote:
Adjusting node.conn[0].timeo.noop_out_interval and
node.conn[0].timeo.noop_out_timeout to 0
didn't seem to make a difference. But increasing the value of /sys/
If it did not make a difference then it might not have got set right. If
you set them to 0,
Mike and all, okay, noted about the ping timeout messages. I set both
of
those values by running:
iscsiadm --mode node --o update -n
node.conn[0].timeo.noop_out_interval -v 10
iscsiadm --mode node --o update -n node.conn[0].timeo.noop_out_timeout
-v 10
I verifed the settings took via iscsiadm
Yes, when I get to office tomorrow I can attach screen output of make
fail, as well as support info with equallogic.
I guess to a different point, I understand if we are just killing the
disk that can cause problems, but how can I set it up so that IO is
slow or queues, and doesn't cause
parameters on the iscsi
NICs, and adjusting iscsid.conf timeouts.
We are running a 2.6.27 kernel with open-iscsi 2.0.870-26.5.
Does anyone have any suggestions on how we can avoide these timeouts
and connection errors?
--
You received this message because you are subscribed to the Google Groups
On 05/21/2010 03:43 PM, Taylor wrote:
We have a SLES 11 server connected to an Equallogic 10 Gig disk array.
Initially everything seemed to work just fine. When doing some IO
testing against the mounted volumes, in which we cause very high IO
loads, i.e. 95 to 100% as reported by iostat, we
Mike, thanks for the reply. The first line in the log i posted shows
the ping timeout. Or were you wanting to see something else? Let me
know what specifically you are looking for.
Yes we are using multipath, I can post multipath.conf if that helps.
I tried tweaking various settings in
I am using iscsi to connect a Centos 5.2 server to a Promise Tech Vtrak
M610i
On the linux box, I have
iscsi-initiator-utils-6.2.0.868-0.18.el5
2.6.18-92.1.13.el5.centos.plus #1 SMP Wed Oct 1 13:41:35 EDT 2008 x86_64
x86_64 x86_64 GNU/Linux
The Promise array is on a separate subnet from the
We've run into some issues in the past with iSCSI disconnects. As an FYI, one
thing that has helped is is to put dm-multipath in the middle and add another
iface. This allows one path to fail and you still get access to the device. I
know it doesn't necessarily answer your question, but may
On 02/23/2010 02:04 PM, Jonathan Murray wrote:
after about 24 hours, we see the following in /var/log/messages (not in
order)
iscsid: connect failed (111)
iscsi: cmd 0x28 is not queued (8)
iscsi: cmd 0x2a is not queued (8)
iscsi: detected conn error (1011)
Kernel reported iSCSI connection 1:0
On Feb 24, 2:19 pm, Mike Christie micha...@cs.wisc.edu wrote:
On 02/23/2010 02:04 PM, Jonathan Murray wrote:
after about 24 hours, we see the following in /var/log/messages (not in
order)
iscsid: connect failed (111)
iscsi: cmd 0x28 is not queued (8)
iscsi: cmd 0x2a is not queued
On Feb 24, 2:19 pm, Mike Christie micha...@cs.wisc.edu wrote:
On 02/23/2010 02:04 PM, Jonathan Murray wrote:
after about 24 hours, we see the following in /var/log/messages (not in
order)
iscsid: connect failed (111)
iscsi: cmd 0x28 is not queued (8)
iscsi: cmd 0x2a is not queued
On 02/24/2010 03:49 PM, Murray wrote:
On Feb 24, 2:19 pm, Mike Christiemicha...@cs.wisc.edu wrote:
On 02/23/2010 02:04 PM, Jonathan Murray wrote:
after about 24 hours, we see the following in /var/log/messages (not in
order)
iscsid: connect failed (111)
iscsi: cmd 0x28 is not queued (8)
Mike Christie wrote:
Evan Broder wrote:
Evan Broder wrote:
Just got another round of failures with the new debugging patch in.
Traffic dump at
http://web.mit.edu/broder/Public/iscsi/iscsi_traffic-2008-12-20-22-00.pcap.bz2,
syslog (including the kernel log) at
Evan Broder wrote:
Evan Broder wrote:
Just got another round of failures with the new debugging patch in.
Traffic dump at
http://web.mit.edu/broder/Public/iscsi/iscsi_traffic-2008-12-20-22-00.pcap.bz2,
syslog (including the kernel log) at
Evan Broder wrote:
Just got another round of failures with the new debugging patch in.
Traffic dump at
http://web.mit.edu/broder/Public/iscsi/iscsi_traffic-2008-12-20-22-00.pcap.bz2,
syslog (including the kernel log) at
http://web.mit.edu/broder/Public/iscsi/syslog-2008-12-20-22-00.bz2
-
Evan Broder wrote:
Incidentally, to what extent is user data exposed in the dump? I've
asked some friends to let me run their VMs on citadel-station to try and
increase the probability of an incident occurring, but they presumably
wouldn't appreciate me sending out logs if data from their
you have any theories on how we could trigger these connection errors,
if they're still occurring?
- Evan
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
open-iscsi group.
To post to this group, send email to open
Mike Christie wrote:
Not with just the above info. I t could be happening for a variety of
reasons.
It looks like the target is either disconnecting us (this is why I was
looking for a TCP_CLOSE in the debug output) because we goofed on some
iscsi protocol issue but normally I would have
On Wed, Dec 10, 2008 at 12:45:04PM +0100, Ulrich Windl wrote:
On 8 Dec 2008 at 17:52, Pasi Kärkkäinen wrote:
iscsiadm -m session -P3
Hi,
being curious: My version if iscsiadm (version 2.0-754) doesn't know about
the -
P3. What ist it expected to do?
It just prints more
network. We've been regularly
experiencing connection errors:
Dec 8 00:50:36 aperture-science kernel: [1010621.595904]
connection1:0: iscsi: detected conn error (1011)
Dec 8 00:50:37 aperture-science iscsid: Kernel reported iSCSI
connection 1:0 error (1011) state (3)
Dec 8 00:50:39 aperture
Ulrich Windl wrote:
On 8 Dec 2008 at 17:52, Pasi Kärkkäinen wrote:
iscsiadm -m session -P3
Hi,
being curious: My version if iscsiadm (version 2.0-754) doesn't know about
the -
P3. What ist it expected to do?
In older versions you might be able to do
iscsiadm -m session -i
This
zhaoyuqiang wrote:
Hi,
Someone solved the issue like this with running opensuse10.3. you can
try download source code from
http://www.open-iscsi.org/bits/open-iscsi-2.0-865.13.tar.gz
http://www.open-iscsi.org/bits/open-iscsi-2.0-865.13.tar.gz and
complie for Ubuntu, it's like
is 10.5.128.129 on all
Evan servers. It doesn't change after one of the connection errors.
That suggests the load balancer is not involved here.
You might check the event logs on the array to see if there are any
messages there around the same time.
paul
A group I work with is currently using a Dell Equallogic RAID with
four servers on a dedicated storage network. We've been regularly
experiencing connection errors:
Dec 8 00:50:36 aperture-science kernel: [1010621.595904]
connection1:0: iscsi: detected conn error (1011)
Dec 8 00:50:37 aperture
Mike Christie wrote:
Evan Broder wrote:
#define ISCSI_TRANSPORT_VERSION 2.0-724
The userspace utilities are 2.0.865.
Are these the Ubuntu tools or did you get them from open-iscsi.org? If
they are ubuntu ones is there more version info on the ubuntu package?
What is the iscsi package
Evan Broder wrote:
A group I work with is currently using a Dell Equallogic RAID with
four servers on a dedicated storage network. We've been regularly
experiencing connection errors:
Dec 8 00:50:36 aperture-science kernel: [1010621.595904]
connection1:0: iscsi: detected conn error (1011
Mike Christie wrote:
Evan Broder wrote:
A group I work with is currently using a Dell Equallogic RAID with
four servers on a dedicated storage network. We've been regularly
experiencing connection errors:
Dec 8 00:50:36 aperture-science kernel: [1010621.595904]
connection1:0: iscsi
Evan Broder wrote:
Mike Christie wrote:
Evan Broder wrote:
A group I work with is currently using a Dell Equallogic RAID with
four servers on a dedicated storage network. We've been regularly
experiencing connection errors:
Dec 8 00:50:36 aperture-science kernel: [1010621.595904
On Mon, Dec 08, 2008 at 02:57:44PM -0500, Evan Broder wrote:
Mike Christie wrote:
Evan Broder wrote:
A group I work with is currently using a Dell Equallogic RAID with
four servers on a dedicated storage network. We've been regularly
experiencing connection errors:
Dec 8 00:50:36
Paul Koning wrote:
You might check the event logs on the array to see if there are any
messages there around the same time.
paul
There isn't anything. There's a message for the disconnect, and a
message for the reconnect.
- Evan
Pasi Kärkkäinen wrote:
On Mon, Dec 08, 2008 at 02:57:44PM -0500, Evan Broder wrote:
Yeah. Our storage network is completely isolated, so we thought about
trying to disable CHAP, but we couldn't find an option to turn it off in
the Equallogic config.
In your volume properties, add
Evan Broder wrote:
Pasi Kärkkäinen wrote:
On Mon, Dec 08, 2008 at 02:57:44PM -0500, Evan Broder wrote:
Yeah. Our storage network is completely isolated, so we thought about
trying to disable CHAP, but we couldn't find an option to turn it off in
the Equallogic config.
In your
Mike Christie wrote:
Is the only log error that bit about:
iqn.2001-05.com.equallogic:0-8a0906-2b6e7d402-891497db5ca48925-xvm-volume-1'
from initiator '10.5.128.16:53712, iqn
1993-08.org.debian:01:bce099ff4d44' was closed.
Yeah, that's the only thing that ever shows up. It's immediately
Evan Broder wrote:
Mike Christie wrote:
Is the only log error that bit about:
iqn.2001-05.com.equallogic:0-8a0906-2b6e7d402-891497db5ca48925-xvm-volume-1'
from initiator '10.5.128.16:53712, iqn
1993-08.org.debian:01:bce099ff4d44' was closed.
Yeah, that's the only thing that ever shows up.
Mike Christie wrote:
If you can play around on the box, it would be helpful to run the
open-iscsi tarball release. Build it with
Oh yeah that is here:
http://www.open-iscsi.org/bits/open-iscsi-2.0-870.1.tar.gz
--~--~-~--~~~---~--~~
You received this message
Hello,
I would strongly suggest using the code version Mike mentioned. I use
ubuntu 8.04/8.10 with that code without issues w/EQL arrays.
Running the older transport kernel module has caused NOOP errors. The
initiator sends out NOOPs w/different SN numbers than what the array is
expecting.
swejis wrote:
I increased the I/O on the initiator yesterday by placing the LUN
holding our mySQL database on this server. Everything looks 'quite'
well part from the error I got this morning. All nop time out set to
zero.
Jul 1 07:15:23 manjula syslog-ng[17906]: STATS: dropped 0
Jul 1
I increased the I/O on the initiator yesterday by placing the LUN
holding our mySQL database on this server. Everything looks 'quite'
well part from the error I got this morning. All nop time out set to
zero.
Jul 1 07:15:23 manjula syslog-ng[17906]: STATS: dropped 0
Jul 1 07:20:38 manjula
Yet again I must have done something wrong since I was unable to set
the timeout values to zero. Yesterday I removed all saved data
meaning the nodes and send_targets directory from /etc/isci and reran
the discovery, now the values where indeed set. I did this yesterday
on two machines (one 64
swejis wrote:
Up to the parts where you see the last scsi device get added.
I previously posted this file: http://www.wehay.com/messages.1.gz wont
that do ?
No. I do not need any of the kernel info. It all seems to be telling us
that the kernel really does think we set the timers as 5
].timeo.noop_out_timeout = 0
node.conn[0].timeo.noop_out_interval = 0
node.conn[0].timeo.noop_out_timeout = 0
Still I'm seeing quite a few connection errors (with the latest path
applied)
Yeah, something is still setting the nops somehow so we are still
hitting the same problem. If you do
cat
Anything else I can do/collect/test ?
Brgds Jonas
--~--~-~--~~~---~--~~
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,
Found it, you made this patch is against a clean tree while I had your
previous patch applied.
New log: http://www.wehay.com/messages.1.gz
Brgds Jonas
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
open-iscsi
I spent some time this morning trying to find more evidence. As said
only one connection seem to suffer of those connections errors. What
also said however is that only connections with I/O suffer. One thing
bothered me for some time is that the /dev/sdX devices move around
when restarting the
Target Configuration
Node ID 1
Node Name iqn.1994-12.com.promise.target.a9.39.4.55.1.0.0.20
Node Alias VTrak M500i
Max Outstanding R2T 1
Max Burst Length256KB
Max Connections 1
Default Time to Wait2 Seconds
Default Time to Retain 20 Seconds
Error
On Thu, May 29, 2008 at 01:06:45AM -0700, swejis wrote:
I spent some time this morning trying to find more evidence. As said
only one connection seem to suffer of those connections errors. What
also said however is that only connections with I/O suffer. One thing
bothered me for some time
On Thu, May 29, 2008 at 03:34:08AM -0700, swejis wrote:
Thanks Pasi, I saw your post a couple of days ago. Perhaps you could
post some Target-configuration to compare ?
It's pretty much the standard or out of the box configuration with a
couple of LD's defined.. I'm running the latest
swejis wrote:
I spent some time this morning trying to find more evidence. As said
only one connection seem to suffer of those connections errors. What
also said however is that only connections with I/O suffer. One thing
bothered me for some time is that the /dev/sdX devices move around
Hello, Mike.
Am I doing something wrong again ?
patch -p1 -i ../more-nop-debug.patch
patching file kernel/libiscsi.c
Hunk #1 FAILED at 319.
Hunk #2 FAILED at 481.
Hunk #3 FAILED at 639.
Hunk #4 succeeded at 758 with fuzz 2 (offset 10 lines).
Hunk #5 FAILED at 1401.
4 out of 5 hunks FAILED --
swejis wrote:
OK, new logfile found here: http://www.wehay.com/messages.new.gz
Can you remind me what target you are using and how many sessions you
should have? It looks like only one session has problems. The other/s
look like they are just fine. Are the errors now (before I understood
On Wed, May 28, 2008 at 01:44:02PM -0500, Mike Christie wrote:
swejis wrote:
OK, new logfile found here: http://www.wehay.com/messages.new.gz
Can you remind me what target you are using and how many sessions you
should have? It looks like only one session has problems. The other/s
Can you remind me what target you are using and how many sessions you
should have?
The m500i have got two portals, so two session are started of for each
portal.
tcp: [1] 192.168.43.6:3260,2 iqn.
1994-12.com.promise.target.a9.39.4.55.1.0.0.20
tcp: [2] 192.168.43.5:3260,1 iqn.
swejis wrote:
So sorry for the delay but I have not been able to reboot the machine
until now. Still I had no success getting your test-version to write
more debug info into the logs. I therefor downloaded and compiled the
latest semi-stable version I found meaning 2.0-869.2. When not this
So sorry for the delay but I have not been able to reboot the machine
until now. Still I had no success getting your test-version to write
more debug info into the logs. I therefor downloaded and compiled the
latest semi-stable version I found meaning 2.0-869.2. When not this
version either wrote
swejis wrote:
I have now changed the following, correct ?
## node.conn[0].timeo.noop_out_interval = 5
node.conn[0].timeo.noop_out_interval = 0
node.conn[1].timeo.noop_out_interval = 0
# node.conn[0].timeo.noop_out_timeout = 5
node.conn[0].timeo.noop_out_timeout = 0
OK, removed iscsi package.
Compiled new package (added suse-parameters recommended from readme
file)
make DEBUG_SCSI=1 KSRC=/usr/src/linux-2.6.25-rc9-17 KBUILD_OUTPUT=/usr/
src/linux-obj/x86_64/default
Compilation completeOutput file
---
I'm sorry Mike but i'm uncertain what to copy. Tried to look and
compare against your previously attached patch but with no success.
manjula:/opt/src/open-iscsi-2.0-869.1.test1 # patch iscsi.patch
patching file Makefile
Hunk #1 FAILED at 32.
1 out of 1 hunk FAILED -- saving rejects to file
swejis wrote:
Hello everyone. I'm not very experienced with iscsi, so please excuse
me if asking stupid questions.
I'm evaluation opensuse 11 (Beta1) for my servers and have found some
worrying errors in the log. The following error quite frequently shows
up.
May 5 21:15:05 manjula
swejis wrote:
Hello everyone. I'm not very experienced with iscsi, so please excuse
me if asking stupid questions.
I'm evaluation opensuse 11 (Beta1) for my servers and have found some
worrying errors in the log. The following error quite frequently shows
up.
May 5 21:15:05 manjula
97 matches
Mail list logo
