On Tue, Feb 14, 2017 at 05:36:34PM +0100, Laszlo Ersek wrote:
On 02/14/17 17:22, Kevin O'Connor wrote:
On Tue, Feb 14, 2017 at 02:50:23PM +0000, Dr. David Alan Gilbert wrote:
I've been sporadically carrying on debugging this and I think I have a bit more understanding, but not quite all the way.
I'm pretty sure we are trying to run code that's been over written by variable data - which I believe to be TimerLast, and I'm also fairly sure the problem is not a delayed reset from multiple reboot signals.
Some detail: a) I added some debug to qemu to print what triggered the reboot by always passing qemu_system_reset_request a string; the kernel is always rebooting via KBD_CCMD_RESET, I see that enter the BIOS and then see SeaBIOS then does KBD_CCMD_RESET again - which I think is the one coming from handle_resume32. But then I noticed that every so often we got a reboot from a KVM_SHUTDOWN which is apparently a triple-fault or the like.
b) With a KVM trace I got the addresses the fault was happening at, and it was always an address in the copy fo the bios around bffbcf.. although the actual failure jumped about a bit, taking the: Relocating init from 0x000e4810 to 0xbffb2050 (size 57120) I worked the fault address back to 'ef799' and from the objdump found that was an address in maininit but also corresponded to TimerLast:
I can confirm there is a defect with TimerLast and reboot handling. I'm not sure what the best fix is - suggestions welcome.
The root of the problem is that QEMU does not reset the f-segment on a reboot signal
Are you sure this applies to recent QEMU too, not just ancient QEMU?
and so SeaBIOS must manually reset that memory.
Do you mean a workaround for the (historically lacking) emulation of the PAM chipset registers? PAM emulation has been correct for quite a while now in QEMU, as far as I can tell.
My understanding was that a write to the PCI reboot register (0x0cf9) would cause a hard reboot - which would reset the PAM registers to their default (a RO view of the pristine bios at 0xf0000). I just did some tests with qemu v2.8 and it does not appear to do that.
Also, the PAM registers on real hardware support a mode where reads to 0xf0000 return the pristine copy of the bios while writes update memory. I didn't think there was any interest in implementing that on QEMU (nor do I think it would be particularly helpful to have).
-Kevin