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 <[EMAIL PROTECTED]>
To: Eric Youngdale <[EMAIL PROTECTED]>
Cc: Nigel Chan <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]>
> * 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 [EMAIL PROTECTED]
>
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
