Bug 197933 - Change in support of USB 3.0 NEC uPD720200 (with JMS539 USB3 to SATA in a Vantec 4 drive box)
Summary: Change in support of USB 3.0 NEC uPD720200 (with JMS539 USB3 to SATA in a Van...
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: usb (show other bugs)
Version: 10.1-RELEASE
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-usb mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-02-22 21:22 UTC by Greg
Modified: 2018-05-28 19:49 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Greg 2015-02-22 21:22:14 UTC
After 'make' upgrade from 10.0 to 10.1, no drives were recognized. 

Swapped cable and rebooted. 1 drive of 3 recognized.  

All were fine in ZFS on 10.0

Dmesg shows timeout on GET MAX LUN command. 

Plugged into USB2 port. All drives now present but obviously much slower. 

Searched change list for 10.1 but don't see any USB related changes.
Comment 1 Greg 2015-02-22 21:25:14 UTC
 $ dmesg | grep -i usb
ehci0: <EHCI (generic) USB 2.0 controller> mem 0xcc429000-0xcc4293ff irq 16 at device 26.0 on pci0
usbus0: EHCI version 1.0
usbus0 on ehci0
xhci0: <NEC uPD720200 USB 3.0 controller> mem 0xca100000-0xca101fff irq 16 at device 0.0 on pci5
usbus1 on xhci0
ehci1: <EHCI (generic) USB 2.0 controller> mem 0xcc428000-0xcc4283ff irq 23 at device 29.0 on pci0
usbus2: EHCI version 1.0
usbus2 on ehci1
usbus0: 480Mbps High Speed USB v2.0
usbus1: 5.0Gbps Super Speed USB v3.0
usbus2: 480Mbps High Speed USB v2.0
ugen1.1: <0x1033> at usbus1
uhub0: <0x1033 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus1
ugen0.1: <Intel> at usbus0
uhub1: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus0
ugen2.1: <Intel> at usbus2
uhub2: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus2
ugen0.2: <vendor 0x8087> at usbus0
uhub3: <vendor 0x8087 product 0x0024, class 9/0, rev 2.00/0.00, addr 2> on usbus0
ugen2.2: <vendor 0x8087> at usbus2
uhub4: <vendor 0x8087 product 0x0024, class 9/0, rev 2.00/0.00, addr 2> on usbus2
ugen0.3: <vendor 0x08ff> at usbus0
ugen0.4: <Sonix Technology Co., Ltd.> at usbus0
ugen2.3: <JMicron> at usbus2
umass0: <MSC Bulk-Only Transport> on usbus2

 $ sudo usbconfig 
ugen1.1: <XHCI root HUB 0x1033> at usbus1, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=SAVE (0mA)
ugen0.1: <EHCI root HUB Intel> at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)
ugen2.1: <EHCI root HUB Intel> at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)
ugen0.2: <product 0x0024 vendor 0x8087> at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)
ugen2.2: <product 0x0024 vendor 0x8087> at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)
ugen0.3: <Fingerprint Sensor vendor 0x08ff> at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (100mA)
ugen0.4: <CNF9055 Sonix Technology Co., Ltd.> at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA)
ugen2.3: <USB to ATAATAPI Bridge JMicron> at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (8mA)
Comment 2 Greg 2015-02-22 21:26:09 UTC
 $ dmesg | grep ^da
da0 at umass-sim0 bus 0 scbus7 target 0 lun 0
da0: <ST4000DX 001-1CE168 0X03> Fixed Direct Access SCSI-6 device 
da0: Serial Number 000000000000
da0: 40.000MB/s transfers
da0: 3815447MB (7814037168 512 byte sectors: 255H 63S/T 486401C)
da0: quirks=0x2<NO_6_BYTE>
da1 at umass-sim0 bus 0 scbus7 target 0 lun 1
da1: <HGST HDN 724040ALE640 0X03> Fixed Direct Access SCSI-6 device 
da1: Serial Number 000000000000
da1: 40.000MB/s transfers
da1: 3815447MB (7814037168 512 byte sectors: 255H 63S/T 486401C)
da1: quirks=0x2<NO_6_BYTE>
da2 at umass-sim0 bus 0 scbus7 target 0 lun 2
da2: <HGST HDN 724040ALE640 0X03> Fixed Direct Access SCSI-6 device 
da2: Serial Number 000000000000
da2: 40.000MB/s transfers
da2: 3815447MB (7814037168 512 byte sectors: 255H 63S/T 486401C)
da2: quirks=0x2<NO_6_BYTE>
Comment 3 Greg 2015-02-22 21:26:36 UTC
 $ uname -a
