Re: Updates
Christian Limpach <[email protected]> Wed, 11 Sep 2002 19:49:39 +0200
| Newsgroups | gmane.os.netbsd.ports.next68k |
|---|---|
| Message-ID | <[email protected]> |
Quoting Charles Hannum <[email protected]>: > > 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 <[email protected]>