On 2014-12-05 11:00, Hans de Goede wrote: > Hi, > > On 12/05/2014 12:35 AM, Marcin Zajączkowski wrote: >> On 2014-12-04 20:21, Hans de Goede wrote: >>> Hi, >>> >>> On 12/03/2014 10:22 PM, Marcin Zajączkowski wrote: >>>> On 2014-12-03 10:53, Oliver Neukum wrote: >>>>> On Wed, 2014-12-03 at 10:41 +0100, Marcin Zajączkowski wrote: >>>>>> 2014-12-03 Oliver Neukum wrote: >>>>>>> On Wed, 2014-12-03 at 00:29 +0100, Marcin Zajączkowski wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> After upgrade to Fedora 21 with 3.17.3-300.fc21.x86_64 (from >>>>>>>> 3.14.x in >>>>>>>> Fedora 19) my USB 3.0 drive (Seagate Backup+ 1TB) stopped working >>>>>>>> with >>>>>>>> USB 3.0 port (works fine with USB 2.0 port). >>>>>>>> >>>>>>>> When plug in for the first time (USB 3.0 port) I see in log: >>>>>>>> >>>>>>>>> kernel: xhci_hcd 0000:04:00.0: ERROR Transfer event for disabled >>>>>>>> endpoint or incorrect stream ring >>>>>>>>> kernel: xhci_hcd 0000:04:00.0: @0000000241eec570 11979000 00000002 >>>>>>>> 05000000 01078001 >>>>>>> >>>>>>> Are you using the UAS driver? >>>>>> >>>>>> Probably yes. How can check that and/or switch to not UAS driver for >>>>>> a test? >>>>> >>>>> Sysfs holds the information. I can be comfortably queried with the >>>>> "usb-devices" script. >>>>> >>>>> To switch drivers you can use the "no UAS" quirk which can be given as >>>>> a module parameter like other quirks. >>>> >>>> Thanks Olivier for your reply. UAS keyword helped me to ignore UAS for >>>> my drive (via `options usb-storage quirks=vendorId:productId:u`) and my >>>> drive can again be used via USB 3.0 port. >> (...) >> >>>> What would you propose to do with the issue with that Seagate drive >>>> (family?)? To either track it or to temporary disable UAS for them >>>> globally (to not produce system crashes). >>> >>> If you have a seagate driver you may need a US_FL_NO_ATA_1X quirk >>> to disable ata pass through commands, as all (current) seagate devices >> >> How can I do that from the modprobe level? > > With the quirk line I've provided below (and you've already tested). > >>> seem to bork on this. What is the usb-id of your seagate device ? >> >> idVendor=0bc2, idProduct=a013 > > Hmm, that one does not yet have the US_FL_NO_ATA_1X quirk most seagate > devices > seem to need. That is not the problem in your case (probing does not get so > far that it matters), but this does seem to be one of the devices which > need > one looking at the model-name and usb-id. So I'll add a quirk for it to > help > out other users. > >>> And can you try with options usb-storage quirks=vendorId:productId:t ? >> >> I tried "quirks=vendorId:productId:t" and it failed. The system reported >> errors when a drive was connected: > > Ok, I already suspected as much, since this seems to be an xhci controller > problem, not an uas problem. > >>> 21:37:32 kernel: usb 4-1: new SuperSpeed USB device number 2 using >>> xhci_hcd >>> 21:37:32 kernel: usb 4-1: New USB device found, idVendor=0bc2, >>> idProduct=a013 >>> 21:37:32 kernel: usb 4-1: New USB device strings: Mfr=2, Product=3, >>> SerialNumber=1 >>> 21:37:32 kernel: usb 4-1: Product: Backup+ BK >>> 21:37:32 kernel: usb 4-1: Manufacturer: Seagate >>> 21:37:32 kernel: usb 4-1: SerialNumber: XXXXXXXX >>> 21:37:33 mtp-probe[2777]: checking bus 4, device 2: >>> "/sys/devices/pci0000:00/0000:00:1c.3/0000:04:00.0/usb4/4-1" >>> 21:37:33 mtp-probe[2777]: bus: 4, device: 2 was not an MTP device >>> 21:37:33 kernel: usbcore: registered new interface driver usb-storage >>> 21:37:33 kernel: scsi host6: uas >>> 21:37:33 kernel: usbcore: registered new interface driver uas >>> 21:37:33 kernel: xhci_hcd 0000:04:00.0: ERROR Transfer event for >>> disabled endpoint or incorrect stream ring >>> 21:37:33 kernel: xhci_hcd 0000:04:00.0: @00000000368b3570 9067b000 >>> 00000000 05000000 01078001 >>> 21:37:33 kernel: xhci_hcd 0000:04:00.0: ERROR Transfer event for >>> disabled endpoint or incorrect stream ring >>> 21:37:33 kernel: xhci_hcd 0000:04:00.0: @00000000368b3580 9067b400 >>> 00000000 05000000 01038001 >>> 21:37:53 kernel: scsi 6:0:0:0: uas_eh_abort_handler ffff88003653ee80 >>> tag -1, inflight: CMD IN >>> 21:37:53 kernel: xhci_hcd 0000:04:00.0: WARN waiting for error on ep >>> to be cleared >>> 21:37:53 kernel: scsi 6:0:0:0: uas_submit_sense_urb ffff88003653ee80 >>> tag -1, inflight: CMD IN abort >>> 21:37:53 kernel: scsi host6: sense urb submission error -22 stream 32 >>> 21:37:53 kernel: scsi host6: uas_eh_task_mgmt: ABORT TASK: submit >>> sense urb failed >>> 21:37:53 kernel: scsi 6:0:0:0: uas_eh_device_reset_handler >>> 21:37:53 kernel: xhci_hcd 0000:04:00.0: WARN waiting for error on ep >>> to be cleared >>> 21:37:53 kernel: scsi 6:0:0:0: uas_submit_sense_urb ffff88003653ee80 >>> tag -1, inflight: CMD IN abort >>> 21:37:53 kernel: scsi host6: sense urb submission error -22 stream 32 >>> 21:37:53 kernel: scsi host6: uas_eh_task_mgmt: LOGICAL UNIT RESET: >>> submit sense urb failed >>> 21:37:53 kernel: scsi host6: uas_eh_bus_reset_handler start >>> 21:37:53 kernel: usb 4-1: stat urb: killed, stream 1 >>> 21:37:53 kernel: scsi 6:0:0:0: uas_data_cmplt ffff88003653ee80 tag >>> -1, inflight: CMD abort >>> 21:37:53 kernel: scsi 6:0:0:0: data cmplt err -2 stream 1 >>> 21:37:53 kernel: scsi 6:0:0:0: uas_zap_dead ffff88003653ee80 tag -1, >>> inflight: CMD abort >>> 21:37:53 kernel: scsi 6:0:0:0: abort completed >>> 21:37:54 kernel: usb 4-1: reset SuperSpeed USB device number 2 using >>> xhci_hcd >>> 21:37:54 kernel: xhci_hcd 0000:04:00.0: xHCI xhci_drop_endpoint >>> called with disabled ep ffff880036a82200 >>> 21:37:54 kernel: xhci_hcd 0000:04:00.0: xHCI xhci_drop_endpoint >>> called with disabled ep ffff880036a82248 >>> 21:37:54 kernel: xhci_hcd 0000:04:00.0: xHCI xhci_drop_endpoint >>> called with disabled ep ffff880036a82290 >>> 21:37:54 kernel: xhci_hcd 0000:04:00.0: xHCI xhci_drop_endpoint >>> called with disabled ep ffff880036a822d8 >>> 21:37:54 kernel: scsi host6: uas_eh_bus_reset_handler success >>> 21:37:54 kernel: xhci_hcd 0000:04:00.0: ERROR Transfer event for >>> disabled endpoint or incorrect stream ring >>> 21:37:54 kernel: xhci_hcd 0000:04:00.0: @00000000368b36c0 9067b800 >>> 00000000 05000000 01078001 >> >> And crashed when disconnected: >> >>> 21:38:17 kernel: usb 4-1: USB disconnect, device number 2 >>> 21:38:17 kernel: usb 4-1: stat urb: status -108 >>> 21:38:17 kernel: scsi 6:0:0:0: uas_disconnect ffff88003653ee80 tag >>> -1, inflight: CMD >>> 21:38:17 kernel: scsi 6:0:0:0: uas_zap_dead ffff88003653ee80 tag -1, >>> inflight: CMD abort >> >> >>> Although the error in this case seems to point to a problem with your >>> xhci controller rather then with the drive in this case. >>> >>> Can you provide the output of lspci -nn please ? >> >> Here's the output: >>> $ lspci -nn | grep USB >>> 00:1a.0 USB controller [0c03]: Intel Corporation 6 Series/C200 Series >>> Chipset Family USB Enhanced Host Controller #2 [8086:1c2d] (rev 05) >>> 00:1d.0 USB controller [0c03]: Intel Corporation 6 Series/C200 Series >>> Chipset Family USB Enhanced Host Controller #1 [8086:1c26] (rev 05) >>> 04:00.0 USB controller [0c03]: Fresco Logic FL1000G USB 3.0 Host >>> Controller [1b73:1000] (rev 04) > > Ah, that is the first time I encounter a Fresco Logic controller, the > Fresco > Logic controllers esp. the FL1000G model already have quite a few quirks, > they were one of the first to market before the spec was fully hashed out > I believe. > > It seems that all the early generations xhci controllers (except for the > NEC ones) > have issues with streams, since there was no OS support for uas yet, so > they > could not be tested. At least the early VIA xhci controllers (pci > product id 0x3432), > the Etron EJ168 and the Asmedia ASM1042 all suffer from this. > > I'll send a patch upstream adding a XHCI_BROKEN_STREAMS quirk for the > Fresco Logic FL1000G controller. This will make the kernel automatically > fall-back to usb-storage for any uas devices attached to such a controller. > > I've also ordered a pci-e addon card for myself to test with a Fresco > Logic controller. This one will likely have a newer version though, but > it is good to verify that streams will work on the newer version. > > In the mean time you can keep using the :u quirk as module option as a > workaround (it does the same thing), note if you use another uas device > with > your controller and the current kernel, you will need to add a quirk for > that device too. Thanks Hans. I updated the bugzilla ticket to reflect that: https://bugzilla.redhat.com/show_bug.cgi?id=1164945 Marcin -- 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
