[Top][All Lists]

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

Re: [Qemu-devel] [Qemu-ppc] [PATCH 01/10] ppc: Fix rfi/rfid/hrfi/... emu

From: Mark Cave-Ayland
Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH 01/10] ppc: Fix rfi/rfid/hrfi/... emulation
Date: Tue, 21 Jun 2016 09:21:40 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.8.0

On 20/06/16 10:32, Benjamin Herrenschmidt wrote:

> On Mon, 2016-06-20 at 18:02 +1000, Benjamin Herrenschmidt wrote:
>> On Mon, 2016-06-20 at 17:08 +1000, Benjamin Herrenschmidt wrote:
>>> That fixed, it dies elsewhere in something related to page faults,
>>> still digging.
>> Next problem: Darwin kernel assumes DSISR is 0 on a 0x380 exception !
>> qemu was leaving it to whatever value it had before. Kaboom.
>> Now it crashes a bit further :-)
> Right so it tries to load a MacRISC2 PE because we don't really emulate
> a MacRISC4 with U3 etc... and that isn't going to do it any good,
> really..
> I'm not *actually* sure where MacOS gets itself into a spin, it seems
> to be poking at something at 0xf280_0000 which is somewhat odd as this
> would be the IO space and we have nothing there afaik, but I am not
> enough of a MacOS expert to figure out quite how to track down which
> kext it gets into etc...
> In any case, the machine we give it is definitely nowhere near a real
> G5 and that might be the main reason. More work needed.

A quick check with "info mtree" shows that this area of memory is PCI
configuration space. There was a patch added to uninorth in order to
suppress some PCI warnings on Darwin boot found by going over the source
to the Darwin MacRISC driver which resulted in the patch at
Maybe it could be related to that?

> I'll still cleanup & submit my current crop of fixes in case somebody
> wants to have a look.

Not sure I can help much here, however I can give everything a good test
and make sure that it doesn't break :)



reply via email to

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