> Date: Thu, 20 Nov 1997 02:52:03 -0500 (EST)
> From: woods@most.weird.com (Greg A. Woods)
> 
[ programs dump core, etc. ]
> 
> Initially re-running ldconfig seemed to make no difference so I checked
> the binaries from the server (still running the older 11/17 kernel), and
> they seemed fine from there.
> 
> Then suddenly they seemed fine on the new kernel.  But not for real.
> Trying to run startx again left me with an xterm.core.  Now I get a
> 'xterm: signal 11' from ldd and even another xterm.core!
> 
> There seems to be some serious bitrot in there somewhere.

This sounds like the old "everything dumps core" problem again.
Oh well.  I was hoping that would be gone, but maybe not yet.

It has been suggested that the pmap code is a likely suspect for
this problem, possibly due to a missing interrupt protection.
The next step planned for the pmap code is to implement detection
of unexpected recursion (which is usually due to spl problems).
The latest pmap code no longer has any recursive calls (where it
used to call malloc which can again call pmap) so it should be
fairly easy to implement recursion detection with a global flag.
If only there were more hours in the day...

> More weirdnesses:
> 
> I had wanted to try enabling all the SCSI options, so the workstation
> being a 3/60 I set the si flags:
> 
> 	si0 at obio0 addr   0x140000 level 2 flags 0x0
> 
> However as you can see above it booted with:
> 
> Nov 20 02:38:41 very.weird.com /netbsd:
> si0 at obio0 addr 0x140000 level 2: options=0xf
[...]
> AH!  I think I see the bug.  It is impossible to set the options to 0:

Oh yeah.  The built-in (default) options should be zero, and
the "standard" 0xf flags should be only in the config file.

> Some innocuous bit must be set in order to not get the default.  How
> about 0x8 (i.e. the host adapter)?

Close.  Using flags=0x80 should be equivalent to zero.
(Says no reselect on the host adapter ID.)

> And a minor annoyance:
> 
> The console on bwtwo doesn't get initialized with the right screen size
> in the tty driver.  In theory it should pull this from the eeprom, which
> I've set to the correct value of 48, but it gets set to 34 instead.
> I'll try and remember to send-pr this too.

I think I've already got a fix for that laying around, but didn't
get time to integrate and test it before the release branch.
Feel free to send the bug report as a reminder.