From owner-freebsd-current@FreeBSD.ORG Tue Apr 27 16:51:43 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB81A106564A; Tue, 27 Apr 2010 16:51:43 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 650898FC23; Tue, 27 Apr 2010 16:51:43 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 1925D46B52; Tue, 27 Apr 2010 12:51:43 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 1C8BE8A026; Tue, 27 Apr 2010 12:51:42 -0400 (EDT) From: John Baldwin To: Maxim Sobolev Date: Tue, 27 Apr 2010 12:04:43 -0400 User-Agent: KMail/1.12.1 (FreeBSD/7.3-CBSD-20100217; KDE/4.3.1; amd64; ; ) References: <4BCD5A7B.2070505@FreeBSD.org> <201004221530.41197.jhb@freebsd.org> <4BD0AC89.5080306@FreeBSD.org> In-Reply-To: <4BD0AC89.5080306@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201004271204.43057.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 27 Apr 2010 12:51:42 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-current@freebsd.org, mj@feral.com Subject: Re: FreeBSD kernel doesn't boot on FUJITSU PRIMERGY RX200 S5 server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 16:51:43 -0000 On Thursday 22 April 2010 4:07:37 pm Maxim Sobolev wrote: > John Baldwin wrote: > > On Thursday 22 April 2010 2:28:26 pm Maxim Sobolev wrote: > >> John Baldwin wrote: > >>> On Thursday 22 April 2010 6:05:04 am Maxim Sobolev wrote: > >>>> Maxim Sobolev wrote: > >>>>> There is already a code to detect non-existing AT keyboard and avoid > >>>>> attaching atkbd to it. The code is i386-only at the moment, I am trying > >>>>> to figure out how to modify it so that it works on amd64 as well. > >>>> Looks like this huge delay is caused by the inb() being astonishingly > >>>> slow, which is not factored by the timeout routines. Reading keyboard > >>>> status port once takes about 0.003s! I am not sure if it's common > >>>> behaviour of the platform, or something specific to this particular > >>>> model. Do you know by any chance? > >>> Well, many BIOSes trigger an SMI# when doing inb/outb to the keyboard ports so > >>> they can emulate a PS/2 keyboard when a USB keyboard is inserted. Do you have > >>> any BIOS options related to the USB legacy compat? I know of the Nehalem > >>> systems I've seen they have a separate option for controlling port 60/64 > >>> emulation which we leave disabled by default. > >> That makes sense. Unfortunately I don't have access to the BIOS > >> settings. This is a hosted system, and the provider keeps BIOS password > >> for themselves. > >> > >> I have a patch that fixes that issue by measuring status register > >> reading time first and then factoring it in the calculations of the > >> number of retries: > >> > >> http://sobomax.sippysoft.com/atkbdc.diff > >> > >> It also applies the same logic to detect broken/non-existing keyboard > >> controller to amd64 as we do to the i386. I'd appreciate if you can do a > >> review. > > > > Hmm, not all i386 CPUs that we support have a TSC. Is the change to > > atkbdc_isa.c sufficient to fix the hang? If so, I'd rather just commit that > > bit and leave out the read_delay changes. > > No, it's not sufficient. The problem here is that for some reason that > test passes on that system (probably emulation works) and so that normal > keyboard attach routine is invoked early in boot, when we don't even > have clock initialized. What if I make TSC-related changes amd64? Will > that be OK? Hmm, I think you should definitely commit the atkbdc_isa.c change first of all. I'm still thinking about the other change. I wonder if we can figure out that a keyboard isn't present sooner somehow? Do you know if the keyboard appears to be present but just slow vs if the keyboard is eventually found to not be present? -- John Baldwin