qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE


From: Blue Swirl
Subject: Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE
Date: Sun, 4 Mar 2012 12:38:34 +0000

On Sun, Mar 4, 2012 at 12:28, Avi Kivity <address@hidden> wrote:
> On 03/04/2012 12:27 PM, Blue Swirl wrote:
>> On Sun, Mar 4, 2012 at 09:46, Michael S. Tsirkin <address@hidden> 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 <address@hidden>
>> > Signed-off-by: Michael S. Tsirkin <address@hidden>
>> >
>> > 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
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]