From owner-freebsd-hardware@FreeBSD.ORG Tue Apr 27 16:54:07 2010 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2EBA6106566B; Tue, 27 Apr 2010 16:54:07 +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 C46FD8FC14; Tue, 27 Apr 2010 16:54:06 +0000 (UTC) Received: by gxk3 with SMTP id 3so6458783gxk.13 for ; Tue, 27 Apr 2010 09:53:57 -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=xdcvL4b99ei2zNP1L9aFHsEGD0Lv+teXU/PEWOOXLSk=; b=VRa819eilCDHdooOTHyTLqNm+NcZ6xmP7DRPigy0qjw5urr2prtTR9fqagzPZk3G4g +eR6oZF+C+HVH2Dg33YHbFvgYty5DOu9kUVYb2HGc8Qz5WWU8MmrAWLBdt/SYUIWr5qr hqO2W/aVRm9qfFWLcPEejmdvgeHpVnSPREAGg= 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=aLV7LKZMqdmv3xk+OtHZdC0rnqBRIiH/XXerWomxSB1Fn4EoFUp++YYCG312dfY3Y0 LXCyTXy1vzUHXx4rqGMYUZZLpMaMVNkVpilSmvRwEeqH8YKlEfeoTxUecnl9n0cUOhUR P6+qv8l0epIercN/5p+HfiFJ6gxerlUDmDzbc= MIME-Version: 1.0 Received: by 10.101.199.13 with SMTP id b13mr1409390anq.58.1272387237212; Tue, 27 Apr 2010 09:53:57 -0700 (PDT) Received: by 10.100.194.19 with HTTP; Tue, 27 Apr 2010 09:53:57 -0700 (PDT) In-Reply-To: <201004270945.33722.jhb@freebsd.org> References: <4B5478D1.4000900@greatbaysoftware.com> <201004201202.56275.jhb@freebsd.org> <201004270945.33722.jhb@freebsd.org> Date: Tue, 27 Apr 2010 12:53:57 -0400 Message-ID: From: Alexander Sack To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Charles Owens , freebsd-hardware@freebsd.org Subject: Re: Minute+ delay between kernel load and initialization (solved!) X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 16:54:07 -0000 On Tue, Apr 27, 2010 at 9:45 AM, John Baldwin wrote: > On Monday 26 April 2010 10:10:17 pm Alexander Sack wrote: >> On Tue, Apr 20, 2010 at 12:02 PM, John Baldwin wrote: >> > On Tuesday 20 April 2010 11:56:34 am Charles Owens wrote: >> >> On 4/20/2010 9:13 AM, John Baldwin wrote: >> >> > On Monday 19 April 2010 6:05:06 pm Charles Owens wrote: >> >> > >> >> >> On 1/18/2010 10:05 AM, Charles Owens wrote: >> >> >> >> >> >>> Hello, >> >> >>> >> >> >>> We have a new system based on the Intel S5520 motherboard that se= ems > to >> >> >>> work fine except during _every_ boot it pauses for about one minu= te > 15 >> >> >>> seconds just before any kernel initialization messages appear. = =A0 We > see >> >> >>> the loader appearing to complete its work (the kernel is loaded) = and >> >> >>> then... it sits. =A0Once it starts up again (with usual kernel-bo= ot >> >> >>> messages) it appears to boot normally (no error messages). >> >> >>> >> >> >>> This has been seen with both FreeBSD 8.0 and 7.1, using GENERIC > kernels. >> >> >>> =A0I'd appreciate any and all assistance in figuring this out. >> >> >>> >> >> >>> Boot output follows (happens to be from a PAE-enabled kernel) >> >> >>> >> >> >>> Thank you, >> >> >>> >> >> >>> Charles >> >> >>> >> >> >>> >> >> >>> >> >> >> [truncated] >> >> >> >> >> >> An answer to this was graciously provided by Titus Manea. =A0 For > details, >> >> >> see >> >> >> >> >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=3Di386/144956 >> >> >> >> >> > Interesting. =A0I do not see the long delay on Nehalem machines her= e. > =A0Would >> >> > either of you be able to debug this further? =A0You could maybe gra= b TSC >> > values >> >> > at various points during the early console probe and print out the >> > relevant >> >> > deltas after cninit() returns. =A0You could then move the TSC probe > points >> >> > around to pinpoint which operations are taking a long time. >> >> > >> >> >> >> John, >> >> >> >> I'm not going to have the cycles to look at this any time soon, >> >> unfortunately. =A0 But, just in case, how does one display TSC values= ? =A0We >> >> did try to enable the kernel debugger, but the delay happens _before_ >> >> the debugger prompt is available. >> >> >> >> We now think of this more as an issue seen with some particular >> >> motherboard/BIOS combinations .... initially the only thing we really >> >> had to go on was the fact that the behavior was seen on new >> >> Nehalem-based systems. >> > >> > You would have to patch the source to add various calls to rdtsc() tha= t > were >> > saved in some sort of global array. =A0Then, once the console was full= y >> > initialized you could print out the TSC deltas by walking the array an= d >> > printing out the delta between each pair of entries. =A0You could then= move > the >> > rdtsc() calls around on subsequent tests to narrow down where the paus= e is >> > happening. >> >> Sorry John, I completely missed this. =A0If you haven't done it already, >> I can look into it for sure. =A0I have several Nehalem machines that do >> this. =A0Its on my TODO list though I thought the kdb probe was the fix? >> =A0Is that NOT the fix? >> >> Just let me know, guys, > > Maxim has a patch for the atkbd driver that works in his testing. =A0I th= ink it > is on another thread however. Alright, I will take a look and do the same on my end as another datapoint. I have been waiting all day to get my hands on this box! :) -aps