Date: Tue, 04 Nov 2014 23:26:19 +0000 From: Steven Hartland <steven@multiplay.co.uk> To: Hans Petter Selasky <hps@selasky.org>, "freebsd-usb@freebsd.org" <freebsd-usb@freebsd.org> Subject: Re: ehci breaking Supermicro IPMI keyboard on uhci? Message-ID: <5459609B.10502@multiplay.co.uk> In-Reply-To: <54594C20.6090006@selasky.org> 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> <54594C20.6090006@selasky.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5459609B.10502>