On Mon, 2021-06-21 at 13:13 -0600, Chris Murphy wrote:
On Mon, Jun 21, 2021 at 10:58 AM Chris Murphy
<lists(a)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