On Mon, Jun 21, 2021 at 3:20 AM Patrick O'Callaghan <pocallaghan@xxxxxxxxx> wrote: > > The logs are now publicly visible at: > https://drive.google.com/drive/folders/1nGwVkeTJh5hz4dYRBD7Ikpx6q4MaPki9?usp=sharing >From the live boot (the least complicated one to look at for starters), there is an anomaly: Jun 19 08:46:41 fedora kernel: BTRFS: device label fedora_localhost-live devid 1 transid 1768306 /dev/sda3 scanned by systemd-udevd (602) Jun 19 08:46:41 fedora kernel: BTRFS: device label storage devid 1 transid 3481192 /dev/sdc1 scanned by systemd-udevd (595) Jun 19 08:46:44 fedora kernel: BTRFS: device label RAID devid 1 transid 1973 /dev/sdd scanned by systemd-udevd (595) Jun 19 08:46:56 fedora systemd[1]: Mounted /sysroot. Jun 19 12:47:14 fedora kernel: BTRFS: device label RAID devid 2 transid 1973 /dev/sde scanned by systemd-udevd (1000) rewinding to see why this device is so much later (ignoring 8 vs 12 which is some clock artifact and not real), even though it's not holding up live boot: Jun 19 08:46:41 fedora kernel: scsi host6: uas Jun 19 08:46:41 fedora kernel: usbcore: registered new interface driver uas Jun 19 08:46:41 fedora kernel: scsi 6:0:0:0: Direct-Access ASMT ASM1156-PM 0 PQ: 0 ANSI: 6 Jun 19 08:46:41 fedora kernel: scsi 6:0:0:1: Direct-Access ASMT ASM1156-PM 0 PQ: 0 ANSI: 6 Jun 19 08:46:41 fedora kernel: sd 6:0:0:0: Attached scsi generic sg4 type 0 Jun 19 08:46:41 fedora kernel: sd 6:0:0:1: Attached scsi generic sg5 type 0 Jun 19 08:46:41 fedora kernel: sd 6:0:0:0: [sdd] 1953525168 512-byte logical blocks: (1.00 TB/932 GiB) Jun 19 08:46:41 fedora kernel: sd 6:0:0:0: [sdd] 4096-byte physical blocks Jun 19 08:46:41 fedora kernel: sd 6:0:0:0: [sdd] Write Protect is off Jun 19 08:46:41 fedora kernel: sd 6:0:0:0: [sdd] Mode Sense: 43 00 00 00 Jun 19 08:46:41 fedora kernel: sd 6:0:0:1: [sde] 1953525168 512-byte logical blocks: (1.00 TB/932 GiB) Jun 19 08:46:41 fedora kernel: sd 6:0:0:1: [sde] 4096-byte physical blocks Jun 19 08:46:41 fedora kernel: sd 6:0:0:1: [sde] Write Protect is off Jun 19 08:46:41 fedora kernel: sd 6:0:0:1: [sde] Mode Sense: 43 00 00 00 Jun 19 08:46:41 fedora kernel: sd 6:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Jun 19 08:46:41 fedora kernel: sd 6:0:0:0: [sdd] Optimal transfer size 33553920 bytes not a multiple of physical block size (4096 bytes) Jun 19 08:46:44 fedora kernel: sd 6:0:0:0: [sdd] Attached SCSI disk 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 Jun 19 12:47:12 fedora kernel: scsi host6: uas_eh_device_reset_handler start Jun 19 12:47:12 fedora kernel: usb 4-3: reset SuperSpeed Gen 1 USB device number 3 using xhci_hcd Jun 19 12:47:12 fedora kernel: scsi host6: uas_eh_device_reset_handler success Jun 19 12:47:12 fedora kernel: sd 6:0:0:1: [sde] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Jun 19 12:47:12 fedora kernel: sd 6:0:0:1: [sde] Optimal transfer size 33553920 bytes not a multiple of physical block size (4096 bytes) Jun 19 12:47:14 fedora kernel: sd 6:0:0:1: [sde] Attached SCSI disk Jun 19 12:47:14 fedora kernel: BTRFS: device label RAID devid 2 transid 1973 /dev/sde scanned by systemd-udevd (1000) Both sd 6:0:0:0: (/dev/sdd) and sd 6:0:0:1: (/dev/sde) are found at the same time, but there's a uas related reset that happens only on /dev/sde. I don't know what this means: 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 But that's the clue that there's some kind of communication issue between drive and kernel. If these are both in SATA USB enclosures I'd ask on the linux-usb list what these messages mean and why the file system on the one with these messages isn't recognized by the kernel until later. You could switch cables only around and see if the problem follows the cables; then switch the drives to see if it follows the drives. I would sooner expect the drive enclosure than cable but since I've got no clue what the above two messages mean, it's just an iterative process. I do recommend using lsusb -v in the initial email to linux-usb, maybe compare the two enclosure outputs to see if there's anything different. The make/model might be identical but it's possible a partial explanation lies with a chipset difference, or revision of the chipset. There's a bunch of usb and uas driver quirks that can be applied to work around problems like this. By reporting them, if there's enough differentiation reported by the enclosures to use a quirk, they'll apply it by default in a future kernel. If not, then it becomes something you apply every boot. -- 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
