ehci breaking Supermicro IPMI keyboard on uhci?

Wed Nov 5 07:17:21 UTC 2014

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