On Mon, 2021-06-21 at 13:13 -0600, Chris Murphy wrote:
On Mon, Jun 21, 2021 at 10:58 AM Chris Murphy lists@colorremedies.com 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.
I rebooted and took some new logs. However this time, for whatever reason, there was no 30-second delay. The logs are prefixed "nodelay-*" in the same directory.
I then rebooted and this time there was a delay. These logs are labelled "delay-*".
One interesting point is that in both cases I have to wait before getting some of these, e.g.
$ systemd-analyze blame Bootup is not yet finished (org.freedesktop.systemd1.Manager.FinishTimestampMonotonic=0). Please try again later. Hint: Use 'systemctl list-jobs' to see active jobs [poc@Bree ~]$ systemctl list-jobs JOB UNIT TYPE STATE 294 dock-watch.service start running
1 jobs listed.
IOW the system thinks that boot hasn't finished because the dock-watch unit is still running, even after I've already logged in. Probably not important.
nodelay-journal doesn't have the reset message, so that is clearly a clue to what's going on.
[...]
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.
There is a single dock with two slots and no other type of enclosure. The disks are internal SATA units inserted directly into the slots. The dock has a single dedicated USB-3 connection direct to the system motherboard with no intervening hub or splitter. It is independently powered via a wall socket and power block.
poc