Subject: Finally - end of my kernel woes - sort of
To: None <current-users@NetBSD.ORG>
From: David Jones <dej@inode.org>
List: current-users
Date: 04/13/1997 14:20:44
Just an update to my earlier post on difficulties compiling the kernel.
I was unable to use a kernel that I compiled myself to compile the
sources again. The result was unbootable.
In addition (and this was obvious if I stopped to think about it), whatever
problem that stopped me from compiling a kernel ALSO caused corruption
when I tried to copy a known good kernel (KGK) to the boot drive.
The solution was clear: get the KCADP-1.2.1 floppy, boot from it, and use
the kernel copy procedure to copy the 1.2.1 generic kernel to the boot
drive. Note that I am booting from a KGK, and using the KGK to copy
a KGK to the boot drive.
After that, I was OK. I updated sources, and built a kernel using that,
which booted. And everyone lived happily ever after... NOT!!!
I still have the problem:
- I can boot the KGK and use it to compile a kernel. Call the new kernel
F95.
- I can boot F95, and use it to filter/route packets (which is what the
machine is for). So far so good. BUT:
- I ***CANNOT*** boot F95 and use it to compile an updated F95 (call it
F95B). F95B will not boot. Instead, immediately after printing
"entry point 0x100020", the machine reboots, as if I had hit the reset
button.
- If I halt the machine and reboot from the KGK, I can compile F95B,
and have it work.
All sources are updated from yesterday.
Now this is not a show-stopper, since the work-around is easy: reboot from
KGK every time I need to recompile F95. But I wonder why this is the case?
On to another subject: you can't print quads in the kernel. The system
simply does not grok %qd. Should I send-pr this (or better, re-work the
*printf functions in subr_prf the way I think they should be, and
send-pr the diffs)?