From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43662) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WkfXQ-0001vb-TZ for qemu-devel@nongnu.org; Wed, 14 May 2014 16:12:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WkfXI-0005lk-O3 for qemu-devel@nongnu.org; Wed, 14 May 2014 16:12:28 -0400 Message-ID: <5373CD82.6000407@ilande.co.uk> Date: Wed, 14 May 2014 21:09:38 +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> 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 14/05/14 12:10, BALATON Zoltan wrote: >>> I've tried doing this and it seems that the cmd_read_toc_pma_atip >>> function returns all right (via the case 0 path) with a 20 byte result >>> array and calls ide_atapi_cmd_reply which takes the DMA path as >>> s->atapi_dma is set to 1 and the error comes from somewhere during >>> trying to DMA the result back to the client. I could not follow it so >>> I've only got a backtrace from where ide_atapi_cmd_error is called: >> >> So this basically confirms that the DMA errors out because s->lba == >> -1 in the macio callback. FWIW you should probably ensure that >> DEBUG_IDE_ATAPI is enabled when posting logs in future as this helps >> show the interaction between the two systems. > > The logs I've posted are with DEBUG_IDE_ATAPI, DEBUG_DBDMA and > DEBUG_MACIO already enabled... Well sure, but not the ones in your last email - I had to go back several mails back into the thread to pull them out. Bear in mind the high volume of these lists means that a lot of people who could help won't have the time to do this. >>> Do you have any idea how to debug this further or does this help to tell >>> where is the problem? (I think the question is where does the -5 return >>> value come from?) >> >> Well from this the cause is fairly easy to spot: ide_atapi_cmd_reply() >> sets s->lba == -1 when called from cmd_read_toc_pma_atip(). And since >> as you correctly point out this is a DMA request, it invokes the >> start_dma function in macio's dbdma_ops (ide_dbdma_start), which kicks >> the DBDMA engine into life. >> >> I think the issue here is related to the fact that reading a TOC >> doesn't actually involve reading physical blocks from disk (as the TOC >> is placed directly in the buffer) and so the dma_bdrv_* functions >> shouldn't actually be invoked in the first place. And because of the >> DBDMA setup, ide_atapi_cmd_read_dma_cb() can't be used which is why >> pmac_ide_transfer_cb() needs to do a lot of similar work itself. Maybe >> you can find some clues there as to what the logic should be? > > I'm afraid I still can't understand it. Is there a way to trace the path > after DBDMA engine is kicked? Where should I break to get some insight > on what is happening? (Maybe it's a dbdma bug not a macio one.) 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. ATB, Mark.