Quoting Charles Hannum <abuse@spamalicious.com>:

> > 2) On my color turbo, with the SCSI driver enabled, the kernel wedges
> >    in a loop printing `esp0: SCSI bus reset' during autoconfig.  I
> >   haven't looked at this.
> 
> The looping `esp0: SCSI bus reset' problem is not specific to the
> NeXT, as it turns out.  I still don't know whether SCSI works with
> devices plugged in.

I haven't looked at SCSI on turbo yet and it's unlikely to work.  I think the 
SCSI bus resets are a result of this or of incorrect termination because you 
have no devices connected.  

A kernel without SCSI support doesn't work well on machines which have SCSI 
devices or which tried to boot from a SCSI device before booting off the 
network.  A kernel with SCSI support doesn't work well on machines which 
don't have SCSI devices or incorrect termination.

SCSI worked for me on non-turbo machines and I'll try what you checked in as 
soon as it's available from anoncvs.no.

> > 3) On the turbo, I get `xe0: discarding oversize frame (len=1519)'
> >    periodically (always with the same `len'), and network access seems
> >    to be slower than I would expect.  It definitely feels slow than
> >    the non-turbo slab.  I suspect something is still wrong here.
> >
> > 4) On the turbo, the boot block sometimes (well, really more often
> >    than not) aborts loading with `enintr: timed out'.
> 
> Both of these are actually caused by the same problem: sometimes an
> extra byte is stuffed at the front of a received frame, which causes
> it to be discarded, and -- if it was a maximum-size packet to begin
> with -- oversized.  I've fixed the boot block so it will retransmit,
> which sidesteps the problem.

I thought the oversized frames were caused by reading the end of dma-transfer 
register when it's already not valid anymore.  Extra byte at the front is 
really weird...

-- 
Christian Limpach <chris@Pin.LU>