Re: [PATCH] libata: Disable ATA_CMD_READ_LOG_DMA_EXT in problematic cases.

From: Damien Le Moal <Damien.LeMoal@wdc.com>
To: "Reimar Döffinger" <Reimar.Doeffinger@gmx.de>
Cc: "linux-ide@vger.kernel.org" <linux-ide@vger.kernel.org>,
	Jens Axboe <axboe@kernel.dk>,
	"hch@infradead.org" <hch@infradead.org>
Subject: Re: [PATCH] libata: Disable ATA_CMD_READ_LOG_DMA_EXT in problematic cases.
Date: Tue, 17 Aug 2021 07:45:58 +0000	[thread overview]
Message-ID: <DM6PR04MB708170BD5DC19ABC03FDC4A3E7FE9@DM6PR04MB7081.namprd04.prod.outlook.com> (raw)
In-Reply-To: YRqfxrWJsIeyjFed@reimardoeffinger.de

On 2021/08/17 2:26, Reimar Döffinger wrote:
> On Mon, Aug 16, 2021 at 12:10:28AM +0000, Damien Le Moal wrote:
>>> +	/* Do not even attempt DMA with PATA-SATA adapters, they seem likely to
>>> +	 * hang, see https://bugzilla.kernel.org/show_bug.cgi?id=195895
>>> +	 */
>>
>> This is not the standard kernel comment style. Multi-lines comment should start
>> with a "/*" line:
> 
> Fixed, somehow I thought I had followed the surrounding style, I was
> wrong.
> 
>> Also, I would remove the bugzilla reference since it is in the commit message.
> 
> Done, though long-term the commit message might be harder to find than
> the comment...

Yes, but long-term, web links tend to go stale too :)

> 
>>>  	if (dev->dma_mode && ata_id_has_read_log_dma_ext(dev->id) &&
>>> +	    (ap_flags & ATA_FLAG_SATA) &&
>>
>> Why is this necessary since you have the ATA_HORKAGE_NO_DMA_LOG flag ?
> 
> Not sure I understand the question right.

I was referring to the added condition "&& (ap_flags & ATA_FLAG_SATA)".
If the port has this flag, then setting the ATA_HORKAGE_NO_DMA_LOG for the
device before coming here would not require this additional condition.

> The patch is a best-guess + "in doubt disable" attempt at
> auto-detecting.
> As I mentioned the data is rather light, so I wanted to only add the
> option at first.
> Now it does 2 things in addition:
> - disable it for Crucial MX500 because the issue was seen and confirmed
>   with and without PATA converter with that device
> - disable it for anything connected with a PATA converter because there
>   are lots of bug reports with different devices that have a PATA
>   converter in common. Unfortunately no confirmation from any of those.
>   However in quick testing I could verify the MX500 issue only with
>   PATA adapter myself, so it seems like an appropriate precaution,
>   especially as now with the new code it is possible to override both
>   ways.

How can you detect the presence of a PATA converter ? Is it what "ap_flags &
ATA_FLAG_SATA" indicates ?

> 
> (should I put something more in the commit message? I didn't want to
> bloat it too much)
> 
> Aside: I don't have the ATA spec, so I can't check, but I do find it
> a bit suspicious that the logs look like the code runs the
> READ_LOG_DMA command before SETXFERMODE is done, and thus while the
> device is still in PIO mode?

ata_read_log_page() has a retry loop: it first tries ATA_CMD_READ_LOG_DMA_EXT
and if that fails, it goes with PIO ATA_CMD_READ_LOG_EXT. So there is no problem
for non-buggy drives with this. Note that initially, dev->dma_mode may not be
set, so PIO is done directly. Once set, DMA version will be used unless the
horkage bit is set. So this all works as expected, and there will (normally) be
no failed command even when DMA is not yet set.

> 
>> If this is really necessary, ATA_HORKAGE_NO_DMA_LOG should be set for all
>> devices that have ATA_FLAG_SATA when the device is initialized. With that, this
>> additional condition can go away.
> 
> I missed the right place to do that before, I think I now found it, so
> moved.
> 
> Thanks for the review,
> Reimar
> 

-- 
Damien Le Moal
Western Digital Research