[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
- [Qemu-devel] [PATCHv2] macio: handle non-block ATAPI DMA transfers the same as block DMA transfers, Mark Cave-Ayland, 2015/08/01
- Re: [Qemu-devel] [PATCHv2] macio: handle non-block ATAPI DMA transfers the same as block DMA transfers, Aurelien Jarno, 2015/08/01
- Re: [Qemu-devel] [PATCHv2] macio: handle non-block ATAPI DMA transfers the same as block DMA transfers, Mark Cave-Ayland, 2015/08/01
- Re: [Qemu-devel] [PATCHv2] macio: handle non-block ATAPI DMA transfers the same as block DMA transfers,
John Snow <=
- Re: [Qemu-devel] [PATCHv2] macio: handle non-block ATAPI DMA transfers the same as block DMA transfers, Mark Cave-Ayland, 2015/08/13
- Re: [Qemu-devel] [PATCHv2] macio: handle non-block ATAPI DMA transfers the same as block DMA transfers, John Snow, 2015/08/13
- Re: [Qemu-devel] [PATCHv2] macio: handle non-block ATAPI DMA transfers the same as block DMA transfers, Aurelien Jarno, 2015/08/18
- Re: [Qemu-devel] [PATCHv2] macio: handle non-block ATAPI DMA transfers the same as block DMA transfers, John Snow, 2015/08/21
- Re: [Qemu-devel] [PATCHv2] macio: handle non-block ATAPI DMA transfers the same as block DMA transfers, Mark Cave-Ayland, 2015/08/21
- Re: [Qemu-devel] [PATCHv2] macio: handle non-block ATAPI DMA transfers the same as block DMA transfers, John Snow, 2015/08/24