UASP blacklist in Linux kernel negeren

[Sebazzz]

Ik heb een ICY Box IB-3740-C31 gekocht om met wat overgebleven harddisks mijn opslag van mijn thuisserver uit te breiden. Bij de aanschaf heb ik specifiek erop gelet dat het UAS(P) ondersteunt, zodat ik ook de SMART informatie kan uitlezen van deze disks.

Allemaal goed en wel, maar helaas blijkt na aanschaf dat er een VL817 SATA Adaptor in zit (device ID 2109:0715) en deze is geblacklist in de kernel: https://www.spinics.net/lists/linux-usb/msg221559.html via UNUSUAL_DEV (unusual_devs.h).

Echter zijn er ook meldingen dat sommige apparaten met deze chipset juist prima werken. Kan ik, zonder de kernel te recompilen, deze blacklist laten negeren voor dit apparaat zodat ik kan testen of UASP bij mij wel goed functioneert?

[gekkie]

Uit de kernel parameters:

usb-storage.quirks=
[UMS] A list of quirks entries to supplement or
override the built-in unusual_devs list. List
entries are separated by commas. Each entry has
the form VID:PID:Flags where VID and PID are Vendor
and Product ID values (4-digit hex numbers) and
Flags is a set of characters, each corresponding
to a common usb-storage quirk flag as follows:
a = SANE_SENSE (collect more than 18 bytes
of sense data, not on uas);
b = BAD_SENSE (don't collect more than 18
bytes of sense data, not on uas);
c = FIX_CAPACITY (decrease the reported
device capacity by one sector);
d = NO_READ_DISC_INFO (don't use
READ_DISC_INFO command, not on uas);
e = NO_READ_CAPACITY_16 (don't use
READ_CAPACITY_16 command);
f = NO_REPORT_OPCODES (don't use report opcodes
command, uas only);
g = MAX_SECTORS_240 (don't transfer more than
240 sectors at a time, uas only);
h = CAPACITY_HEURISTICS (decrease the
reported device capacity by one
sector if the number is odd);
i = IGNORE_DEVICE (don't bind to this
device);
j = NO_REPORT_LUNS (don't use report luns
command, uas only);
k = NO_SAME (do not use WRITE_SAME, uas only)
l = NOT_LOCKABLE (don't try to lock and
unlock ejectable media, not on uas);
m = MAX_SECTORS_64 (don't transfer more
than 64 sectors = 32 KB at a time,
not on uas);
n = INITIAL_READ10 (force a retry of the
initial READ(10) command, not on uas);
o = CAPACITY_OK (accept the capacity
reported by the device, not on uas);
p = WRITE_CACHE (the device cache is ON
by default, not on uas);
r = IGNORE_RESIDUE (the device reports
bogus residue values, not on uas);
s = SINGLE_LUN (the device has only one
Logical Unit);
t = NO_ATA_1X (don't allow ATA(12) and ATA(16)
commands, uas only);
u = IGNORE_UAS (don't bind to the uas driver);
w = NO_WP_DETECT (don't test whether the
medium is write-protected).
y = ALWAYS_SYNC (issue a SYNCHRONIZE_CACHE
even if the device claims no cache,
not on uas)
Example: quirks=0419:aaf5:rl,0421:0433:rc

Lijkt te suggereren dat je ook zou kunnen "overriden" maar niet expliciet hoe. Wellicht dat dit alles overruled wanneer je de quick voor dat device niet expliciet weer actief benoemd ?

[Sebazzz]

Die had ik inderdaad ook gevonden, maar het is niet duidelijk of het gebrek aan flags ook betekent dat ze geunset worden.

[gekkie]

Dan kom je vervolgens uit op de functie usb_stor_adjust_quirks() in file:
https://git.kernel.org/pu...drivers/usb/storage/usb.c

Waar je met je beste "C" kennis kunt uitvogelen hoe de masking van die flags werkt

[Sebazzz]

Helaas, aan de kernel command line toegevoegd als usb-storage.quirks=2109:0715: maar er veranderd niets (na reboot).

[gekkie]

Als je kijkt naar die file dan zie je in get_device_info() dat er iets gelogged zou kunnen worden en dat die
Wat gedaan wordt nadat die fflags gemasked zijn op basis van die wat iets eerder in die functie wordt de call gedaan naar: usb_stor_adjust_quirks(us->pusb_dev, &us->fflags);

Dus deze output zouden de op dat moment actieve quirks moeten zijn:
if (us->fflags)
dev_info(pdev, "Quirks match for vid %04x pid %04x: %llx\n",
le16_to_cpu(dev->descriptor.idVendor),
le16_to_cpu(dev->descriptor.idProduct),
us->fflags);

Dus wellicht nog even in je kernel logging kijken ?

[ Voor 4% gewijzigd door gekkie op 13-01-2024 13:00 ]

[Sebazzz]

gekkie schreef op zaterdag 13 januari 2024 @ 13:00:
Dus wellicht nog even in je kernel logging kijken ?

Hmm ik denk dat hij daar nooit komt. Inderdaad geen matches als ik dmesg bekijk (niets over quirks oid), maar het is ook net alsof hij de schijven niet ziet zitten:

 sudo lsblk -S
NAME HCTL       TYPE VENDOR   MODEL           REV SERIAL           TRAN
sda  1:0:0:0    disk ATA      CT480BX500SSD1 054  2209E615343A     sata
sdb  6:0:0:0    disk          VirtualDisk         0000000000000004 usb
sdc  5:0:0:0    disk          VirtualDisk         0000000000000003 usb
sdd  4:0:0:0    disk          VirtualDisk         0000000000000002 usb
sde  3:0:0:0    disk          VirtualDisk         0000000000000001 usb

sudo mdadm --create --verbose --level=5 --name=volume2 --raid-devices=4 /dev/md2 /dev/sdb /dev/sdc /dev/sdd /dev/sde
mdadm: layout defaults to left-symmetric
mdadm: cannot open /dev/sdb: No medium found

En:

 sudo mdadm --zero-superblock /dev/sdb
mdadm: Couldn't open /dev/sdb for write - not zeroing

Dit is trouwens de output van lsusb:

sudo lsusb -t
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 10000M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 10000M
        |__ Port 1: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 10000M
        |__ Port 2: Dev 4, If 0, Class=Mass Storage, Driver=usb-storage, 10000M
        |__ Port 3: Dev 5, If 0, Class=Mass Storage, Driver=usb-storage, 10000M
        |__ Port 4: Dev 6, If 0, Class=Mass Storage, Driver=usb-storage, 10000M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M
    |__ Port 3: Dev 2, If 0, Class=Wireless, Driver=btusb, 480M
    |__ Port 3: Dev 2, If 1, Class=Wireless, Driver=btusb, 480M
    |__ Port 3: Dev 2, If 2, Class=Wireless, Driver=, 480M
    |__ Port 4: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 12M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 10000M
    |__ Port 2: Dev 2, If 0, Class=Hub, Driver=hub/4p, 10000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M
    |__ Port 2: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
    |__ Port 4: Dev 5, If 0, Class=Communications, Driver=cdc_acm, 12M
    |__ Port 4: Dev 5, If 1, Class=CDC Data, Driver=cdc_acm, 12M

[Sebazzz]

gekkie schreef op zaterdag 13 januari 2024 @ 13:00:
Wat gedaan wordt nadat die fflags gemasked zijn op basis van die wat iets eerder in die functie wordt de call gedaan naar: usb_stor_adjust_quirks(us->pusb_dev, &us->fflags);

Volgens de code overschrijven de kernel command line inderdaad wat hardcoded is gezet.

[Hero of Time]

Als je bij de kernel parameter alleen het VID en PID opgeeft zonder flags, dan gaat er natuurlijk niets veranderen. Je moet dus nog wel even de flags opgeven die je wilt omzetten. Zie ook het voorbeeld in de quote met uitleg.

[gekkie]

Dat is wel wazig idd en er zijn ook geen USB devices die expliciet geignored worden in je logging ?
Je zou wellicht je kernel debug level nog eens op debug kunnen zetten en kijken of je nog wat ziet waar die device/bus id's langs komen ?

En anders is een kernel builden waar je die patch revert ook nog best wel te doen lijkt me ?

[ Voor 16% gewijzigd door gekkie op 13-01-2024 13:22 ]

[Sebazzz]

gekkie schreef op zaterdag 13 januari 2024 @ 13:19:
Dat is wel wazig idd en er zijn ook geen USB devices die expliciet geignored worden in je logging ?

Dit is alles wat ik zie als ik hem fysiek verbind:

[ 3428.813012] usb 4-1: new SuperSpeed Plus Gen 2x1 USB device number 12 using xhci_hcd
[ 3428.862561] usb 4-1: New USB device found, idVendor=2109, idProduct=8822, bcdDevice= 5.a3
[ 3428.862570] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 3428.862573] usb 4-1: Product: USB3.1 Hub
[ 3428.862576] usb 4-1: Manufacturer: VIA Labs, Inc.
[ 3428.862578] usb 4-1: SerialNumber: 000000001
[ 3428.887590] hub 4-1:1.0: USB hub found
[ 3428.887819] hub 4-1:1.0: 4 ports detected
[ 3433.696566] usb 4-1.1: new SuperSpeed Plus Gen 2x1 USB device number 13 using xhci_hcd
[ 3433.723366] usb 4-1.1: New USB device found, idVendor=2109, idProduct=0715, bcdDevice= 6.14
[ 3433.723374] usb 4-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 3433.723378] usb 4-1.1: Product: USB3.1 SATA Bridge
[ 3433.723380] usb 4-1.1: Manufacturer: VIA Labs,Inc
[ 3433.723383] usb 4-1.1: SerialNumber: 0000000000000001
[ 3433.723840] usb-storage 4-1.1:1.0: USB Mass Storage device detected
[ 3433.724200] scsi host3: usb-storage 4-1.1:1.0
[ 3433.804798] usb 4-1.2: new SuperSpeed Plus Gen 2x1 USB device number 14 using xhci_hcd
[ 3433.831170] usb 4-1.2: New USB device found, idVendor=2109, idProduct=0715, bcdDevice= 6.14
[ 3433.831179] usb 4-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 3433.831183] usb 4-1.2: Product: USB3.1 SATA Bridge
[ 3433.831186] usb 4-1.2: Manufacturer: VIA Labs,Inc
[ 3433.831188] usb 4-1.2: SerialNumber: 0000000000000002
[ 3433.831656] usb-storage 4-1.2:1.0: USB Mass Storage device detected
[ 3433.831923] scsi host4: usb-storage 4-1.2:1.0
[ 3433.916678] usb 4-1.3: new SuperSpeed Plus Gen 2x1 USB device number 15 using xhci_hcd
[ 3433.943066] usb 4-1.3: New USB device found, idVendor=2109, idProduct=0715, bcdDevice= 6.14
[ 3433.943075] usb 4-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 3433.943078] usb 4-1.3: Product: USB3.1 SATA Bridge
[ 3433.943081] usb 4-1.3: Manufacturer: VIA Labs,Inc
[ 3433.943083] usb 4-1.3: SerialNumber: 0000000000000003
[ 3433.943542] usb-storage 4-1.3:1.0: USB Mass Storage device detected
[ 3433.943813] scsi host5: usb-storage 4-1.3:1.0
[ 3434.028534] usb 4-1.4: new SuperSpeed Plus Gen 2x1 USB device number 16 using xhci_hcd
[ 3434.059347] usb 4-1.4: New USB device found, idVendor=2109, idProduct=0715, bcdDevice= 6.14
[ 3434.059355] usb 4-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 3434.059359] usb 4-1.4: Product: USB3.1 SATA Bridge
[ 3434.059362] usb 4-1.4: Manufacturer: VIA Labs,Inc
[ 3434.059364] usb 4-1.4: SerialNumber: 0000000000000004
[ 3434.059837] usb-storage 4-1.4:1.0: USB Mass Storage device detected
[ 3434.060080] scsi host6: usb-storage 4-1.4:1.0
[ 3434.725602] scsi 3:0:0:0: Direct-Access              VirtualDisk           PQ: 0 ANSI: 6
[ 3434.725944] sd 3:0:0:0: Attached scsi generic sg1 type 0
[ 3434.726552] sd 3:0:0:0: [sdb] Media removed, stopped polling
[ 3434.727601] sd 3:0:0:0: [sdb] Attached SCSI removable disk
[ 3434.853578] scsi 4:0:0:0: Direct-Access              VirtualDisk           PQ: 0 ANSI: 6
[ 3434.853976] sd 4:0:0:0: Attached scsi generic sg2 type 0
[ 3434.854486] sd 4:0:0:0: [sdc] Media removed, stopped polling
[ 3434.855305] sd 4:0:0:0: [sdc] Attached SCSI removable disk
[ 3434.949494] scsi 5:0:0:0: Direct-Access              VirtualDisk           PQ: 0 ANSI: 6
[ 3434.949897] sd 5:0:0:0: Attached scsi generic sg3 type 0
[ 3434.950328] sd 5:0:0:0: [sdd] Media removed, stopped polling
[ 3434.951211] sd 5:0:0:0: [sdd] Attached SCSI removable disk
[ 3435.077381] scsi 6:0:0:0: Direct-Access              VirtualDisk           PQ: 0 ANSI: 6
[ 3435.077746] sd 6:0:0:0: Attached scsi generic sg4 type 0
[ 3435.078208] sd 6:0:0:0: [sde] Media removed, stopped polling
[ 3435.079077] sd 6:0:0:0: [sde] Attached SCSI removable disk

