successfully,
> everything
> > looks well
> > but when i start to read I/O(dd if=/dev/sdb of=/dev/null bs=512k), it
> > will print
> > "connection1:0: detected conn error (1011) "
> > it happened many times
> > a
/null bs=512k), it
> > will print
> > "connection1:0: detected conn error (1011) "
> > it happened many times
> > any reply will be welcome
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups
.
What target is this with?
On 07/22/2014 09:42 PM, 木木夕 wrote:
> hello everyone,
> the iscsi initiator can login the iscsi target successfully, everything
> looks well
> but when i start to read I/O(dd if=/dev/sdb of=/dev/null bs=512k), it
> will print
> "connection1:0: de
hello everyone,
the iscsi initiator can login the iscsi target successfully, everything
looks well
but when i start to read I/O(dd if=/dev/sdb of=/dev/null bs=512k), it will
print
"connection1:0: detected conn error (1011) "
it happened many times
any reply will be welcome
--
You rec
From: Mike Christie [mailto:micha...@cs.wisc.edu]
Sent: Tuesday, December 14, 2010 7:18 PM
To: open-iscsi@googlegroups.com
Cc: Paul
Subject: Re: connection1:0: ping timeout of 5 secs expired, recv timeout
5 / connection1:0: detected conn error (1011)
On 12/14/2010 03:12 PM, p...@fhri.org wrote:
&g
On 12/14/2010 03:12 PM, p...@fhri.org wrote:
Hi all...
I have four CentOS 5.4 (2.6.18-164.11.1.el5) servers with iscsid version
2.0-871. Two are misbehaving despite identical configuration. They all
connect to Enhance Tech RS8-IP4 array the same way, directly NIC-to-NIC
without a switch, physi
, now
21989752817
Dec 13 17:11:59 db4 kernel: connection1:0: detected conn error (1011)
Dec 13 17:12:00 db4 iscsid: Kernel reported iSCSI connection 1:0 error
(1011) state (3)
Dec 13 17:12:17 db4 iscsid: connection1:0 is operational after recovery
(2 attempts)
Dec 13 17:13:06 db4 kernel: connection1:0:
Sorry,
this message was intended for someone else. E-Mail program tricked me. -- Ulrich
>>> "Ulrich Windl" schrieb am 08.09.2010 um
13:51 in Nachricht <4c8794da02a1f...@gwsmtp1.uni-regensburg.de>:
--
You received this message because you are subscribed to the Google Groups
"open-iscs
: connection19:0: iscsi: detected conn error
(1011)
Sep 7 16:08:23 hostname kernel: connection31:0: iscsi: detected conn error
(1011)
Sep 7 16:08:23 hostname kernel: connection20:0: iscsi: detected conn error
(1011)
Sep 7 16:08:23 hostname kernel: connection32:0: iscsi: detected conn error
(1011)
Sep
ecv timeout 10, last rx 371574, last ping 372574, now 374074
Aug 27 15:35:50 cb-xen-srv16 kernel: connection3:0: detected conn error (1011)
Aug 27 15:35:51 cb-xen-srv16 iscsid: Kernel reported iSCSI connection 3:0 error
(1011) state (3)
Aug 27 15:36:06 cb-xen-srv16 multipathd: sdm: tur checker report
On Thu, Sep 02, 2010 at 03:15:31PM -0700, Shantanu Mehendale wrote:
> Hi Hannes/Mike,
>
> I am also dealing with another issue on ISCSI transport where I am
> seeing "DID_TRASNPORT_FAILFAST" hostbyte errors reaching the application
> which is sending I/O on a device-mapper node. Reading the code
Thanks Hannes and Mike,
Your help has been highly appreciated!
Cheers,
-Goncalo.
-Original Message-
From: Hannes Reinecke [mailto:h...@suse.de]
Sent: 31 August 2010 14:43
To: Goncalo Gomes
Cc: Mike Christie; open-iscsi@googlegroups.com; Shantanu Mehendale
Subject: Re: detected conn
Goncalo Gomes wrote:
> Hi Hannes,
>
> Thanks. The Citrix XenServer 5.6 distribution kernel is based on the 2.6.27
> tree of SLES 11.
> We add a few extra patches specific to Xen, dom0 integration and some
> backports from upstream.
> To the best of my knowledge these additions don't touch the i
orward thinking' with regards to the issue, though!
Thanks,
-Goncalo.
-Original Message-
From: Hannes Reinecke [mailto:h...@suse.de]
Sent: 30 August 2010 15:12
To: Goncalo Gomes
Cc: Mike Christie; open-iscsi@googlegroups.com; Shantanu Mehendale
Subject: Re: detected conn error (1011)
Goncalo Gomes wrote:
> Hi,
>
> On Fri, 2010-08-06 at 15:57 +0100, Hannes Reinecke wrote:
>> Mike Christie wrote:
>>> ccing Hannes from suse, because this looks like a SLES only bug.
>>>
>>> Hey Hannes,
>>>
>>> The user is using Linux 2.6.27 x86 based on SLES + Xen 3.4 (as dom0)
>>> running a coup
TIES OF NONINFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE WITH RESPECT TO THE PRIVATE FILES. THE PRIVATE FILES ARE DELIVERED ON
AN "AS IS" BASIS. YOU SHALL HAVE THE SOLE RESPONSIBILITY FOR ADEQUATE
PROTECTION AND BACK-UP OF AN<6>Loading iSCSI transport class v2.0
On 08/06/2010 11:38 AM, Mike Christie wrote:
It should stall, It works like FC and the fast io fail tmo. Users need
to set the iscsi replacement/recovery timeout like they would FC's fast
io fail tmo. They should set it to 3 or 5 secs or lower if they want
really fast failovers.
Oh yeah, Qlog
On 08/06/2010 09:57 AM, Hannes Reinecke wrote:
Mike Christie wrote:
ccing Hannes from suse, because this looks like a SLES only bug.
Hey Hannes,
The user is using Linux 2.6.27 x86 based on SLES + Xen 3.4 (as dom0)
running a couple of RHEL 5.5 VMs. The underlying storage for these VMs
is iSCSI
bject: Re: detected conn error (1011)
Mike Christie wrote:
> ccing Hannes from suse, because this looks like a SLES only bug.
>
> Hey Hannes,
>
> The user is using Linux 2.6.27 x86 based on SLES + Xen 3.4 (as dom0)
> running a couple of RHEL 5.5 VMs. The underlying storage for the
Mike Christie wrote:
> ccing Hannes from suse, because this looks like a SLES only bug.
>
> Hey Hannes,
>
> The user is using Linux 2.6.27 x86 based on SLES + Xen 3.4 (as dom0)
> running a couple of RHEL 5.5 VMs. The underlying storage for these VMs
> is iSCSI based via open-iscsi 2.0.870-26.6.1
ccing Hannes from suse, because this looks like a SLES only bug.
Hey Hannes,
The user is using Linux 2.6.27 x86 based on SLES + Xen 3.4 (as dom0)
running a couple of RHEL 5.5 VMs. The underlying storage for these VMs
is iSCSI based via open-iscsi 2.0.870-26.6.1 and a DELL equallogic array.
On Wed, 2010-08-04 at 21:51 -0500, Mike Christie wrote:
> conn error 1011 is generic. If this is occurring when the eql box is
> rebalancing luns, it is a little different than above. With the above
> problem we did not know why we got the error. With your situation we
> sort of expect this. We
On Thu, 2010-08-05 at 08:50 +0200, Ulrich Windl wrote:
> I guess that's SLES11 already. I just read an announcement that there is an
> opne-iscsi update for SLES11 SP1 available. Unfortunately Novell does not
> give any details in the announcements:
>
> 4. Recommended update for open-iscsi
>
>
>>> Goncalo Gomes schrieb am 04.08.2010 um 23:12
>>> in
Nachricht
:
> I'm running a setup composed of: Linux 2.6.27 x86 based on SLES + Xen 3.4 (as
> dom0) running a couple of RHEL 5.5 VMs. The underlying storage for these VMs
> is iSCSI based via open-iscsi 2.0.870-26.6.1 and a DELL equallogic
r the equallogic rebalances the LUNs between the controllers/ports, it
requests the initiator to logout and login again to the new port/ip. If the
guests are idle, the following messages show up in the logs:
Aug 3 17:55:08 goncalog140 kernel: connection1:0: detected conn error (1011)
Aug 3 17:
n the controllers/ports, it
requests the initiator to logout and login again to the new port/ip. If the
guests are idle, the following messages show up in the logs:
Aug 3 17:55:08 goncalog140 kernel: connection1:0: detected conn error (1011)
Aug 3 17:55:09 goncalog140 kernel: connection1:0: det
On 07/28/2010 09:34 AM, Sean S wrote:
What version of open-iscsi-871 are you using is it 871.1 or .2 .3?
I downloaded the "current semi-stable release":
http://www.open-iscsi.org/bits/open-iscsi-2.0-871.tar.gz
It doesn't appear to have a minor version number. Should I be using
something else?
>> "Ulrich Windl" schrieb am
>> 28.07.2010
> um
16:46 in Nachricht <4c505ef502a1e...@gwsmtp1.uni-regensburg.de>
> :
>>> Sean S schrieb am 28.07.2010 um 16:34 in
> > Nachricht
> > com>:
> How did you get those other kernel messages? If you can just get the
> > > iscsid log
>> >>> Sean S schrieb am 28.07.2010 um 16:34 in
> Nachricht
com>:
How did you get those other kernel messages? If you can just get the
> > iscsid log info that is sent after lines like this
>
> I'm able to issue the "dmesg" command after the drive is lost and
> still retrieve some logging info
> How did you get those other kernel messages? If you can just get the
> iscsid log info that is sent after lines like this
I'm able to issue the "dmesg" command after the drive is lost and
still retrieve some logging info. Unfortunately, what I sent was all
that I can get. If the drive ever succe
On 07/26/2010 05:37 PM, Sean S wrote:
Did you see anything from iscsid about why it could not log in? iscsid
writes to /var/log/messages by default.
Does the session/connection ever re-login (you would see some message in
/var/log/messages about connection X:Y is operational after recovery (Z
>> >>> Sean S schrieb am 27.07.2010 um 00:37 in
> Nachricht
<109cc690-901c-4e53-9fa9-1a9903380...@l14g2000yql.googlegroups.
> com>:
[...]
> I'm unable to view /var/log/messages after the failure due to running
> as iscsi root. Ulrich mentioned writing the log to a serial port, but
> I haven't bee
> Did you see anything from iscsid about why it could not log in? iscsid
> writes to /var/log/messages by default.
> Does the session/connection ever re-login (you would see some message in
> /var/log/messages about connection X:Y is operational after recovery (Z
> attempts)?
I'm unable to view /
On 07/26/2010 04:36 PM, Sean S wrote:
Thanks for the patch Mike. Below is the output from a failure when
running with the patch. Any thoughts?
[] iscsi_conn_failure+0x10/0x69 [libiscsi]
[] iscsi_eh_abort+0x2f1/0x406 [libiscsi]
[] __scsi_try_to_abort_cmd+0x19/0x1a [scsi_mod]
[] scsi_error_hand
+0x2b/0x3d
[] scsi_error_handler+0x0/0x422 [scsi_mod]
[] kthread+0xc0/0xeb
[] kthread+0x0/0xeb
[] kernel_thread_helper+0x7/0x10
===
connection1:0 detected conn error (1011)
[] iscsi_conn_failure+0x10/0x69 [libiscsi]
[] iscsi_eh_target_reset+0xbb/0x218 [libiscsi
t the error:
connection1:0 detected conn error (1011)
session1: session recovery timed out after 400 sec
Hi!
I cannot answer your question, but that brings up something I wanted to talk
about. Please apologize if something already exists, but I don't know:
In HP-UX 11.31 you can print "s
>>> Sean S schrieb am 14.07.2010 um 04:33 in Nachricht
<83cd8c40-2e84-4c52-a864-36643dd0a...@d8g2000yqf.googlegroups.com>:
> Nothing else in the log from iscsid. No mention of a failed reconnect,
> although the only log I'm really able to access post failure is dmesg.
> Since I'm running a root is
>>> Sean S schrieb am 13.07.2010 um 20:41 in Nachricht
<1f2389e7-9717-4f82-a05c-671f36a4c...@x21g2000yqa.googlegroups.com>:
> I'm running an iscsi root partition for a CentOS machine running a
> 2.6.18-53 kernel. Every couple of days I get the error:
>
> connect
sconnect the ethernet from the initiator
while running, all I/O access is correctly paused without returning I/
O errors. If I then reconnect before the 400s is up things go back to
normal. I don't however see the "detected conn error (1011)" message
in this situation however. Not sure if
e?
Curiously, if I physically disconnect the ethernet from the initiator
while running, all I/O access is correctly paused without returning I/
O errors. If I then reconnect before the 400s is up things go back to
normal. I don't however see the "detected conn error (1011)" message
in th
On 07/13/2010 01:41 PM, Sean S wrote:
I'm running an iscsi root partition for a CentOS machine running a
2.6.18-53 kernel. Every couple of days I get the error:
connection1:0 detected conn error (1011)
session1: session recovery timed out after 400 sec
Is there anything more to the lo
I'm running an iscsi root partition for a CentOS machine running a
2.6.18-53 kernel. Every couple of days I get the error:
connection1:0 detected conn error (1011)
session1: session recovery timed out after 400 sec
I compiled the open-iscsi 2.0-871 user tools and kernel modules from
s
> > I do not see this with SLES10 SP2 x86_64 on the same setup.
>
> > Dec 7 18:42:05 cdc-r710s1 kernel: connection2:0: detected conn error
> > (1011)
> > Dec 7 18:42:06 cdc-r710s1 iscsid: connection2:0 is operational after
> > recovery (1 attempts)
> &
avora wrote:
> With SLES10 SP3 x86_64,
> as soon as I start the second iscsi session2, I am very frequently
> getting the connection errors/
> I do not see this with SLES10 SP2 x86_64 on the same setup.
>
> Dec 7 18:42:05 cdc-r710s1 kernel: connection2:0: detected conn error
11:15:12 cdc-r710s3 iscsid: Kernel reported iSCSI connection 1:0 error
> (1011) state (3)
> Dec 14 11:15:13 cdc-r710s3 kernel: connection2:0: detected conn error (1011)
> Dec 14 11:15:13 cdc-r710s3 iscsid: connection2:0 is operational after
> recovery (1 attempts)
> Dec 14 11:15:13
bytes (5.1 MB) copied, 0.177076 seconds, 28.9 MB/s
dd: reading `/dev/sdaa8': Input/output error
2976+0 records in
2976+0 records out
Dec 14 11:15:12 cdc-r710s3 iscsid: Kernel reported iSCSI connection 1:0 error
(1011) state (3)
Dec 14 11:15:13 cdc-r710s3 kernel: connection2:0: detected co
Sorry, I do not see an upload option for me even after (signing-in).
How to upload ?
--- On Thu, 12/10/09, Mike Christie wrote:
> From: Mike Christie
> Subject: Re: SLES10 SP3 x86_64 - connection2:0: detected conn error (1011)
> To: open-iscsi@googlegroups.com
> Date: Thursday,
Anuarg Vora wrote:
> I did sent the ethereal trace yesterday.
> I am not sure why it didn't reach, is there any place I can upload it ?
>
http://groups-beta.google.com/group/open-iscsi/files
--
You received this message because you are subscribed to the Google Groups
"open-iscsi" group.
To pos
scsid Session State: REPOEN
--- On Thu, 12/10/09, Mike Christie wrote:
> From: Mike Christie
> Subject: Re: SLES10 SP3 x86_64 - connection2:0: detected conn error (1011)
> To: open-iscsi@googlegroups.com
> Date: Thursday, December 10, 2009, 11:22 PM
> avora wrote:
> > Yes Mik
avora wrote:
> Yes Mike, the recovery message is seen right away.
>
> Dec 7 18:42:06 cdc-r710s1 iscsid: connection2:0 is operational after
> recovery (1 attempts)
>
> 'conn error' and 'recovery' are seen one after the other, continuosly.
>
Do you have other initiators connected to the target?
There is no CHAP configured on the array.
--- On Thu, 12/10/09, berthiaume_wa...@emc.com wrote:
> From: berthiaume_wa...@emc.com
> Subject: RE: SLES10 SP3 x86_64 - connection2:0: detected conn error (1011)
> To: open-iscsi@googlegroups.com
> Date: Thursday, December 10, 2009,
Yes Mike, the recovery message is seen right away.
Dec 7 18:42:06 cdc-r710s1 iscsid: connection2:0 is operational after
recovery (1 attempts)
'conn error' and 'recovery' are seen one after the other, continuosly.
On Dec 10, 8:04 am, Mike Christie wrote:
> avora wrote:
> > I got a similar issue
Is CHAP configured on the array?
-Original Message-
From: open-iscsi@googlegroups.com [mailto:open-is...@googlegroups.com]
On Behalf Of Mike Christie
Sent: Wednesday, December 09, 2009 9:54 PM
To: open-iscsi@googlegroups.com
Subject: Re: SLES10 SP3 x86_64 - connection2:0: detected conn
Mike Christie wrote:
> avora wrote:
>> I do not see ping/nop timeout message in the logs
>> (probably that's why changing the noop timeouts did not work).
>> Simply starting the session does not cause these errors.
>> On starting the second session, I start a daemon
>> that does SCSI commands like
avora wrote:
> I got a similar issue while browsing
> http://groups.google.com/group/open-iscsi/browse_thread/thread/3c9c37903e40cd6f
>
> I wanted to enable logging as mentioned in above link.
>
> echo 1 > /sys/module/libiscsi/parameters/debug_libiscsi_conn
> echo 1 > /sys/module/libiscsi/par
avora wrote:
> I do not see ping/nop timeout message in the logs
> (probably that's why changing the noop timeouts did not work).
> Simply starting the session does not cause these errors.
> On starting the second session, I start a daemon
> that does SCSI commands like INQUIRY on all the paths.
>
I got a similar issue while browsing
http://groups.google.com/group/open-iscsi/browse_thread/thread/3c9c37903e40cd6f
I wanted to enable logging as mentioned in above link.
echo 1 > /sys/module/libiscsi/parameters/debug_libiscsi_conn
echo 1 > /sys/module/libiscsi/parameters/debug_libiscsi_sess
I do not see ping/nop timeout message in the logs
(probably that's why changing the noop timeouts did not work).
Simply starting the session does not cause these errors.
On starting the second session, I start a daemon
that does SCSI commands like INQUIRY on all the paths.
After that I see these me
avora wrote:
> With SLES10 SP3 x86_64,
> as soon as I start the second iscsi session2, I am very frequently
> getting the connection errors/
> I do not see this with SLES10 SP2 x86_64 on the same setup.
>
> Dec 7 18:42:05 cdc-r710s1 kernel: connection2:0: detected conn error
With SLES10 SP3 x86_64,
as soon as I start the second iscsi session2, I am very frequently
getting the connection errors/
I do not see this with SLES10 SP2 x86_64 on the same setup.
Dec 7 18:42:05 cdc-r710s1 kernel: connection2:0: detected conn error
(1011)
Dec 7 18:42:06 cdc-r710s1 iscsid
Matthew Dickinson wrote:
>
>
> On 11/10/09 11:39 AM, "Mike Christie" wrote:
>> What version of open-iscsi were you using and what kernel, and were you
>> using the iscsi kernel modules with open-iscsi.org tarball or from the
>> kernel?
>
> iscsi-initiator-utils-6.2.0.871-0.10.el5
> kernel-2.6.1
On 11/10/09 11:39 AM, "Mike Christie" wrote:
>
> What version of open-iscsi were you using and what kernel, and were you
> using the iscsi kernel modules with open-iscsi.org tarball or from the
> kernel?
iscsi-initiator-utils-6.2.0.871-0.10.el5
kernel-2.6.18-164.2.1.el5
RedHat RPMs
>
>
>
oh... also, the "ovm1" server is the dom0. That system is connecting to IETD
targets from within the dom0 using iscsi-initiator-utils-6.2.0.871-0.7. There
are two ifaces setup to connect to two portal IP's on my CentOS 5.3, aka
"storage", system. The result is this:
[r...@ovm1 ~]# iscsiadm
sorry... wrong information. Here is the correct information. I was doing some
testing in VMWare Fusion VM's for a presentation that I'm giving. The
"storage" server is CentOS 5.3, which dishes out IETD targets for my OVM
servers. The OVM 2.2 environment is as follows:
[r...@ovm1 ~]# uname
Hoot, Joseph wrote:
> [r...@storage ~]# uname -r
> 2.6.18-164.el5
> [r...@storage ~]# rpm -qa | grep iscsi
> iscsi-initiator-utils-6.2.0.868-0.18.el5_3.1
> [r...@storage ~]#
>
Weird.
Is 2.6.18-164.el5 the kernel being used in the virtual machine/DonU? Is
that where you are using iscsi? It look
l getting errors:
>
> Nov 10 09:08:04 backup kernel: connection12:0: detected conn error (1011)
> Nov 10 09:08:05 backup iscsid: Kernel reported iSCSI connection 12:0 error
> (1011) state (3)
> Nov 10 09:08:08 backup iscsid: connection12:0 is operational after recovery
> (1 attempts)
&
On 11/6/09 3:39 PM, "Matthew Dickinson" wrote:
>
>
>>
>> Try disabling nops by setting
>>
>> node.conn[0].timeo.noop_out_interval = 0
>> node.conn[0].timeo.noop_out_timeout = 0
>
I'm still getting errors:
Nov 10 09:08:04 backup kern
[r...@storage ~]# uname -r
2.6.18-164.el5
[r...@storage ~]# rpm -qa | grep iscsi
iscsi-initiator-utils-6.2.0.868-0.18.el5_3.1
[r...@storage ~]#
On Nov 10, 2009, at 12:17 PM, Mike Christie wrote:
>
> Hoot, Joseph wrote:
>> I've had about 3 threads of dt (kicking off a bit randomly) on (3) separa
Hoot, Joseph wrote:
> I've had about 3 threads of dt (kicking off a bit randomly) on (3) separate
> volumes for over a week and haven't had a single disconnect yet. I am
> currently using whatever rpm is distributed with Oracle VM v2.2. I know for
> sure that they have included the 871 base,
I've had about 3 threads of dt (kicking off a bit randomly) on (3) separate
volumes for over a week and haven't had a single disconnect yet. I am
currently using whatever rpm is distributed with Oracle VM v2.2. I know for
sure that they have included the 871 base, plus I believe at least a o
Hoot, Joseph wrote:
> it was for OiS 871 code prior to RHEL 5.4 release (not sure if the
> release include it or not). I'm not sure who came up with it. I was
> working with Don Williams from Dell EqualLogic. He got ahold of it
> somehow. I applied it and it seemed to improve things.
>
it was for OiS 871 code prior to RHEL 5.4 release (not sure if the
release include it or not). I'm not sure who came up with it. I was
working with Don Williams from Dell EqualLogic. He got ahold of it
somehow. I applied it and it seemed to improve things.
On Nov 9, 2009, at 2:31 PM, M
Hoot, Joseph wrote:
> What version of OiS are you using? I had lots of weirdness and the
> same types of disconnects to our Dell EqualLogic when we were
> (actually still are in production) using 868 code. I'm now using open-
> iscsi-871 code plus a sendwait patch and haven' had the issue.
ow many attempts)?
>
> Here's one particular connection:
>
> Nov 4 05:12:14 backup kernel: connection22:0: ping timeout of 5 secs
> expired, recv timeout 5, last rx 4321648393, last ping 4321653393, now
> 4321658393
> Nov 4 05:12:14 backup kernel: connection22:0: detected conn
What version of OiS are you using? I had lots of weirdness and the
same types of disconnects to our Dell EqualLogic when we were
(actually still are in production) using 868 code. I'm now using open-
iscsi-871 code plus a sendwait patch and haven' had the issue. I've
now been slamming my
El 06/11/09 14:10, mdaitc escribió:
Hi mdaitc,
> I’m seeing similar TCP “weirdness” as the other posts mention as well
> as the below errors.
(..)
> Nov 2 08:15:14 backup kernel: connection33:0: detected conn error
> The performance isn’t what I’d expect:
(..)
What happens if you disable
El 03/11/09 0:52, Mike Christie escribió:
Dear Mike,
> You can turn off ping/nops by setting
>
> node.conn[0].timeo.noop_out_interval = 0
> node.conn[0].timeo.noop_out_timeout = 0
>
> (set that in iscsid.conf then rediscovery the target or run "iscsiadm -m
> node -T your_target -o update -n name
El 02/11/09 19:43, James A. T. Rice escribió:
Dear James,
> That looks vaguely familiar, although I think mine was nop-out timeout
> (might be reported in another log file). Does it mostly happen when you do
> long sequential reads from the Infortrend unit? In my case it turned out
> to be a ver
gt;
> http://tr.im/DVQm
> http://tr.im/DVQp
>
> Open-iSCSI logs this:
>
> ===
> Nov 2 18:34:02 vz-17 kernel: ping timeout of 5 secs expired, last rx
> 408250499, last ping 408249467, now 408254467
> Nov 2 18:34:02 vz-1
/tr.im/DVQp
>
> Open-iSCSI logs this:
>
> ===
> Nov 2 18:34:02 vz-17 kernel: ping timeout of 5 secs expired, last rx
> 408250499, last ping 408249467, now 408254467
> Nov 2 18:34:02 vz-17 kernel: connection1:0: iscsi: detected conn
> error (1011)
>
rx
> 408250499, last ping 408249467, now 408254467
> Nov 2 18:34:02 vz-17 kernel: connection1:0: iscsi: detected conn error
> (1011)
> Nov 2 18:34:03 vz-17 iscsid: Kernel reported iSCSI connection 1:0 error
> (1011) state (3)
> Nov 2 18:34:07 vz-17 iscsid: connection1:0 is o
8:34:02 vz-17 kernel: ping timeout of 5 secs expired, last rx
408250499, last ping 408249467, now 408254467
Nov 2 18:34:02 vz-17 kernel: connection1:0: iscsi: detected conn
error (1011)
Nov 2 18:34:03 vz-17 iscsid: Kernel reported iSCSI connection 1:0
error (1011) state (3)
Nov 2 18:3
Christie wrote:
>>>>> hissing_sid wrote:
>>>>>> All sorted. Definitely running only open-iscsi now.
>>>>> Ok ignore the request to use iscsi-initiator-utils.
>>>>>> Still broken though
>>>>>> Loading iSCSI transpo
gt;> hissing_sid wrote:
> >>>> All sorted. Definitely running only open-iscsi now.
> >>> Ok ignore the request to use iscsi-initiator-utils.
> >>>> Still broken though
> >>>> Loading iSCSI transport class v2.0-870.
> >>>>
or-utils.
>>>> Still broken though
>>>> Loading iSCSI transport class v2.0-870.
>>>> iscsi: registered transport (tcp)
>>>> iscsi: registered transport (iser)
>>>> scsi6 : iSCSI Initiator over TCP/IP
>>>> connection1:0: detected con
> > > scsi6 : iSCSI Initiator over TCP/IP
> > > connection1:0: detected conn error (1011)
> > > session1: host reset succeeded
> > > connection1:0: detected conn error (1011)
> > > session1: host reset succeeded
> > > scsi 6:0:0:0: Device offl
ng iSCSI transport class v2.0-870.
> > iscsi: registered transport (tcp)
> > iscsi: registered transport (iser)
> > scsi6 : iSCSI Initiator over TCP/IP
> > connection1:0: detected conn error (1011)
> > session1: host reset succeeded
> > connection1:0: detected conn erro
scsi6 : iSCSI Initiator over TCP/IP
> connection1:0: detected conn error (1011)
> session1: host reset succeeded
> connection1:0: detected conn error (1011)
> session1: host reset succeeded
> scsi 6:0:0:0: Device offlined - not ready after error recovery
>
Can you get a ether
;>> tcp: [1] 10.52.145.121:3260,2 iqn.1999-02.com.nexsan:p1:sataboy:
>>> 028a2347
>>> Loading iSCSI transport class v2.0-870.
>>> iscsi: registered transport (tcp)
>>> iscsi: registered transport (iser)
>>> scsi3 : iSCSI Initiator over TCP/IP
>>
All sorted. Definitely running only open-iscsi now.
Still broken though
Loading iSCSI transport class v2.0-870.
iscsi: registered transport (tcp)
iscsi: registered transport (iser)
scsi6 : iSCSI Initiator over TCP/IP
connection1:0: detected conn error (1011)
session1: host reset succeeded
sends is timing out. The iscsi layer probably tries to abort the command
> and that fails so we try to drop the session (conn error 1011) then
> re-login. It looks like we log in at the iscsi level ok.
>
> I am not sure why this would happen. Let me do some digging. I think
> this might
registered transport (iser)
> scsi3 : iSCSI Initiator over TCP/IP
> connection1:0: detected conn error (1011)
> session1: host reset succeeded
Looks like maybe the initial inquiry or repport luns that the scsi layer
sends is timing out. The iscsi layer probably tries to abort the command
and th
Loading iSCSI transport class v2.0-870.
iscsi: registered transport (tcp)
iscsi: registered transport (iser)
scsi3 : iSCSI Initiator over TCP/IP
connection1:0: detected conn error (1011)
session1: host reset succeeded
connection1:0: detected conn error (1011)
session1: host reset succeeded
scsi
Konrad Rzeszutek wrote:
> On Thu, Apr 17, 2008 at 06:07:12AM -0400, Konrad Rzeszutek wrote:
>>> It looks like the network is off but the session is still running. We
>>> eventually get to the kernel shutoff here. Is your init script getting
>>> run? If not then run it. If you left the session on
Konrad Rzeszutek schrieb:
>> "Synchronizing SCSI cache for disk" happens because:
>>
>> - iSCSI sessions were not properly disconnected, and
>
> Correct.
>
>> - they can't be properly disconnected any more, because the network is
>> already disabled.
>
> Kind of. There is a kernel timer that g
> "Synchronizing SCSI cache for disk" happens because:
>
> - iSCSI sessions were not properly disconnected, and
Correct.
> - they can't be properly disconnected any more, because the network is
> already disabled.
Kind of. There is a kernel timer that gets activated during the logout sequence
Konrad Rzeszutek schrieb:
> On Thu, Apr 17, 2008 at 06:07:12AM -0400, Konrad Rzeszutek wrote:
>>> It looks like the network is off but the session is still running. We
>>> eventually get to the kernel shutoff here. Is your init script getting
>>> run? If not then run it. If you left the session
On Thu, Apr 17, 2008 at 06:07:12AM -0400, Konrad Rzeszutek wrote:
> > It looks like the network is off but the session is still running. We
> > eventually get to the kernel shutoff here. Is your init script getting
> > run? If not then run it. If you left the session on on purpose then you
> >
gt; > # iscsiadm -m node -T iqn.1991-05.com.microsoft:atlante-vm-shared-
> > disk-vm1-target -l
> > prints out:
>
> > Logging in to [iface: default, target: iqn.
> > 1991-05.com.microsoft:atlante-vm-shared-disk-vm1-target, portal:
> > 192.168.29.13,3260]
> > Login
d-
> disk-vm1-target -l
> prints out:
>
> Logging in to [iface: default, target: iqn.
> 1991-05.com.microsoft:atlante-vm-shared-disk-vm1-target, portal:
> 192.168.29.13,3260]
> Login to [iface: default, target: iqn.1991-05.com.microsoft:atlante-vm-
> shared-disk-vm1-target, portal: 192.168.29
1 - 100 of 105 matches
Mail list logo
