[Iscsitarget-devel] Software issues/bugs with iscsitarget

[Darko]

Hello,

I was testing iscsitarget software with vmware ESXi 4.1 and I believe I
have discovered an error in the kernel module. Please note that my current
configuration is in a test mode and I wanted to explore the software and
its behavior when I ran into a problem.
After setting IOMode=ro as one one of the LUN parameters, the ESX was able
to find the iscsi target and as it attepted to write on it and create a
file system, the liunux server that was running the iscsitarget software
displayed serveral lines of error messages on the console. The errors were
kernel generated and I have included dmesg from the system which displays
the errors on the very bottom of the file. I have also attached the kernel
configuration as well as the ietd.conf file. I understand that ro option
does not allow the iscsi initiator to write in that particular lun, but
using this option caused the system to become unstable. Once the errors
got generated, trying to shut off the ietd and unload the module from the
kernel was unsuccessfull. Running the script /etc/rc.d/iscsi-target stop
just hung and was not able to unload the module. The only cure was to
reboot the system. I hope this information helps you to find the bug might
be.
If there is any additional information that you may require, feel free to
contact me.

Thanks,

--
Darko Kraus
Enterprise Network Administrator
Tel: +1-586-739-1624

[Scott Kaelin]

Are you using the latest SVN copy of IET? Can you provide more info on the box IET was running on?

--
Scott Kaelin
0x5F3B167B

[Arne Redlich]

2011/4/20 Darko <da...@hytron.net>:

Darko,

Thanks for reporting this. I was able to reproduce it with a linux
initiator and sg_dd and will look into it.

Thanks,
Arne

------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
Iscsitarget-devel mailing list
Iscsitar...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel

[Arne Redlich]

Darko,

Can you verify that the below patch (also attached for your convenience)
fixes the issue for you?

Thanks,
Arne

diff --git a/kernel/iscsi.c b/kernel/iscsi.c
index 05197f2..4e4679f 100644
--- a/kernel/iscsi.c
+++ b/kernel/iscsi.c
@@ -1008,16 +1008,16 @@ static void scsi_cmnd_start(struct iscsi_conn *conn, struct iscsi_cmnd *req)
loff_t offset;
u32 length;

- req->r2t_length = be32_to_cpu(req_hdr->data_length) - req->pdu.datasize;
- req->is_unsolicited_data = !(req_hdr->flags & ISCSI_CMD_FINAL);
- req->target_task_tag = get_next_ttt(conn->session);
-
if (LUReadonly(req->lun)) {
create_sense_rsp(req, DATA_PROTECT, 0x27, 0x0);
cmnd_skip_data(req);
break;
}

+ req->r2t_length = be32_to_cpu(req_hdr->data_length) - req->pdu.datasize;
+ req->is_unsolicited_data = !(req_hdr->flags & ISCSI_CMD_FINAL);
+ req->target_task_tag = get_next_ttt(conn->session);
+
if (!param->immediate_data && req->pdu.datasize)
eprintk("%x %x\n", cmnd_itt(req), req_hdr->scb[0]);

[Brian Cockrell]

Is there a patch available to compile release 1.4.20.2 against kernels 2.6.37 or 2.6.38?  Or is there an unpublished release / version that I could use?

Thanks,
Brian

[Darko]

Hello Arne,

Thank You for your quick response. I did apply the patch and the kernel no
longer displays that "panic" message, however the following was logged:

iscsi_trgt: cmnd_skip_pdu(459) 90e0000 1c 2a 0
iscsi_trgt: cmnd_skip_pdu(459) fc0e0000 1c 2a 0

I am not sure if this a normal behavior of the module. Other than the
message, it appears to be working ok!

Thanks,

Darko Kraus

On Thu, 21 Apr 2011, Arne Redlich wrote:

> Date: Thu, 21 Apr 2011 21:43:23 +0200
> From: Arne Redlich <arne.r...@googlemail.com>
> To: Darko <da...@hytron.net>
> Cc: iscsitar...@lists.sourceforge.net,
> Ross Walker <rsww...@gmail.com>
> Subject: Re: [Iscsitarget-devel] Software issues/bugs with iscsitarget

------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails

[Ross S. W. Walker]

On Apr 21, 2011, at 4:25 PM, "Brian Cockrell" <bjcoc...@hotmail.com> wrote:

> Is there a patch available to compile release 1.4.20.2 against kernels 2.6.37 or 2.6.38? Or is there an unpublished release / version that I could use?

Yes, the fix is the svn.

Grab the HEAD of the 1.4.20 branch.

-Ross

______________________________________________________________________
This e-mail, and any attachments thereto, is intended only for use by
the addressee(s) named herein and may contain legally privileged
and/or confidential information. If you are not the intended recipient
of this e-mail, you are hereby notified that any dissemination,
distribution or copying of this e-mail, and any attachments thereto,
is strictly prohibited. If you have received this e-mail in error,
please immediately notify the sender and permanently delete the
original and any copy or printout thereof.

------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails

[Arne Redlich]

2011/4/22 Darko <da...@hytron.net>:

> Hello Arne,
>
> Thank You for your quick response. I did apply the patch and the kernel no
> longer displays that "panic" message, however the following was logged:
>
> iscsi_trgt: cmnd_skip_pdu(459) 90e0000 1c 2a 0
> iscsi_trgt: cmnd_skip_pdu(459) fc0e0000 1c 2a 0
>
> I am not sure if this a normal behavior of the module. Other than the
> message, it appears to be working ok!
>
> Thanks,
>
> Darko Kraus

Hi Darko,

Thanks for the feedback. The "cmnd_skip_pdu" message is expected and
harmless, as now (instead of crashing) an error is returned to the
initiator and any write data is discarded (which leads to the
cmnd_skip_pdu message).

Greetings,
Arne