Ik denk dat hij defect is, want zelfs met de usb-storage driver moet hij in ieder geval naar de disks moeten schrijven, maar zelfs dit lukt niet:

 sudo dd if=/dev/zero of=/dev/sdd                                                                                                                                                                                                        
dd: failed to open '/dev/sdd': No medium found

Dit probleem speelt met alle disks (sdb, sdc, sdd, sde).

[gekkie]

Defect kan natuurlijk ook altijd, ook al eens met maar 1 disk fysiek er in geprobeerd of je die dan wel kunt benaderen ?

[Sebazzz]

gekkie schreef op zaterdag 13 januari 2024 @ 14:14:
Defect kan natuurlijk ook altijd, ook al eens met maar 1 disk fysiek er in geprobeerd of je die dan wel kunt benaderen ?

Nee, nog niet, maar dat zou niets moeten uitmaken. Het ding is simpelweg een printplaat met een USB 3 hub die splitst naar vier USB-to-SATA controllers. Het apparaat heeft er zelf geen weet van hoeveel disks erin zitten.

[gekkie]

Sebazzz schreef op zaterdag 13 januari 2024 @ 14:18:
[...]

Nee, nog niet, maar dat zou niets moeten uitmaken. Het ding is simpelweg een printplaat met een USB 3 hub die splitst naar vier USB-to-SATA controllers. Het apparaat heeft er zelf geen weet van hoeveel disks erin zitten.

