On Sun, Jul 19, 2020 at 11:22:10AM +0100, Tj (Elloe Linux) wrote: > With all kernels from 4.14 to 5.8.0-rc5 we're seeing failures with uas > on a Turris Mox aarch64 Marvell Armada 3720 that we don't see on amd64. > > The device that triggers them is: > > Bus 003 Device 002: ID 152d:0562 JMicron Technology Corp. / JMicron USA > Technology Corp. > > These are USB3<>NVME adapters with 256GB NVME attached. > > On advice from the Turris Mox developers we tried booting with and > without "pci=nomsi". That implies that the host controller, or the PCI controller code, is not working on the arm system well? > We have other similar JMicron devices but they use usb-storage instead > and work fine. > > Linked below is the complete output from dmesg, lspci -vvnnk, lsusb -v > but here's a snapshot of the error messages: > > ... > [ 13.601433] hub 2-1:1.0: 4 ports detected > [ 13.724437] usb 3-1: new SuperSpeed Gen 1 USB device number 2 using > xhci_hcd > [ 13.784151] scsi host0: uas > [ 13.788820] scsi 0:0:0:0: Direct-Access JMicron Tech > 0204 PQ: 0 ANSI: 6 > [ 13.830081] sd 0:0:0:0: [sda] 500118192 512-byte logical blocks: (256 > GB/238 GiB) > [ 13.835692] sd 0:0:0:0: Attached scsi generic sg0 type 0 > [ 13.840597] sd 0:0:0:0: [sda] 4096-byte physical blocks > [ 13.894211] sd 0:0:0:0: [sda] Write Protect is off > [ 13.904097] sd 0:0:0:0: [sda] Mode Sense: 5f 00 00 08 > [ 13.907773] sd 0:0:0:0: [sda] Write cache: enabled, read cache: > enabled, doesn't support DPO or FUA > [ 13.944550] sd 0:0:0:0: [sda] Optimal transfer size 33553920 bytes > not a multiple of physical block size (4096 bytes) > ... > [ 15.390872] sd 0:0:0:0: [sda] Attached SCSI disk > ... > [ 46.104025] sd 0:0:0:0: [sda] tag#21 uas_eh_abort_handler 0 uas-tag 6 > inflight: IN > [ 46.109072] sd 0:0:0:0: [sda] tag#21 CDB: opcode=0x28 28 00 1d cf 2f > d8 00 00 28 00 > [ 46.119512] sd 0:0:0:0: [sda] tag#20 uas_eh_abort_handler 0 uas-tag 5 > inflight: IN > [ 46.124842] sd 0:0:0:0: [sda] tag#20 CDB: opcode=0x28 28 00 1d cf 2f > 28 00 00 a8 00 > [ 46.152049] scsi host0: uas_eh_device_reset_handler start > [ 46.285155] usb 3-1: reset SuperSpeed Gen 1 USB device number 2 using > xhci_hcd > [ 46.312219] scsi host0: uas_eh_device_reset_handler success > [ 76.827742] scsi host0: uas_eh_device_reset_handler start > [ 76.831151] sd 0:0:0:0: [sda] tag#21 uas_zap_pending 0 uas-tag 1 > inflight: > [ 76.837629] sd 0:0:0:0: [sda] tag#21 CDB: opcode=0x28 28 00 1d cf 2f > d8 00 00 28 00 > [ 76.845513] sd 0:0:0:0: [sda] tag#20 uas_zap_pending 0 uas-tag 2 > inflight: > [ 76.852678] sd 0:0:0:0: [sda] tag#20 CDB: opcode=0x28 28 00 1d cf 2f > 28 00 00 a8 00 > [ 76.992756] usb 3-1: reset SuperSpeed Gen 1 USB device number 2 using > xhci_hcd > ... Where is an error here? Those looks ok to me. > If we try to read the device with, e.g: > > $ sudo dd if=/dev/sda count=8 | hexdump -C > > then we see I/O errors: > > ... > [ 199.911106] blk_update_request: I/O error, dev sda, sector 500117288 > op 0x0:(READ) flags 0x80700 phys_seg 21 prio class 0 > [ 199.922749] sd 0:0:0:0: [sda] tag#21 UNKNOWN(0x2003) Result: > hostbyte=0x08 driverbyte=0x00 cmd_age=184s > [ 199.932074] sd 0:0:0:0: [sda] tag#21 CDB: opcode=0x28 28 00 1d cf 2f > d8 00 00 28 00 > [ 199.939976] blk_update_request: I/O error, dev sda, sector 500117464 > op 0x0:(READ) flags 0x80700 phys_seg 5 prio class 0 So only the block layer is reporting errors, not the USB layer? Any usb controller errors? And what USB controller driver are you using here? thanks, greg k-h
