From owner-freebsd-current@FreeBSD.ORG Tue Apr 27 21:27:55 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 1EA2B106566C; Tue, 27 Apr 2010 21:27:55 +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 D09888FC16; Tue, 27 Apr 2010 21:27: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 63DD346B09; Tue, 27 Apr 2010 17:27:54 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 43D338A021; Tue, 27 Apr 2010 17:27:53 -0400 (EDT) From: John Baldwin To: Maxim Sobolev Date: Tue, 27 Apr 2010 17:25:36 -0400 User-Agent: KMail/1.12.1 (FreeBSD/7.3-CBSD-20100217; KDE/4.3.1; amd64; ; ) References: <4BCD5A7B.2070505@FreeBSD.org> <201004271654.07340.jhb@freebsd.org> <4BD751DD.80407@FreeBSD.org> In-Reply-To: <4BD751DD.80407@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201004271725.36518.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 27 Apr 2010 17:27: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 21:27:55 -0000 On Tuesday 27 April 2010 5:06:37 pm Maxim Sobolev wrote: > John Baldwin wrote: > > 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? > > Unfortunately it's not possible. Hosting provider doesn't allow me to > have access to BIOS settings. Hmm, ok. > >> 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. > > Please take a closer look. Use of rdtsc() in this version is conditonal > on __amd64__ only. Ok, that does look a lot better. I don't like having to use rdtsc() to time the delay but I don't have any better suggestions. I think you should add a block comment above the calibration section to explain why you are doing it (i.e. some BIOSes' PS/2 emulation take a really long time to execute). -- John Baldwin