Hello, On Mon, Aug 1, 2016 at 1:44 PM, Durval Menezes <jmlnxusb@xxxxxxxxxxxxx> wrote: > Hi Mike, > > On Mon, Aug 1, 2016 at 12:05 PM, Mike Murdoch <main.haarp@xxxxxxxxxxxxxx> wrote: > > On 2016-08-01 13:57, Durval Menezes wrote: > > > Hi Mathias, > > > > > > On Mon, Aug 1, 2016 at 8:20 AM, Mathias Nyman <mathias.nyman@xxxxxxxxxxxxxxx> wrote: > > >>> On 01.08.2016 13:15, Durval Menezes wrote: > > >>> Hello Mike, Mathias, list, > > >>> > > >>> On 06.02.2016 19:08, Mike Murdoch wrote: > > >>> Bug ID: 111251 > > >>> > > >>> I have a NEC uPD720200 USB3.0 controller in a Thinkpad W520 laptop on > > >>> kernel 4.4.1-gentoo. > > >>> > > >>> 0e:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host > > >>> Controller (rev 04) (prog-if 30 [XHCI]) > > >>> Subsystem: Lenovo uPD720200 USB 3.0 Host Controller > > >>> Flags: bus master, fast devsel, latency 0 > > >>> Memory at f3800000 (64-bit, non-prefetchable) [size=8K] > > >>> Capabilities: [50] Power Management version 3 > > >>> Capabilities: [70] MSI: Enable- Count=1/8 Maskable- 64bit+ > > >>> Capabilities: [90] MSI-X: Enable+ Count=8 Masked- > > >>> Capabilities: [a0] Express Endpoint, MSI 00 > > >>> Capabilities: [100] Advanced Error Reporting > > >>> Capabilities: [140] Device Serial Number ff-ff-ff-ff-ff-ff-ff-ff > > >>> Capabilities: [150] Latency Tolerance Reporting > > >>> Kernel driver in use: xhci_hcd > > >>> Kernel modules: xhci_pci > > >>> > > >>> When runtime power control for this controller is disabled > > >>> (/sys/bus/pci/devices/0000:0e:00.0/power/control = on), the controller > > >>> works fine and reaches over 120MB/s transfer rates. > > >>> > > >>> When runtime power control for this controller is enabled > > >>> (/sys/bus/pci/devices/0000:0e:00.0/power/control = auto), two effects > > >>> can be observed: > > >>> > > >>> - Transfer rates are much lower at around 30MB/s > > >>> - During transfers, the controller dies after a couple of seconds: > > >>> > > >>> I found this message in the list archives, and I have the exact same > > >>> issues on exactly the same hardware (Thinkpad W520 laptop with the same > > >>> USB3 controller showing on lspci -v); otherwise, I'm running distro kernel > > >>> 2.6.32-573.7.1.el6.x86_64 on a Springdale Linux 6.7 (RHEL6) install. > > >>> > > >>> I just verified that my controller's PM was set by default to "auto": > > >>> cat /sys/bus/pci/devices/0000\:0e\:00.0/power/control > > >>> auto > > >>> I have now set it to "on" and will test whether this will work around > > >>> the issue (I'm waiting for my USB3.0 "heavy duty" disk docks to be > > >>> released from another system that is using them right now). The docks (actually a 4-disk Mediasonic Probox enclosure, and a single-disk USpeed SATA-to-USB adapter) have returned; I've rebooted my machine (to make sure I was starting from as clean a slate as possible), then (before plugging anything) set the controller's PM to "on" (ie, no power management) with the "echo" command above, and confirmed it with the "cat" command above. Then I tried to plug first the adapter to each of the two ports controlled by the uPD720200; the result for each attempt (as recorded on syslog with level debug) was just: Aug 2 11:45:16 localhost kernel: hub 3-0:1.0: unable to enumerate USB device on port 1 For the lower port, and Aug 2 11:54:19 localhost kernel: hub 3-0:1.0: unable to enumerate USB device on port 2 For the upper port. To confirm that the adapter is working, I connected it to the "combo" USB/eSATA adapter (which on the W520 is right besides the two uPD720200 ports) and it worked great (albeit limited to USB2.1, as this is this port's type): Aug 2 11:56:46 localhost kernel: usb 2-1.2: new high speed USB device number 3 using ehci_hcd Aug 2 11:56:47 localhost kernel: usb 2-1.2: New USB device found, idVendor=174c, idProduct=5106 Aug 2 11:56:47 localhost kernel: usb 2-1.2: New USB device strings: Mfr=2, Product=3, SerialNumber=1 Aug 2 11:56:47 localhost kernel: usb 2-1.2: Product: AS2105 Aug 2 11:56:47 localhost kernel: usb 2-1.2: Manufacturer: ASMedia Aug 2 11:56:47 localhost kernel: usb 2-1.2: SerialNumber: W2A87518 Aug 2 11:56:47 localhost kernel: usb 2-1.2: configuration #1 chosen from 1 choice Aug 2 11:56:47 localhost kernel: Initializing USB Mass Storage driver... Aug 2 11:56:47 localhost kernel: scsi6 : SCSI emulation for USB Mass Storage devices Aug 2 11:56:47 localhost kernel: usb-storage: device found at 3 Aug 2 11:56:47 localhost kernel: usb-storage: waiting for device to settle before scanning Aug 2 11:56:47 localhost kernel: usbcore: registered new interface driver usb-storage Aug 2 11:56:47 localhost kernel: USB Mass Storage support registered. Aug 2 11:56:48 localhost kernel: usb-storage: device scan complete Aug 2 11:56:48 localhost kernel: scsi 6:0:0:0: Direct-Access ST250DM0 00-1BD141 KC45 PQ: 0 ANSI: 5 Aug 2 11:56:48 localhost kernel: sd 6:0:0:0: Attached scsi generic sg3 type 0 Aug 2 11:56:48 localhost kernel: sd 6:0:0:0: [sdd] 488397168 512-byte logical blocks: (250 GB/232 GiB) Aug 2 11:56:48 localhost kernel: sd 6:0:0:0: [sdd] Write Protect is off Aug 2 11:56:48 localhost kernel: sd 6:0:0:0: [sdd] Mode Sense: 23 00 00 00 Aug 2 11:56:48 localhost kernel: sd 6:0:0:0: [sdd] Assuming drive cache: write through Aug 2 11:56:48 localhost kernel: sd 6:0:0:0: [sdd] Assuming drive cache: write through Aug 2 11:56:48 localhost kernel: sdd: sdd1 Aug 2 11:56:48 localhost kernel: sd 6:0:0:0: [sdd] Assuming drive cache: write through Aug 2 11:56:48 localhost kernel: sd 6:0:0:0: [sdd] Attached SCSI disk With the 4-disk enclosure, it was at least recognized/enumerated on the uPD720200 ports ports: Aug 2 12:29:01 localhost kernel: usb 4-1: new SuperSpeed USB device number 3 using xhci_hcd Aug 2 12:29:01 localhost kernel: usb 4-1: New USB device found, idVendor=152d, idProduct=0567 Aug 2 12:29:01 localhost kernel: usb 4-1: New USB device strings: Mfr=10, Product=11, SerialNumber=5 Aug 2 12:29:01 localhost kernel: usb 4-1: Product: USB to ATA/ATAPI Bridge Aug 2 12:29:01 localhost kernel: usb 4-1: Manufacturer: JMicron Aug 2 12:29:01 localhost kernel: usb 4-1: SerialNumber: 152D00539000 Aug 2 12:29:01 localhost kernel: usb 4-1: configuration #1 chosen from 1 choice Aug 2 12:29:01 localhost kernel: scsi8 : SCSI emulation for USB Mass Storage devices Aug 2 12:29:01 localhost kernel: usb-storage: device found at 3 Aug 2 12:29:01 localhost kernel: usb-storage: waiting for device to settle before scanning Aug 2 12:29:02 localhost kernel: usb-storage: device scan complete Aug 2 12:29:02 localhost kernel: scsi 8:0:0:0: Direct-Access ST310005 24AS 0125 PQ: 0 ANSI: 6 Aug 2 12:29:02 localhost kernel: scsi 8:0:0:1: Direct-Access ST310005 24AS 0125 PQ: 0 ANSI: 6 Aug 2 12:29:02 localhost kernel: scsi 8:0:0:2: Direct-Access ST310005 24AS 0125 PQ: 0 ANSI: 6 Aug 2 12:29:02 localhost kernel: scsi 8:0:0:3: Direct-Access ST310005 24AS 0125 PQ: 0 ANSI: 6 But things went straight to hell as soon as I tried to do I/O on it: Aug 2 12:33:11 localhost kernel: xhci_hcd 0000:0e:00.0: xHCI host not responding to stop endpoint command. Aug 2 12:33:11 localhost kernel: xhci_hcd 0000:0e:00.0: Assuming host is dying, halting host. Aug 2 12:33:11 localhost kernel: xhci_hcd 0000:0e:00.0: HC died; cleaning up Aug 2 12:33:11 localhost kernel: usb 4-1: USB disconnect, device number 3 Aug 2 12:33:11 localhost kernel: hub 4-0:1.0: hub_port_status failed (err = -19) Aug 2 12:33:11 localhost kernel: sd 8:0:0:3: Device offlined - not ready after error recovery Aug 2 12:33:11 localhost kernel: sd 8:0:0:3: [sdg] Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK Aug 2 12:33:11 localhost kernel: sd 8:0:0:3: [sdg] CDB: Read(10): 28 60 6a a2 47 58 00 00 08 00 Aug 2 12:33:11 localhost kernel: end_request: I/O error, dev sdg, sector 1789019992 So it seems the "disable power management" workaround did not work for my case. I will try backporting the patches, and then upgrading the firmware. Will keep everyone posted. Thanks, -- Durval Menezes. > > >>> > > >>> I have one question for Mike: have you upgraded your uPD720200 controller > > >>> firmware (as per [1], [2]) or are you still running stock? > > >>> > > >>> Also, one question for Mathias: do you know whether your patches at [3] > > >>> can be applied to kernel 2.6.32? > > >> The last patch in [3] is faulty. So don't use the patches from the mail. > > >> > > >> I just force updated that branch, so if you like you can try to backport > > >> patches from: > > >> > > >> git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git bug_usb3_enum_rtresume > > >> > > >> only 2 patches are relevant: > > >> > > >> 8caabe9 xhci: Don't suspend the xhci bus it there is a pending event. > > >> 4427456 xhci: resume USB 3 roothub first > > > Thanks Mathias. Now I only need Mike's response concerning the firmware > > > in order to proceed. > > > > > No, I haven't tried updating the firmware. Feel free to give it a go, > > I'm curious if it'll make a difference. > > As long as the patch (or the workaround) allow me to avoid the issue, > I'd rather let sleeping dragons lie (windows-only update procedure, etc) > > :-) > > > As for the patches. All three of them did fix this bug, but introduced > > other problems (I don't remember details, sorry). As Mathias said, the > > last one is faulty. However, using only the first two patches is *not* > > enough to completely fix this bug (I verified it just now). > > No prob, Mathias sent me a reference to the relevant (and presumably > working) patches, I will first try the "disable PM mode" workaround and > later (possibly *much* later) to backport the patches to my kernel. > > > Unfortunately I don't have the time to do much testing. The Thinkpad is > > used by someone else and I only have access to it on the weekends. A > > workaround is to just disable runtime power management. > > Thanks for the feedback. > > > Let me know how things work for you! > > Will do: will post a progress report (on the workaround) later today to the > list and, as you asked, directly to your email too. > > Thanks again, > -- > Durval Menezes (durval AT tmp DOT com DOT br, http://www.tmp.com.br/) -- 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
