On Mon, 2021-06-21 at 13:13 -0600, Chris Murphy wrote: > 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. 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 _______________________________________________ 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
