lkml.org 
[lkml]   [1999]   [Jul]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [BUGREPORT] 2.2.10-ac10: oops+panic when interrupting cdrecord session


On Fri, 16 Jul 1999, Marc Mutz wrote:

> Bert Lindner wrote:
> >
> <snip>
> > > And that would seem to be in the sym53c8xx driver when unloaded. Gerard?
> > > I think that you will not have any trouble if you compile the driver
> > > into your kernel instead of as a module.
> >
> > I just tried that, and the problem remained. Putting the sym53c8xx driver
> <snip>
>
> Bert,
> Maybe you should interchange the sym53c8xx with the older/more general
> ncr53c8xx driver. If the problem remains, then one can rule out that
> particular driver (except when both share a fair amount of code).

Indeed. But not the way they deal with memory allocations. The sym53c8xx
driver incorporates its own memory allocator since I wanted naturally
aligned blocks in order to make efficient address calculations using the 8
bit ALUs of the SCRIPTS processor. Linux didn't offered that unlike most
other O/Ses.

There is something that amazed me since years in Linux. If we take into
account all the hardware, firmare, software, bloatware, userware, overware
wrongware and chineseware out of what a modern computer is made, the SCSI
driver is probably less than 0,00..1 % of the total amount of that
whateverware. But SCSI drivers are focused 99,99..9 % of the time when a
machine using SCSI is experiencing problems.

I donnot mean that the driver is not candidate in the problem trigerring
or that it cannot be the culprit. But, in my experience, people are often
surprised of the real cause of a failure, especially those that
arbitrarily designate a single component as the only possible candidate.

For the problem that have been reported, I didn't see any obvious
correlation with some driver fault. In the initial post, it appeared
that the kernel stack contains some frames that indicated that the
driver had serviced an interrupt, but the last visible trace was
scsi_old_done() that may indicate the driver was probably done with
its interrupt handling and that the problem occurred later.

Gérard.


-
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/

\
 
 \ /
  Last update: 2005-03-22 13:53    [W:0.843 / U:0.448 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site