On Fri, 2002-11-15 at 10:12, Greg Troxel wrote:
> summary: I built a 1.5 kernel with -msupersparc for an SS20, and it
> failed to boot.  Is this a bug, or is the answer "Don't do this"
> because the kernel environment is somehow special?
> 
> Is it ok to link files compiled with -msupersparc with files compiled
> without?  I would think that this just allows the use of
> supersparc-only instructions, so having other files that decline to
> use them should not present a problem (other than performance).
> 
> I have a SS20 running 1.5.4_ALPHA (recent netbsd-1-5 branch).
> Following suggestions from this list, I installed the cpuflags pkg and
> put
> 
>   .sinclude "/usr/pkg/share/mk/cpuflags.mk"
> 
> in /etc/mk.conf and rebuilt libcrypto and ssh.  (ssh is the critical
> one because the DH code for the ssh2 KEX is in ssh, not libcrypto.)
> This sped up ssh2 by a factor of 2.
> 
> Then, I did a cvs update and rebuilt a kernel (config/make
> depend/make), and did 'make build'.  On rebooting, the machine did not
> come up.  I asked someone to check on it (I'm remote), and he reported
> that the console said "Instruction access exception".  Booting onetbsd
> brought it back, so the new userland seems fine.
> 
> The new kernel seems bigger, and I don't know why.  I am rebuilding a
> kernel without cpuflags and will try that.

This sounds like the problem I ran into with 1.6 and a custom kernel.

If so, the problem is that the kernel is too big for the default
bootloader. I haven't tried it, but apparently the trick is to rebuild
the boot blocks with a different setting that allows a physically larger
kernel.

Check the archives from early October for more info.

<<<john>>>