[8540] in linux-scsi channel archive
Re: Bad segment list supplied to aha1542.c
daemon@ATHENA.MIT.EDU (Eric Youngdale)
Tue Apr 4 13:35:23 2000
Message-ID: <002d01bf9e5a$ac64b6b0$4d0310ac@fairfax.datafocus.com>
From: "Eric Youngdale" <eric@andante.org>
To: "Jens Axboe" <axboe@suse.de>
Cc: "Nigel Chan" <nigel.chan@alcatel.com.au>,
<linux-scsi@vger.rutgers.edu>
Date: Tue, 4 Apr 2000 13:24:46 -0400
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
----- Original Message -----
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>
Sent: Tuesday, April 04, 2000 1:01 PM
Subject: Re: Bad segment list supplied to aha1542.c
> On Tue, Apr 04 2000, Eric Youngdale wrote:
> > Yes, this isn't good at all. We will need to look and see how that
17th
> > segment got into the list.
>
> 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.
-Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.rutgers.edu
