lkml.org 
[lkml]   [1997]   [Feb]   [15]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateSat, 15 Feb 1997 13:05:17 +0100 (MET)
FromIngo Molnar <>
SubjectRe: kernel stack overflow profiler.. two very long oopses
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
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?

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

additionally:

> 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


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