On Sat, 2011-08-13 at 21:25 +0100, Chris Boot wrote:
> On 13/08/2011 14:08, Nicholas A. Bellinger wrote:
> > On Fri, 2011-08-12 at 15:40 -0700, Kiran Patil wrote:
> >> Hi Chris, Nick,
> >>
> >> Please see my suggested solution and I also have patch (I can send
> >> that patch later) for that Bogus SGL issue.
> >>
> >> But after fixing that issue, ran into another issue (not NULL pointer
> >> deference). Please read my response.
> >>
> > Hi Kiran& Co,
> >
> >> On 8/12/2011 2:11 PM, Chris Boot wrote:
> >>> On 09/08/2011 09:15, Chris Boot wrote:
> > <SNIP>
> >
> >>> Well, I tried applying the patchset nab posted to the list yesterday
> >>> ([PATCH 0/3] target: various CDB processing fixes for -rc2) to my
> >>> kernel and giving it another whirl. The bug I had is still there,
> >>> but doesn't make the target hang - and I see some new messages too.
> >>> The logging is _extremely_ verbose so sifting through the log has
> >>> been fun... I should add that I did this last test on Windows
> >>> instead of Linux (sorry for all the swapping around).
> >>>
<SNIP>
> >>
> >> Solution to this problem is,
> >>
> >> In function transport_allocate_data_tasks:
> >>
> >> Changed following line from:
> >>
> >> if(cmd->se_tfo->task_sg_chaining) {
> >>
> >> to:
> >>
> >> if(cmd->se_tfo->task_sg_chaining&& (i< (task_count -1))) {
> >>
> >>
> >> After this fix, I haven;t seen any more Bogus SGL or NULL pointer
> >> deference but then unable to discover the LUN properly.
> >>
> >> Please let me know if you want to see log and wireshark trace.
> >>
> > Ok, so this turned out to be two seperate issues wrt to the new code in
> > transport_allocate_data_tasks(). The first patch should address the
> > problems that Chris ran into recently with iscsi-target that are related
> > to multi-task handling being broken in transport_allocate_data_tasks()
> > for -rc1:
> >
> > target: Fix task count> 1 handling breakage and use max_sector page alignment
> >
> > The second patch should address the seperate breakage you have been
> > hitting with tcm_fc wrt to task SGL chaining logic that managed to get
> > broken in target core for -rc1 as well.. (Andy and Christoph, please
> > have a look)
> >
> > target: Fix task SGL chaining breakage with transport_allocate_data_tasks
> >
> > I've done some light testing this morning with tcm_qla2xxx using
> > transport_do_task_sg_chain(), and things appear to be functioning as
> > expected again with the two changes. Please verify with tcm_fc and let
> > me know if anything else needs attention.
> Nick,
>
> After much testing this afternoon and evening I can definitely confirm
> the first patch fixes my issue. My iSCSI target has been running very
> well indeed with 3.1-rc1 and that patch applied on top.
>
> Thanks again Nick.
Thank you for verifying this bugfix with iscsi-target, and for all your
efforts the past week to help get this one issue identified and
resolved. :)
So following the max_sectors=256 attribute from the backend in question,
your setup is currently generating (task_count > 1) within
transport_allocate_data_tasks() for each iSCSI CDB where the expected
transfer length exceeds 128K using the default 512 byte sector size.
Note that a modern open-iscsi client is using in the neighorhood of
max_sectors_kb=512, so target core is currently expected to handle this
SCSI payload offset into backend storage subsystem dependent code. Btw,
you can also check the individual struct scsi_device iSCSI LUN on the
open-iscsi client via /sys/block/$SDX/queue/[max_sectors_kb,
max_hw_sectors_kb], which can be changed explictly to reduce the max
SCSI payload size generated by the block layer.
--nab
--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
