cvs commit: src/sys/boot/i386/cdboot cdboot.s

[Maxim Sobolev]

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
> 
>