qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] SPARC64: unable to boot OpenBIOS from git master


From: Blue Swirl
Subject: Re: [Qemu-devel] SPARC64: unable to boot OpenBIOS from git master
Date: Sat, 3 Mar 2012 15:09:16 +0000

On Mon, Feb 27, 2012 at 06:36, Mark Cave-Ayland
<address@hidden> wrote:
> Hi all,
>
> I've been experimenting with SPARC64 under QEMU, and with current git master
> I am unable to boot OpenBIOS at all with the following error:
>
> OpenBIOS for Sparc64
> Unhandled Exception 0x0000000000000032
> PC = 0x00000000ffd19d84 NPC = 0x00000000ffd19d88
> Stopping execution
>
> Using git bisect indicates that the problem lies with the following commit:
>
>
> commit d5f27e88699f14c802d66c01de70e5ea37b7153a
> Author: Michael S. Tsirkin <address@hidden>
> Date:   Tue Feb 21 15:57:58 2012 +0200
>
>    pci: set memory type for memory behind the bridge
>
>    As we make upper bits in IO and prefetcheable memory
>    registers writeable, we should declare support
>    for 64 bit prefetcheable memory and 32 bit io
>    in the bridge.
>
>    This changes the default for apb, dec, but I'm guessing
>    they got the defaults wrong by accident.
>    Alternatively, we could let bridges declare lack of
>    64 bit support and make the upper bits read-only zero.
>
>    With this applied, we can drop these bits
>    from express code.
>
>    Reported-by: Gerd Hoffmann <address@hidden>
>    Signed-off-by: Michael S. Tsirkin <address@hidden>
>
>    Could someone familiar with apb,dec ack this please?
>    Signed-off-by: Anthony Liguori <address@hidden>
>
>
> Does anyone have an idea as to whether this is something that needs to be
> fixed in QEMU or OpenBIOS?

No idea. Michael, should the commit be reverted?

It's easy to confirm the bug, just run qemu-system-sparc64 without any
arguments. Bug: black screen, no bug: yellow screen with OpenBIOS boot
text.

In fact, it's pretty annoying to see that even this very minimal
amount of testing effort has not been spent by a critical subsystem
maintainer.

>
> Many thanks,
>
> Mark.
>



reply via email to

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