Re: [Qemu-devel] [Qemu-ppc] macio ide question/bug report

[Mark Cave-Ayland]

On 15/05/14 00:21, BALATON Zoltan wrote:

> > Which part is it that's still confusing you? Putting breakpoints on
> > pmac_ide_transfer() and pmac_ide_atapi_transfer_cb() will show you the
> > iterations on each DMA request (be sure to compare against a "known
> > good" example to understand how it should work first). If you can give
> > more detail as to which bits are confusing, I will try my best to
> > explain them.
>
> Looking at the backtrace:
>
> #0  ide_atapi_cmd_error (s=0x5555563cb238, sense_key=5, asc=33)
>      at hw/ide/atapi.c:141
> #1  0x00005555556cecf5 in ide_atapi_io_error (s=0x5555563cb238, ret=-5)
>      at hw/ide/atapi.c:160
> #2  0x00005555556d9d01 in pmac_ide_atapi_transfer_cb
> (opaque=0x5555563ccc68,
>      ret=-5) at hw/ide/macio.c:64
> #3  0x00005555556780d2 in dma_complete (dbs=0x5555563ab840, ret=-5)
>      at dma-helpers.c:121
> #4  0x00005555556781db in dma_bdrv_cb (opaque=0x5555563ab840, ret=-5)
>      at dma-helpers.c:149
> #5  0x0000555555614dd1 in bdrv_co_em_bh (opaque=0x5555563b5000) at
> block.c:4602
> #6  0x00005555555f8170 in aio_bh_poll (ctx=0x55555637fc00) at async.c:81
> #7  0x00005555555f7dc9 in aio_poll (ctx=0x55555637fc00, blocking=false)
>      at aio-posix.c:188
> #8  0x00005555555f8587 in aio_ctx_dispatch (source=0x55555637fc00,
> callback=
>      0x0, user_data=0x0) at async.c:205
> #9  0x00007ffff78ca6d5 in g_main_context_dispatch ()
>     from /lib64/libglib-2.0.so.0
> #10 0x00005555557a0f42 in glib_pollfds_poll () at main-loop.c:190
> #11 0x00005555557a1042 in os_host_main_loop_wait (timeout=0) at
> main-loop.c:235
> #12 0x00005555557a1115 in main_loop_wait (nonblocking=1) at main-loop.c:484
> #13 0x0000555555844190 in main_loop () at vl.c:2075
> #14 0x000055555584bc23 in main (argc=30, argv=0x7fffffffdc88, envp=
>      0x7fffffffdd80) at vl.c:4556
>
> shows that pmac_ide_atapi_transfer_cb is called with ret=-5 which is why
> it fails, so putting a breakpoint there is too late. What I don't
> understand is where this -5 value comes from. I don't have a known good
> example because Darwin reads the TOC differently (probably before
> enabling DMA, I did not trace it more than the logs I've included
> earlier though) and MorphOS always fails.

Have you noticed that the dma_bdrv_*() functions use a function pointer 
to pmac_ide_atapi_transfer_cb() as their callback function? The 
dma_bdrv_*() functions operate in a separate thread and then invoke the 
callback function when finished.

The breakpoint you are hitting above is the invocation of 
pmac_ide_atapi_transfer_cb() as a result of the callback *after* the 
command has already failed, and not the invocation of 
pmac_ide_atapi_transfer_cb() which calls dma_bdrv_*() to setup the 
asynchronous transfer. Hence the DMA has already failed and the -5 value 
is being returned from the IDE code. I can only guess the reason this 
works with Darwin is because it is a non-DMA request.

If you place a breakpoint on pmac_ide_transfer() then its invocation of 
pmac_ide_atapi_transfer_cb() should be the first iteration which sets up 
the DMA request, and the second invocation should be the (failing) 
callback from the dma_bdrv_*() functions. But as I mentioned before, I 
think the problem is that these functions shouldn't be called in the 
first place when requesting a TOC.


HTH,

Mark.