Date: Tue, 04 Nov 2014 22:58:56 +0100 From: Hans Petter Selasky <hps@selasky.org> To: Steven Hartland <steven@multiplay.co.uk>, "freebsd-usb@freebsd.org" <freebsd-usb@freebsd.org> Subject: Re: ehci breaking Supermicro IPMI keyboard on uhci? Message-ID: <54594C20.6090006@selasky.org> In-Reply-To: <54593576.9050100@multiplay.co.uk> References: <5458184E.5020801@multiplay.co.uk> <54587E9B.50709@selasky.org> <54590195.7090600@multiplay.co.uk> <545902B4.8030001@selasky.org> <54591009.5020401@multiplay.co.uk> <54593576.9050100@multiplay.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
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 :( > > Regards > Steve > 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? --HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54594C20.6090006>