Hello, Am 15.08.2017 um 13:25 schrieb Laszlo Ersek: > On 08/14/17 20:39, Dr. David Alan Gilbert wrote: >> * Philipp Hahn (h...@univention.de) wrote: >>> I'm currently investigating a problem, were a Linux VM does not reboot >>> and gets stuck in the SeaBIOS reboot code: >>> >>> I'm using SeaBIOS-1.7 from Debian with a more modern qemu-2.8 ...>>> If I dump both regions and compare them, I get a difference: ...>> You might want seabios commit c68aff5 and b837e6 that got fixed after >> I tracked down some reboot hangs - although they were rare, not every >> time. c68aff5 did certainly cause a corruption, and the address of that >> corruption was determined at link time and could overlay random useful >> bits of code if you were unlucky.
Thanks you for the commit IDs - to me this looks like they fixed the problem. Testing with seabios-1.10 does not show any reboot problem so far. >>> 1. How can it be, that the low-mem ROM mapping is modified? >> >> I can't remember all the details, but PC ROM is shadowed and mapped over >> with RAM at various times, > > Right. I don't remember for sure, but I believe the state of the PAM > registers doesn't only affect what the VCPUs see in that address range, > but also what your monitor commands will dump. (This would be the > logical choice -- make the monitor output what the VCPUs see anyway, at > the moment, dependent on the PAM settings.) That makes sense. Do you know by change what change in Qemu triggered that bug, as I've never seen any reboot problem with qemu-1.1.2, but only since switching to qemu-2.8? Thanks again for your excellent help. Philipp
