On Mon, Jul 18, 2011 at 9:22 PM, Juergen Lock <n...@jelal.kn-bremen.de> wrote: > Hi! > > I'm the FreeBSD qemu port maintainer and don't have a sparc64 box > myself, but Jashank Jeremy (Cc'd) now was so kind to test qemu 0.14.1 > on a FreeBSD/sparc64 box booting a FreeBSD 8/i386 install iso using > i386-softmmu and we found two things: > > 1. The hang people have been reporting seems to be caused by this tb: > > IN: > 0x000e7a31: in $0xb3,%al > 0x000e7a33: test %al,%al > 0x000e7a35: jne 0xe7a31 > > i.e. it (the qemu bios I suppose) is waiting for x86 ioport 0xb3 > to become zero. This port is #defined in hw/apm.c as: > > qemu-0.14.1/hw/apm.c:#define APM_STS_IOPORT 0xb3 > > but the definition seems to be used nowhere in that source file. > Anyone have an idea why this port is never zero on sparc64 hosts > but seems to be on others? (endian issue? uninitialized variable?)
The port belongs to SMI, it's PORT_SMI_STATUS in Seabios. There is a crash on OpenBSD/Sparc64 at this point. The problem is that somewhere in do_smm_enter() or the functions that it calls, global register for CPUState %g5 gets a different value that it should have. Probably a system library uses it. I'll try if dropping -ffixed-g5 changes anything. > 2. Booting the same guest with -no-acpi gets further, bios and > bootloader messages are printed until it hangs again, this > time while handling a guest irq 8 which seems to be rtc. Yes, same here. > Maybe this is useful to some... :) > > Thanx, > Juergen >
