[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: Wed, 14 May 2014 05:55:29 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10

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?



reply via email to

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