usb/181159: Problem attaching USB device

[Hans Petter Selasky]

On 11/06/13 16:10, Roland Behme wrote:
> The following reply was made to PR usb/181159; it has been noted by GNATS.
>
> From: Roland Behme <rb at nugman.de>
> To: bug-followup at FreeBSD.org
> Cc:
> Subject: Re: usb/181159: Problem attaching USB device
> Date: Wed, 06 Nov 2013 16:02:10 +0100
>
>   I think I have a similar problem with an ASRock H87 Pro4 mainboard here.
>   First I tried with FreeBSD 9.2 RELEASE, then after I found this PR I
>   switched to 9.2 STABLE in order to try the patch mentioned above.
>   Unfortunately unlike for my fellow poster, it doesn't help in my case.
>
>   When I enable the USB 3.0 feature in UEFI BIOS, the plugged in devices
>   are not attached.
>
>   This is what I get from dmesg:
>
>   xhci0: <Intel Lynx Point USB 3.0 controller> mem 0xf0420000-0xf042ffff
>   irq 16 at device 20.0 on pci0
>   xhci0: 32 byte context size.
>   xhci0: Port routing mask set to 0xffffffff
>   usbus0 on xhci0
>   [...]
>   usbus0: 5.0Gbps Super Speed USB v3.0
>   ugen0.1: <0x8086> at usbus0
>   uhub0: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0
>   [...]
>   Root mount waiting for: usbus0
>   uhub0: 21 ports with 21 removable, self powered
>   Root mount waiting for: usbus0
>   xhci0: Port routing mask set to 0x00000000
>   usb_alloc_device: device init 2 failed (USB_ERR_IOERROR, ignored)
>   ugen0.2: <Unknown> at usbus0 (disconnected)
>   uhub_reattach_port: could not allocate new device
>
>
>
>   At least I'm able to use my USB devices when I disable USB 3.0 in UEFI
>   BIOS. Then dmesg looks like this:
>
>   ehci0: <EHCI (generic) USB 2.0 controller> mem 0xf0424000-0xf04243ff irq
>   16 at device 26.0 on pci0
>   usbus0: EHCI version 1.0
>   usbus0 on ehci0
>   [...]
>   ehci1: <EHCI (generic) USB 2.0 controller> mem 0xf0423000-0xf04233ff irq
>   23 at device 29.0 on pci0
>   usbus1: EHCI version 1.0
>   usbus1 on ehci1
>   [...]
>   usbus0: 480Mbps High Speed USB v2.0
>   usbus1: 480Mbps High Speed USB v2.0
>   ugen0.1: <Intel> at usbus0
>   uhub0: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus0
>   ugen1.1: <Intel> at usbus1
>   uhub1: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus1
>   [...]
>   Root mount waiting for: usbus1 usbus0
>   uhub0: 2 ports with 2 removable, self powered
>   uhub1: 2 ports with 2 removable, self powered
>   Root mount waiting for: usbus1 usbus0
>   ugen0.2: <vendor 0x8087> at usbus0
>   uhub2: <vendor 0x8087 product 0x8008, class 9/0, rev 2.00/0.05, addr 2>
>   on usbus0
>   ugen1.2: <vendor 0x8087> at usbus1
>   uhub3: <vendor 0x8087 product 0x8000, class 9/0, rev 2.00/0.05, addr 2>
>   on usbus1
>   uhub2: 6 ports with 6 removable, self powered
>   uhub3: 8 ports with 8 removable, self powered
>   ugen1.3: <American Power Conversion> at usbus1
>   Root mount waiting for: usbus1
>   ugen1.4: <Sunplus Technology Inc.> at usbus1
>   umass0: <Bulk Only Interface> on usbus1
>   umass0:  SCSI over Bulk-Only; quirks = 0x4101
>   umass0:6:0:-1: Attached to scbus6
>
>
>   So in EHCI mode everything is running, XHCI fails to attach the devices.
>   Any suggestions?

Hi,

Maybe you could try to get some information from the manufacturer, or 
look at how the ports are wired on the mainboard itself. I tested this a 
while back in a similar setup, and the command sequence in question can 
be successfully exercised by the XHCI if no device is connected to the 
port. I found the when a XHCI port is connected to a real device, some 
of the initial XHCI commands fail with the invalid parameter error code. 
This of course is not true, and I think the manufacturer has put some 
hidden magic there we need to figure out to get this working.

--HPS