On Sun, 2003-01-05 at 21:48, Eric W. Biederman wrote:
>
> O.k. I have switched to using the init_mm and premapping the reboot
> code buffer.
<snip>
> The code in machine_kexec now takes no locks and is drop dead simple,
> so it should be safe to call from a panic handler.
Eric,
The patch applies cleanly to 2.5.54 for me. Current behavior matches
the version of kexec for 2.5.48 that I carried forward into 2.5.52 and
2.5.54 (and kexec_tools 1.8):
- the kexec-ed kernel starts rebooting and finds all of my system's
memory, so the generic kexec machinery is working as expected.
- the kexec-ed kernel hangs while calibrating the delay loop. The list
of kernels I attempted to reboot includes permutations of 2.5.48 +/-
kexec, 2.5.52 +/- kexec(from 2.5.48), 2.5.54, 2.5.54 + kexec(from
2.5.48), and 2.5.54 + kexec (recent patch from you).
- Whatever it is that SuSE supplies in 8.0 (2.4.x +) panics near/during
frame buffer initialization when rebooted via kexec for 2.5.54:
.
.
.
Initializing CPU#0
Detected 799.665 MHz Processor
Console: colour VGA+ 80x25
invalid operand: 0000
CPU: 0
EIP: 0010[<00000007>] Not tainted
EFLAGS 00010002
.
.
.
Something has definitely changed in the 2.5.5x series, and the symptoms
indicate that at least the clock interrupt is not being received.
kexec for 2.5.48 worked for me (with some limits), so I should be able
to walk the tree forwards and poke at it some more.
For those that have had success w/ recent vintage kernels and kexec (>
2.5.48), could I get a roll-call of your machine's hardware? Uniproc,
SMP, AGP, chipset, BIOS version, that kind of thing. lspci -v,
/cat/proc/cpuinfo, and maybe the boot-up messages would all be
appreciated.
Regards,
Andy
-
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 : Tue Jan 07 2003 - 22:00:37 EST