"Munjun Kang" <malas(a)pinetron.com> writes:
> Dear Eric W. Biederman.
>
> First of all, thanks for your reply.
> I apply some other schem to linuxbios.
> This is my boot process.
An unreliable scheme, that does not provide the opportunity for
running anything except the linux kernel. This is why I suggested
a change.
[snip current boot process]
> Do you have any idea to solve this problem?
Already provided but let me reiterate. Many times I have seen a
problem like this it has been due to an improper memory controller
setup, or a corrupted kernel image. At the very least those two
problems should be ruled out before progressing farther.
You have not provided the output of ksymoops from your kernel so I have
no clue if the crash is related to a specific piece of hardware.
memtest86 is good at catching most cases of memory corruption, so
please run it and let me know what happens.
mkelfImage puts a checksum on the image so there is some verification the
image transfered across the network correctly.
The latest versions of etherboot check the checksum.
The version of etherboot in the linuxbios tree is actively dangerous
as it does not call the network card disable routine, so you could
receive packets after the kernel is loaded, but before the kernel has
initialized the card. Causing your kernel image to be corrupted.
And now that I think about it very weird problems may also be caused
by only initializing one cpu in a dual cpu setup. So there may be
something in the cpu setup that doesn't quite work. I don't know
if anyone has worked with the via centaur cpus before. Let alone
set them up in a dual cpu configuration. Or is this a single cpu
in a dual cpu motherboard?
Eric