ehci breaking Supermicro IPMI keyboard on uhci?

[Hans Petter Selasky]

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