From owner-freebsd-usb@FreeBSD.ORG Tue Nov 4 23:27:47 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 4D148C51 for ; Tue, 4 Nov 2014 23:27:47 +0000 (UTC) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CEFE6F1 for ; Tue, 4 Nov 2014 23:27:46 +0000 (UTC) Received: by mail-wi0-f178.google.com with SMTP id q5so514378wiv.5 for ; Tue, 04 Nov 2014 15:27:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=FIGlRzI582pKWbzLMzvsEsfIz04zE1hRlaVZ75cBLFo=; b=LLqH6hrKT1U1r9P4i59w5ZvFjWCNl6cgaom/RyCjx5G2c1Mcdf9H5pHBao4G8/lBTY a/C5HjK7qSIyG3gZ5T14I8EPdRVOteiU5Q2q1xF5ZiwpwSJx6Mfs3QMNYv/WThaW0Lbo SHMrF2zCcZx2lkDafaXWzceOhjckyhDtoEWI316eSMJxWW7a1PHzDz4TRS65pyCYgtbD D1HOnzq1DaO7if2iGMcX5txh6tUKZR5ygDqko9qZts09P+6aOR0b06hND307LsvwQAOq 7UO8tOcNKTf96kVTu7bgd0ZVOaHr3UbWSM6HHZ35zebKnmm6hmbEH3iX55uDPlRgzr+X 0fXw== X-Gm-Message-State: ALoCoQnj2noVPEk0C+19zGUprWBforAIzhONKu4IxYRKAFaQBjS4T7ksbzDhBjMwh9A7TaAvRNfA X-Received: by 10.194.77.142 with SMTP id s14mr3801422wjw.94.1415143664078; Tue, 04 Nov 2014 15:27:44 -0800 (PST) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id bf6sm2116571wjb.13.2014.11.04.15.27.42 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Nov 2014 15:27:43 -0800 (PST) Message-ID: <5459609B.10502@multiplay.co.uk> Date: Tue, 04 Nov 2014 23:26:19 +0000 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Hans Petter Selasky , "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> In-Reply-To: <54594C20.6090006@selasky.org> 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: Tue, 04 Nov 2014 23:27:47 -0000 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 :) Regards Steve