Klopt maar misschien is er iets mis met bijvb de voeding van het apparaat en probeert het te draaien op puur wat USB kan leveren en kan dat met 1 disk net wel nog werken.

[Sebazzz]

gekkie schreef op zaterdag 13 januari 2024 @ 14:22:
[...]

Klopt maar misschien is er iets mis met bijvb de voeding van het apparaat en probeert het te draaien op puur wat USB kan leveren en kan dat met 1 disk net wel nog werken.

Dat hielp helaas niet maar krijg nou f#$@#$%.. blijkbaar zijn alle vier 2TB schijven die ik aan de praat probeer te krijgen dood. Dermate dood dat ze dus ook geen SMART informatie vrijgeven, ze kwamen allemaal uit dezelfde NAS. Heel bijzonder...

Ik heb wat andere oude harddisks gepakt en die worden wel correct gedetecteerd, en via de kernel parameter ook in UAS.

[gekkie]

Sebazzz schreef op zaterdag 13 januari 2024 @ 15:20:
[...]

Dat hielp helaas niet maar krijg nou f#$@#$%.. blijkbaar zijn alle vier 2TB schijven die ik aan de praat probeer te krijgen dood. Dermate dood dat ze dus ook geen SMART informatie vrijgeven, ze kwamen allemaal uit dezelfde NAS. Heel bijzonder...

