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

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

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.