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? -- error compiling committee.c: too many arguments to function
