From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40342) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WkRGz-000257-2j for qemu-devel@nongnu.org; Wed, 14 May 2014 00:58:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WkRGr-0005X1-EI for qemu-devel@nongnu.org; Wed, 14 May 2014 00:58:33 -0400 Message-ID: <5372F741.9080108@ilande.co.uk> Date: Wed, 14 May 2014 05:55:29 +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> 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 00:02, BALATON Zoltan wrote: >> command 0x43 is read the TOC which according to atapi_cmd_table should >> call cmd_read_toc_pma_atip(). You can see that in your MorphOS case >> you are getting a line with a "atapi_cmd_error" prefix which indicates >> that something is calling ide_atapi_cmd_error() to return an error >> code instead of ide_atapi_cmd_reply() which would output the "reply" >> prefix as seen in your Darwin case. So you need to step through these >> functions in QEMU in order to see why your ATAPI command is failing. > > 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. > 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? HTH, Mark.