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;
