Re: Kernel OOPS on 2.2.10 SCSI related

Douglas Gilbert (dgilbert@interlog.com)
Sat, 03 Jul 1999 09:06:50 -0400

Gerard Roudier wrote:
>
> On Fri, 2 Jul 1999, Douglas Gilbert wrote:
>
> > > Hi All
> > >
> > > Im running a Quad Xeon with 1Gig of ram with Kernel 2.2.10 since 2 weeks with no
> > > Problem
> > > but yesterday i got the following oops:
> > >
> > > It happens when my backup starts and the module for the symbios scsi-controler
> > > det loaded.
> >
> > That hole is plugged in 2.2.10-ac1+ and hopefully will
> > get into 2.2.11 . The solution isn't great:
> > fail the 'insmod sym53c6xx' but it is better that
> > an oops.
> >
> > You will be pleased to hear that your system ran out
> > of memory under the 16MB level even though your
> > sym53c8xx could have used any available RAM for
> > DMA purposes.
>
> Hmmm... If you are severe each time you discover that something that
> worked fine years ago does not work at the moment, you may end-up thinking
> that all ancient programs had been write by stupid guys and obviously this
> is absolutely _untrue_. The problem of the current SCSI code is that it
> hasn't been maintained as it should have been, and it is a good thing that
> people like you decided to maintain this code.

I am one of those ancient programmers :-) who
still hasn't heard a good excuse for not checking
malloc() returns (kmalloc in this case) for NULL.
The difference in 2.2 seems to be an increased
probability of kmalloc(..., GFP_DMA) returning
NULL.

As for the design of the SCSI sub-system, I quite
like it and give credit to Drew and Eric for that.
Given the relatively short time scales they are
talking about for the 2.3 series of kernels it seems
as though we will be living with this design into
2.4 . Doug Ledford seemed to suggested that the whole
sub-system was going to be re-designed in 2.3 but
my guess is that it is already too late for that.
The CAM design from a Linux point of view looks
like "throw the whole thing out and start again".
This seems to be what they did in FreeBSD.

So how about a spot of strengthening of the design
we have in Linux? I have 2 suggestions:
- increase the sense buffer from 16 to 32 bytes
(that way we at least comply with SCSI 2)
- add an "actual bytes tranfered" count into
the same structure

[snip]

Doug Gilbert

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/