[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 21:09:38 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10

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.



reply via email to

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