From owner-freebsd-current@FreeBSD.ORG Tue Apr 27 21:06:29 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 D978B106567C; Tue, 27 Apr 2010 21:06:29 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id 997E88FC18; Tue, 27 Apr 2010 21:06:29 +0000 (UTC) Received: from [192.168.1.38] (S0106005004e13421.vs.shawcable.net [70.71.175.212]) (authenticated bits=0) by sippysoft.com (8.14.3/8.14.3) with ESMTP id o3RL6PGR064914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Apr 2010 14:06:26 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Message-ID: <4BD751DD.80407@FreeBSD.org> Date: Tue, 27 Apr 2010 14:06:37 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: John Baldwin References: <4BCD5A7B.2070505@FreeBSD.org> <201004271204.43057.jhb@freebsd.org> <4BD74861.30603@FreeBSD.org> <201004271654.07340.jhb@freebsd.org> In-Reply-To: <201004271654.07340.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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:06:30 -0000 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. >> 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. -Maxim