On Sun, Mar 4, 2012 at 12:28, Avi Kivity <a...@redhat.com> wrote: > On 03/04/2012 12:27 PM, Blue Swirl wrote: >> On Sun, Mar 4, 2012 at 09:46, Michael S. Tsirkin <m...@redhat.com> wrote: >> > commit 5caef97a16010f818ea8b950e2ee24ba876643ad introduced >> > a regression: we do not make IO base/limit upper 16 >> > bit registers writeable, so we should report a 16 bit >> > IO range type, not a 32 bit one. >> > Note that PCI_PREF_RANGE_TYPE_32 is 0x0, but PCI_IO_RANGE_TYPE_32 is 0x1. >> > >> > In particular, this broke sparc64. >> > >> > Note: this just reverts to behaviour prior to the patch. >> > Making PCI_IO_BASE_UPPER16 and PCI_IO_LIMIT_UPPER16 >> > registers writeable should, and seems to, work just as well, but >> > as no system seems to actually be interested in 32 bit IO, >> > let's not make unnecessary changes. >> > >> > Reported-by: Mark Cave-Ayland <mark.cave-ayl...@ilande.co.uk> >> > Signed-off-by: Michael S. Tsirkin <m...@redhat.com> >> > >> > Mark, can you confirm that this fixes the bug for you? >> >> No, running >> qemu-system-sparc64 -serial stdio >> still shows black screen and the following on console: >> OpenBIOS for Sparc64 >> Unhandled Exception 0x0000000000000032 >> PC = 0x00000000ffd19e18 NPC = 0x00000000ffd19e1c >> Stopping execution >> >> This unassigned memory exception is triggered because CMD646 IDE I/O >> registers are not accessible: >> >> (qemu) info pci >> Bus 0, device 5, function 0: >> IDE controller: PCI device 1095:0646 >> IRQ 1. >> BAR0: I/O at 0xffffffffffffffff [0x0006]. >> BAR1: I/O at 0xffffffffffffffff [0x0002]. >> BAR2: I/O at 0xffffffffffffffff [0x0006]. >> BAR3: I/O at 0xffffffffffffffff [0x0002]. >> BAR4: I/O at 0xffffffffffffffff [0x000e]. >> id "" > > The BARs are not initialized, so they aren't accessible. > > But perhaps the dump was not taken at the point of failure, can you > provide a relevant dump if so?
No, this is after failure. > > -- > error compiling committee.c: too many arguments to function >
