[8565] in linux-scsi channel archive
Re: Bad segment list supplied to aha1542.c
daemon@ATHENA.MIT.EDU (Eric Youngdale)
Fri Apr 7 12:10:57 2000
Message-ID: <003001bfa0aa$50e606c0$4d0310ac@fairfax.datafocus.com>
From: "Eric Youngdale" <eric@andante.org>
To: "Nigel Chan" <nigel.chan@alcatel.com.au>
Cc: <linux-scsi@vger.rutgers.edu>
Date: Fri, 7 Apr 2000 11:59:55 -0400
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Sigh. It sounds like some of the queueing code doesn't have sanity
checking. I guess I will have to dust off the 1542 in my test machine and
see if I can reproduce it. I am hoping that this won't be *too* hard to
reproduce and find.
-Eric
----- Original Message -----
From: Nigel Chan <nigel.chan@alcatel.com.au>
To: Eric Youngdale <eric@andante.org>
Cc: <linux-scsi@vger.rutgers.edu>
Sent: Friday, April 07, 2000 9:23 AM
Subject: Re: Bad segment list supplied to aha1542.c
> Hi Eric,
>
> I did have the SCSI Queue Debugging option turned ON in the kernel and the
> error message I sent in my original posting was all that appeared.
>
> Cheers,
> Nigel
>
> Eric Youngdale wrote:
> >
> > And I just remembered a good way to track this down. Turn on the
> > kernel
> > option for debugging the new queueing code. After each merge, it should
> > verify that the number of segments isn't too large, and it will panic
when
> > this happens. You should get a line number and source file - this will
> > tell
> > us which function is screwing up. If that isn't enough, we can fix it
to
> > display more debugging information until we know exactly what is wrong
with
> > the merging.
> >
> > -Eric
> >
> > ----- 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 2:06 PM
> > Subject: Re: Bad segment list supplied to aha1542.c
> >
> > > 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
> > >
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.rutgers.edu
>
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.rutgers.edu
