Hallo zusammen,
ich bin über ein merkwürdiges Thema gestolpert. Soviel vorab: Grundsätzlich konnte ich es bereits lösen, wenn auch anders als gedacht.
Ich habe ein paar externe USB 3.0 HDDs (von Intenso sowie Gehäuse von inateck), die mit einem JMicron Chipsatz arbeiten. Grundsätzlich sind das feine Teile. An meinem Acer Aspire A315-42-R7QB mit Ryzen 3 CPU mit einem USB 3.0 Port (die anderen sind USB 2.0) habe ich mit diesen Geräten bisher keine Probleme gehabt.
Nun habe ich einen USB 3.0 Hub mit eigener Stromversorgung von Hama. Wenn ich hier ein solches USB-3.0-HDD anstecke und beispielsweise Dateien > 1 GB raufschiebe, gibt es in dmesg Meldungen wie diese:
1 2 3 4 5 | sd 1:0:0:0: [sda] tag#0 uas_eh_abort_handler 0 uas-tag 11 inflight: CMD OUT sd 1:0:0:0: [sda] tag#0 CDB: Write(10) 2a 00 15 92 55 28 00 04 00 00 scsi host1: uas_eh_device_reset_handler start usb 2-2.2: reset SuperSpeed Gen 1 USB device number 8 using xhci_hcd scsi host1: uas_eh_device_reset_handler success |
Meistens gehen keine Daten verloren, aber es passieren mehrere solcher Resets, bis der Transfer abgeschlossen werden kann, und das dauert dann entsprechend.
Nach entsprechender Recherche habe ich herausgefunden, dass der Treiber uas dafür verantwortlich ist. Ich habe mir die Vendor-/Product-IDs der betroffenen Laufwerke notiert und hätte diese dann in eine /etc/modprobe.d/blacklist-uas.conf eintragen wollen als
1 2 | options usb-storage quirks=152d:0578:u options usb-storage quirks=152d:0579:u |
Noch schnell ein sudo update-initramfs -u und neu gestartet... Aber die Einträge wurden ignoriert, trotzdem wurde der uas Treiber verwendet.
Am Ende habe ich die Einstellung als Kernel-Option usb-storage.quirks=152d:0578:u,152d:0579:u via GRUB angehängt, das hat funktioniert.
Was ich nicht verstanden habe: Warum wurden die Einträge in der Blacklist-Datei ignoriert? Ich konnte auch keine Fehlermeldungen entdecken auf Syntaxfehler o.ä.