for 2, the BIOS sets the hardware to a known state,
or if you can trigger *the* hardware reset line,
which will also do that, then you're going through
the BIOS again. Now if you made your own bios...
see www.linuxbios.org.
there are patches where a kernel can load another
kernel, also.
As for taking crashdumps on the way up, I believe
(SGI's ?) linux kernel crash dumps does *exactly*
this.
Jeremy
----- Original Message -----
From: "Martin J. Bligh" <fletch@aracnet.com>
To: <linux-kernel@vger.kernel.org>
Sent: Friday, April 05, 2002 11:13 AM
Subject: Faster reboots (and a better way of taking crashdumps?)
> My real motivation for this isn't actually faster reboots,
> it's rebooting at all - I have some strange hardware that
> won't do init 6 in traditional ways ... but it might mean
> a faster reboot for others.
>
> What's to stop me rebooting by having machine_restart load
> the first sector of the first disk (as the BIOS does), where
> the LILO code should be, and just jumping to it?
>
> 1. Are there tables that are created by the BIOS that we
> destroy during Linux runtime? mps tables spring to mind -
> I can't see where we preserve them ...
>
> 2. Things that are reset by reboot that we don't reset during
> normal kernel boot?
>
> As a side effect, this means we could potentially take
> crashdumps on the way up, rather than the way down, so
> the kernel is more likely to be in a working state (we'd
> have to load a minimal kernel / crashdumper to take the
> dump first ... this is similar to what we did with PTX).
>
> M.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Apr 07 2002 - 22:00:19 EST