>Michael Hitch discovered the reason why every tape drive access result
>in SCSI timeout errors.  It's an integer math overflow of 32bit system
>which cause negative timeout value.   NetBSD/pmax has 256HZ hardclock
>which is a higher precision than any other 32bit systems have.   Look at
>a single statement in dev/ic/ncr53c9x.c;
>
>     timeout(ncr53c9x_timeout, ecb, (ecb->timeout * hz) / 1000); 
>
>If ecb->timeout (signed int) value was large enough, intermidate
>arithmetic would produce negatives.
>
>The instant solution is reduce tape operation timeout value. In a file
>'dev/scsipi/st.c';
>
>    #define ST_SPC_TIME     (4 * 60 * 60 * 1000)    /* 4 hours */
>
>Timeout after 4 hours looks aweful someshow, let's say '1 hour' for now.


Great news!

Where does this put us vis-a-vis shipping MI scsi for 1.5?
My understanding is that there's two efforts:
	a) Nisimura-san's branch which uses MI scsi ncr53c9x.cK
        b) michael hitch's code which uses the `old' Mach-derived
	   asc driver, but interfacing to the MI scsi subsystem

Neither of which addresses the SII in the 2100/3100/5100.  So
reworking the SII driver to talk to the MI scsi layer is the main
hurdle. Is that right? 

Michael?  Want to take on another 4.4BSD-to-scspi rewrite?

--Jonathan