From owner-freebsd-current@FreeBSD.ORG Tue Apr 27 19:11:16 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 81A46106566B; Tue, 27 Apr 2010 19:11:16 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from mail-gx0-f211.google.com (mail-gx0-f211.google.com [209.85.217.211]) by mx1.freebsd.org (Postfix) with ESMTP id 148678FC21; Tue, 27 Apr 2010 19:11:15 +0000 (UTC) Received: by gxk3 with SMTP id 3so6506132gxk.13 for ; Tue, 27 Apr 2010 12:11:10 -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=wLIiXEurL8yw2+osM0n1WDNl9puV9hbXmD483far+6g=; b=bvtwVRMnvQgEjWwJx22FMGrOr7aTgIxVYzIxs/JQLlW7IA6y1J4zeTStiKBpz7rrPe 943+T3G/vRU5CA6PTp2idUmNOLS7FK49b0+005k2yk12Io1x/Ca0Q5B2VxBh4UvIVFqT SOLvFw34P4JdgerW+fwje8UZJAnuXKXttUsis= 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=T1jnnnXJ78NymGpqq1POrhJnKTbrq9PXttxw3ipIqF4YGjvVdIh3fds7zGvK5mVb6J +G5KHOsryACtzhyNirosboc6i6IzGaZeB6TnnjJ03XNqjt9WC7ZQQc8x9BgZIiQZ1GCu RlWutYnztmoxDEUSXQ2GTqrgWTBkFIhOaNwlo= MIME-Version: 1.0 Received: by 10.101.116.2 with SMTP id t2mr1551541anm.242.1272395470508; Tue, 27 Apr 2010 12:11:10 -0700 (PDT) Received: by 10.100.194.19 with HTTP; Tue, 27 Apr 2010 12:11:10 -0700 (PDT) In-Reply-To: <201004271204.43057.jhb@freebsd.org> References: <4BCD5A7B.2070505@FreeBSD.org> <201004221530.41197.jhb@freebsd.org> <4BD0AC89.5080306@FreeBSD.org> <201004271204.43057.jhb@freebsd.org> Date: Tue, 27 Apr 2010 15:11:10 -0400 Message-ID: From: Alexander Sack To: John Baldwin 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: Tue, 27 Apr 2010 19:11:16 -0000 On Tue, Apr 27, 2010 at 12:04 PM, John Baldwin wrote: > On Thursday 22 April 2010 4:07:37 pm Maxim Sobolev wrote: >> John Baldwin wrote: >> > On Thursday 22 April 2010 2:28:26 pm Maxim Sobolev wrote: >> >> John Baldwin wrote: >> >>> On Thursday 22 April 2010 6:05:04 am Maxim Sobolev wrote: >> >>>> Maxim Sobolev wrote: >> >>>>> There is already a code to detect non-existing AT keyboard and avo= id >> >>>>> attaching atkbd to it. The code is i386-only at the moment, I am > trying >> >>>>> to figure out how to modify it so that it works on amd64 as well. >> >>>> Looks like this huge delay is caused by the inb() being astonishing= ly >> >>>> slow, which is not factored by the timeout routines. Reading keyboa= rd >> >>>> status port once takes about 0.003s! I am not sure if it's common >> >>>> behaviour of the platform, or something specific to this particular >> >>>> model. Do you know by any chance? >> >>> Well, many BIOSes trigger an SMI# when doing inb/outb to the keyboar= d > ports so >> >>> they can emulate a PS/2 keyboard when a USB keyboard is inserted. = =A0Do > you have >> >>> any BIOS options related to the USB legacy compat? =A0I know of the > Nehalem >> >>> systems I've seen they have a separate option for controlling port 6= 0/64 >> >>> emulation which we leave disabled by default. >> >> That makes sense. Unfortunately I don't have access to the BIOS >> >> settings. This is a hosted system, and the provider keeps BIOS passwo= rd >> >> for themselves. >> >> >> >> I have a patch that fixes that issue by measuring status register >> >> reading time first and then factoring it in the calculations of the >> >> number of retries: >> >> >> >> http://sobomax.sippysoft.com/atkbdc.diff >> >> >> >> It also applies the same logic to detect broken/non-existing keyboard >> >> controller to amd64 as we do to the i386. I'd appreciate if you can d= o a >> >> review. >> > >> > Hmm, not all i386 CPUs that we support have a TSC. =A0Is the change to >> > atkbdc_isa.c sufficient to fix the hang? =A0If so, I'd rather just com= mit > that >> > bit and leave out the read_delay changes. >> >> No, it's not sufficient. The problem here is that for some reason that >> test passes on that system (probably emulation works) and so that normal >> keyboard attach routine is invoked early in boot, when we don't even >> have clock initialized. What if I make TSC-related changes amd64? Will >> that be OK? > > Hmm, I think you should definitely commit the atkbdc_isa.c change first o= f > all. =A0I'm still thinking about the other change. =A0I wonder if we can = figure > out that a keyboard isn't present sooner somehow? =A0Do you know if the k= eyboard > appears to be present but just slow vs if the keyboard is eventually foun= d to > not be present? S5520UR, Intel BIOS 48 (last 2 digits), Build 2/27/10. If I disable 60/64 emulation the box refuses to go into the BIOS or boot anything. The BIOS just simply hangs after the Intel logo screen. This just seems like a bug. On the last generation Alcolu based machines, we usually have 60/64h emulation disabled which works just fine (USB Legacy Mode is still enabled so things like the debugger still/kinda/sorta work). I will work through our Intel channels to have them look at this (we already discovered some other bugs with respect to flashing and RMM3). I am looking at the atkbd driver for the first time. It would seem to me at first glance that John makes a very good point: there is already code to deal with a lack of a keyboard in the i386 code. I would *assume* that turning it on for amd64 would be all that is necessar= y? Btw these systems also fail other keyboard related tests. I also see: "atkbd: unable to set the command byte." On all Nehalem systems (this might be less serious given the OS has taken over from the BIOS). I am testing a variant of Maxim's patch right now. Stay tuned, -aps