Jonathan Stone wrote:

> >I've been planning a snapshot for a while, but then the the R4000
> >ld.elf_so thing got in the way.  I've also got some new bootblocks that
> >are ready to be committed after I hear the reports of one more test and
> >there's also a few funny disk reports - the non-existant drives (not
> >recent apparently) and reports of disks that sound like they're showing
> >up on asc1 on a 5000/200 instead of asc0.  
> 
> I was about to say that the non-existent drives must be pre-SCSI-2
> devices. I testsed some old pre-scsi-2, SCSI-1 CCS-ish drives at
> Stanford.  Initially they didn't work: the geometry-sense code we
> lifted from the MI scsi confused them. Perhaps the same is happening
> here?

The 3100 scsi probe from John Darrow's machine shows:

	U[1]    Dev typ   0 RZ
		  RMB     0x0
		  Vrs     1
		  Format  1 CCS
		  Add len 31
		  Vndr    HITACHI
		  PID     DK515C
		  Frevlvl CP15

If the "Vrs" is SCSI version, you're theory is sounding good.  I was
thinking of making rzprobe() really version and giving John a test
kernel.  Sound like a good start?

> Waiting for the new bootblocks sounds like a great idea.
> Especially since we want to ship these in 1.5.

They're this close (picture two fingers an eighth of an inch apart).
I'm just waiting on one more test for a ISO format CD ROM on a 5000/200.
The final version (unless you want to jump in quickly!) is second stage
bootblocks called "boot.pmax", and the first default kernel searched is
"netbsd.pmax", followed by "netbsd", "netbsd.bak", etc...

> >I think it'd be better to
> >hold off on a snapshot just a little longer...
> 
> Emacs. Must fix emacs under X. (Did someone fix it already)?  Didn't
> someone report over summer that applying the patches I posted back
> whenever actually worked?  That suggests the problem lies elsewhere
> than we'd thought.

The last I remember off the top of my head (so this is a guess!) was
that you found some symbols that were being relocated to twice their
proper value or something like that?  I haven't heard if it was fixed or
otherwise.

> >>From memory, it takes about 18ish hours on a /260, and another couple
> >to build xsrc as well.
> 
> On what kind of disks? (a Richocet would take at least 18 hours just
> to  update the source...)

I work with the source tree NFS mounted of an Ultrix /260 (filled with
RZ28's) with obj dirs on the local RZ28s.

Simon.