From owner-freebsd-current@FreeBSD.ORG Tue Apr 27 20:26:05 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 0472E106566B; Tue, 27 Apr 2010 20:26:05 +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 A0F2D8FC15; Tue, 27 Apr 2010 20:26:04 +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 o3RKPwpM064698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Apr 2010 13:25:59 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Message-ID: <4BD74861.30603@FreeBSD.org> Date: Tue, 27 Apr 2010 13:26:09 -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> <201004221530.41197.jhb@freebsd.org> <4BD0AC89.5080306@FreeBSD.org> <201004271204.43057.jhb@freebsd.org> In-Reply-To: <201004271204.43057.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 20:26:05 -0000 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. 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 -Maxim