On Mon, Jun 21, 2021 at 10:58 AM Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > > Jun 19 12:47:12 fedora kernel: sd 6:0:0:1: tag#2 uas_eh_abort_handler > 0 uas-tag 2 inflight: IN > Jun 19 12:47:12 fedora kernel: sd 6:0:0:1: tag#2 CDB: Mode Sense(6) 1a > 00 08 00 18 00 Yeah and in the install-boot log it happens again: Jun 20 15:45:20 Bree kernel: sd 6:0:0:1: tag#16 uas_eh_abort_handler 0 uas-tag 1 inflight: IN Jun 20 15:45:20 Bree kernel: sd 6:0:0:1: tag#16 CDB: Mode Sense(6) 1a 00 08 00 18 00 Jun 20 15:45:20 Bree kernel: scsi host6: uas_eh_device_reset_handler start Jun 20 15:45:20 Bree kernel: usb 4-3: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd Jun 20 15:45:20 Bree kernel: scsi host6: uas_eh_device_reset_handler success Jun 20 15:45:20 Bree kernel: sd 6:0:0:1: [sde] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Jun 20 15:45:20 Bree kernel: sd 6:0:0:1: [sde] Optimal transfer size 33553920 bytes not a multiple of physical block size (4096 bytes) Jun 20 15:45:20 Bree kernel: sd 6:0:0:1: [sde] Attached SCSI disk What's new here is the explicit USB reset message. Jun 20 15:44:50 Bree kernel: usb 4-3: new SuperSpeed Gen 1 USB device number 2 using xhci_hcd Jun 20 15:44:50 Bree kernel: usb 4-3: New USB device found, idVendor=174c, idProduct=55aa, bcdDevice= 1.00 Jun 20 15:44:50 Bree kernel: usb 4-3: New USB device strings: Mfr=2, Product=3, SerialNumber=1 Jun 20 15:44:50 Bree kernel: usb 4-3: Product: ASM1156-PM Jun 20 15:44:50 Bree kernel: usb 4-3: Manufacturer: ASMT Jun 20 15:44:50 Bree kernel: usb 4-3: SerialNumber: 00000000000000000000 Curiously there is no usb of a second ASM1156 product, even though there are two: Jun 20 15:44:50 Bree kernel: scsi 6:0:0:0: Direct-Access ASMT ASM1156-PM 0 PQ: 0 ANSI: 6 Jun 20 15:44:50 Bree kernel: scsi 6:0:0:1: Direct-Access ASMT ASM1156-PM 0 PQ: 0 ANSI: 6 Jun 20 15:44:50 Bree kernel: sd 6:0:0:0: [sdd] 1953525168 512-byte logical blocks: (1.00 TB/932 GiB) Jun 20 15:44:50 Bree kernel: sd 6:0:0:1: [sde] 1953525168 512-byte logical blocks: (1.00 TB/932 GiB) And they have their own /dev node. So is one in a USB enclosure and the other isn't? Or maybe they are both just appearing as usb 4-3 even though they get different scsi id's - that's probably it. But then one of them is having some sort of issue, even if it's just confusion that results in the need for the kernel to do a reset on it. but *shrug* this is the joy of USB, it's not necessarily a hardware problem per se. I've got one SATA USB enclosure that tries to use the uas driver if direct connected to an Intel NUC. And I get no end of grief from it (this is with a pre 5.0 kernel I'm sure, it may very well have since been fixed in the kernel). All kinds of uas related errors. Plug it into an externally powered USB hub, and it doens't use the uas driver and I don't have any problems with it, and it reads/writes at approximately the drive's spec'd performance, depending on where on the platter the head is at. As it turns out a USB hub is very much like an ethernet hub. It's not just amplifying a signal, it's reading it, parsing it, and rewriting out that entire stream, as well as any other stream from another connected device. They're a PITA but kind of an engineering marvel (from my perspective anyway). So the hub does in effect seem to normalize the command/control/data streams from myriad devices so they have a better chance of playing well together. It's almost like the idea is "we'll use crap chipsets in the devices and hosts themselves, and just let the hubs figure it all out". And as it turns out with the well behaved SATA USB enclosures, they have transient read and write errors (one a day, then 10 times in a row) if direct connect to that same Intel NUC. With the *externally* powered (not bus powered) hub, zero problems. For years. So if both drives are in SATA USB enclosures, and if they're both connected to ports on a dock, you might track down or borrow an externally powered hub and connect both of the drives to that hub, and the hub to the dock. And see if this problem goes away. -- Chris Murphy _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
