From owner-freebsd-hardware@FreeBSD.ORG Tue Apr 27 15:24: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 6BFCB106564A; Tue, 27 Apr 2010 15:24:42 +0000 (UTC) (envelope-from cowens@greatbaysoftware.com) Received: from portcityhosting.com (edge.tidalhosting.net [64.140.243.92]) by mx1.freebsd.org (Postfix) with ESMTP id 007F48FC29; Tue, 27 Apr 2010 15:24:41 +0000 (UTC) Received: from Inbox ([75.202.235.205]) by portcityhosting.com with MailEnable ESMTP; Tue, 27 Apr 2010 11:24:36 -0400 X-WatchGuard-Mail-Exception: Allow MIME-Version: 1.0 From: Charles Owens Date: Tue, 27 Apr 2010 11:24:50 -0400 To: Alexander Sack , John Baldwin Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-WatchGuard-AntiVirus: part scanned. clean action=allow X-ME-Bayesian: 0.000000 Message-Id: <20100427152442.6BFCB106564A@hub.freebsd.org> Cc: 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 15:24:42 -0000 The device.hints tweak is a fine workaround. If problem is at all widespre= ad, though, I'd argue that it is insufficient.=20 ---- Charles Owens Great Bay Software, Inc. sent from my phone -----Original Message----- From: Alexander Sack Sent: Monday, April 26, 2010 10:10 PM To: John Baldwin Cc: Charles Owens ; freebsd-hardware@freebsd.o= rg Subject: Re: Minute+ delay between kernel load and initialization (solved!) 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. =A0 W= e see >> >>> the loader appearing to complete its work (the kernel is loaded) and >> >>> then... it sits. =A0Once 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 kern= els. >> >>> =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 det= ails, >> >> see >> >> >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=3Di386/144956 >> >> >> > Interesting. =A0I do not see the long delay on Nehalem machines here. = =A0Would >> > either of you be able to debug this further? =A0You could maybe grab T= SC > 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 po= ints >> > 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() that w= ere > saved in some sort of global array. =A0Then, 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. =A0You could then mo= ve the > rdtsc() calls around on subsequent tests to narrow down where the pause i= s > 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, -aps