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 _______________________________________________ SeaBIOS mailing list [email protected] https://www.coreboot.org/mailman/listinfo/seabios
