[8542] in linux-scsi channel archive
Re: Bad segment list supplied to aha1542.c
daemon@ATHENA.MIT.EDU (Jens Axboe)
Tue Apr 4 14:08:05 2000
Date: Tue, 4 Apr 2000 20:06:28 +0200
From: Jens Axboe <axboe@suse.de>
To: Eric Youngdale <eric@andante.org>
Cc: Nigel Chan <nigel.chan@alcatel.com.au>,
linux-scsi@vger.rutgers.edu
Message-ID: <20000404200628.U5338@suse.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <002d01bf9e5a$ac64b6b0$4d0310ac@fairfax.datafocus.com>; from eric@andante.org on Tue, Apr 04, 2000 at 01:24:46PM -0400
On Tue, Apr 04 2000, Eric Youngdale wrote:
> > It could get in there if the write / read is big enough, nothing is
> > limiting the number of request segments for such hardware right now
> > (aside from the ll_rw_blk default MAX_SEGMENTS).
>
> No, the code in scsi_merge.c should be checking the limit. In
> aha1542.h, the symbol is AHA1542_SCATTER, and this is stored in the host
> template in the field sg_tablesize. In scsi_merge.c there are places all
> over where we check against this limit before we allow another segment to be
> added, and someplace this isn't working correctly.
Of course you are right, I hadn't looked closely enough at the merging
in scsi_merge.c. Initially I can't see why an extra segment could
get added.
--
* Jens Axboe <axboe@suse.de>
* Linux CD/DVD-ROM, SuSE Labs
* http://kernel.dk
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.rutgers.edu
