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

[Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>]

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.