Re: kernel stack overflow profiler.. two very long oopses

Ingo Molnar (
Sat, 15 Feb 1997 13:05:17 +0100 (MET)

On Sat, 15 Feb 1997, Michael L. Galbraith wrote:

> Yep, it works. Copying from /dos_d (vfat) to /mnt (vfat) via tar, twice for
> good measure. The second one left tar hung and dead. I haven't checked to see
> if the vfat fs is trashed, but I expect it's hosed. I'll leave that partition
> alone for a couple of days in case someone wants additional info.

> kernel stack overflow. Forcing Oops.

i'm not an SCSI expert, but i've snipped out some imho interesting

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

[ and additionally those 900 byte stack allocs per request take away 3600
bytes alone which explains those overflows i guess ... ]


> Trace: c0218fa8 <rw_intr+1e0/3b0>
> Trace: c0218fa8 <rw_intr+1e0/3b0>
> Trace: c0218fa8 <rw_intr+1e0/3b0>

thats a 3 ways deep SCSI interrupt. An absolute no-no as well?

this might explain why these things happen more often on SMP systems: the
SMP kernel 'clusters' interrupts on the base processor, and they might
happen in 'bursts' -> such recursions have higher probability?

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

-- mingo