Jeff Pickell wrote:
Sorry if I'm way off base on this one, but I've been paying around with
different kernels (mostly the 2.4.18 stuff) on an Ultra I. When I've
finished compiling the source, the resulting vmlinux file isn't
compressed, just like you've stated. Just for grins, I used gzip to
compress the file, then simply moved and renamed it to its proper
place/name (/boot/vmlinux-011503). I recreate the symbolic link from
/vmlinuz to my new kernel, check Silo.conf to make sure everything is
pointing to where it should and I can then reboot without any
problems. Since I've g'zipped the kernel, it's small enough, and the
system knows
to decompress it.
Perhaps you might try the same thing with the 2.4.20 source.
It doesn't matter if you compress it or not for the limit that I
was hitting. (But it does help if you strip it.) There is a fixed
size area of memory that second.b of silo/tilo uncompresses/loads
into. If it hits the end of it before it's done, it fails.
This isn't the problem I'm having though. I'm getting
"scheduling while atomic" early in the boot process (right
after the POSIX message) and dump_stack() isn't implemented
on sparc64.