Re: [PATCH v2 2/2] ata: libata-core: Disable READ LOG DMA EXT for Samsung 840 EVOs

[Damien Le Moal <damien.lemoal@opensource.wdc.com>]

On 2022/03/20 5:31, Reimar Döffinger wrote:
> 
> 
>> On 19 Mar 2022, at 21:11, Christian Lamparter <chunkeey@gmail.com> wrote:
>> 
>> Samsung' 840 EVO with the latest firmware (EXT0DB6Q) locks up with the a
>> message: "READ LOG DMA EXT failed, trying PIO" during boot.
> 
> I don't see any info on which kernel this happened with anywhere. Because
> there was a bug that tried to use READ LOG DMA EXT even though DMA was not
> enabled. That was fixed by a patch from me for 5.16 (and backports). The
> behaviour you describe matches the possible symptoms of that bug. So it would
> be good to know we're not blaming the drive for an already fixed bug in the
> kernel... (I am still seeing some issues that READ LOG EXT - the non-DMA
> version - times out with interrupt lost for some device/controller
> combinations, but at least that "only" adds an extra 15 seconds to the boot.
> It's still a bit silly because in combination with e.g. IDE controllers READ
> LOG provides absolutely no useful functionality as far as I can tell).

Yes, the added 15s is a longer timeout to wait for READ LOG EXT reply on resume.
Some drives are slow to respond and that was causing drives to disapear on
resume. I agree that for old IDE/PATA drive, we could disable READ LOG [DMA[ EXT
entirely as all the information for the drive can be found in the IDENTIFY data.
So no point. All the pata drivers could set the nolog horkage. There are still
many more recent drives that have weird behavior with read log though. This is a
pain to sort out and can be done only if a bug report is filed.

I am preparing a series to improve the libata.force boot parameter to allow
setting any horkage/link flag to disable things for drives that do not behave
nicely. That will allow users to tune systems without having to wait for the
kernel to be patched.

> 
> Best regards, Reimar


-- 
Damien Le Moal
Western Digital Research