All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boaz Harrosh <bharrosh@panasas.com>
To: James Bottomley <James.Bottomley@SteelEye.com>,
	FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: jens.axboe@oracle.com, linux-scsi@vger.kernel.org,
	bhalevy@panasas.com, hch@infradead.org,
	akpm@linux-foundation.org, michaelc@cs.wisc.edu
Subject: Re: [PATCH v2] add bidi support for block pc requests
Date: Thu, 17 May 2007 17:00:21 +0300	[thread overview]
Message-ID: <464C5FF5.6000705@panasas.com> (raw)
In-Reply-To: <1179408422.3785.5.camel@mulgrave.il.steeleye.com>

James Bottomley wrote:
> On Thu, 2007-05-17 at 11:49 +0300, Boaz Harrosh wrote:
>> These are regular fs (ext3) requests during bootup. The machine will not
>> boot. (Usually from the read ahead code)
>> Don't believe me look at the second patch Over Tomo's cleanup.
>> If I define SCSI_MAX_SG_SEGMENTS to 127 it will crash even when I
>> did in code:
>> 	blk_queue_max_phys_segments(q, SCSI_MAX_SG_SEGMENTS);
>> I suppose someone is looking at a different definition. Or there is
>> another call I need to do for this to work.
> 
> It would really help us if you showed the actual code for what you did
> and where ... if this is wrong, we have bigger problems that quibbling
> about bidirectional slab sizes.  The correct way to adjust this limit
> artificially to 127 is:
> 
> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index 1f5a07b..4a27841 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -1576,7 +1576,7 @@ struct request_queue *__scsi_alloc_queue(struct Scsi_Host *shost,
>  		return NULL;
>  
>  	blk_queue_max_hw_segments(q, shost->sg_tablesize);
> -	blk_queue_max_phys_segments(q, SCSI_MAX_PHYS_SEGMENTS);
> +	blk_queue_max_phys_segments(q, 127);
>  	blk_queue_max_sectors(q, shost->max_sectors);
>  	blk_queue_bounce_limit(q, scsi_calculate_bounce_limit(shost));
>  	blk_queue_segment_boundary(q, shost->dma_boundary);
> 
> (It doesn't alter the allocation pools or anything else, just limits the
> max phys segments of the queue).  The way to check that this limit is
> being honoured is:
> 
> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index 1f5a07b..ae42e4d 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -1000,6 +1000,7 @@ static int scsi_init_io(struct scsi_cmnd *cmd)
>  	 * kmapping pages)
>  	 */
>  	cmd->use_sg = req->nr_phys_segments;
> +	WARN_ON(req->nr_phys_segments > 127);
>  
>  	/*
>  	 * If sg table allocation fails, requeue request later.
> 
> James
> 
> 
Yes Tomo found it at ata_scsi_slave_config(). Attached below the way I
fixed it. Now it works with 127.

(By the way Tomo, a printk like you did in scsi_init_io and
scsi_free_sgtable, 2 for every IO, or even 1 for every IO, will make
a SCSI booting PC like mine almost un-usable. Think of printk going
to log-file doing a printk...)

diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
index dd81fa7..de8c796 100644
--- a/drivers/ata/libata-scsi.c
+++ b/drivers/ata/libata-scsi.c
@@ -800,7 +800,9 @@ int ata_scsi_slave_config(struct scsi_device *sdev)

 	ata_scsi_sdev_config(sdev);

-	blk_queue_max_phys_segments(sdev->request_queue, LIBATA_MAX_PRD);
+	if ( sdev->request_queue->max_phys_segments > LIBATA_MAX_PRD )
+		blk_queue_max_phys_segments(sdev->request_queue,
+		                                       LIBATA_MAX_PRD);

 	sdev->manage_start_stop = 1;



  reply	other threads:[~2007-05-17 14:02 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-08  2:25 [PATCH v2] add bidi support for block pc requests FUJITA Tomonori
2007-05-08 18:53 ` Boaz Harrosh
2007-05-08 20:01   ` James Bottomley
2007-05-09  7:46     ` Boaz Harrosh
2007-05-09 10:52       ` FUJITA Tomonori
2007-05-09 13:58         ` Boaz Harrosh
2007-05-09 14:54           ` FUJITA Tomonori
2007-05-09 14:55           ` James Bottomley
2007-05-09 16:54             ` Boaz Harrosh
2007-05-10  6:53               ` FUJITA Tomonori
2007-05-10  7:45                 ` FUJITA Tomonori
2007-05-10 12:37                   ` Boaz Harrosh
2007-05-10 13:01                     ` FUJITA Tomonori
2007-05-10 15:10                     ` Douglas Gilbert
2007-05-10 15:48                       ` Boaz Harrosh
2007-05-11 16:26                       ` James Bottomley
2007-05-16 17:29       ` Boaz Harrosh
2007-05-16 17:53         ` Jens Axboe
2007-05-16 18:06           ` James Bottomley
2007-05-16 18:13             ` Jens Axboe
2007-05-17  8:46               ` Boaz Harrosh
2007-05-17  2:57           ` FUJITA Tomonori
2007-05-17  5:48             ` Jens Axboe
2007-05-17  5:59               ` FUJITA Tomonori
2007-05-17  8:49                 ` Boaz Harrosh
2007-05-17 11:12                   ` FUJITA Tomonori
2007-05-17 17:37                     ` Benny Halevy
2007-05-24 16:37                     ` Boaz Harrosh
2007-05-24 16:46                       ` Boaz Harrosh
2007-05-24 16:47                       ` FUJITA Tomonori
2007-05-24 16:59                         ` Boaz Harrosh
2007-05-17 11:29                   ` FUJITA Tomonori
2007-05-17 13:27                   ` James Bottomley
2007-05-17 14:00                     ` Boaz Harrosh [this message]
2007-05-17 14:11                       ` FUJITA Tomonori
2007-05-17 15:49                         ` Boaz Harrosh
2007-06-01 20:21                           ` Jeff Garzik
2007-06-03  7:45                             ` Boaz Harrosh
2007-06-03 13:17                               ` James Bottomley
2007-07-07 15:27                                 ` Jeff Garzik
2007-07-07 15:42                                   ` James Bottomley
2007-07-07 16:59                                     ` Jeff Garzik
2007-05-09 10:49     ` FUJITA Tomonori

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=464C5FF5.6000705@panasas.com \
    --to=bharrosh@panasas.com \
    --cc=James.Bottomley@SteelEye.com \
    --cc=akpm@linux-foundation.org \
    --cc=bhalevy@panasas.com \
    --cc=fujita.tomonori@lab.ntt.co.jp \
    --cc=hch@infradead.org \
    --cc=jens.axboe@oracle.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=michaelc@cs.wisc.edu \
    /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.