Date: Tue, 11 Apr 2006 20:57:36 -0700 From: Maxim Sobolev <sobomax@FreeBSD.org> To: phk@FreeBSD.org Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org, John Baldwin <jhb@FreeBSD.org> Subject: Re: cvs commit: src/sys/boot/i386/cdboot cdboot.s Message-ID: <443C7AB0.4030906@FreeBSD.org> In-Reply-To: <443C76A0.30308@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?443C7AB0.4030906>