qemu-ppc
[Top][All Lists]
Advanced

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

Re: [Qemu-ppc] Tests with the latest ppc repo


From: Programmingkid
Subject: Re: [Qemu-ppc] Tests with the latest ppc repo
Date: Mon, 12 Jan 2015 18:45:30 -0500

On Jan 12, 2015, at 2:41 PM, Mark Cave-Ayland wrote:

> On 11/01/15 21:25, Programmingkid wrote:
> 
>> I used this repo for my tests:  git://github.com/agraf/qemu.git 
>> tags/signed-ppc-for-upstream. 
>> 
>> The results of the tests: 
>> Mac OS 10.2 install cd doesn't boot. It prints "Still waiting for root 
>> device". 
>> Mac OS 10.3 boots up. 
>> Mac OS 10.4 boots up. 
>> 
>> This is the command I used for testing:
>> qemu-system-ppc -cdrom ~/jaguariso -boot d -prom-env boot-args=-v
>> 
>> Jaguar is very picky about the location of the cd-rom drive. I'm guessing it 
>> was changed. 
> 
> I've had some ongoing regression issues with my Darwin ISO tests for
> which I've sent some further information through to Alex off-list. There
> seems to be 2 distinct failures I can see here:
> 
> 
> 1) The fix I posted for MorphOS seems to introduce random boot failures
> here:
> http://git.qemu.org/?p=qemu.git;a=commitdiff;h=85720d36676ef0b765a69f1e312b4c9d4ff6fa16.
> 
> Can you see if surrounding the new code in the above commit with a #if 0
> ... #endif block gets things working for 10.2 again? I do have an
> alpha-quality patch refactoring of the macio code which fixes this bug
> for me, but held off on finishing the patch because of discovering the
> second issue below.

Disabling the code did make Mac OS 10.2 boot again. 


> 2) The fix for mixing synchronous and asynchronous requests in the macio
> code corrupts a fresh install of my Darwin test ISO when running through
> the complete installation:
> http://git.qemu.org/?p=qemu.git;a=commitdiff;h=3e300fa6ad4ee19b16339c25773dec8df0bfb982
> 
> So far I don't see anything obvious with the above commit except that
> the multi-write combining seems to be more aggressive afterwards. I'm
> wondering whether or not the synchronous requests for the unaligned
> accesses had a side effect of introducing read/write barriers which have
> now been removed?

I wish I could help, but I don't know very much about that kind of stuff. 

> 
> 
> I can provide an easy, although annoyingly time-consuming test case if
> either Kevin or Stefan (added to CC) are able to help point me in the
> right direction as to how to go about debugging this?
> 
> 
> ATB,
> 
> Mark.
> 




reply via email to

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