From owner-freebsd-current@FreeBSD.ORG Tue Apr 27 20:55:54 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 CF55B1065670; Tue, 27 Apr 2010 20:55:54 +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 8CB4F8FC15; Tue, 27 Apr 2010 20:55:54 +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 27C0D46B38; Tue, 27 Apr 2010 16:55:54 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 292EE8A01F; Tue, 27 Apr 2010 16:55:53 -0400 (EDT) From: John Baldwin To: Maxim Sobolev Date: Tue, 27 Apr 2010 16:54:07 -0400 User-Agent: KMail/1.12.1 (FreeBSD/7.3-CBSD-20100217; KDE/4.3.1; amd64; ; ) References: <4BCD5A7B.2070505@FreeBSD.org> <201004271204.43057.jhb@freebsd.org> <4BD74861.30603@FreeBSD.org> In-Reply-To: <4BD74861.30603@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201004271654.07340.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 27 Apr 2010 16:55:53 -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 20:55:55 -0000 On Tuesday 27 April 2010 4:26:09 pm Maxim Sobolev wrote: > John Baldwin wrote: > > 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? > > Our syscons does keyboard probing two times - once early during kernel > initialization before most of the subsystems have been initialized yet, > and then "real" probing later in boot process. Interesting thing is that > initially keyboard looks present. Reading status port in > atkbdc_configure() gives value other than 0xff, although reading is > thousand times slower than usually. This causes syscons try attaching > it. Even though reading status port works, apparently either emulation > is not complete or there is some other issue, so that it never responds > to some commands. Slow access and lack of response results in > wait_for_data() function waiting several minutes instead of 200ms as > designed. This what causes that 6-10 minutes delay in boot process. I believe the USB driver has disabled the keyboard emulation by the time the second probe happens in syscons. Can you try disabling legacy USB support in the BIOS just to make sure that is what causes the delay? > In fact I've also tried sending 0xAA command instead of just checking > that value read from the status port is not 0xFF, and it actually > completed fine at this point. The controller has returned 0x55 as > expected. Therefore, I believe measuring inb() delay is the only > reasonable way to avoid that big boot delay at this point. > > Later on, when we probe/attach keyboard second time (in atkbdc_isa.c) > reading status port returns 0xff, so the we can fail attachment process > immediately. However, this is not a big issue since at this point > reading from status port is as fast as any other ISA inb() operations, > so it doesn't cause any noticeable delay. > > Here is the latest version of the patch: > > http://sobomax.sippysoft.com/atkbdc.diff Hmm, still has the issue that we can't assume a TSC on i386. I would still commit the easy bits to change various '#if defined(__i386__)' to '#if defined(__i386__) || defined(__amd64__)' now. One thing that could make this cleaner would be to have a macro defined something like this in atkbdc.c: /* CPU will stay inside loops for 100msec at most. */ #ifdef __amd64__ #define KBD_RETRY(kbd) (100000 / ((KBDD_DELAYTIME * 2) + kbdc->read_delay)) #else #define KBD_RETRY(kbd) (5000) #endif and then use 'KBD_RETRY(kbd)' to initialize 'retry' in various places. -- John Baldwin