Hello,
On Mon, Aug 1, 2016 at 1:44 PM, Durval Menezes <jmlnx...@durval.com.br> wrote:
> Hi Mike,
>
> On Mon, Aug 1, 2016 at 12:05 PM, Mike Murdoch <main.ha...@googlemail.com>
> wrote:
> > On 2016-08-01 13:57, Durval Menezes wrote:
> > > Hi Mathias,
> > >
> > > On Mon, Aug 1, 2016 at 8:20 AM, Mathias Nyman
> > > <mathias.ny...@linux.intel.com> 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
