From owner-freebsd-hardware@FreeBSD.ORG Tue Apr 27 16:51:42 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 B2F001065672 for ; Tue, 27 Apr 2010 16:51:42 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 6E0418FC22 for ; Tue, 27 Apr 2010 16:51:42 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 0735146B2C; Tue, 27 Apr 2010 12:51:42 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 6EFC58A025; Tue, 27 Apr 2010 12:51:32 -0400 (EDT) From: John Baldwin To: Alexander Sack Date: Tue, 27 Apr 2010 09:45:33 -0400 User-Agent: KMail/1.12.1 (FreeBSD/7.3-CBSD-20100217; KDE/4.3.1; amd64; ; ) References: <4B5478D1.4000900@greatbaysoftware.com> <201004201202.56275.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201004270945.33722.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 27 Apr 2010 12:51:32 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00, DATE_IN_PAST_03_06 autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx 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:51:42 -0000 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 seems to > >> >>> work fine except during _every_ boot it pauses for about one minute 15 > >> >>> seconds just before any kernel initialization messages appear. We see > >> >>> the loader appearing to complete its work (the kernel is loaded) and > >> >>> then... it sits. Once it starts up again (with usual kernel-boot > >> >>> messages) it appears to boot normally (no error messages). > >> >>> > >> >>> This has been seen with both FreeBSD 8.0 and 7.1, using GENERIC kernels. > >> >>> I'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. For details, > >> >> see > >> >> > >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=i386/144956 > >> >> > >> > Interesting. I do not see the long delay on Nehalem machines here. Would > >> > either of you be able to debug this further? You could maybe grab TSC > > values > >> > at various points during the early console probe and print out the > > relevant > >> > deltas after cninit() returns. You 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. But, just in case, how does one display TSC values? We > >> 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() that were > > saved in some sort of global array. Then, once the console was fully > > initialized you could print out the TSC deltas by walking the array and > > printing out the delta between each pair of entries. You could then move the > > rdtsc() calls around on subsequent tests to narrow down where the pause is > > happening. > > Sorry John, I completely missed this. If you haven't done it already, > I can look into it for sure. I have several Nehalem machines that do > this. Its on my TODO list though I thought the kdb probe was the fix? > Is that NOT the fix? > > Just let me know, guys, Maxim has a patch for the atkbd driver that works in his testing. I think it is on another thread however. -- John Baldwin