Bug 172487 - Difficulty with some iSCSI targets in iscsi_sfnet
Summary: Difficulty with some iSCSI targets in iscsi_sfnet
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel
Version: 4.0
Hardware: All
OS: Linux
Target Milestone: ---
: ---
Assignee: Mike Christie
QA Contact: Brian Brock
Depends On:
Blocks: 168429
TreeView+ depends on / blocked
Reported: 2005-11-05 05:29 UTC by Andrew J Forgue
Modified: 2007-11-30 22:07 UTC (History)
1 user (show)

Clone Of:
Last Closed: 2006-03-07 20:38:00 UTC

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2005:808 normal SHIPPED_LIVE Important: kernel security update 2005-10-27 04:00:00 UTC
Red Hat Product Errata RHSA-2006:0132 qe-ready SHIPPED_LIVE Moderate: Updated kernel packages available for Red Hat Enterprise Linux 4 Update 3 2006-03-09 16:31:00 UTC

Description Andrew J Forgue 2005-11-05 05:29:32 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7

Description of problem:
When using the iSCSI initiator and associated driver for the above kernel, I receive many of the following syslog messages:

iscsi-sfnet:host1: Dropping session after receiving unexpected opcode 0xe0
iscsi-sfnet:host1: Session dropped
iscsi-sfnet:host1: Waiting 2 seconds before next login attempt
iscsi-sfnet:host1: Session established

This happens a lot and just demolishes performance and occasionally makes the driver not connect to the target until the next reboot.  Previous versions of sfnet's iscsi had this line (marked with +) in iscsi-recv-pdu.c:

       switch (hdr->opcode) {
+      case ISCSI_OP_NOOP_IN | 0xc0: /* work-around a bug in the Intel Nov05 target */
       case ISCSI_OP_NOOP_IN:
               handle_nop_in(session, hdr);

That line seems to be gone in the RHEL4U2 version of the file.  I did all kinds of google searching for what 'Nov05' is, but can't find anything.  My iSCSI applicance is at the latest firmware revision from the vendor.  I installed the latest SRPM for the kernel and rebuilt it with that line and now iSCSI works like it should.  

This extra case statement was in iscsi.c and then iscsi.c disappeared[1] and then the case statement re-appeared in iscs-recv-pdu.c[2].  I have no idea why this line of code was removed, I can't find anything in the changelogs or CVS commit logs.

Anyways,  I would very much prefer not recompiling my kernel every time RHEL releases a new update.

[1]: http://cvs.sourceforge.net/viewcvs.py/linux-iscsi/linux-iscsi/driver/Attic/iscsi.c?rev=

[2]: http://cvs.sourceforge.net/viewcvs.py/linux-iscsi/linux-iscsi/driver/iscsi-recv-pdu.c?rev=1.33&view=markup

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
Get an iSCSI target that sends you 0xe0 codes for some reason.  The Intransa IP5000 works well.

Additional info:

Comment 1 Mike Christie 2005-11-10 22:39:24 UTC
That code was removed becuase it was for a unsupported buggy target. However,
our opcode code has a bug that triggers when targets send us bad commands. Could
you try this sourceforge release and tell me if this fixes it for you


If it does I will try to get the fix into the next RHEL update.

Comment 2 Mike Christie 2005-11-10 22:50:55 UTC
Until we get this fixed you can also just set


so the initiator will not send pings.

Comment 3 Andrew J Forgue 2005-11-10 22:57:28 UTC
Thanks for taking the time to fix this up for me.... Here's the output of the build:

[forgue@mccoy linux-iscsi-rhel4]$ make

Note: using kernel source from /lib/modules/2.6.9-22.0.1.EL.rootsmp/build
containing kernel version 2.6.9-22.0.1.EL.rootsmp

Note: using kernel config from

make[1]: Entering directory `/usr/src/kernels/2.6.9-22.0.1.EL.root-smp-i686'
  CC [M]  /home/f/forgue/linux-iscsi-rhel4/driver/iscsi-initiator.o
  CC [M]  /home/f/forgue/linux-iscsi-rhel4/driver/iscsi-attr.o
  CC [M]  /home/f/forgue/linux-iscsi-rhel4/driver/iscsi-session.o
  CC [M]  /home/f/forgue/linux-iscsi-rhel4/driver/iscsi-task.o
  CC [M]  /home/f/forgue/linux-iscsi-rhel4/driver/iscsi-portal.o
  CC [M]  /home/f/forgue/linux-iscsi-rhel4/driver/iscsi-ioctl.o
  CC [M]  /home/f/forgue/linux-iscsi-rhel4/driver/iscsi-network.o
  CC [M]  /home/f/forgue/linux-iscsi-rhel4/driver/iscsi-recv-pdu.o
/home/f/forgue/linux-iscsi-rhel4/driver/iscsi-recv-pdu.c: In function
/home/f/forgue/linux-iscsi-rhel4/driver/iscsi-recv-pdu.c:918: error: syntax
error before '=' token
/home/f/forgue/linux-iscsi-rhel4/driver/iscsi-recv-pdu.c:924: error: `op'
undeclared (first use in this function)
/home/f/forgue/linux-iscsi-rhel4/driver/iscsi-recv-pdu.c:924: error: (Each
undeclared identifier is reported only once
/home/f/forgue/linux-iscsi-rhel4/driver/iscsi-recv-pdu.c:924: error: for each
function it appears in.)
/home/f/forgue/linux-iscsi-rhel4/driver/iscsi-recv-pdu.c:929: error: `opcode'
undeclared (first use in this function)
make[2]: *** [/home/f/forgue/linux-iscsi-rhel4/driver/iscsi-recv-pdu.o] Error 1
make[1]: *** [_module_/home/f/forgue/linux-iscsi-rhel4/driver] Error 2
make[1]: Leaving directory `/usr/src/kernels/2.6.9-22.0.1.EL.root-smp-i686'
make: *** [module] Error 2

Comment 4 Mike Christie 2005-11-10 23:23:55 UTC
Try this:


Note that you need the sysfsutils-devel rpm installed. There are also some
incompatibily tools so just do this:

- tar -zxvf inux-iscsi-test2.tar.gz
- cd linux-iscsi.work
- make
- if you have iscsi_sfnet and scsi_transport_iscsi loaded, rmmod them
- While in the linux-iscsi.work dir do a
insmod driver/scsi_transport_iscsi.ko
insmod driver/iscsi_sfnet.ko
- Then from linux-iscsi.work run

Linux-i686 is the dir for my single proc Intel box, but you may have PPC or smp
or some other arch.

And tell me if this works for you.

Comment 5 Andrew J Forgue 2005-11-10 23:37:52 UTC
Yes, thank you.

That seems to work, no more messages on the console about dropping sessions.  I
formatted and mounted a 150gb volume on the iSCSI target and did not have any
errors in dmesg about dropping connections.  I think this fixed it.

Comment 6 Mike Christie 2005-11-11 03:20:40 UTC
ok, I think we may have missed the window for U3, but I will try since this is
minor patch. If not U3 it will be in U4. Until then you can use disable the ping
timeout like in comment 2. Thankd for testing.

Comment 8 Linda Wang 2005-11-21 22:59:42 UTC
commited in -22.23

Comment 12 Red Hat Bugzilla 2006-03-07 20:38:00 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


Note You need to log in before you can comment on or make changes to this bug.