From owner-freebsd-current@FreeBSD.ORG Wed Apr 28 17:25: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 68F791065670; Wed, 28 Apr 2010 17:25:05 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from mail-yw0-f193.google.com (mail-yw0-f193.google.com [209.85.211.193]) by mx1.freebsd.org (Postfix) with ESMTP id C7FD48FC13; Wed, 28 Apr 2010 17:25:04 +0000 (UTC) Received: by ywh31 with SMTP id 31so6999903ywh.3 for ; Wed, 28 Apr 2010 10:24:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ix+N+ZkFCvCs4Fz0wgGbCuhW1CMTylDbPZMBLhrxB1M=; b=jBEc8hfioP/of8zdKX2uI1bkdVVtiRgHVHIEkoo31918OguJhU26a1g09njMqXkJeV gbib/e9z1gCa2/vbDtAJu7S9r7x8YB+WIUg3wP0cbzSHByMtmgBxPGtj50xPpvULC/oE C9b9aSrpBSNKVOuSF4wWT+pehDe9kROe6riJ8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=pI6OtLl8ZsgY0duFBJDxU651Qtp7LS5Wv0maLHCyW22GGN3KWq1iqVNU1JJ/zHxKdi vIPFXk/Rgu+IVj1PuJf+tXS+e74vQOPPE7gnZZx/4nPJP1vVZ0PJaS7OFEQCkcGGyqjE UptWeW3Eb5Z8rhvD8Qsrz/zkrl9NA3NjiJlX4= MIME-Version: 1.0 Received: by 10.101.102.9 with SMTP id e9mr2926076anm.86.1272475496709; Wed, 28 Apr 2010 10:24:56 -0700 (PDT) Received: by 10.100.194.19 with HTTP; Wed, 28 Apr 2010 10:24:55 -0700 (PDT) In-Reply-To: <4BD76E04.30604@FreeBSD.org> References: <4BCD5A7B.2070505@FreeBSD.org> <201004271654.07340.jhb@freebsd.org> <4BD751DD.80407@FreeBSD.org> <201004271725.36518.jhb@freebsd.org> <4BD76E04.30604@FreeBSD.org> Date: Wed, 28 Apr 2010 13:24:55 -0400 Message-ID: From: Alexander Sack To: Maxim Sobolev Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: Wed, 28 Apr 2010 17:25:05 -0000 On Tue, Apr 27, 2010 at 7:06 PM, Maxim Sobolev wrote: > Alexander Sack wrote: >> >> On Tue, Apr 27, 2010 at 5:25 PM, John Baldwin wrote: >>> >>> 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. =A0I'm still thinking about the other change. =A0I wonder if w= e can >>>>>>> figure >>>>>>> out that a keyboard isn't present sooner somehow? =A0Do you know if= the >>>>>>> keyboard >>>>>>> appears to be present but just slow vs if the keyboard is eventuall= y >>>>>>> found to >>>>>>> not be present? >>>>>> >>>>>> Our syscons does keyboard probing two times - once early during kern= el >>>>>> 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 attachin= g >>>>>> it. Even though reading status port works, apparently either emulati= on >>>>>> 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. =A0Can 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. >> >> Stunt double: =A0I tried it and it has no effect. =A0The waits in atkdbd >> kills it with or without USB legacy support on. =A0The wait on this >> machine is about 1-2 minutes before boot. =A0Just another data point. > > Have you tried my patch? Does it help? Maxim, yes I have. Works much better. Wait time is nominal. I would definitely document the time delay code as its non-intuitive looking at it. -aps