On 04/11/2014 21:58, Hans Petter Selasky wrote:
On 11/04/14 21:22, Steven Hartland wrote:
On 04/11/2014 17:42, Steven Hartland wrote:
On 04/11/2014 16:45, Hans Petter Selasky wrote:
On 11/04/14 17:40, Steven Hartland wrote:
On 04/11/2014 07:22, Hans Petter Selasky wrote:
On 11/04/14 01:05, Steven Hartland wrote:
Had the problem where the Supermicro IPMI keyboard wouldn't work
on some
machines for a while, tonight I finally had time to play with
all the
options to see if anything would make it work.
Turns out adding the following to loader.conf does fixes the issue:
hint.ehci.0.disabled="1"
So the question is why would this help?
Surely disabling one controller shouldn't make devices attached to
another work?
Hi,
The USB device is failing to enumerate. Are you sure there is no
XHCI
controller on this device?
I did try removing xhci from my kernel config, but that had no
effect,
only when I disabled the ehci controller did it correctly
enumerate the
devices attached to the uhci controller.
Attached is the outuput from pciconf -l -v in case that helps. If
there's anything else I can provide which will help just let me know.
For reference I'm currently testing 10.1-RC4 on this box.
Regards
Steve
Maybe you can check the PCI IDs with Linux EHCI driver, if your
hardware requires some special quirks?
I cant find any mention of quirks for the Intel USB controller PCI IDs
but I might be looking in the wrong place, do you have a link to what
I should be searching though?
I did however find the following which is for the exact device I'm
having issues with and seems to indicate the HW might have an issue
with HighSpeed mode.
https://lkml.org/lkml/2012/4/19/224
http://lkml.iu.edu//hypermail/linux/kernel/1204.3/03115.html
Which makes me wonder if hw.usb.ehci.no_hs=1 would also result in a
working device.
Ok so without the disabled hit but with no_hs=1 the devices still works
and usbconfig list shows:
ugen1.1: <UHCI root HUB Intel> at usbus1, cfg=0 md=HOST spd=FULL
(12Mbps) pwr=SAVE (0mA)
ugen0.1: <UHCI root HUB Intel> at usbus0, cfg=0 md=HOST spd=FULL
(12Mbps) pwr=SAVE (0mA)
ugen3.1: <EHCI root HUB Intel> at usbus3, cfg=0 md=HOST spd=HIGH
(480Mbps) pwr=SAVE (0mA)
ugen2.1: <UHCI root HUB Intel> at usbus2, cfg=0 md=HOST spd=FULL
(12Mbps) pwr=SAVE (0mA)
ugen2.2: <Multidevice Peppercon AG> at usbus2, cfg=0 md=HOST spd=FULL
(12Mbps) pwr=ON (100mA)
and messages:
Nov 4 19:28:53 test1 kernel: usbus0 on uhci0
Nov 4 19:28:53 test1 kernel: usbus1 on uhci1
Nov 4 19:28:53 test1 kernel: usbus2 on uhci2
Nov 4 19:28:53 test1 kernel: usbus3: EHCI version 1.0
Nov 4 19:28:53 test1 kernel: usbus3 on ehci0
Nov 4 19:28:53 test1 kernel: usbus0: 12Mbps Full Speed USB v1.0
Nov 4 19:28:53 test1 kernel: usbus1: 12Mbps Full Speed USB v1.0
Nov 4 19:28:53 test1 kernel: usbus2: 12Mbps Full Speed USB v1.0
Nov 4 19:28:53 test1 kernel: usbus3: 480Mbps High Speed USB v2.0
Nov 4 19:28:53 test1 kernel: ugen1.1: <Intel> at usbus1
Nov 4 19:28:53 test1 kernel: uhub0: <Intel UHCI root HUB, class 9/0,
rev 1.00/1.00, addr 1> on usbus1
Nov 4 19:28:53 test1 kernel: ugen0.1: <Intel> at usbus0
Nov 4 19:28:53 test1 kernel: uhub1: <Intel UHCI root HUB, class 9/0,
rev 1.00/1.00, addr 1> on usbus0
Nov 4 19:28:53 test1 kernel: ugen3.1: <Intel> at usbus3
Nov 4 19:28:53 test1 kernel: uhub2: <Intel EHCI root HUB, class 9/0,
rev 2.00/1.00, addr 1> on usbus3
Nov 4 19:28:53 test1 kernel: ugen2.1: <Intel> at usbus2
Nov 4 19:28:53 test1 kernel: uhub3: <Intel UHCI root HUB, class 9/0,
rev 1.00/1.00, addr 1> on usbus2
Nov 4 19:28:53 test1 kernel: Root mount waiting for: usbus3
Nov 4 19:28:53 test1 kernel: Root mount waiting for: usbus3
Nov 4 19:28:53 test1 kernel: Root mount waiting for: usbus3
Nov 4 19:28:53 test1 kernel: ugen2.2: <Peppercon AG> at usbus2
Nov 4 19:28:53 test1 kernel: ukbd0: <Peppercon AG Multidevice, class
0/0, rev 2.00/0.01, addr 2> on usbus2
So now I'm even more confused :(
Maybe we could set the no-hs as a fallback from the EHCI controller to
the UHC/OHCI ones ...
Looks like a HW issue. BTW: are there any high speed devices connected
to this board?
The only connected devices are the onboard IPMI which provides the
keyboard and mouse + virtual media.
From what I can see its meant to be USB 2.0 compilient but there's a
lot of reports of issues with them, so I wouldn't rule out a
implementation issue.
The following seems related:
http://www.supermicro.com/support/faqs/faq.cfm?faq=11530
I've asked Supermicro for an updated firmware, we're already running the
latest they have on their site (1.64)
Falling back to full speed if high speed fails to negotiate seems like a
good plan though. Do you think that's going to be easy to do? Count me
in as tester if that will help :)
Regards
Steve
_______________________________________________
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
