Hello, I think its UAS: >From the dmesg: [ 652.335275] usb 1-1.3: Product: SABRENT [ 652.335279] usb 1-1.3: Manufacturer: SABRENT [ 652.335283] usb 1-1.3: SerialNumber: DB98765432123 [ 652.337283] scsi host8: uas [ 652.338731] scsi 8:0:0:0: Direct-Access SABRENT 4101 PQ: 0 ANSI: 6 SABRENT Is the HDD craddle. I have an external Toshiba HDD running on the same computer with the xhci_hcd driver for years without problems. But it reads: >>> usb-storage 4-1:1.0: USB Mass Storage device detected so i think its fundamentally different. Yes. data corruption ocurred when Oopsing. Like i said, i tried different HDDs and have two HDD Craddles to play with. all combinations brought the same result. Both craddles have SATA-USB3 chipsets from JMicrion. running on a USB2 chipset with the ehci driver works fine. Regards Tomas On Mon, Mar 12, 2018 at 6:52 AM, Oliver Neukum <oneukum@xxxxxxxx> wrote: > Am Sonntag, den 11.03.2018, 10:48 -0300 schrieb Tomas M: >> Hello, >> >> I reported the bug here and was suggested to forward it to the ML. >> https://bugzilla.kernel.org/show_bug.cgi?id=199075 >> >> find attached the owed dmesg with the stack trace. >> >> using the ehci ports produces no error. >> using the xhci ports fails very fast when writing. >> >> this happens with the >> Bus 001 Device 005: ID 152d:0578 JMicron Technology Corp. / JMicron >> USA Technology Corp. JMS567 SATA 6Gb/s bridge >> >> and another similar chipset from JMicron too. >> >> I have another external USB3 drive using the xhci driver without problems. >> >> Regards > > UAS or storage? > > A CRC error is really unusual and an oops in RCU is arcane. > Do you have errors with other Super Speed devices? This looks > like data corruption. > > Regards > Oliver > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
