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@xxxxx wrote:
From: Zoltán Böszörményi <zboszor@xxxxxxxxx>
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@xxxxxxxxx>
---
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
