lkml.org 
[lkml]   [1997]   [Feb]   [16]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateSun, 16 Feb 1997 06:04:38 +0100 (MET)
From"Michael L. Galbraith" <>
SubjectRe: kernel stack overflow profiler.. two very long oopses
On Sat, 15 Feb 1997, Ingo Molnar wrote:

> > kernel stack overflow. Forcing Oops.> > i'm not an SCSI expert, but i've snipped out some imho interesting
> functions:> > > Trace: c02192b1 <do_sd_request+139/190>> > Trace: c02192b1 <do_sd_request+139/190>> > Trace: c02192b1 <do_sd_request+139/190>> > Trace: c02192b1 <do_sd_request+139/190>> > damn. This means we are recursing 4 ways deep in the Adaptec driver? Isnt
> this a no-no?> 

Possibly because of tagged queueing enabled (wa guess)?  This seems to work
fine.. except for vfat/dos file systems.  I have copied >1.6 Gig ext2 fs
the same way with no illness (several times).

Also, ran into same stack corruption with tagged queueing disabled.

> > i will try to trade my Adaptec for a BusLogic as soon as possible ...
> 

I figured that this driver would _eventually_ get fixed since sooo many
people have 2940s (tried/ka-booom)... even whimpered politely to author.

but if I do...

Will I then run into that nasty sector mapping problem?

It _would_ be sorta nice to be able to backup again.  God's probably tired of
hearing the same fervent prayers after every little crash. :))

	-Mike


\
 
 \ /
  Last update: 2005-03-22 13:38    [W:0.677 / U:0.170 seconds]
©2003-2008 Jasper Spaans