Just in case this helps, I've used the debugger to look around at things
when the biodone already panic occurs.  WWhat I've found is that somewhere
along the way an xs (scsi transfer) structure has been deallocated twice to
the free list.  next_free_ns points to an entry whose link points to
itself!  And the sc_link structure's opennings field (essentially, an
"outstanding I/O credits" counter) contains a value of 3, even though it
was initialized at 2.

Further, the problem only seems to occur _after_ a transfer has completed
with an error of XS_BUSY (xs->error = 8).  And xs->retries field has been
decremented all the way to -1 (ie, no more retries allowed).

I put some extra debugging code into scsi_base.c and verified that the xs
has indeed been doubly-deallocated, and that the previous transfer
completed with XS_BUSY.  It seems that just doing a "printf ("XS_BUSY!\n")
" in routine sc_err1 causes enuf delay to avoid the problem most of the
time, but not always.

I'm running with a Toshiba 1.2BG internal hard drive with separate root,
swap and usr partitions, and an external Syquest 270MB cartridge drive for
the source tree, both of which claim to be SCSI-2 capable.  The XS_BUSY
error only occurs on the Toshiba.  So, now I'm rebuilding with the Syquest
as my Root&Usr drive, and I'll use the Toshiba for the sources.  This way,
at least I'll be able to keep things up long enuf to do something useful,
but I may not be able to build any new kernels for further testing.  :(

Hope this helps someone who's more familiar with scsi innards to solve the
problem.  This (and the adb scrolling bug) are the only things I have to
grouse/gripe/bitch about!

------------------------------------------------------------------
| Paul Goyette            | PGP Public key available on request  |
| Paul@pgoyette.ccnet.com | Fingerprint: 9D 3C 90 0E DA 46 10 59 |
| goyettep@ccnet.com      |              15 F2 87 D6 AA BD 90 D5 |
------------------------------------------------------------------


.