FreeBSD swiss.mlb.akua.com 10.1-STABLE FreeBSD 10.1-STABLE #0 r279138: Sun Feb 22 00:07:35 EST 2015     akua@swiss.mlb.akua.com:/KIN/CACHE/obj/NAP/SRC/10/src/sys/swiss-10-c  amd64
Comment 4 Hans Petter Selasky freebsd_committer 2015-02-24 21:55:59 UTC
Hi,

Can you upgrade to 10-stable.

Also check and/or set hw.usb.xhci.xhci_port_route=-1 in /boot/loader.conf.

Does it make any difference?

--HPS
Comment 5 Hans Petter Selasky freebsd_committer 2015-02-25 08:42:42 UTC
Can you also try this patch:
https://svnweb.freebsd.org/changeset/base/279233

Thank you.

--HPS
Comment 6 Greg 2015-02-25 12:49:33 UTC
Will do these things later today. Did you mean to ask I if I can downgrade to 10.0 stable? From 10.1S -> 10.0S?

Since the latter is where I just upgraded from, I presume that would take me back to full xhci functionality on this chipset.

Thanks
Greg
Comment 7 Hans Petter Selasky freebsd_committer 2015-02-25 14:03:07 UTC
There is only one 10-stable. 10.0 release and 10.1 release is not what I mean.

I want you to try "10-stable" with and without
https://svnweb.freebsd.org/changeset/base/279233

10-stable code is here:
https://svnweb.freebsd.org/base/stable/10/

--HPS
Comment 8 Hans Petter Selasky freebsd_committer 2015-03-04 13:21:00 UTC
Hi,

I think the USB 3.0 controller you've got is of the same kind which was patched
here:

https://svnweb.freebsd.org/changeset/base/279563

Can you also try the patch in r279563 ?

--HPS
Comment 9 Greg 2015-03-07 18:00:41 UTC
Spending time on this today - just so you know I haven't disappeared.

