[Top][All Lists]

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

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

From: Mark Cave-Ayland
Subject: Re: [Qemu-devel] [Qemu-ppc] macio ide question/bug report
Date: Thu, 15 May 2014 20:22:34 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.5.0

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,
     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.



Attachment: qemu-macio-atapi.patch
Description: Text Data

reply via email to

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