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

John Baldwin jhb at
Wed Apr 12 14:32:19 UTC 2006

On Tuesday 11 April 2006 23:40, 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.
> >>>
> >>>
> >> 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:

I looked but unfortunately there isn't much to go on.  We follow the sequence
Intel specifies.  If you want to debug this you'll have to probably do
something like bring back the postcode stuff in mp startup and dump the
various postcode values to see how far the AP got, etc.

> You can find acpidump here:
> mptable tells that there is no MP table...

mptable and madt just tell us which CPUs are present, so basically they
are just a list of APIC IDs and don't have any bearing on CPU startup

John Baldwin <jhb at>  <><
"Power Users Use the Power to Serve"  =

More information about the cvs-src mailing list