> 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