Date: Tue, 27 Apr 2010 11:24:50 -0400 From: Charles Owens <cowens@greatbaysoftware.com> To: Alexander Sack <pisymbol@gmail.com>, John Baldwin <jhb@freebsd.org> Cc: freebsd-hardware@freebsd.org Subject: RE: Minute+ delay between kernel load and initialization (solved!) Message-ID: <20100427152442.6BFCB106564A@hub.freebsd.org>
next in thread | raw e-mail | index | archive | help
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 <pisymbol@gmail.com> Sent: Monday, April 26, 2010 10:10 PM To: John Baldwin <jhb@freebsd.org> Cc: Charles Owens <cowens@greatbaysoftware.com>; 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 <jhb@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100427152442.6BFCB106564A>