Messages in this thread |  | | Date | Sun, 16 Feb 1997 06:04:38 +0100 (MET) | From | "Michael L. Galbraith" <> | Subject | Re: 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
|  |