![]() | |||||||||||||
Messages in this thread |
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 | |||||||||||||