Date: Wed, 05 Nov 2014 08:17:30 +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: <5459CF0A.5080900@selasky.org> In-Reply-To: <5459609B.10502@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> <54594C20.6090006@selasky.org> <5459609B.10502@multiplay.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On 11/05/14 00:26, Steven Hartland wrote: > > 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 :) Hi, It's just a matter of switching a bit in the port status register of the EHCI controller. --HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5459CF0A.5080900>