Re: [Qemu-devel] qemu-ppc (prep) crashes with NetBSD guest

[Alexander Graf]

On 13.08.2013, at 08:45, Felix Deichmann wrote:

> Hi,
> 
> I tried to install NetBSD/prep 6.1 in qemu-ppc (-M prep), but qemu
> crashes during installation with "floating point exception" in a
> reproducible way.
> 
> qemu is version 1.5.2-1 from Arch Linux (sorry, didn't have the time
> to build a current one) on a x86_64 host. The same happens with Win
> qemu 1.5.1 binaries from http://lassauge.free.fr/qemu/.
> I boot a custom NetBSD installation image ("sysinst_com0.fs") via the
> "-kernel" option, and use a serial console (VGA doesn't work for me).
> The custom image contains a kernel which does not use NetBSD's pnpbus
> for prep, but hardwired device configuration like ISA IDE
> controller's, as qemu seems to miss PnP information found on real PReP
> machines completely?
> 
> # qemu-system-ppc -nographic -M prep -m 128M -hda hda.qcow2 -cdrom
> NetBSD-6.1-prep.iso -serial ... -kernel sysinst_com0.fs
> 
> There seems to be a connection between the amount of RAM chosen and
> the point where the crash happens. With 128M, qemu will crash when the
> installer extracts some of the earlier packages, with 256M the crash
> will happen later when extracting. Each one is reproducible at the
> exact point of installation. And the amount of bytes extracted could
> be the amount of RAM minus some number.
> (64M and >256MB won't boot at all, so I could not finish installation...)
> 
> The boot image I used can be found at:
> http://www.flxd.de/netbsd/qemu-ppc/sysinst_com0.fs
> 
> The ISO is the standard one from NetBSD.
> 
> Would be great if someone (also with a current qemu) could have a
> look, as I did not even manage to get a core file...

Gerd, this seems to be vbe related and you're the only person I know who might 
have a clue what's going on there :). Based on where the VGA code was crashing 
I came up with the following patch, but I'd assume the underlying issue is 
somewhere else.

  1) During line_offset set val == 0, so we get a division by 0
  2) the VBE ENABLE call tries to clear the frame buffer, but its calculation 
is bigger than the allocated size


Alex

diff --git a/hw/display/vga.c b/hw/display/vga.c
index 21a108d..0ea9b2d 100644
--- a/hw/display/vga.c
+++ b/hw/display/vga.c
@@ -697,7 +697,8 @@ void vbe_ioport_write_data(void *opaque, uint32_t addr, 
uint32_t val)
                 /* clear the screen (should be done in BIOS) */
                 if (!(val & VBE_DISPI_NOCLEARMEM)) {
                     memset(s->vram_ptr, 0,
-                           s->vbe_regs[VBE_DISPI_INDEX_YRES] * 
s->vbe_line_offset);
+                           MIN(s->vbe_regs[VBE_DISPI_INDEX_YRES] *
+                               s->vbe_line_offset, s->vram_size));
                 }

                 /* we initialize the VGA graphic mode (should be done
@@ -743,7 +744,7 @@ void vbe_ioport_write_data(void *opaque, uint32_t addr, 
uint32_t val)
             break;
         case VBE_DISPI_INDEX_VIRT_WIDTH:
             {
-                int w, h, line_offset;
+                int w, h = 0, line_offset;

                 if (val < s->vbe_regs[VBE_DISPI_INDEX_XRES])
                     return;
@@ -752,7 +753,9 @@ void vbe_ioport_write_data(void *opaque, uint32_t addr, 
uint32_t val)
                     line_offset = w >> 1;
                 else
                     line_offset = w * ((s->vbe_regs[VBE_DISPI_INDEX_BPP] + 7) 
>> 3);
-                h = s->vram_size / line_offset;
+                if (line_offset > 0) {
+                    h = s->vram_size / line_offset;
+                }
                 /* XXX: support weird bochs semantics ? */
                 if (h < s->vbe_regs[VBE_DISPI_INDEX_YRES])
                     return;