Ari Suutari writes:
> Hi everyone,
> 
> 	I grabbed the NetBSD-current sys.tar.gz (about week or 
> 	two ago) and compiled it on MicroVAX II. Seems to boot ok.
> 
> 	I also compiled the boot blocks and another kernel with
> 	VS2000 devices in it. I put the boot blocks and the kernel
> 	to a rx33 floppy and tried to boot my VS2000 with it.
> 
> 	After saying "B DUA2" boot block loads, /boot gets loaded
> 	and starts loading /netbsd. However, after kernel is loaded
> 	there is no signs of life after 'start at <address>' message.

If the machine doesn't display any "HLT PC=xxxx" message but just
sits there and seems to dead, this is almost sure due to an endless
loop while counting memory...

badaddr() which traps invalid addresses on other VAXen doesn't (or
at least didn't when I checked last time) work on VS2000 and VS3100.
This is because the physically available memory on these machines is
mapped into the physical address space multiple times so that each
physical address seems to be valid.

For debugging purposes I've once done an ugly hack in my vax/pmap.c 
which writes a pattern (and the actual address) into each page visited
and checks this for the existence of this pattern when counting memory.
So I found out which address was the first one which didn't "exist"
but was only a mapping. I haven't looked into -current for quite some
time now but I think that these debugging things usually don't get
commited into the official tree (which is more than OK, since this
was no general solution but a hack for VS2000 and VS3100).

On our ftp-server ifib4.ifib.uni-karlsruhe.de there are still my
old sources lying around. Get them, extract pmap.c, either replace
pmap.c or temporarily integrate the old debug-stuff into pmap.c
and rebuild your kernel for VS2000. I'd like to know if anything
changes...

Ciao,
	bertram

PS: As I said before, this hack was for VS2000 and VS3100 only. I've
    never checked, but it might have bad side-effects on other machines.