Ik heb wat andere oude harddisks gepakt en die worden wel correct gedetecteerd, en via de kernel parameter ook in UAS.

Zijn ze echt dood (en was dat al min of meer de verwachting), of is er misschien toch wat anders aan de hand zoals gedoe dat sommige schijven niet willen omdat ze iets anders verwachten qua 3.3v (al heb ik dat vooral met hitachi/wd's in grotere storage sizes wel eens gehad)?

Kortom wat doen ze dan aan een normale s-ata stekker en voedingskabel ?

[ Voor 4% gewijzigd door gekkie op 13-01-2024 15:47 ]

[Sebazzz]

gekkie schreef op zaterdag 13 januari 2024 @ 15:46:
[...]

Zijn ze echt dood (en was dat al min of meer de verwachting), of is er misschien toch wat anders aan de hand zoals gedoe dat sommige schijven niet willen omdat ze iets anders verwachten qua 3.3v (al heb ik dat vooral met hitachi/wd's in grotere storage sizes wel eens gehad)?

Dit zijn Samsung HD203WI 2TB harddisks, die hebben +12V en +5V nodig volgens het label. Nee, ik heb niet verwacht dat ze overleden.

[gekkie]

Ik lees her en der wel dat er compatibiliteitsproblemen zijn geweest met chipsets en er ook ooit een firmware update voor is uitgegeven. Maar goed dat is ook een longshot, dus ik zou het dan verder ook niet meer weten.

[ Voor 23% gewijzigd door gekkie op 13-01-2024 17:39 ]

[Sebazzz]

gekkie schreef op zaterdag 13 januari 2024 @ 17:39:
Ik lees her en der wel dat er compatibiliteitsproblemen zijn geweest met chipsets en er ook ooit een firmware update voor is uitgegeven. Maar goed dat is ook een longshot, dus ik zou het dan verder ook niet meer weten.

Ik denk dat je daar op een spoor zit... In mijn computer wordt (N=1) de schijf wel goed herkend en de SMART is positief, maar hij zit ook nog op de oude firmware.

Helaas kan mijn moederbord - ASUS X570-Prime - niet de SATA controller in IDE mode zetten (alleen AHCI en RAID), waardoor de firmware flashing utility de schijf niet kan vinden om te flashen. Ik heb de schijf ook geprobeerd aan te sluiten op een Gigabyte BACE-3150 NUC, maar die ziet te schijf niet - waarschijnlijk omdat de schijf 12V wilt hebben.