On Sunday 21 October 2012 21:27:54 Uffe Jakobsen wrote:
> >Number:         172937
> >Category:       usb
> >Synopsis:       FreeBSD 9.1-RC2 usb3 port disconnects
> >Confidential:   no
> >Severity:       non-critical
> >Priority:       low
> >Responsible:    freebsd-usb
> >State:          open
> >Quarter:
> >Keywords:
> >Date-Required:
> >Class:          sw-bug
> >Submitter-Id:   current-users
> >Arrival-Date:   Sun Oct 21 19:30:01 UTC 2012
> >Closed-Date:
> >Last-Modified:
> >Originator:     Uffe Jakobsen
> >Release:        FreeBSD 9.1-RC2
> >Organization:
> 
> >Environment:
> FreeBSD asus-u32u 9.1-RC2 FreeBSD 9.1-RC2 #0 r241106: Mon Oct  1 18:26:44
> UTC 2012     root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC 
> amd64
> 
> >Description:
> Running FreeBSD 9.1-RC2 amd64 on an Asus U32U 13" Notebook with 2x USB3
> port and 1x USB2 port produces strange disconnects of the equipment
> connected to USB3.0 (blue connectors) ports.
> 
> Mouse and keyboard is connected through a hub. The scenario is the
> following: suddenly mouse and keyboard stops working - looking at the hub
> I can see that is disconnected - some seconds later the hub leds indicate
> that it is connected and the keyboard and mouse works again for some
> minutes. Some days the units cannot reconnect after lots of disconnects
> and reboot seems to be the only option. Also connecting the keyboard and
> mouse directly to the USB3 ports (without the hub) produces the problem.
> Same equipment (keyboard, wireless mouse through hub) works without
> problems on the single USB2.0 port on the same system.
> 
> usbconfig:
> ugen0.1: <OHCI root HUB ATI> at usbus0, cfg=0 md=HOST spd=FULL (12Mbps)
> pwr=SAVE ugen1.1: <EHCI root HUB ATI> at usbus1, cfg=0 md=HOST spd=HIGH
> (480Mbps) pwr=SAVE ugen2.1: <OHCI root HUB ATI> at usbus2, cfg=0 md=HOST
> spd=FULL (12Mbps) pwr=SAVE ugen3.1: <EHCI root HUB ATI> at usbus3, cfg=0
> md=HOST spd=HIGH (480Mbps) pwr=SAVE ugen4.1: <XHCI root HUB 0x1b21> at
> usbus4, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=SAVE ugen3.2: <ASUS USB2.0
> WebCam 04G6200086K1AN1B70007KB> at usbus3, cfg=0 md=HOST spd=HIGH
> (480Mbps) pwr=ON ugen2.2: <product 0x3304 vendor 0x13d3> at usbus2, cfg=0
> md=HOST spd=FULL (12Mbps) pwr=ON ugen4.2: <Generic USB Hub ALCOR> at
> usbus4, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE ugen4.3: <Dell USB
> Keyboard Dell> at usbus4, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON ugen4.4:
> <Microsoft Nano Transceiver v2.0 Microsoft> at usbus4, cfg=0 md=HOST
> spd=FULL (12Mbps) pwr=ON
> 
> 
> The only trace of the incidents can be found in dmesg:
> 
> dmesg boot messages containing usb (dmesg |grep -i usb)
> 
> ohci0: <AMD SB7x0/SB8x0/SB9x0 USB controller> mem 0xfeb4b000-0xfeb4bfff irq
> 18 at device 18.0 on pci0 usbus0 on ohci0
> ehci0: <AMD SB7x0/SB8x0/SB9x0 USB 2.0 controller> mem 0xfeb4a000-0xfeb4a0ff
> irq 17 at device 18.2 on pci0 usbus1: EHCI version 1.0
> usbus1 on ehci0
> ohci1: <AMD SB7x0/SB8x0/SB9x0 USB controller> mem 0xfeb49000-0xfeb49fff irq
> 18 at device 19.0 on pci0 usbus2 on ohci1
> ehci1: <AMD SB7x0/SB8x0/SB9x0 USB 2.0 controller> mem 0xfeb48000-0xfeb480ff
> irq 17 at device 19.2 on pci0 usbus3: EHCI version 1.0
> usbus3 on ehci1
> xhci0: <XHCI (generic) USB 3.0 controller> mem 0xfe900000-0xfe907fff irq 18
> at device 0.0 on pci5 usbus4 on xhci0
> usbus0: 12Mbps Full Speed USB v1.0
> usbus1: 480Mbps High Speed USB v2.0
> usbus2: 12Mbps Full Speed USB v1.0
> usbus3: 480Mbps High Speed USB v2.0
> usbus4: 5.0Gbps Super Speed USB v3.0
> ugen0.1: <ATI> at usbus0
> uhub0: <ATI OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus0
> ugen1.1: <ATI> at usbus1
> uhub1: <ATI EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus1
> ugen2.1: <ATI> at usbus2
> uhub2: <ATI OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus2
> ugen3.1: <ATI> at usbus3
> uhub3: <ATI EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus3
> ugen4.1: <0x1b21> at usbus4
> uhub4: <0x1b21 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus4
> ugen4.2: <Dell> at usbus4
> ukbd0: <Dell Dell USB Keyboard, class 0/0, rev 1.10/3.01, addr 1> on usbus4
> ugen3.2: <04G6200086K1AN1B70007KB> at usbus3
> ugen2.2: <vendor 0x13d3> at usbus2
> ubt0: <vendor 0x13d3 product 0x3304, class 224/1, rev 1.10/0.01, addr 2> on
> usbus2
> 
> 
> dmesg logging from disconnect followed by automatic reconnect a few seconds
> later:
> 
> ugen4.2: <ALCOR> at usbus4 (disconnected)
> uhub5: at uhub4, port 3, addr 1 (disconnected)
> ugen4.3: <Dell> at usbus4 (disconnected)
> ukbd0: at uhub5, port 2, addr 2 (disconnected)
> ugen4.4: <Microsoft> at usbus4 (disconnected)
> ukbd1: at uhub5, port 4, addr 3 (disconnected)
> ums0: at uhub5, port 4, addr 3 (disconnected)
> uhid0: at uhub5, port 4, addr 3 (disconnected)
> ugen4.2: <ALCOR> at usbus4
> uhub5: <ALCOR Generic USB Hub, class 9/0, rev 1.10/3.12, addr 1> on usbus4
> uhub5: 4 ports with 4 removable, self powered
> ugen4.3: <Dell> at usbus4
> ukbd0: <Dell Dell USB Keyboard, class 0/0, rev 1.10/3.01, addr 2> on usbus4
> kbd2 at ukbd0
> ugen4.4: <Microsoft> at usbus4
> ukbd1: <Microsoft Microsoft Nano Transceiver v2.0, class 0/0, rev
> 2.00/6.34, addr 3> on usbus4 kbd3 at ukbd1
> ums0: <Microsoft Microsoft Nano Transceiver v2.0, class 0/0, rev 2.00/6.34,
> addr 3> on usbus4 ums0: 5 buttons and [XYZT] coordinates ID=26
> ums0: 0 buttons and [T] coordinates ID=0
> uhid0: <Microsoft Microsoft Nano Transceiver v2.0, class 0/0, rev
> 2.00/6.34, addr 3> on usbus4
> 

Hi,

Is your ALCOR HUB FULL speed?

I know these HUBS have some problems, and you might want to try connecting 
through another branded HUB.

--HPS

Hi,

On 2012-10-24 10:04, Hans Petter Selasky wrote:
>
> Is your ALCOR HUB FULL speed?
>

Yes it is.

> I know these HUBS have some problems, and you might want to try connecting
> through another branded HUB.
>

I discovered that the BIOS was several releases away from the current - 
so I upgraded the BIOS - and I haven't seen the problem for some days 
now. I cannot really explain the connection between this problem and the 
BIOS but it is gone now - so I guess that we can close this case.

Sorry for the noise.

I think that this case can be closed