qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCHv2] macio: handle non-block ATAPI DMA transfers t


From: John Snow
Subject: Re: [Qemu-devel] [PATCHv2] macio: handle non-block ATAPI DMA transfers the same as block DMA transfers
Date: Mon, 03 Aug 2015 13:01:00 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0


On 08/01/2015 02:54 PM, Mark Cave-Ayland wrote:
> On 01/08/15 19:33, Aurelien Jarno wrote:
> 
>> On 2015-08-01 17:54, Mark Cave-Ayland wrote:
>>> The existing code incorrectly changes the dma_active flag when a non-block
>>> transfer has completed leading to a hang on newer versions of Linux because 
>>> the
>>> IDE and DMA engines deadlock waiting for each other.
>>>
>>> Instead copy the buffer directly to RAM, set the remaining transfer size to 
>>> 0 and
>>> then invoke the ATAPI callback manually once again to correctly finish the
>>> transfer in an identical manner to a block transfer.
>>>
>>> Signed-off-by: Mark Cave-Ayland <address@hidden>
>>> ---
>>
>> Thanks for the patch, it improves things here. I don't get messages
>> anymore, and I get less messages when mounting the CD-ROM, though I
>> still get one:
>>
>>   [  307.258463] pata-macio 0.00021000:ata-4: timeout flushing DMA
>>   [  307.262856] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
>>   [  307.262919] ata2.00: BMDMA stat 0x6
>>   [  307.263048] sr 1:0:0:0: CDB: Get configuration: 46 00 00 28 00 00 00 00 
>> 10 00
>>   [  307.263289] ata2.00: cmd a0/01:00:00:10:00/00:00:00:00:00/a0 tag 0 dma 
>> 16400 in
>>   [  307.263297]          res 41/50:03:00:10:00/00:00:00:00:00/a0 Emask 0x20 
>> (host bus error)
>>   [  307.263407] ata2.00: status: { DRDY ERR }
>>   [  307.271251] ata2.00: configured for MWDMA2
>>   [  307.271824] ata2: EH complete
>>
>> The CD-ROM is fully functional though.
> 
> Hmmmm yes I can recreate that here - must be another transition between
> the non-block and the block transfer code (I was working on eliminating
> the boot messages) caused by reading the disc metadata upon mount.
> Unfortunately I don't have much time to work on this right now so maybe
> it's a 2.4.1/2.5 thing unless John can take a look?
> 
> 
> ATB,
> 
> Mark.
> 

Definitely a 2.4.1/2.5 thing anyway at this time. If you prepare a v3 to
nail down the last state transition error message you're seeing, just CC
stable as well, and I'll handle it for 2.5.

--js



reply via email to

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