From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43006) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wks2o-00044J-MW for qemu-devel@nongnu.org; Thu, 15 May 2014 05:33:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wks2h-0003oV-74 for qemu-devel@nongnu.org; Thu, 15 May 2014 05:33:42 -0400 Message-ID: <53748952.9080909@ilande.co.uk> Date: Thu, 15 May 2014 10:30:58 +0100 From: Mark Cave-Ayland MIME-Version: 1.0 References: <5366CA94.3030803@ilande.co.uk> <536A328F.6070100@ilande.co.uk> <536A6F3C.1030708@ilande.co.uk> <5370F620.7050206@ilande.co.uk> <5371303F.1060903@ilande.co.uk> <5372F741.9080108@ilande.co.uk> <5373CD82.6000407@ilande.co.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Qemu-ppc] macio ide question/bug report List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: BALATON Zoltan Cc: qemu-ppc@nongnu.org, Alexander Graf , qemu-devel@nongnu.org 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.