Elias Rajczyk <[EMAIL PROTECTED]> writes:
>
> We have problem rebooting our system with LinuxBios. After the command
> "reboot" the system freezes.
Knowing what hardware you are running LinuxBIOS on would help to debug this.
> There were plenty of mails on this subject saying this issue is caused by
> the pentium chip missing a reset instruction and others saying the cause is
> linux's way of rebooting is wrong. Well, apparently cause/cure are elsewhere
> : the system that freezes when rebooting with LinuxBios, restarts just fine
> in all modes (reset,hot reboot,soft reboot) with regular Bios.
> Apparently LinuxBios misses some system configuration...
Ron seems to be asking for my input so here goes.
1) There are three kinds of reboot.
a) software only (monte or kexec) or jump to 0xFFFFF0 in 16 bit mode.
b) cpu only (This will reliably get you back into the x86 firmware)
c) reset line on the entire motherboard.
2) When an x86 cpu tripple faults, or receives a reset signal it
hangs, until the it receives a signal that it is o.k. to continue.
It takes some close reading of the documentation to see this but is
is documented for both Athlons and Pentiums. Usually it is the
southbridge that controlls the reboot behaviour, on some
southbridges it defaults to setting this up correctly, and on
southbridges some registers need to be setup for this to work.
3) There are two options to reboot Linux under LinuxBIOS.
a) issue the corrent port I/O instruction to the hardware
to get a board level reboot. This is what Ron and Ollie
usually do. I support this but we need a way to specify
in the LinuxBIOS table where this is in case there are multiple
possibilities on the motherboard.
b) specify "reboot=hard" on the kernel command line and get a cpu
only reset either throught a triple fault or the keyboard
controller. This gets you back into LinuxBIOS and with the
a little additional code to skip the memory setup, you can issue
the board level reset from LinuxBIOS.
Things are a bit different here because LinuxBIOS by design does
not support any callbacks. Which does break the kernels default
reboot method of jumping to the BIOS (and we don't leave one
running).
I have been implementing option (b) at least initially because
it lets me avoid requiring a patched kernel. Which makes
maintenance much easier.
Eric
