[PATCH] libata: add horkage for M88V29

[PATCH] libata: add horkage for M88V29

[zboszor]

From: Zoltán Böszörményi <zboszor@gmail.com>

This device is a CF card, or possibly an SSD in CF form factor.
It supports NCQ and high speed DMA.

While it also advertises TRIM support, I/O errors are reported
when the discard mount option fstrim is used. TRIM also fails
when disabling NCQ and not just as an NCQ command.

TRIM must be disabled for this device.

Signed-off-by: Zoltán Böszörményi <zboszor@gmail.com>
---
 drivers/ata/libata-core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 67f88027680a..4a7f58fcc411 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -4028,6 +4028,7 @@ static const struct ata_blacklist_entry ata_device_blacklist [] = {
 
 	/* devices that don't properly handle TRIM commands */
 	{ "SuperSSpeed S238*",		NULL,	ATA_HORKAGE_NOTRIM, },
+	{ "M88V29*",			NULL,	ATA_HORKAGE_NOTRIM, },
 
 	/*
 	 * As defined, the DRAT (Deterministic Read After Trim) and RZAT
-- 
2.34.1

Re: [PATCH] libata: add horkage for M88V29

[Damien Le Moal]

On 2/4/22 21:57, zboszor@pr.hu wrote:
> From: Zoltán Böszörményi <zboszor@gmail.com>
> 
> This device is a CF card, or possibly an SSD in CF form factor.
> It supports NCQ and high speed DMA.
> 
> While it also advertises TRIM support, I/O errors are reported
> when the discard mount option fstrim is used. TRIM also fails
> when disabling NCQ and not just as an NCQ command.
> 
> TRIM must be disabled for this device.
> 
> Signed-off-by: Zoltán Böszörményi <zboszor@gmail.com>
> ---
>  drivers/ata/libata-core.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
> index 67f88027680a..4a7f58fcc411 100644
> --- a/drivers/ata/libata-core.c
> +++ b/drivers/ata/libata-core.c
> @@ -4028,6 +4028,7 @@ static const struct ata_blacklist_entry ata_device_blacklist [] = {
>  
>  	/* devices that don't properly handle TRIM commands */
>  	{ "SuperSSpeed S238*",		NULL,	ATA_HORKAGE_NOTRIM, },
> +	{ "M88V29*",			NULL,	ATA_HORKAGE_NOTRIM, },
>  
>  	/*
>  	 * As defined, the DRAT (Deterministic Read After Trim) and RZAT

Applied to for-5.17-fixes. Thanks !

-- 
Damien Le Moal
Western Digital Research

Re: [PATCH] libata: add horkage for M88V29

[Böszörményi Zoltán]

2022. 02. 08. 9:07 keltezéssel, Damien Le Moal írta:
> On 2/4/22 21:57, zboszor@pr.hu wrote:
>> From: Zoltán Böszörményi <zboszor@gmail.com>
>>
>> This device is a CF card, or possibly an SSD in CF form factor.
>> It supports NCQ and high speed DMA.
>>
>> While it also advertises TRIM support, I/O errors are reported
>> when the discard mount option fstrim is used. TRIM also fails
>> when disabling NCQ and not just as an NCQ command.
>>
>> TRIM must be disabled for this device.
>>
>> Signed-off-by: Zoltán Böszörményi <zboszor@gmail.com>
>> ---
>>   drivers/ata/libata-core.c | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
>> index 67f88027680a..4a7f58fcc411 100644
>> --- a/drivers/ata/libata-core.c
>> +++ b/drivers/ata/libata-core.c
>> @@ -4028,6 +4028,7 @@ static const struct ata_blacklist_entry ata_device_blacklist [] = {
>>   
>>   	/* devices that don't properly handle TRIM commands */
>>   	{ "SuperSSpeed S238*",		NULL,	ATA_HORKAGE_NOTRIM, },
>> +	{ "M88V29*",			NULL,	ATA_HORKAGE_NOTRIM, },
>>   
>>   	/*
>>   	 * As defined, the DRAT (Deterministic Read After Trim) and RZAT
> Applied to for-5.17-fixes. Thanks !

Thank you. However, I have second thoughts about this patch.
The device advertises this:

# hdparm -iI /dev/sda
...
  Enabled Supported
     *    Data Set Management TRIM supported (limit 1 block)
...

but the I/O failures always reported higher number of blocks,
IIRC the attempted number of block was 8 or so.

Can the kernel limit or split TRIM commands according to the
advertised limit? If not (or not yet) then the quirk is good for now.

Best regards,
Zoltán Böszörményi

Re: [PATCH] libata: add horkage for M88V29

[Böszörményi Zoltán]

2022. 06. 23. 9:47 keltezéssel, Böszörményi Zoltán írta:
> 2022. 02. 08. 9:07 keltezéssel, Damien Le Moal írta:
>> On 2/4/22 21:57, zboszor@pr.hu wrote:
>>> From: Zoltán Böszörményi <zboszor@gmail.com>
>>>
>>> This device is a CF card, or possibly an SSD in CF form factor.
>>> It supports NCQ and high speed DMA.
>>>
>>> While it also advertises TRIM support, I/O errors are reported
>>> when the discard mount option fstrim is used. TRIM also fails
>>> when disabling NCQ and not just as an NCQ command.
>>>
>>> TRIM must be disabled for this device.
>>>
>>> Signed-off-by: Zoltán Böszörményi <zboszor@gmail.com>
>>> ---
>>>   drivers/ata/libata-core.c | 1 +
>>>   1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
>>> index 67f88027680a..4a7f58fcc411 100644
>>> --- a/drivers/ata/libata-core.c
>>> +++ b/drivers/ata/libata-core.c
>>> @@ -4028,6 +4028,7 @@ static const struct ata_blacklist_entry ata_device_blacklist [] = {
>>>       /* devices that don't properly handle TRIM commands */
>>>       { "SuperSSpeed S238*",        NULL,    ATA_HORKAGE_NOTRIM, },
>>> +    { "M88V29*",            NULL,    ATA_HORKAGE_NOTRIM, },
>>>       /*
>>>        * As defined, the DRAT (Deterministic Read After Trim) and RZAT
>> Applied to for-5.17-fixes. Thanks !
> 
> Thank you. However, I have second thoughts about this patch.
> The device advertises this:
> 
> # hdparm -iI /dev/sda
> ...
>   Enabled Supported
>      *    Data Set Management TRIM supported (limit 1 block)
> ...

Here's the complete hdparm output:

/dev/sda:

  Model=M88V29 32GB, FwRev=181019i, SerialNo=20211023AA20A0656011
  Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
  RawCHS=16383/15/63, TrkSize=0, SectSize=0, ECCbytes=4
  BuffType=unknown, BuffSize=unknown, MaxMultSect=1, MultSect=off
  CurCHS=16383/15/63, CurSects=15481935, LBA=yes, LBAsects=62533296
  IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
  PIO modes:  pio0 pio1 pio2 pio3 pio4
  DMA modes:  mdma0 mdma1 mdma2
  UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5
  AdvancedPM=yes: unknown setting
  Drive conforms to: Unspecified:  ATA/ATAPI-5,6,7

  * signifies the current active mode


CompactFlash ATA device
	Model Number:       M88V29 32GB
	Serial Number:      20211023AA20A0656011
	Firmware Revision:  181019i
Standards:
	Supported: 8 7 6 5
	Likely used: 8
Configuration:
	Logical		max	current
	cylinders	16383	16383
	heads		15	15
	sectors/track	63	63
	--
	CHS current addressable sectors:    15481935
	LBA    user addressable sectors:    62533296
	LBA48  user addressable sectors:    62533296
	Logical/Physical Sector size:           512 bytes
	device size with M = 1024*1024:       30533 MBytes
	device size with M = 1000*1000:       32017 MBytes (32 GB)
	cache/buffer size  = unknown
	Nominal Media Rotation Rate: Solid State Device
Capabilities:
	LBA, IORDY(can be disabled)
	Standby timer values: spec'd by Vendor, with device specific minimum
	R/W multiple sector transfer: Max = 1	Current = 0
	Advanced power management level: 0
	DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5
	     Cycle time: min=120ns recommended=120ns
	PIO: pio0 pio1 pio2 pio3 pio4
	     Cycle time: no flow control=120ns  IORDY flow control=120ns
Commands/features:
	Enabled	Supported:
	   *	SMART feature set
	    	Security Mode feature set
	   *	Power Management feature set
	   *	Look-ahead
	   *	WRITE_BUFFER command
	   *	READ_BUFFER command
	   *	NOP cmd
	   *	DOWNLOAD_MICROCODE
	   *	CFA feature set
	   *	Advanced Power Management feature set
	   *	48-bit Address feature set
	   *	Mandatory FLUSH_CACHE
	   *	FLUSH_CACHE_EXT
	   *	SMART error logging
	   *	SMART self-test
	   *	General Purpose Logging feature set
	   *	WRITE_{DMA|MULTIPLE}_FUA_EXT
	   *	{READ,WRITE}_DMA_EXT_GPL commands
	   *	DOWNLOAD MICROCODE DMA command
	   *	Data Set Management TRIM supported (limit 1 block)
	   *	Deterministic read data after TRIM
		CFA max advanced io_udma cycle time: 80ns
		CFA max advanced mem_udma cycle time: 80ns
	   *	CFA advanced modes: pio5 pio6 mdma3 mdma4 io_udma4 io_udma5 io_udma6 io_udma7 
io_udma8 *io_udma9 mem_udma4 mem_udma5 mem_udma6 mem_udma7 mem_udma8 *mem_udma9
		CFA Power Level 1  not supported (max 100mA)
Security:
		supported
	not	enabled
	not	locked
		frozen
	not	expired: security count
		supported: enhanced erase
	4min for SECURITY ERASE UNIT. 4min for ENHANCED SECURITY ERASE UNIT.
HW reset results:
	CBLID- above Vih
	Device num = 0
Checksum: correct

> 
> but the I/O failures always reported higher number of blocks,
> IIRC the attempted number of block was 8 or so.
> 
> Can the kernel limit or split TRIM commands according to the
> advertised limit? If not (or not yet) then the quirk is good for now.
> 
> Best regards,
> Zoltán Böszörményi
> 

Re: [PATCH] libata: add horkage for M88V29

[Damien Le Moal]

On 6/23/22 16:47, Böszörményi Zoltán wrote:
> 2022. 02. 08. 9:07 keltezéssel, Damien Le Moal írta:
>> On 2/4/22 21:57, zboszor@pr.hu wrote:
>>> From: Zoltán Böszörményi <zboszor@gmail.com>
>>>
>>> This device is a CF card, or possibly an SSD in CF form factor.
>>> It supports NCQ and high speed DMA.
>>>
>>> While it also advertises TRIM support, I/O errors are reported
>>> when the discard mount option fstrim is used. TRIM also fails
>>> when disabling NCQ and not just as an NCQ command.
>>>
>>> TRIM must be disabled for this device.
>>>
>>> Signed-off-by: Zoltán Böszörményi <zboszor@gmail.com>
>>> ---
>>>   drivers/ata/libata-core.c | 1 +
>>>   1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
>>> index 67f88027680a..4a7f58fcc411 100644
>>> --- a/drivers/ata/libata-core.c
>>> +++ b/drivers/ata/libata-core.c
>>> @@ -4028,6 +4028,7 @@ static const struct ata_blacklist_entry ata_device_blacklist [] = {
>>>   
>>>   	/* devices that don't properly handle TRIM commands */
>>>   	{ "SuperSSpeed S238*",		NULL,	ATA_HORKAGE_NOTRIM, },
>>> +	{ "M88V29*",			NULL,	ATA_HORKAGE_NOTRIM, },
>>>   
>>>   	/*
>>>   	 * As defined, the DRAT (Deterministic Read After Trim) and RZAT
>> Applied to for-5.17-fixes. Thanks !
> 
> Thank you. However, I have second thoughts about this patch.
> The device advertises this:
> 
> # hdparm -iI /dev/sda
> ...
>   Enabled Supported
>      *    Data Set Management TRIM supported (limit 1 block)
> ...
> 
> but the I/O failures always reported higher number of blocks,
> IIRC the attempted number of block was 8 or so.
> 
> Can the kernel limit or split TRIM commands according to the
> advertised limit? If not (or not yet) then the quirk is good for now.

Yes, the kernel does that. See the sysfs queue attributes
discard_max_bytes and discard_max_hw_bytes. What are the values for your
device ? I think that the "limit 1 block" indicated by hdparm is simply to
say that the DSM command (to trim the device) accept only at most a 1
block (512 B) list of sectors to trim. That is not the actual trim limit
for each sector range in that list.

> 
> Best regards,
> Zoltán Böszörményi
> 


-- 
Damien Le Moal
Western Digital Research

Re: [PATCH] libata: add horkage for M88V29

[Böszörményi Zoltán]

2022. 06. 23. 10:22 keltezéssel, Damien Le Moal írta:
> On 6/23/22 16:47, Böszörményi Zoltán wrote:
>> 2022. 02. 08. 9:07 keltezéssel, Damien Le Moal írta:
>>> On 2/4/22 21:57, zboszor@pr.hu wrote:
>>>> From: Zoltán Böszörményi <zboszor@gmail.com>
>>>>
>>>> This device is a CF card, or possibly an SSD in CF form factor.
>>>> It supports NCQ and high speed DMA.
>>>>
>>>> While it also advertises TRIM support, I/O errors are reported
>>>> when the discard mount option fstrim is used. TRIM also fails
>>>> when disabling NCQ and not just as an NCQ command.
>>>>
>>>> TRIM must be disabled for this device.
>>>>
>>>> Signed-off-by: Zoltán Böszörményi <zboszor@gmail.com>
>>>> ---
>>>>    drivers/ata/libata-core.c | 1 +
>>>>    1 file changed, 1 insertion(+)
>>>>
>>>> diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
>>>> index 67f88027680a..4a7f58fcc411 100644
>>>> --- a/drivers/ata/libata-core.c
>>>> +++ b/drivers/ata/libata-core.c
>>>> @@ -4028,6 +4028,7 @@ static const struct ata_blacklist_entry ata_device_blacklist [] = {
>>>>    
>>>>    	/* devices that don't properly handle TRIM commands */
>>>>    	{ "SuperSSpeed S238*",		NULL,	ATA_HORKAGE_NOTRIM, },
>>>> +	{ "M88V29*",			NULL,	ATA_HORKAGE_NOTRIM, },
>>>>    
>>>>    	/*
>>>>    	 * As defined, the DRAT (Deterministic Read After Trim) and RZAT
>>> Applied to for-5.17-fixes. Thanks !
>> Thank you. However, I have second thoughts about this patch.
>> The device advertises this:
>>
>> # hdparm -iI /dev/sda
>> ...
>>    Enabled Supported
>>       *    Data Set Management TRIM supported (limit 1 block)
>> ...
>>
>> but the I/O failures always reported higher number of blocks,
>> IIRC the attempted number of block was 8 or so.
>>
>> Can the kernel limit or split TRIM commands according to the
>> advertised limit? If not (or not yet) then the quirk is good for now.
> Yes, the kernel does that. See the sysfs queue attributes
> discard_max_bytes and discard_max_hw_bytes. What are the values for your
> device ? I think that the "limit 1 block" indicated by hdparm is simply to
> say that the DSM command (to trim the device) accept only at most a 1
> block (512 B) list of sectors to trim. That is not the actual trim limit
> for each sector range in that list.

With the quirk in effect (TRIM disabled) I have these:

[root@chef queue]# pwd
/sys/block/sda/queue
[root@chef queue]# cat discard_granularity
0
[root@chef queue]# cat discard_max_bytes
0
[root@chef queue]# cat discard_max_hw_bytes
0

>
>> Best regards,
>> Zoltán Böszörményi
>>
>

Re: [PATCH] libata: add horkage for M88V29

[Böszörményi Zoltán]

2022. 06. 23. 10:38 keltezéssel, Böszörményi Zoltán írta:
> 2022. 06. 23. 10:22 keltezéssel, Damien Le Moal írta:
>> On 6/23/22 16:47, Böszörményi Zoltán wrote:
>>> 2022. 02. 08. 9:07 keltezéssel, Damien Le Moal írta:
>>>> On 2/4/22 21:57, zboszor@pr.hu wrote:
>>>>> From: Zoltán Böszörményi <zboszor@gmail.com>
>>>>>
>>>>> This device is a CF card, or possibly an SSD in CF form factor.
>>>>> It supports NCQ and high speed DMA.
>>>>>
>>>>> While it also advertises TRIM support, I/O errors are reported
>>>>> when the discard mount option fstrim is used. TRIM also fails
>>>>> when disabling NCQ and not just as an NCQ command.
>>>>>
>>>>> TRIM must be disabled for this device.
>>>>>
>>>>> Signed-off-by: Zoltán Böszörményi <zboszor@gmail.com>
>>>>> ---
>>>>>    drivers/ata/libata-core.c | 1 +
>>>>>    1 file changed, 1 insertion(+)
>>>>>
>>>>> diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
>>>>> index 67f88027680a..4a7f58fcc411 100644
>>>>> --- a/drivers/ata/libata-core.c
>>>>> +++ b/drivers/ata/libata-core.c
>>>>> @@ -4028,6 +4028,7 @@ static const struct ata_blacklist_entry ata_device_blacklist 
>>>>> [] = {
>>>>>           /* devices that don't properly handle TRIM commands */
>>>>>        { "SuperSSpeed S238*",        NULL, ATA_HORKAGE_NOTRIM, },
>>>>> +    { "M88V29*",            NULL,    ATA_HORKAGE_NOTRIM, },
>>>>>           /*
>>>>>         * As defined, the DRAT (Deterministic Read After Trim) and RZAT
>>>> Applied to for-5.17-fixes. Thanks !
>>> Thank you. However, I have second thoughts about this patch.
>>> The device advertises this:
>>>
>>> # hdparm -iI /dev/sda
>>> ...
>>>    Enabled Supported
>>>       *    Data Set Management TRIM supported (limit 1 block)
>>> ...
>>>
>>> but the I/O failures always reported higher number of blocks,
>>> IIRC the attempted number of block was 8 or so.
>>>
>>> Can the kernel limit or split TRIM commands according to the
>>> advertised limit? If not (or not yet) then the quirk is good for now.
>> Yes, the kernel does that. See the sysfs queue attributes
>> discard_max_bytes and discard_max_hw_bytes. What are the values for your
>> device ? I think that the "limit 1 block" indicated by hdparm is simply to
>> say that the DSM command (to trim the device) accept only at most a 1
>> block (512 B) list of sectors to trim. That is not the actual trim limit
>> for each sector range in that list.
>
> With the quirk in effect (TRIM disabled) I have these:
>
> [root@chef queue]# pwd
> /sys/block/sda/queue
> [root@chef queue]# cat discard_granularity
> 0
> [root@chef queue]# cat discard_max_bytes
> 0
> [root@chef queue]# cat discard_max_hw_bytes
> 0

And also this, which seems to match the sector limit:

[root@chef queue]# cat max_discard_segments
1

>
>>
>>> Best regards,
>>> Zoltán Böszörményi
>>>
>>
>

Re: [PATCH] libata: add horkage for M88V29

[Damien Le Moal]

On 6/23/22 17:38, Böszörményi Zoltán wrote:
> 2022. 06. 23. 10:22 keltezéssel, Damien Le Moal írta:
>> On 6/23/22 16:47, Böszörményi Zoltán wrote:
>>> 2022. 02. 08. 9:07 keltezéssel, Damien Le Moal írta:
>>>> On 2/4/22 21:57, zboszor@pr.hu wrote:
>>>>> From: Zoltán Böszörményi <zboszor@gmail.com>
>>>>>
>>>>> This device is a CF card, or possibly an SSD in CF form factor.
>>>>> It supports NCQ and high speed DMA.
>>>>>
>>>>> While it also advertises TRIM support, I/O errors are reported
>>>>> when the discard mount option fstrim is used. TRIM also fails
>>>>> when disabling NCQ and not just as an NCQ command.
>>>>>
>>>>> TRIM must be disabled for this device.
>>>>>
>>>>> Signed-off-by: Zoltán Böszörményi <zboszor@gmail.com>
>>>>> ---
>>>>>    drivers/ata/libata-core.c | 1 +
>>>>>    1 file changed, 1 insertion(+)
>>>>>
>>>>> diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
>>>>> index 67f88027680a..4a7f58fcc411 100644
>>>>> --- a/drivers/ata/libata-core.c
>>>>> +++ b/drivers/ata/libata-core.c
>>>>> @@ -4028,6 +4028,7 @@ static const struct ata_blacklist_entry ata_device_blacklist [] = {
>>>>>    
>>>>>    	/* devices that don't properly handle TRIM commands */
>>>>>    	{ "SuperSSpeed S238*",		NULL,	ATA_HORKAGE_NOTRIM, },
>>>>> +	{ "M88V29*",			NULL,	ATA_HORKAGE_NOTRIM, },
>>>>>    
>>>>>    	/*
>>>>>    	 * As defined, the DRAT (Deterministic Read After Trim) and RZAT
>>>> Applied to for-5.17-fixes. Thanks !
>>> Thank you. However, I have second thoughts about this patch.
>>> The device advertises this:
>>>
>>> # hdparm -iI /dev/sda
>>> ...
>>>    Enabled Supported
>>>       *    Data Set Management TRIM supported (limit 1 block)
>>> ...
>>>
>>> but the I/O failures always reported higher number of blocks,
>>> IIRC the attempted number of block was 8 or so.
>>>
>>> Can the kernel limit or split TRIM commands according to the
>>> advertised limit? If not (or not yet) then the quirk is good for now.
>> Yes, the kernel does that. See the sysfs queue attributes
>> discard_max_bytes and discard_max_hw_bytes. What are the values for your
>> device ? I think that the "limit 1 block" indicated by hdparm is simply to
>> say that the DSM command (to trim the device) accept only at most a 1
>> block (512 B) list of sectors to trim. That is not the actual trim limit
>> for each sector range in that list.
> 
> With the quirk in effect (TRIM disabled) I have these:
> 
> [root@chef queue]# pwd
> /sys/block/sda/queue
> [root@chef queue]# cat discard_granularity
> 0
> [root@chef queue]# cat discard_max_bytes
> 0
> [root@chef queue]# cat discard_max_hw_bytes
> 0

Yes, expected. What are the values without the quirk applied ?
With 5.19, you can use libata.force to disable/enable it. See
Documentation/admin-guide/kernel-parameters.txt for details.
You could try disabling DSM TRIM (queued trim) and see if the non-ncq trim
work.

-- 
Damien Le Moal
Western Digital Research

Re: [PATCH] libata: add horkage for M88V29

[Böszörményi Zoltán]

2022. 06. 23. 10:46 keltezéssel, Damien Le Moal írta:
> On 6/23/22 17:38, Böszörményi Zoltán wrote:
>> 2022. 06. 23. 10:22 keltezéssel, Damien Le Moal írta:
>>> On 6/23/22 16:47, Böszörményi Zoltán wrote:
>>>> 2022. 02. 08. 9:07 keltezéssel, Damien Le Moal írta:
>>>>> On 2/4/22 21:57, zboszor@pr.hu wrote:
>>>>>> From: Zoltán Böszörményi <zboszor@gmail.com>
>>>>>>
>>>>>> This device is a CF card, or possibly an SSD in CF form factor.
>>>>>> It supports NCQ and high speed DMA.
>>>>>>
>>>>>> While it also advertises TRIM support, I/O errors are reported
>>>>>> when the discard mount option fstrim is used. TRIM also fails
>>>>>> when disabling NCQ and not just as an NCQ command.
>>>>>>
>>>>>> TRIM must be disabled for this device.
>>>>>>
>>>>>> Signed-off-by: Zoltán Böszörményi <zboszor@gmail.com>
>>>>>> ---
>>>>>>     drivers/ata/libata-core.c | 1 +
>>>>>>     1 file changed, 1 insertion(+)
>>>>>>
>>>>>> diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
>>>>>> index 67f88027680a..4a7f58fcc411 100644
>>>>>> --- a/drivers/ata/libata-core.c
>>>>>> +++ b/drivers/ata/libata-core.c
>>>>>> @@ -4028,6 +4028,7 @@ static const struct ata_blacklist_entry ata_device_blacklist [] = {
>>>>>>     
>>>>>>     	/* devices that don't properly handle TRIM commands */
>>>>>>     	{ "SuperSSpeed S238*",		NULL,	ATA_HORKAGE_NOTRIM, },
>>>>>> +	{ "M88V29*",			NULL,	ATA_HORKAGE_NOTRIM, },
>>>>>>     
>>>>>>     	/*
>>>>>>     	 * As defined, the DRAT (Deterministic Read After Trim) and RZAT
>>>>> Applied to for-5.17-fixes. Thanks !
>>>> Thank you. However, I have second thoughts about this patch.
>>>> The device advertises this:
>>>>
>>>> # hdparm -iI /dev/sda
>>>> ...
>>>>     Enabled Supported
>>>>        *    Data Set Management TRIM supported (limit 1 block)
>>>> ...
>>>>
>>>> but the I/O failures always reported higher number of blocks,
>>>> IIRC the attempted number of block was 8 or so.
>>>>
>>>> Can the kernel limit or split TRIM commands according to the
>>>> advertised limit? If not (or not yet) then the quirk is good for now.
>>> Yes, the kernel does that. See the sysfs queue attributes
>>> discard_max_bytes and discard_max_hw_bytes. What are the values for your
>>> device ? I think that the "limit 1 block" indicated by hdparm is simply to
>>> say that the DSM command (to trim the device) accept only at most a 1
>>> block (512 B) list of sectors to trim. That is not the actual trim limit
>>> for each sector range in that list.
>> With the quirk in effect (TRIM disabled) I have these:
>>
>> [root@chef queue]# pwd
>> /sys/block/sda/queue
>> [root@chef queue]# cat discard_granularity
>> 0
>> [root@chef queue]# cat discard_max_bytes
>> 0
>> [root@chef queue]# cat discard_max_hw_bytes
>> 0
> Yes, expected. What are the values without the quirk applied ?

I built 5.18.6 with removing the quirk.

[root@chef queue]# pwd
/sys/block/sda/queue/
[root@chef queue]# cat discard_granularity
512
[root@chef queue]# cat discard_max_bytes
2147450880
[root@chef queue]# cat discard_max_hw_bytes
2147450880
[root@chef queue]# cat max_discard_segments
1

> With 5.19, you can use libata.force to disable/enable it. See
> Documentation/admin-guide/kernel-parameters.txt for details.
> You could try disabling DSM TRIM (queued trim) and see if the non-ncq trim
> work.
>

Re: [PATCH] libata: add horkage for M88V29

[Damien Le Moal]

On 6/23/22 18:32, Böszörményi Zoltán wrote:
> 2022. 06. 23. 10:46 keltezéssel, Damien Le Moal írta:
>> On 6/23/22 17:38, Böszörményi Zoltán wrote:
>>> 2022. 06. 23. 10:22 keltezéssel, Damien Le Moal írta:
>>>> On 6/23/22 16:47, Böszörményi Zoltán wrote:
>>>>> 2022. 02. 08. 9:07 keltezéssel, Damien Le Moal írta:
>>>>>> On 2/4/22 21:57, zboszor@pr.hu wrote:
>>>>>>> From: Zoltán Böszörményi <zboszor@gmail.com>
>>>>>>>
>>>>>>> This device is a CF card, or possibly an SSD in CF form factor.
>>>>>>> It supports NCQ and high speed DMA.
>>>>>>>
>>>>>>> While it also advertises TRIM support, I/O errors are reported
>>>>>>> when the discard mount option fstrim is used. TRIM also fails
>>>>>>> when disabling NCQ and not just as an NCQ command.
>>>>>>>
>>>>>>> TRIM must be disabled for this device.
>>>>>>>
>>>>>>> Signed-off-by: Zoltán Böszörményi <zboszor@gmail.com>
>>>>>>> ---
>>>>>>>     drivers/ata/libata-core.c | 1 +
>>>>>>>     1 file changed, 1 insertion(+)
>>>>>>>
>>>>>>> diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
>>>>>>> index 67f88027680a..4a7f58fcc411 100644
>>>>>>> --- a/drivers/ata/libata-core.c
>>>>>>> +++ b/drivers/ata/libata-core.c
>>>>>>> @@ -4028,6 +4028,7 @@ static const struct ata_blacklist_entry ata_device_blacklist [] = {
>>>>>>>     
>>>>>>>     	/* devices that don't properly handle TRIM commands */
>>>>>>>     	{ "SuperSSpeed S238*",		NULL,	ATA_HORKAGE_NOTRIM, },
>>>>>>> +	{ "M88V29*",			NULL,	ATA_HORKAGE_NOTRIM, },
>>>>>>>     
>>>>>>>     	/*
>>>>>>>     	 * As defined, the DRAT (Deterministic Read After Trim) and RZAT
>>>>>> Applied to for-5.17-fixes. Thanks !
>>>>> Thank you. However, I have second thoughts about this patch.
>>>>> The device advertises this:
>>>>>
>>>>> # hdparm -iI /dev/sda
>>>>> ...
>>>>>     Enabled Supported
>>>>>        *    Data Set Management TRIM supported (limit 1 block)
>>>>> ...
>>>>>
>>>>> but the I/O failures always reported higher number of blocks,
>>>>> IIRC the attempted number of block was 8 or so.
>>>>>
>>>>> Can the kernel limit or split TRIM commands according to the
>>>>> advertised limit? If not (or not yet) then the quirk is good for now.
>>>> Yes, the kernel does that. See the sysfs queue attributes
>>>> discard_max_bytes and discard_max_hw_bytes. What are the values for your
>>>> device ? I think that the "limit 1 block" indicated by hdparm is simply to
>>>> say that the DSM command (to trim the device) accept only at most a 1
>>>> block (512 B) list of sectors to trim. That is not the actual trim limit
>>>> for each sector range in that list.
>>> With the quirk in effect (TRIM disabled) I have these:
>>>
>>> [root@chef queue]# pwd
>>> /sys/block/sda/queue
>>> [root@chef queue]# cat discard_granularity
>>> 0
>>> [root@chef queue]# cat discard_max_bytes
>>> 0
>>> [root@chef queue]# cat discard_max_hw_bytes
>>> 0
>> Yes, expected. What are the values without the quirk applied ?
> 
> I built 5.18.6 with removing the quirk.
> 
> [root@chef queue]# pwd
> /sys/block/sda/queue/
> [root@chef queue]# cat discard_granularity
> 512
> [root@chef queue]# cat discard_max_bytes
> 2147450880
> [root@chef queue]# cat discard_max_hw_bytes
> 2147450880
> [root@chef queue]# cat max_discard_segments
> 1

All normal. This is 65535 sectors at most per trim range times 64 ranges
at most (64 range in at most 1 512B range list).
65535*512*64=2147450880

So if that is not working, then it means that DSM TRIM are not working
correctly on that device. Have you tried disabling NCQ trim ?
Use libata.force noncqtrim option.

> 
>> With 5.19, you can use libata.force to disable/enable it. See
>> Documentation/admin-guide/kernel-parameters.txt for details.
>> You could try disabling DSM TRIM (queued trim) and see if the non-ncq trim
>> work.
>>
> 


-- 
Damien Le Moal
Western Digital Research

Re: [PATCH] libata: add horkage for M88V29

[Böszörményi Zoltán]

2022. 06. 23. 11:32 keltezéssel, Böszörményi Zoltán írta:
> 2022. 06. 23. 10:46 keltezéssel, Damien Le Moal írta:
>> On 6/23/22 17:38, Böszörményi Zoltán wrote:
>>> 2022. 06. 23. 10:22 keltezéssel, Damien Le Moal írta:
>>>> On 6/23/22 16:47, Böszörményi Zoltán wrote:
>>>>> 2022. 02. 08. 9:07 keltezéssel, Damien Le Moal írta:
>>>>>> On 2/4/22 21:57, zboszor@pr.hu wrote:
>>>>>>> From: Zoltán Böszörményi <zboszor@gmail.com>
>>>>>>>
>>>>>>> This device is a CF card, or possibly an SSD in CF form factor.
>>>>>>> It supports NCQ and high speed DMA.
>>>>>>>
>>>>>>> While it also advertises TRIM support, I/O errors are reported
>>>>>>> when the discard mount option fstrim is used. TRIM also fails
>>>>>>> when disabling NCQ and not just as an NCQ command.
>>>>>>>
>>>>>>> TRIM must be disabled for this device.
>>>>>>>
>>>>>>> Signed-off-by: Zoltán Böszörményi <zboszor@gmail.com>
>>>>>>> ---
>>>>>>>     drivers/ata/libata-core.c | 1 +
>>>>>>>     1 file changed, 1 insertion(+)
>>>>>>>
>>>>>>> diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
>>>>>>> index 67f88027680a..4a7f58fcc411 100644
>>>>>>> --- a/drivers/ata/libata-core.c
>>>>>>> +++ b/drivers/ata/libata-core.c
>>>>>>> @@ -4028,6 +4028,7 @@ static const struct ata_blacklist_entry ata_device_blacklist 
>>>>>>> [] = {
>>>>>>>             /* devices that don't properly handle TRIM commands */
>>>>>>>         { "SuperSSpeed S238*",        NULL, ATA_HORKAGE_NOTRIM, },
>>>>>>> +    { "M88V29*",            NULL, ATA_HORKAGE_NOTRIM, },
>>>>>>>             /*
>>>>>>>          * As defined, the DRAT (Deterministic Read After Trim) and RZAT
>>>>>> Applied to for-5.17-fixes. Thanks !
>>>>> Thank you. However, I have second thoughts about this patch.
>>>>> The device advertises this:
>>>>>
>>>>> # hdparm -iI /dev/sda
>>>>> ...
>>>>>     Enabled Supported
>>>>>        *    Data Set Management TRIM supported (limit 1 block)
>>>>> ...
>>>>>
>>>>> but the I/O failures always reported higher number of blocks,
>>>>> IIRC the attempted number of block was 8 or so.
>>>>>
>>>>> Can the kernel limit or split TRIM commands according to the
>>>>> advertised limit? If not (or not yet) then the quirk is good for now.
>>>> Yes, the kernel does that. See the sysfs queue attributes
>>>> discard_max_bytes and discard_max_hw_bytes. What are the values for your
>>>> device ? I think that the "limit 1 block" indicated by hdparm is simply to
>>>> say that the DSM command (to trim the device) accept only at most a 1
>>>> block (512 B) list of sectors to trim. That is not the actual trim limit
>>>> for each sector range in that list.
>>> With the quirk in effect (TRIM disabled) I have these:
>>>
>>> [root@chef queue]# pwd
>>> /sys/block/sda/queue
>>> [root@chef queue]# cat discard_granularity
>>> 0
>>> [root@chef queue]# cat discard_max_bytes
>>> 0
>>> [root@chef queue]# cat discard_max_hw_bytes
>>> 0
>> Yes, expected. What are the values without the quirk applied ?
>
> I built 5.18.6 with removing the quirk.
>
> [root@chef queue]# pwd
> /sys/block/sda/queue/
> [root@chef queue]# cat discard_granularity
> 512
> [root@chef queue]# cat discard_max_bytes
> 2147450880
> [root@chef queue]# cat discard_max_hw_bytes
> 2147450880
> [root@chef queue]# cat max_discard_segments
> 1

"echo 512 >discard_max_hw_bytes" says permission denied.
"echo 512 >discard_max_bytes" can be set

But with or without libata.force=noncqtrim, running
"fstrim /boot" (which is ext4) goes into an infinite loop
dumping a lot of I/O errors into dmesg.

Interestingly, after setting discard_max_bytes=512,
in both cases (with or without libata.force=noncqrtim)
running "fstrim /" (which is f2fs) there is no error in
dmesg and fstrim returns after a small delay.

So I guess TRIM does work but ext4 seems to be misbehaving.

FWIW "mount" shows "discard" for the big f2fs partition but
it doesn't for ext4 but it's in the default mount option AFAIK.
"mount /boot -o remount.discard" doesn't make a difference.
the machine dumps a lot of errors into dmesg with "fstrim /boot".

>
>> With 5.19, you can use libata.force to disable/enable it. See
>> Documentation/admin-guide/kernel-parameters.txt for details.
>> You could try disabling DSM TRIM (queued trim) and see if the non-ncq trim
>> work.
>>
>

Re: [PATCH] libata: add horkage for M88V29

[Damien Le Moal]

On 6/23/22 19:12, Böszörményi Zoltán wrote:
> 2022. 06. 23. 11:32 keltezéssel, Böszörményi Zoltán írta:
>> 2022. 06. 23. 10:46 keltezéssel, Damien Le Moal írta:
>>> On 6/23/22 17:38, Böszörményi Zoltán wrote:
>>>> 2022. 06. 23. 10:22 keltezéssel, Damien Le Moal írta:
>>>>> On 6/23/22 16:47, Böszörményi Zoltán wrote:
>>>>>> 2022. 02. 08. 9:07 keltezéssel, Damien Le Moal írta:
>>>>>>> On 2/4/22 21:57, zboszor@pr.hu wrote:
>>>>>>>> From: Zoltán Böszörményi <zboszor@gmail.com>
>>>>>>>>
>>>>>>>> This device is a CF card, or possibly an SSD in CF form factor.
>>>>>>>> It supports NCQ and high speed DMA.
>>>>>>>>
>>>>>>>> While it also advertises TRIM support, I/O errors are reported
>>>>>>>> when the discard mount option fstrim is used. TRIM also fails
>>>>>>>> when disabling NCQ and not just as an NCQ command.
>>>>>>>>
>>>>>>>> TRIM must be disabled for this device.
>>>>>>>>
>>>>>>>> Signed-off-by: Zoltán Böszörményi <zboszor@gmail.com>
>>>>>>>> ---
>>>>>>>>     drivers/ata/libata-core.c | 1 +
>>>>>>>>     1 file changed, 1 insertion(+)
>>>>>>>>
>>>>>>>> diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
>>>>>>>> index 67f88027680a..4a7f58fcc411 100644
>>>>>>>> --- a/drivers/ata/libata-core.c
>>>>>>>> +++ b/drivers/ata/libata-core.c
>>>>>>>> @@ -4028,6 +4028,7 @@ static const struct ata_blacklist_entry ata_device_blacklist 
>>>>>>>> [] = {
>>>>>>>>             /* devices that don't properly handle TRIM commands */
>>>>>>>>         { "SuperSSpeed S238*",        NULL, ATA_HORKAGE_NOTRIM, },
>>>>>>>> +    { "M88V29*",            NULL, ATA_HORKAGE_NOTRIM, },
>>>>>>>>             /*
>>>>>>>>          * As defined, the DRAT (Deterministic Read After Trim) and RZAT
>>>>>>> Applied to for-5.17-fixes. Thanks !
>>>>>> Thank you. However, I have second thoughts about this patch.
>>>>>> The device advertises this:
>>>>>>
>>>>>> # hdparm -iI /dev/sda
>>>>>> ...
>>>>>>     Enabled Supported
>>>>>>        *    Data Set Management TRIM supported (limit 1 block)
>>>>>> ...
>>>>>>
>>>>>> but the I/O failures always reported higher number of blocks,
>>>>>> IIRC the attempted number of block was 8 or so.
>>>>>>
>>>>>> Can the kernel limit or split TRIM commands according to the
>>>>>> advertised limit? If not (or not yet) then the quirk is good for now.
>>>>> Yes, the kernel does that. See the sysfs queue attributes
>>>>> discard_max_bytes and discard_max_hw_bytes. What are the values for your
>>>>> device ? I think that the "limit 1 block" indicated by hdparm is simply to
>>>>> say that the DSM command (to trim the device) accept only at most a 1
>>>>> block (512 B) list of sectors to trim. That is not the actual trim limit
>>>>> for each sector range in that list.
>>>> With the quirk in effect (TRIM disabled) I have these:
>>>>
>>>> [root@chef queue]# pwd
>>>> /sys/block/sda/queue
>>>> [root@chef queue]# cat discard_granularity
>>>> 0
>>>> [root@chef queue]# cat discard_max_bytes
>>>> 0
>>>> [root@chef queue]# cat discard_max_hw_bytes
>>>> 0
>>> Yes, expected. What are the values without the quirk applied ?
>>
>> I built 5.18.6 with removing the quirk.
>>
>> [root@chef queue]# pwd
>> /sys/block/sda/queue/
>> [root@chef queue]# cat discard_granularity
>> 512
>> [root@chef queue]# cat discard_max_bytes
>> 2147450880
>> [root@chef queue]# cat discard_max_hw_bytes
>> 2147450880
>> [root@chef queue]# cat max_discard_segments
>> 1
> 
> "echo 512 >discard_max_hw_bytes" says permission denied.

That is normal. This is a hardware characteristic so this is read only.

> "echo 512 >discard_max_bytes" can be set

Yes, this is the soft limit that can be used to limit trim command size.

> But with or without libata.force=noncqtrim, running
> "fstrim /boot" (which is ext4) goes into an infinite loop
> dumping a lot of I/O errors into dmesg.
> 
> Interestingly, after setting discard_max_bytes=512,
> in both cases (with or without libata.force=noncqrtim)
> running "fstrim /" (which is f2fs) there is no error in
> dmesg and fstrim returns after a small delay.

Which would tend to indicate that the drive only likes single sector trims...

> 
> So I guess TRIM does work but ext4 seems to be misbehaving.

I do not think so. The ext4 is going to issue whatever trim request for
free blocks it has and the block layer will split these request into at
most discard_max_bytes trim commands. You can check this behavior using
blktrace.

> FWIW "mount" shows "discard" for the big f2fs partition but
> it doesn't for ext4 but it's in the default mount option AFAIK.
> "mount /boot -o remount.discard" doesn't make a difference.
> the machine dumps a lot of errors into dmesg with "fstrim /boot".

If you have an empty partition, you could experiment using blkdiscard
command to remove the fs.

-- 
Damien Le Moal
Western Digital Research