I wrote:

> I'm going to test a kernel built without the erroneous "/ CLSIZE"
> bits in it tonight, and report back later.

Well, it fixed that particular problem, but the kernel still crashes
badly -- and with panic types I recognize from earlier attempts.

Here's some dmesg output that shows what happens (incidentally, it's
interesting that this newer kernel, with the same configuration, but a
newer, on other platforms larger code base, and the addition of the
new RAIDFrame code, which I look forward to playing with, still shows
up a megabyte more "avail mem" than did 1.3F):

NetBSD 1.3I (LUDWIG) #4: Thu Dec 10 21:16:17 CET 1998
    tih@ludwig.Hamartun.Priv.NO:/usr/local/netbsd/src/sys/arch/vax/compile/LUDWIG

MicroVAX 3500/3600
realmem = 16736256
avail mem = 13045760
Using 204 buffers containing 835584 bytes of memory.
mainbus0 (root)
cpu0 at mainbus0: KA650, CVAX microcode rev 4 Firmware rev 18
uba0 at mainbus0: Q22
mtc0 at uba0 csr 174500 vec 774 ipl 17
mscpbus2 at mtc0: version 4 model 3
mscpbus2: DMA burst size set to 4
mt0 at mscpbus2 drive 0: TK50
uda0 at uba0 csr 172150 vec 770 ipl 17
mscpbus0 at uda0: version 6 model 13
mscpbus0: DMA burst size set to 4
ra0 at mscpbus0 drive 0: RA82
uda1 at uba0 csr 160334 vec 764 ipl 17
mscpbus1 at uda1: version 2 model 3
mscpbus1: DMA burst size set to 4
ra4 at mscpbus1 drive 0:   52
ra5 at mscpbus1 drive 1:   52
rx0 at mscpbus1 drive 2: RX50
rx1 at mscpbus1 drive 3: RX50
qe0 at uba0 csr 174440 vec 760 ipl 17
qe0: deqna, hardware address 08:00:2b:02:8e:24
dhu0 at uba0 csr 160500 vec 310 ipl 17
dhu0: rom(1) version 2 rom(0) version 2
Kernelized RAIDframe activated
boot device: ra0
root on ra0a dumps on ra0b
ra0: size 1284720 sectors
panic: trap: access fault without process
syncing disks... panic: trap: access fault without process
NetBSD 1.3I (LUDWIG) #4: Thu Dec 10 21:16:17 CET 1998
    tih@ludwig.Hamartun.Priv.NO:/usr/local/netbsd/src/sys/arch/vax/compile/LUDWIG

MicroVAX 3500/3600
realmem = 16736256
panic: Segv in kernel mode: pc 86e1b010 addr 86e1b010
syncing disks... panic: ptelen fault in system space: addr ffffffb0 pc
8006d9f4
NetBSD 1.3I (LUDWIG) #4: Thu Dec 10 21:16:17 CET 1998
    tih@ludwig.Hamartun.Priv.NO:/usr/local/netbsd/src/sys/arch/vax/compile/LUDWIG

MicroVAX 3500/3600
realmem = 16736256
avail mem = 13045760
Using 204 buffers containing 835584 bytes of memory.
mainbus0 (root)
cpu0 at mainbus0: KA650, CVAX microcode rev 4 Firmware rev 18
uba0 at mainbus0: Q22
mtc0 at uba0 csr 174500 vec 774 ipl 17
mscpbus2 at mtc0: version 4 model 3
mscpbus2: DMA burst size set to 4
mt0 at mscpbus2 drive 0: TK50
uda0 at uba0 csr 172150 vec 770 ipl 17
mscpbus0 at uda0: version 6 model 13
mscpbus0: DMA burst size set to 4
ra0 at mscpbus0 drive 0: RA82
uda1 at uba0 csr 160334 vec 764 ipl 17
mscpbus1 at uda1: version 2 model 3
mscpbus1: DMA burst size set to 4
ra4 at mscpbus1 drive 0:   52
ra5 at mscpbus1 drive 1:   52
rx0 at mscpbus1 drive 2: RX50
rx1 at mscpbus1 drive 3: RX50
qe0 at uba0 csr 174440 vec 760 ipl 17
qe0: deqna, hardware address 08:00:2b:02:8e:24
dhu0 at uba0 csr 160500 vec 310 ipl 17
dhu0: rom(1) version 2 rom(0) version 2
Kernelized RAIDframe activated
boot device: ra0
root on ra0a dumps on ra0b
ra0: size 1284720 sectors

Oh, and I said that 1.3F was "rock solid" on this system.  This is
only almost true: when I have an experimental 1.3I kernel running, and
I use the "reboot" command to get back to 1.3F, the 1.3F kernel will
normally crash like this during boot (and then reboot automatically,
and be perfectly good after that):

NetBSD 1.3F (LUDWIG) #0: Tue Jun 16 18:10:13 CEST 1998
    tih@ludwig.Hamartun.Priv.NO:/sys/arch/vax/compile/LUDWIG

MicroVAX 3500/3600
realmem = 16736256
panic: ptelen fault in system space: addr c2045004 pc c2045004
syncing disks... panic: ptelen fault in system space: addr ffffffb0 pc 80027f0c

If I "halt" from 1.3I, then ">>> I" and ">>> B", this doesn't happen.

-tih
-- 
Popularity is the hallmark of mediocrity.  --Niles Crane, "Frasier"