Re: lmCompile Prolem of core-iscsi-v1.6.2.9 on kernel 2.6.26.1

[Nicholas A. Bellinger]

On Wed, 2008-09-10 at 13:54 -0700, Andy Ngo wrote:
> Hi, nab,
>
> Thanks for your reply.
>
> I downloaded the R391 version.
>
> The testing of R391 showed that the iscsi client still hangs when the
> "rmmod iscsi_initiator_mod" command is issued.
>

So yes, I am working on the rmmod iscsi_initiator_mod hang in question
for Core-iSCSI initiator now..

> Another thing we noticed is that when we started the connection, we
> encountered "Addconn: [FAILED]: 255" as follows:
>
> iSCSI Core Stack[1] - Loading Core-iSCSI Initiator: [OK]
> iSCSI Core Stack[1] - Starting iSCSI Authentication: [OK]
> iSCSI Core Stack[1] - Processing /etc/sysconfig/initiator
> iSCSI Channel[0] - Starting connection to 9.34.205.13:3260
> iSCSI Channel[0] - Login: [OK]
> iSCSI Channel[1] - Skipping disabled iSCSI CHANNEL
>
>
> iSCSI Channel[0] - Skipping disabled iSCSI DEVICE entries
> iSCSI Channel[0] - Starting connection to 9.34.205.13:3260
> iSCSI Channel[0] - Addconn: [FAILED]: 255
>
>
> We experienced this same issue with the earlier download but we didn't
> notice it because there was a delay between the login and the starting
> of the connection.

So, the second parameter in your /etc/sysconfig/initiator:CHANNEL=""
define is for the iSCSI connection count (eg: yours is greater than
one). In order for additional iSCSI connections to established to the
iSCSI channel/session in question, your iSCSI Target node endpoint must:

1) Support Multiple Connections Per Session (MC/S). (If you are not
using LIO-Target, yours does not)

2) Have MaxConnections= allowed to be greater than 1 for the iSCSI
Target Portal Group in the iSCSI Initiator will be connecting to (known
as default TPG parameters). The iSCSI Target Portal Group endpoint can
enforce MaxConnections as well. You will notice we have been discussing
this on another thread (see below) wrt 'target-ctl settpgparam' using
LIO-Target v2.9. With LIO-Target we do this using a iSCSI Target Node
Name (targetname=) + iSCSI Target Portal Group (tpgt=) tuple, as well as
all of the other LIO-Target related commands. :-)

>
> Do you have any suggestions for the above problems?
> Also, what iscsi target software (with version) are you using to test
> with?
>
>

This is the Target-Engine-Core / LIO-Target mailing list btw :-)

http://linux-iscsi.org/index.php/LIO-Target

I CC'ed the original Core-iSCSI list (which has been quiet for some
time, as Open/iSCSI has gone stable), but I don't have a problem with
any Linux and non Linux iSCSI Initiator discussion or posting here.. :-)

LIO-Target supports the MC/S you mention above with Core-iSCSI, as well
as the active-active iSCSI connection recovery (known as
ErrorRecoveryLevel=2) logic defined by RFC 3720: 7.2. Connection
Cleanup State Diagram for Initiators and Targets.

--nab

>
>
>
> >

[Nicholas A. Bellinger]

On Wed, 2008-09-10 at 15:03 -0700, Nicholas A. Bellinger wrote:

> On Wed, 2008-09-10 at 14:25 -0700, Nicholas A. Bellinger wrote:
> > On Wed, 2008-09-10 at 13:54 -0700, Andy Ngo wrote:
> > > Hi, nab,
> > >
> > > Thanks for your reply.
> > >
> > > I downloaded the R391 version.
> > >
> > > The testing of R391 showed that the iscsi client still hangs when the
> > > "rmmod iscsi_initiator_mod" command is issued.
> > >
> >
> > So yes, I am working on the rmmod iscsi_initiator_mod hang in question
> > for Core-iSCSI initiator now..
> >
>

> Ok, here was the last bit of breakage.. r392 is tested and works on
> v2.6.26.5. The CPP macros in the patch are kinda hard to read, but it
> is not too bad.
>
> The joys of backward (and in this case forwards) compatibility. :-)
>
> ------------------------------------------------------------------------
> r392 | nab | 2008-09-10 15:00:56 -0700 (Wed, 10 Sep 2008) | 5 lines
> Changed paths:
> M /branches/coreiscsi-1.6.2/core/iscsi_initiator_sysfs.c
>
> [Core-iSCSI]: Fixed kobject_unregister() removal breakage for >= v2.6.25.
>
> With kobject_unregister() removed with >= v2.6.25 kernels, we call kobject_put()
> twice for the iSCSI Channel's conn_val_obj and sess_val_object instead of only a
> single time (this is the logic that kobject_unregister() used to implement..
>

Hrrmmm, doing an 'rmmod iscsi_initiator_mod' or initiator-ctl freechan
with r392 on v2.6.25.10 produces a BUG() in kobject_release().

Again, just to be clear, r392 with v2.6.26.5 x86 works as expected in
both cases, so I would recommend sticking with v2.6.26.x for now.

--nab

[Nicholas A. Bellinger]

Ok, commited r393. Everything should be good to go all kernel revisions
now.

--nab