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

[Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>]

[-- Attachment #1: Type: text/plain, Size: 4891 bytes --]

On 15/05/14 18:28, BALATON Zoltan wrote:

>> 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.
>
> OK, I've done that and stopped at the first invocation of
> pmac_ide_atapi_transfer_cb. Here is a backtrace and the contents of some
> data structures:
>
> #0  pmac_ide_atapi_transfer_cb (opaque=0x5555563ccc68, ret=0)
>      at hw/ide/macio.c:55
> #1  0x00005555556da6d0 in pmac_ide_transfer (io=0x5555563ccc68)
>      at hw/ide/macio.c:225
> #2  0x00005555556eeee2 in start_input (ch=0x5555563ccc18, key=0, addr=
>      14777932, req_count=804, is_last=1) at hw/misc/macio/mac_dbdma.c:334
> #3  0x00005555556ef444 in channel_run (ch=0x5555563ccc18)
>      at hw/misc/macio/mac_dbdma.c:489
> #4  0x00005555556ef599 in DBDMA_run (s=0x5555563cba40)
>      at hw/misc/macio/mac_dbdma.c:531
> #5  0x00005555556ef5f4 in DBDMA_run_bh (opaque=0x5555563cba40)
>      at hw/misc/macio/mac_dbdma.c:542
> #6  0x00005555555f8200 in aio_bh_poll (ctx=0x55555637fc00) at async.c:81
> #7  0x00005555555f7e59 in aio_poll (ctx=0x55555637fc00, blocking=false)
>      at aio-posix.c:188
> #8  0x00005555555f8617 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 0x00005555557a0fde in glib_pollfds_poll () at main-loop.c:190
> #11 0x00005555557a10de in os_host_main_loop_wait (timeout=15883632)
>      at main-loop.c:235
> #12 0x00005555557a11b1 in main_loop_wait (nonblocking=0) at main-loop.c:484
> #13 0x000055555584422c in main_loop () at vl.c:2075
> #14 0x000055555584bcbf in main (argc=32, argv=0x7fffffffdc48, envp=
>      0x7fffffffdd50) at vl.c:4556

(lots cut)

So that looks like the correct request based upon it's size so what 
happened when you stepped into pmac_ide_atapi_transfer_cb()...?

> My testing was done with commit 80fc95d8bdaf3392106b131a97ca701fd374489a
> already reverted as that was established before that it is not needed
> any more which simplifies pmac_ide_atapi_transfer_cb() quite a bit

Sadly I've now found that this isn't the case (email to the qemu-devel 
list to follow, but I've run out of time today) :(

> but I
> still can't understand the flow of this function and don't see where
> should I add a condition to handle this lba=-1 case that happens with
> READ_TOC using DMA. The reason I don't understand it is that the
> different fields (sizes and indexes) in these structures that are used
> in this callback don't make sense to me and I don't know how to use
> cpu_physical_memory_write() to copy data from the ide buffer to the
> guest memory as was suggested by Mark. Now that the problem is fairly
> well understood, wouldn't it be easier to one of you who understands
> what's happening to create a patch, instead of trying to explain all
> this to me?

Well my understanding is that it's impossible to boot a MorphOS image 
directly and requires all sorts of tricks with debuggers etc. Unless you 
can provide a "run this and it breaks" test case, then the time barrier 
for trying to fix bugs like this is exceptionally high.

You mention that you don't understand the fields and sizes, so explain 
which ones you don't understand and ask. Search around for guides to how 
ATAPI/IDE works, and compare with gdb output to find the correlation 
with the IDEState variables. Have you tried looking at the header file 
for cpu_physical_memory_write()? Even to someone who had never seen this 
function before Alex's patches, it seems fairly obvious how the API 
should work.

I'm afraid that there really is no alternative to spending the time 
getting stuck into the code, experimenting, adding printf()'s in 
exciting places, and then asking specific questions to the mailing list.

> This part was last touched by Alexander Graf so I assume he knows how it
> works and it would not be too hard for him to fix it. I'm happy to help
> testing and providing more debugging info as needed but I'm not sure I
> want to detangle it and figure out the whole block layer and DBDMA
> without any documentation to be able to fix it myself. Would it be
> possible to find some time for it in the foreseeable future? (That might
> still be sooner than me wrapping my head around it.)

Please see above. FWIW based upon the your gdb output I've put together 
the following patch which compiles, but that's all I can vouch for it. 
Further testing and debugging will have to be done by you, although I 
will try and respond to specific questions where possible.


ATB,

Mark.


[-- Attachment #2: qemu-macio-atapi.patch --]
[-- Type: text/x-diff, Size: 716 bytes --]

diff --git a/hw/ide/macio.c b/hw/ide/macio.c
index da94580..96c2556 100644
--- a/hw/ide/macio.c
+++ b/hw/ide/macio.c
@@ -111,6 +111,14 @@ static void pmac_ide_atapi_transfer_cb(void *opaque, int ret)
         return;
     }
 
+    if (s->packet_transfer_size && s->lba == -1) {
+        MACIO_DPRINTF("non-IO ATAPI DMA transfer size: %d\n", io->len);
+        /* Copy ATAPI buffer directly to RAM and finish */
+        cpu_physical_memory_write(io->addr, s->io_buffer, io->len);
+        s->packet_transfer_size -= io->len;
+        MACIO_DPRINTF("end of non-IO ATAPI DMA transfer\n");    
+    }
+    
     if (!s->packet_transfer_size) {
         MACIO_DPRINTF("end of transfer\n");
         ide_atapi_cmd_ok(s);