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

[BALATON Zoltan]

On Wed, 14 May 2014, Mark Cave-Ayland wrote:
> 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.

The logs I've posted are with DEBUG_IDE_ATAPI, DEBUG_DBDMA and DEBUG_MACIO 
already enabled...

> > 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.)

Regards,
BALATON Zoltan