> From: "Harry Schreurs" <HLS@oce.nl>
> Date:          Tue, 30 May 1995 18:59:46 GMT +0100

> > Unfortunately, ftp.netbsd.org is off the air for a while, so I've
> > put a tar/gzip image of src/sys/arch/sun3 on our FTP server as:
> >     ftp.mc.com//pub/NetBSD-src-sun3.tar.gz
> > 
> I wasn't able to contact the above mentioned FTP server. I managed to get
> the sources from firewall.mc.com instead!

Yes, that is the real name.  ftp.mc.com is an alias.
Anyway, ftp.netbsd.org is back on-line again.

> I was able to build a working GENERIC kernel using the following procedure:
[ using cross-build ]
Native build is easier, but I haven't had time to update the sun3
binary snapshot yet, so you have to build "user-land" first...

> Alas there is at least on problem left! NetBSD doesn't see any SCSI
> devices connected to the SUN 3/50 "si" controller.
> 
> Using DDB I enabled SCSI debugging using:
> 
>         db> write si_debug 1

> si0 at obio0 addr 0x140000 level 2
> si_reset_adapter
> si_reset_scsibus
> scsibus0 at si0
> si_select_target: still BSY|SEL
> si_dorequest: select returned 1
> si_select_target: still BSY|SEL
> si_dorequest: select returned 1

That usually means something is "sitting on the bus" and the
driver should force a SCSI bus reset.  (Not sure it does...)

> So far I only discovered that the memory location, pointed to by:
> 
>      regs->sci_bus_csr
>      
> on a Sun 3/50 always returns 0xff when being read.

That is really strange.  Perhaps you should check its mapping with:
	db> mach pgmap <virtual-address>