All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Hounschell <dmarkh@cfl.rr.com>
To: Mike Christie <michaelc@cs.wisc.edu>
Cc: markh@compro.net, linux-scsi@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Tony Battersby <tonyb@cybernetics.com>
Subject: Re: New 2.6.24.2 SG_IO SCSI problems
Date: Wed, 05 Mar 2008 06:58:34 -0500	[thread overview]
Message-ID: <47CE8AEA.1060209@cfl.rr.com> (raw)
In-Reply-To: <47BF4BD0.7080008@cs.wisc.edu>

Mike Christie wrote:
> Mark Hounschell wrote:
>> Mark Hounschell wrote:
>>> Mike Christie wrote:
>>>> Mike Christie wrote:
>>>>> Mark Hounschell wrote:
>>>>>> I seem to have run into some sort of regression in the SG_IO
>>>>>> interface of 2.6.24.2. I have an application that up until 2.6.24
>>>>>> worked fine. The 2.6.23.16 kernel works fine.
>>>>>>
>>>>>> During reads I get these kernel messages. Writes and other functions
>>>>>> _seem_ OK. Actually basic
>>>>>> reads  are working. Its with large BC reads using an io_vec list that
>>>>>> the problem shows up.
>>>>>>
>>>>> Are you doing SG_IO to the sg device (/dev/sg*) or to the block device
>>>>> (/dev/sdX)?
>>>> If you are doing SG_IO to the sg device, then I know of one regression
>>>> (well not regression exactly, but I fixed a bug but the patch got
>>>> partially overwritten by another patch and that caused a new bug). Both
>>>> bugs are fixed in 2.6.25-rc2. Could you try that out if you are doing
>>>> SG_IO to the sg device.
>>>>
>>> Yes, I'm using /dev/sg*. And yes again I'll checkout 2.6.25-rc2 ASIC.
>>>
>>> Thanks
>>> Mark
>>> -
>>  
>> 2.6.25-rc2 does fix the problem I'm having. I don't suppose there is a
>> patch
>> lying around for 2.6.24.2??
>>
> 
> I attached a backport of the patch from Tony (added as cc) that is in
> 2.6.25-rc2. Could you try it out against 2.6.24.2 just to make sure it
> was this patch, then we can send it to stable.
> 

>Mark Hounschell wrote:
>
>Sorry it took so long. This does fix my problem. I hope it's not to
>late for 2.6.24.3
>

Backport
76d78300a6eb8b7f08e47703b7e68a659ffc2053
to 2.6.24

>From Tony Battersby:

When sending a SCSI command to a tape drive via the SCSI Generic (sg)
driver, if the command has a data transfer length more than
scatter_elem_sz (32 KB default) and not a multiple of 512, then I either
hit BUG_ON(!valid_dma_direction(direction)) in dma_unmap_sg() or else
the command never completes (depending on the LLDD).

When constructing scatterlists, the sg driver rounds up the scatterlist
element sizes to be a multiple of 512.  This can result in
sum(scatterlist lengths) > bufflen.  In this case, scsi_req_map_sg()
incorrectly sets bio->bi_size to sum(scatterlist lengths) rather than to
bufflen.  When the command completes, req_bio_endio() detects that
bio->bi_size != 0, and so it doesn't call bio_endio().  This causes the
command to be resubmitted, resulting in BUG_ON or the command never
completing.

This patch makes scsi_req_map_sg() set bio->bi_size to bufflen rather
than to sum(scatterlist lengths), which fixes the problem.

Signed-off-by: Mike Christie <michaelc@cs.wisc.edu>

--- linux-2.6.24.2/drivers/scsi/scsi_lib.c	2008-02-10 23:51:11.000000000
-0600
+++ linux-2.6.24.2.work/drivers/scsi/scsi_lib.c	2008-02-22
16:20:09.000000000 -0600
@@ -298,7 +298,6 @@ static int scsi_req_map_sg(struct reques
 		page = sg_page(sg);
 		off = sg->offset;
 		len = sg->length;
- 		data_len += len;

 		while (len > 0 && data_len > 0) {
 			/*


Did this ever get sent to the stable team?

Regards
Mark

  parent reply	other threads:[~2008-03-05 12:03 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-21 15:15 New 2.6.24.2 SG_IO SCSI problems Mark Hounschell
2008-02-21 15:41 ` James Bottomley
2008-02-21 16:21   ` Mark Hounschell
2008-02-22 10:03     ` Mark Hounschell
2008-02-22 16:50 ` Mike Christie
2008-02-22 16:59   ` Mike Christie
2008-02-22 17:56     ` Mark Hounschell
2008-02-22 21:38       ` Mark Hounschell
2008-02-22 22:25         ` Mike Christie
2008-02-22 22:48           ` Tony Battersby
2008-02-23 11:16           ` Mark Hounschell
2008-03-05 11:58           ` Mark Hounschell [this message]
2008-03-05 15:44             ` James Bottomley
2008-03-05 16:28               ` Mark Hounschell
2008-03-05 17:13               ` Mike Christie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=47CE8AEA.1060209@cfl.rr.com \
    --to=dmarkh@cfl.rr.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=markh@compro.net \
    --cc=michaelc@cs.wisc.edu \
    --cc=tonyb@cybernetics.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.