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

[Kevin Wolf]

Am 12.01.2015 um 20:41 hat Mark Cave-Ayland geschrieben:
> 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.
> 
> 
> 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

First of all, the commits message says:

    However, the block infrastructure changed below our feet and now
    it's impossible to call a synchronous block read/write from the aio
    callback handler of a previous block access.

That's news for me. If it's true, this is probably not intentional at
all and block layer code should have been fixed instead.

What kind of failure do you get when you try such a call?

> So far I don't see anything obvious with the above commit except that
> the multi-write combining seems to be more aggressive afterwards.

Maybe I'm missing something, but I don't see any combining in this code?

> 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?

Let's start a bit simpler: While a request is running, its iov is in
use. pmac_ide_transfer_cb() seems to issue an AIO request and
immediately continue working on the same iov. I wouldn't be surprised if
some internal data structures in the macio driver weren't made for
multiple requests at the same time either.

The usual pattern is that after issuing an AIO command, you return, and
only continue what you were doing in its callback.

That said, you have so many operations in pmac_ide_transfer_cb() using
the function recursively as their callback that I find it really hard to
read by now. Perhaps it would benefit from a conversion to coroutines,
which would make the code linear again.

> 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?

I'm not familiar enough with the controller to help in debugging it, but
as long as we know which one is the faulty patch, we can probably solve
this by code review.

Kevin