From owner-freebsd-usb@FreeBSD.ORG Wed Nov 5 07:17:21 2014 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8B9E2E3E for ; Wed, 5 Nov 2014 07:17:21 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 38793BA6 for ; Wed, 5 Nov 2014 07:17:21 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id F19A41FE022; Wed, 5 Nov 2014 08:17:18 +0100 (CET) Message-ID: <5459CF0A.5080900@selasky.org> Date: Wed, 05 Nov 2014 08:17:30 +0100 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Steven Hartland , "freebsd-usb@freebsd.org" Subject: Re: ehci breaking Supermicro IPMI keyboard on uhci? 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> In-Reply-To: <5459609B.10502@multiplay.co.uk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 07:17:21 -0000 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: at usbus1, cfg=0 md=HOST spd=FULL >>> (12Mbps) pwr=SAVE (0mA) >>> ugen0.1: at usbus0, cfg=0 md=HOST spd=FULL >>> (12Mbps) pwr=SAVE (0mA) >>> ugen3.1: at usbus3, cfg=0 md=HOST spd=HIGH >>> (480Mbps) pwr=SAVE (0mA) >>> ugen2.1: at usbus2, cfg=0 md=HOST spd=FULL >>> (12Mbps) pwr=SAVE (0mA) >>> ugen2.2: 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: at usbus1 >>> Nov 4 19:28:53 test1 kernel: uhub0: >> rev 1.00/1.00, addr 1> on usbus1 >>> Nov 4 19:28:53 test1 kernel: ugen0.1: at usbus0 >>> Nov 4 19:28:53 test1 kernel: uhub1: >> rev 1.00/1.00, addr 1> on usbus0 >>> Nov 4 19:28:53 test1 kernel: ugen3.1: at usbus3 >>> Nov 4 19:28:53 test1 kernel: uhub2: >> rev 2.00/1.00, addr 1> on usbus3 >>> Nov 4 19:28:53 test1 kernel: ugen2.1: at usbus2 >>> Nov 4 19:28:53 test1 kernel: uhub3: >> 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: at usbus2 >>> Nov 4 19:28:53 test1 kernel: ukbd0: >> 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