I believe I am on 10 stable - as noted in my uname below (FreeBSD 10.1-STABLE #0 r279138) - which has me a bit confused when you ask me to "upgrade to 10-stable".

When I download the patch to xhci.c and replace the existing one - it does not build.

I put the old xhci.c back and svn updated /usr/src and rebuilt+installed the kernel - which I presume picked up the change you listed right before this message.

(FreeBSD swiss.mlb 10.1-STABLE FreeBSD 10.1-STABLE #1 r279724:279726: Sat Mar  7 12:42:34 EST 2015)

Connecting 4-drive RAID to USB3 port gives the following on USB3 port for lsusb -v

Bus /dev/usb Device /dev/ugen1.2: ID 152d:0539 JMicron Technology Corp. / JMicron USA Technology Corp. 
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               3.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0         9
  idVendor           0x152d JMicron Technology Corp. / JMicron USA Technology Corp.
  idProduct          0x0539 
  bcdDevice           28.03
  iManufacturer          10 JMicron
  iProduct               11 USB to ATA/ATAPI Bridge
  iSerial                 5 000000000000
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           44
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xc0
      Self Powered
    MaxPower                2mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     80 Bulk (Zip)
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               0
        ** UNRECOGNIZED:  06 30 0f 00 00 00
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               0
        ** UNRECOGNIZED:  06 30 0f 00 00 00
Device Status:     0x0001
  Self Powered

The diff against a USB2 connection (snipped outside of the -/+ lines):

-Bus /dev/usb Device /dev/ugen2.4: ID 152d:0539 JMicron Technology Corp. / JMicron USA Technology Corp. 
+Bus /dev/usb Device /dev/ugen1.2: ID 152d:0539 JMicron Technology Corp. / JMicron USA Technology Corp. 

-  bcdUSB               2.10
+  bcdUSB               3.00

-  bMaxPacketSize0        64
+  bMaxPacketSize0         9

-    wTotalLength           32
+    wTotalLength           44

-    iConfiguration          4 USB Mass Storage
+    iConfiguration          0 

-    MaxPower                8mA
+    MaxPower                2mA

-      iInterface              6 MSC Bulk-Only Transport
+      iInterface              0 

-        wMaxPacketSize     0x0200  1x 512 bytes
+        wMaxPacketSize     0x0400  1x 1024 bytes
         bInterval               0
+        ** UNRECOGNIZED:  06 30 0f 00 00 00

-        wMaxPacketSize     0x0200  1x 512 bytes
+        wMaxPacketSize     0x0400  1x 1024 bytes

-Device Qualifier (for other device speed):
-  bLength                10
-  bDescriptorType         6
-  bcdUSB               2.10
-  bDeviceClass            0 (Defined at Interface level)
-  bDeviceSubClass         0 
-  bDeviceProtocol         0 
-  bMaxPacketSize0        64
-  bNumConfigurations      1
+        ** UNRECOGNIZED:  06 30 0f 00 00 00
Comment 10 Greg 2015-03-07 18:04:46 UTC
Adding hw.usb.xhci.xhci_port_route=-1 to boot/loader.conf - still times out on GET MAX LUN while booting and no drives on xhci.
Comment 11 Greg 2015-03-07 18:07:36 UTC
Branch I am on - which I believe is what you want me to be on:

 akua@swiss:/usr/src 13:06 / 
 $ svn info
Path: .
Working Copy Root Path: /NAP/SRC/10/src
URL: svn://svn.freebsd.org/base/stable/10
Relative URL: ^/stable/10
Repository Root: svn://svn.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 279724
Node Kind: directory
Schedule: normal
Last Changed Author: jkim
Last Changed Rev: 279713
Last Changed Date: 2015-03-06 17:31:35 -0500 (Fri, 06 Mar 2015)
Comment 12 Greg 2015-03-07 18:23:11 UTC
Obviously that sysctl won't have an affect w/o the patch applied - I see the tunable was added there.

The link you gave me here: https://svnweb.freebsd.org/changeset/base/279233 appears to be HEAD (not an svn expert) - which doesn't build in 10 stable because...

clang -O2 -pipe -march=native  -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS ... xhci.c:597:21: error: assigning to 'struct usb_bus_methods *' from 'const struct usb_bus_methods *' dsc->sc_bus.methods = &xhci_bus_methods;

... xhci.c:3994:14: error: assigning to 'struct usb_pipe_methods *' from 'const struct usb_pipe_methods *
         ep->methods = &xhci_device_generic_methods;
Comment 13 Hans Petter Selasky freebsd_committer 2015-03-07 21:15:46 UTC
If you want you can simply __DECONST() those pointers and the rest it is complaining about and it will build.

--HPS
Comment 14 braddeicide 2015-06-04 11:43:29 UTC
fyi I just bought one of these cards:

xhci0: <NEC uPD720200 USB 3.0 controller> mem 0xf7c00000-0xf7c01fff irq 16 at device 0.0 on pci4

and it the same error:

usb_alloc_device: Failure selecting configuration index 0:USB_ERR_TIMEOUT, port 2, addr 1 (ignored) 

After setting the sysctl it is now recognized.

sysctl -w hw.usb.xhci.xhci_port_route=-1

da7 at umass-sim1 bus 1 scbus6 target 0 lun 0
da7: <WD Elements 107C 1065> Fixed Direct Access SCSI-6 device
da7: Serial Number <derp>
da7: 400.000MB/s transfers
da7: 2861556MB (732558336 4096 byte sectors: 255H 63S/T 45599C)
da7: quirks=0x2<NO_6_BYTE>

Thanks.
Comment 15 Hans Petter Selasky freebsd_committer 2015-06-05 06:26:02 UTC
Please add a patch to sys/dev/usb/controller/xhci_pci.c

--HPS
Comment 16 Eitan Adler freebsd_committer freebsd_triage 2018-05-28 19:49:13 UTC
batch change:

For bugs that match the following
-  Status Is In progress 
AND
- Untouched since 2018-01-01.
AND
- Affects Base System OR Documentation

DO:

Reset to open status.


Note:
I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.