Regression in 8.2.90: cpu_physical_memory_snapshot_get_dirty: assertion failed
Host environment
- Operating system: Debian Bookworm (and Windows 10 22H2, too)
- OS/kernel version: Linux rodrigo 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1 (2024-02-01) x86_64 GNU/Linux
- Architecture: x86_64
- QEMU flavor: qemu-system-i386
- QEMU version: 8.2.90 - commit determined by git bisect: 973a724e
- QEMU command line:
qemu-system-i386 oberon/oberon.qcow2
Emulated/Virtualized environment
- Operating system: ETH Native Oberon
- OS/kernel version: ETH Oberon / PC Native 05.01.2003
- Architecture: i386
Description of problem
On executing the image from QEMU advent calendar 2014, door 12 the following error is shown and QEMU exists.
On Debian (built on git-repo)
$ qemu-system-i386 oberon/oberon.qcow2
qemu-system-i386: ../system/physmem.c:948: cpu_physical_memory_snapshot_get_dirty: Zusicherung »start + length <= snap->end« nicht erfüllt.
Abgebrochen
On Windows (built on qemu-9.0.0-rc0.tar.xz)
$ qemu-system-i386 oberon/oberon.qcow2
ERROR:../qemu-9.0.0-rc0/system/physmem.c:946:cpu_physical_memory_snapshot_get_dirty: assertion failed: (start + length <= snap->end)
Bail out! ERROR:../qemu-9.0.0-rc0/system/physmem.c:946:cpu_physical_memory_snapshot_get_dirty: assertion failed: (start + length <= snap->end)
Steps to reproduce
- Retrieve oberon.tar.xz with
wget http://qemu-advent-calendar.org/2014/download/oberon.tar.xz
- Extract with
tar -xf oberon.tar.xz
- Execute with
qemu-system-i386 oberon/oberon.qcow2
Additional information
The same error is shown for QEMU advent calendar 2014, door 15 (Plan 9 from Bell Labs) soon after switch to graphical mode.
git bisect result:
973a724eb006f674301a0c45f34b3c08dee0fe49 is the first bad commit
commit 973a724eb006f674301a0c45f34b3c08dee0fe49
Author: Paolo Bonzini <pbonzini@redhat.com>
Date: Mon Dec 29 14:48:14 2014 +0100
vga: implement horizontal pel panning in graphics modes
This implements smooth scrolling, as used for example by Commander Keen
and Second Reality.
Unfortunately, this is not enough to avoid tearing in Commander Keen,
because sometimes the wrong start address is used for a frame.
On real EGA, the panning register is sampled on every line, while
the display start is latched for the next frame at the start of the
vertical retrace. On real VGA, the panning register is also latched,
but at the end of the vertical retrace. It looks like Keen exploits
this by only waiting for horizontal retrace when setting the display
start, but implementing it breaks the 256-color Keen games...
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Edited by Mark Cave-Ayland