From owner-cvs-all@FreeBSD.ORG Wed Apr 12 03:57:50 2006 Return-Path: X-Original-To: cvs-all@FreeBSD.org Delivered-To: cvs-all@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C022516A400; Wed, 12 Apr 2006 03:57:50 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk.360sip.com [72.236.70.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2DAF343D45; Wed, 12 Apr 2006 03:57:49 +0000 (GMT) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.0.47] ([204.244.149.125]) (authenticated bits=0) by sippysoft.com (8.13.4/8.13.4) with ESMTP id k3C4CuEj012528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Apr 2006 21:12:58 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Message-ID: <443C7AB0.4030906@FreeBSD.org> Date: Tue, 11 Apr 2006 20:57:36 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: phk@FreeBSD.org References: <200604110439.k3B4dTOD072774@repoman.freebsd.org> <200604111358.41929.jhb@freebsd.org> <443C19A9.1000108@FreeBSD.org> <200604111803.27889.jhb@freebsd.org> <443C76A0.30308@FreeBSD.org> In-Reply-To: <443C76A0.30308@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org, John Baldwin Subject: Re: cvs commit: src/sys/boot/i386/cdboot cdboot.s X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2006 03:57:50 -0000 I doubt that it is related, but another interesting observation regarding the new Apple hardware is that our routine that calculates i8254 clock rate reports value significantly lower that the normal rate as a result TSC rate estimate goes upward by the same margin ((1193182/781653) == (3027.8/2000)): Calibrating clock(s) ... i8254 clock: 781653 Hz 781653 Hz differs from default of 1193182 Hz by more than 1% Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 3027797532 Hz CPU: Genuine Intel(R) CPU T2500 @ 2.00GHz (3027.80-MHz 686-class CPU) I wonder if machine has any i8254 hardware at all or that 781653 is just a bogus result of our kernel trying to get something out of nothing. Any comments for timekeeping gurus? ;-) -Maxim Maxim Sobolev wrote: > John Baldwin wrote: >> On Tuesday 11 April 2006 17:03, Maxim Sobolev wrote: >>> John Baldwin wrote: >>>> On Tuesday 11 April 2006 10:34, Maxim Sobolev wrote: >>>>> boo1 does the same - timeout loop. My small research seemingly >>>>> suggests that doing A20 via the BIOS is not very reliable and may >>>>> not work on all machines. >>>> Can you test a patch for pxeboot? It looks to be the one other >>>> place that >>>> goes near the A20 line. >>>> >>>> http://www.FreeBSD.org/~jhb/patches/pxe_a20.patch >>> Done. Returning to the subject, loader's version of A20-enabling >>> routine suffers from the very same problem (libi386/gatea20.c), but >>> luckily we don't use this routing in the loader at all. I suspect >>> that it relies on A20 being enabled by previous boot stages. >> >> Did you test it for the non-legacy case as well? :-P I already took >> care of the loader's A20 hack. :) > > Well, since we distribute this "timeout hack" as part of boot1 loader > for ages I think it should be just fine for the "normal", legacy-full > i386 machine. > > BTW, can you please take a look at the problem with SMP bootstrap on > Aplintel notebooks? For some reason our SMP kernel can't start the > second processor. You can find more details here: > > http://groups.google.ca/group/mailing.freebsd.current/browse_thread/thread/2b554e7a6cf3d3cd/b4f74b7c7907cb41?lnk=st&q=%22Intel+Macs+that+boot+FreeBSD%3F%22&rnum=1&hl=en#b4f74b7c7907cb41 > > > You can find acpidump here: > > http://people.freebsd.org/~sobomax/acpi.out > > mptable tells that there is no MP table... > > -Maxim > >