reassign linux-image-2.6.32-1-amd64
thanks

Hi,
the bug is still existant on amd64 with kernel image linux-image-2.6.32-1-amd64.

Still all attempts to mount an iscsi target with open-iscsi leads
to a hang in the --login ...

Renders open-iscsi unusable for amd64 ...

strace Log of an open-iscsi login which hangs ...

11280 execve("/usr/bin/iscsiadm", ["iscsiadm", "-m", "node", "--targetname", "iqn.1997-01.org.rfc822.lab.t4:st"..., "--portal", "195.71.99.251:3260", "--login"], [/* 14 vars */]) = 0
11280 brk(0) = 0x8cfb000
11280 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
11280 mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf77d2000
11280 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
11280 open("/etc/ld.so.cache", O_RDONLY) = 3
11280 fstat64(3, {st_mode=S_IFREG|0644, st_size=26171, ...}) = 0
11280 mmap2(NULL, 26171, PROT_READ, MAP_PRIVATE, 3, 0) = 0xf77cb000
11280 close(3) = 0
11280 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
11280 open("/lib/i686/cmov/libc.so.6", O_RDONLY) = 3
11280 read(3, "177ELF111331260e10044"..., 512) = 512
11280 fstat64(3, {st_mode=S_IFREG|0755, st_size=1413540, ...}) = 0
11280 mmap2(NULL, 1418864, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xf7670000
11280 mmap2(0xf77c5000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x155) = 0xf77c5000
11280 mmap2(0xf77c8000, 9840, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xf77c8000
11280 close(3) = 0
11280 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf766f000
11280 set_thread_area({entry_number:-1 -> 12, base_addr:0xf766f6b0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
11280 mprotect(0xf77c5000, 4096, PROT_READ) = 0
11280 munmap(0xf77cb000, 26171) = 0
11280 rt_sigaction(SIGINT, {0x8066bc0, [], 0}, {SIG_DFL}, 8) = 0
11280 umask(0177) = 022
11280 getrlimit(RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=1024}) = 0
11280 setrlimit(RLIMIT_NOFILE, {rlim_cur=16*1024, rlim_max=16*1024}) = 0
11280 access("/etc/iscsi/", F_OK) = 0
11280 mmap2(NULL, 462848, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf75fe000
11280 access("/var/lock/iscsi", F_OK) = 0
11280 open("/var/lock/iscsi/lock", O_RDWR|O_CREAT, 0666) = 3
11280 close(3) = 0
11280 link("/var/lock/iscsi/lock", "/var/lock/iscsi/lock.write") = 0
11280 access("/etc/iscsi/ifaces", F_OK) = 0
11280 unlink("/var/lock/iscsi/lock.write") = 0
11280 brk(0) = 0x8cfb000
11280 brk(0x8d1c000) = 0x8d1c000
11280 open("/sys/class/iscsi_host", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOE XEC) = 3
11280 fstat64(3, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
11280 fcntl64(3, F_GETFD) = 0x1 (flags FD_CLOEXEC)
11280 getdents(3, /* 2 entries */, 4096) = 32
11280 getdents(3, /* 0 entries */, 4096) = 0
11280 close(3) = 0
11280 open("/etc/iscsi/nodes", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOE XEC) = 3
11280 fstat64(3, {st_mode=S_IFDIR|0600, st_size=1024, ...}) = 0
11280 getdents(3, /* 4 entries */, 1024) = 132
11280 open("/etc/iscsi/nodes/iqn.1997-01.org.rfc822.lab.t4:storage.t4.disk1", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOE XEC) = 4
11280 fstat64(4, {st_mode=S_IFDIR|0600, st_size=1024, ...}) = 0
11280 getdents(4, /* 3 entries */, 1024) = 64
11280 open("/etc/iscsi/nodes/iqn.1997-01.org.rfc822.lab.t4:storage.t4.disk1/195.71.99.251,3260,1", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOE XEC) = 5
11280 fstat64(5, {st_mode=S_IFDIR|0600, st_size=1024, ...}) = 0
11280 getdents(5, /* 3 entries */, 1024) = 52
11280 access("/var/lock/iscsi", F_OK) = 0
11280 open("/var/lock/iscsi/lock", O_RDWR|O_CREAT, 0666) = 6
11280 close(6) = 0
11280 link("/var/lock/iscsi/lock", "/var/lock/iscsi/lock.write") = 0
11280 open("/etc/iscsi/nodes/iqn.1997-01.org.rfc822.lab.t4:storage.t4.disk1/195.71.99.251,3260,1/default", O_RDONLY) = 6
11280 fstat64(6, {st_mode=S_IFREG|0600, st_size=1676, ...}) = 0
11280 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf77d1000
11280 _llseek(6, 0, [0], SEEK_SET) = 0
11280 read(6, "node.name = iqn.1997-01.org.rfc82"..., 1024) = 1024
11280 read(6, "n.iscsi.MaxConnections = 1
node.s"..., 1024) = 652
11280 read(6, ""..., 1024) = 0
11280 close(6) = 0
11280 munmap(0xf77d1000, 4096) = 0
11280 unlink("/var/lock/iscsi/lock.write") = 0
11280 getdents(5, /* 0 entries */, 1024) = 0
11280 close(5) = 0
11280 getdents(4, /* 0 entries */, 1024) = 0
11280 close(4) = 0
11280 open("/etc/iscsi/nodes/iqn.2010-01.localhost:disk1", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOE XEC) = 4
11280 fstat64(4, {st_mode=S_IFDIR|0600, st_size=1024, ...}) = 0
11280 getdents(4, /* 3 entries */, 1024) = 60
11280 open("/etc/iscsi/nodes/iqn.2010-01.localhost:disk1/127.0.0.1,3260,1", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOE XEC) = 5
11280 fstat64(5, {st_mode=S_IFDIR|0600, st_size=1024, ...}) = 0
11280 getdents(5, /* 3 entries */, 1024) = 52
11280 access("/var/lock/iscsi", F_OK) = 0
11280 open("/var/lock/iscsi/lock", O_RDWR|O_CREAT, 0666) = 6
11280 close(6) = 0
11280 link("/var/lock/iscsi/lock", "/var/lock/iscsi/lock.write") = 0
11280 open("/etc/iscsi/nodes/iqn.2010-01.localhost:disk1/127.0.0.1,3260,1/default", O_RDONLY) = 6
11280 fstat64(6, {st_mode=S_IFREG|0600, st_size=1643, ...}) = 0
11280 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf77d1000
11280 _llseek(6, 0, [0], SEEK_SET) = 0
11280 read(6, "node.name = iqn.2010-01.localhost"..., 1024) = 1024
11280 read(6, "de.session.iscsi.MaxOutstandingR2"..., 1024) = 619
11280 read(6, ""..., 1024) = 0
11280 close(6) = 0
11280 munmap(0xf77d1000, 4096) = 0
11280 unlink("/var/lock/iscsi/lock.write") = 0
11280 getdents(5, /* 0 entries */, 1024) = 0
11280 close(5) = 0
11280 getdents(4, /* 0 entries */, 1024) = 0
11280 close(4) = 0
11280 getdents(3, /* 0 entries */, 1024) = 0
11280 close(3) = 0
11280 fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
11280 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf77d1000
11280 write(1, "Logging in to [iface: default, ta"..., 115) = 115
11280 socket(PF_FILE, SOCK_STREAM, 0) = 3
11280 connect(3, {sa_family=AF_FILE, path=@"ISCSIADM_ABSTRACT_NAMESPACE"...}, 110) = 0
11280 write(3, "1230q304377230q304377iqn.1997-01.o"..., 5244) = 5244
11280 recv(3, 0xffc46760, 2464, MSG_WAITALL) = ? ERESTARTSYS (To be restarted)
11280 --- SIGINT (Interrupt) @ 0 (0) ---
11280 write(2, "iscsiadm: "..., 10) = 10
11280 write(2, "caught SIGINT, exiting..."..., 25) = 25
11280 write(2, "
"..., 1) = 1
11280 exit_group(1) = ?

Flo
--
Florian Lohoff f@zz.de
"Es ist ein grobes Missverständnis und eine Fehlwahrnehmung, dem Staat
im Internet Zensur- und Überwachungsabsichten zu unterstellen."
- - Bundesminister Dr. Wolfgang Schäuble -- 10. Juli in Berlin



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Thu, Feb 11, 2010 at 04:37:36PM +0100, Florian Lohoff wrote:
> 11280 connect(3, {sa_family=AF_FILE, path=@"ISCSIADM_ABSTRACT_NAMESPACE"...}, 110) = 0
> 11280 write(3, "1230q304377230q304377iqn.1997-01.o"..., 5244) = 5244
> 11280 recv(3, 0xffc46760, 2464, MSG_WAITALL) = ? ERESTARTSYS (To be restarted)

This only shows that iscsid does not respond to the requests of
iscsiadm. However I consider it unlikely that such a bug should have
survived for 14 kernel releases.

Please show all the relevant configs, strace outputs of iscsiadm _and_
iscsid and also network traces.

Bastian

--
A princess should not be afraid -- not with a brave knight to protect her.
-- McCoy, "Shore Leave", stardate 3025.3



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Thu, Feb 11, 2010 at 05:51:38PM +0100, Bastian Blank wrote:
> On Thu, Feb 11, 2010 at 04:37:36PM +0100, Florian Lohoff wrote:
> > 11280 connect(3, {sa_family=AF_FILE, path=@"ISCSIADM_ABSTRACT_NAMESPACE"...}, 110) = 0
> > 11280 write(3, "1230q304377230q304377iqn.1997-01.o"..., 5244) = 5244
> > 11280 recv(3, 0xffc46760, 2464, MSG_WAITALL) = ? ERESTARTSYS (To be restarted)
>
> This only shows that iscsid does not respond to the requests of
> iscsiadm. However I consider it unlikely that such a bug should have
> survived for 14 kernel releases.
>
> Please show all the relevant configs, strace outputs of iscsiadm _and_
> iscsid and also network traces.

Something _is_ broken - I am very successful building up open-iscsi/iscsitarget
pairs on i386 - as soon as the initiator (open-iscsi) is on amd64 the login
hangs forever ... No matter whether the target is on the same machine
or on a different machine ...

What i did now:

bladesys3:~# tcpdump -i eth0 -s0 -w /tmp/login.pcap host t4.lab.rfc822.org and port 3260

and in parallel:

bladesys3:~# strace -t -f -o /tmp/scsid.strace.log /etc/init.d/open-iscsi start

Starting iSCSI initiator service: iscsid.
Setting up iSCSI targets:
iscsiadm: No records found!
.
Mounting network filesystems:.

And then:

iscsiadm -m discovery -t st -p 195.71.99.251
iscsiadm -m node

iscsiadm -m node --targetname "iqn.1997-01.org.rfc822.lab.t4:storage.t4.disk1" --portal "195.71.99.251:3260" --op=update --name node.session.auth.authmethod --value=CHAP
iscsiadm -m node --targetname "iqn.1997-01.org.rfc822.lab.t4:storage.t4.disk1" --portal "195.71.99.251:3260" --op=update --name node.session.auth.username --value=storage1
iscsiadm -m node --targetname "iqn.1997-01.org.rfc822.lab.t4:storage.t4.disk1" --portal "195.71.99.251:3260" --op=update --name node.session.auth.password --value=mi4Taibi

iscsiadm -m node --targetname "iqn.1997-01.org.rfc822.lab.t4:storage.t4.disk1" --portal "195.71.99.251:3260" --login

tcpdump:

http://silicon-verl.de/home/flo/tmp/iscsilogin.pcap
http://silicon-verl.de/home/flo/tmp/scsid.strace.log

The scsid strace shows repeated stuff like:

3444 20:14:08 connect(9, {sa_family=AF_INET, sin_port=htons(3260), sin_addr=inet_addr("195.71.99.251")}, 128) = -1 EINPROGRESS (Operation now in progress)

Although telnet (as the tcpdump) reports the connect is no problem:

bladesys3:/tmp# telnet t4.lab.rfc822.org 3260
Trying 195.71.99.251...
Connected to tiles-four.lab.rfc822.org.
Escape character is '^]'.
^]
telnet> close
Connection closed.

Still - the login hangs - dead ... I have never seen something like this
between i386 machines.

open-iscsi config is untouched.

What else?

Flo
--
Florian Lohoff f@zz.de
"Es ist ein grobes Missverständnis und eine Fehlwahrnehmung, dem Staat
im Internet Zensur- und Überwachungsabsichten zu unterstellen."
- - Bundesminister Dr. Wolfgang Schäuble -- 10. Juli in Berlin

On Thu, Feb 11, 2010 at 08:23:12PM +0100, Florian Lohoff wrote:
> Something _is_ broken - I am very successful building up open-iscsi/iscsitarget
> pairs on i386 - as soon as the initiator (open-iscsi) is on amd64 the login
> hangs forever ... No matter whether the target is on the same machine
> or on a different machine ...

Yes, it is. The iscsi_uevent structure defined in scsi/iscsi_if.h
suffers of the 64-bit-allignment-desease on i386.

Also please not that this interface is officialy _not_ exported.

Bastian

--
Captain's Log, star date 21:34.5...



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Mon, 2010-02-15 at 21:19 +0100, Florian Lohoff wrote:
> On Thu, Feb 11, 2010 at 09:13:21PM +0100, Bastian Blank wrote:
> > On Thu, Feb 11, 2010 at 08:23:12PM +0100, Florian Lohoff wrote:
> > > Something _is_ broken - I am very successful building up open-iscsi/iscsitarget
> > > pairs on i386 - as soon as the initiator (open-iscsi) is on amd64 the login
> > > hangs forever ... No matter whether the target is on the same machine
> > > or on a different machine ...
> >
> > Yes, it is. The iscsi_uevent structure defined in scsi/iscsi_if.h
> > suffers of the 64-bit-allignment-desease on i386.
> >
> > Also please not that this interface is officialy _not_ exported.
>
> So? What would be the correct state? Wontfix? Forwarded-UpStream?

If you want to get this fixed in the kernel then please report this
upstream at <https://bugzilla.kernel.org> or on an appropriate mailing
list. If it's accepted as a real bug and fixed upstream then we can
backport the fix.

Ben.

--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.

On Tue, Apr 06, 2010 at 04:21:46AM +0100, Ben Hutchings wrote:
> > > On Thu, Feb 11, 2010 at 08:23:12PM +0100, Florian Lohoff wrote:
> > > > Something _is_ broken - I am very successful building up open-iscsi/iscsitarget
> > > > pairs on i386 - as soon as the initiator (open-iscsi) is on amd64 the login
> > > > hangs forever ... No matter whether the target is on the same machine
> > > > or on a different machine ...
> > >
> > > Yes, it is. The iscsi_uevent structure defined in scsi/iscsi_if.h
> > > suffers of the 64-bit-allignment-desease on i386.
> > >
> > > Also please not that this interface is officialy _not_ exported.
> >
> > So? What would be the correct state? Wontfix? Forwarded-UpStream?
>
> If you want to get this fixed in the kernel then please report this
> upstream at <https://bugzilla.kernel.org> or on an appropriate mailing
> list. If it's accepted as a real bug and fixed upstream then we can
> backport the fix.

The bug has been confirmnd on the open-iscsi mailingliste and reported
to be on the low priority fixlist. So basically open-iscsi is broken in
Debian with a amd64 kernel and 32 bit userspace with no solution.

See attached mail.

Flo
--
Florian Lohoff f@zz.de
"Es ist ein grobes Missverständnis und eine Fehlwahrnehmung, dem Staat
im Internet Zensur- und Überwachungsabsichten zu unterstellen."
- - Bundesminister Dr. Wolfgang Schäuble -- 10. Juli in Berlin

On Wed, Apr 07, 2010 at 09:31:17PM +0200, Florian Lohoff wrote:
> On Tue, Apr 06, 2010 at 04:21:46AM +0100, Ben Hutchings wrote:
> > > > On Thu, Feb 11, 2010 at 08:23:12PM +0100, Florian Lohoff wrote:
> > > > > Something _is_ broken - I am very successful building up open-iscsi/iscsitarget
> > > > > pairs on i386 - as soon as the initiator (open-iscsi) is on amd64 the login
> > > > > hangs forever ... No matter whether the target is on the same machine
> > > > > or on a different machine ...
> > > >
> > > > Yes, it is. The iscsi_uevent structure defined in scsi/iscsi_if.h
> > > > suffers of the 64-bit-allignment-desease on i386.
> > > >
> > > > Also please not that this interface is officialy _not_ exported.
> > >
> > > So? What would be the correct state? Wontfix? Forwarded-UpStream?
> >
> > If you want to get this fixed in the kernel then please report this
> > upstream at <https://bugzilla.kernel.org> or on an appropriate mailing
> > list. If it's accepted as a real bug and fixed upstream then we can
> > backport the fix.
>
> The bug has been confirmnd on the open-iscsi mailingliste and reported
> to be on the low priority fixlist. So basically open-iscsi is broken in
> Debian with a amd64 kernel and 32 bit userspace with no solution.

Adding Debian open-iscsi maintainers to CC.

Since according to upstream this is unlikey to be fixed for the Squeeze
kernel, maybe you should at least document in the open-iscsi package?

Cheers,
Moritz



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100501204456.GA24611@galadriel.inutil.org">http://lists.debian.org/20100501204456.GA24611@galadriel.inutil.org

forwarded 502845 http://thread.gmane.org/gmane.linux.iscsi.open-iscsi/4896/focus=5070
retitle 502845 open-iscsi: login fails using 64-bit kernel with 32-bit userland
tags 502845 = upstream
quit

Ritesh Raj Sarraf wrote:
> On Monday 03 May 2010 12:56:52 Florian Lohoff wrote:

>> Are there ANY reports for successful login with amd64 kernel and
>> 32bit userspace? I have tried everything and i didnt get anything to
>> work.
>
> None that I am aware of. For most of my testings, the focus was only on a 64
> => 64 or a 32 => 32 config.
[...]
> I think README.Debian should be enough. The way open-iscsi currently is in
> Debian, a user will be required to go and have a read of the README.Debian
> doc.

Thanks, all. (I am guessing the current status is the same.) Marking
the bug with the result of the investigation so far as I understand
it, in the hope that it might help the next person with time to
investigate that runs into this to pick up where previous work left
off.



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110727024849.GA16623@elie">http://lists.debian.org/20110727024849.GA16623@elie