Re: Long wait for start job

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux