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

[Mark Cave-Ayland]

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.