[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: Fri, 16 May 2014 12:22:26 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.5.0

On 15/05/14 21:28, BALATON Zoltan wrote:

On Thu, 15 May 2014, BALATON Zoltan wrote:
On Thu, 15 May 2014, BALATON Zoltan wrote:
confusing.) Do you think that replacing io->len in your patch with
s->io_buffer_size would be the correct thing to do?

That looks reasonable, as the MIN() will help prevent excessive memory clobber.

Probably that's not enough. I've tried it and then it gets to here:

I should've also included these lines too to make it more clear what did
I change:

Yes, this is definitely helpful. It appears that cmd_read_toc_pma_atip() returns 0x20 bytes of data (can you confirm this?), while the DMA engine is configured to transfer 0x324 bytes of data - perhaps this is the maximum possible size of a TOC?. So the existing code determines there are still 0x324 - 0x20 = 0x304 bytes remaining for the DMA request and falls into the unaligned code which is definitely not what we want.

Perhaps we need to assume for a non-IO DMA request that the result will only be a single ATAPI reply packet? Attached is another version of the patch for you to experiment with which makes your s->io_buffer_size change but also moves the logic into pmac_ide_transfer() so that we don't inadvertently drop into the unaligned code.



Attachment: qemu-macio-atapi-v2.patch
Description: Text Data

reply via email to

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