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 http://git.qemu.org/?p=qemu.git;a=commitdiff;h=98ae3b27d57b59c6dc9a74e6351e339523c16def. 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 :) ATB, Mark.