Date: Wed, 12 Apr 2006 10:32:04 -0400 From: John Baldwin <jhb@freebsd.org> To: Maxim Sobolev <sobomax@freebsd.org> Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/boot/i386/cdboot cdboot.s Message-ID: <200604121032.07279.jhb@freebsd.org> In-Reply-To: <443C76A0.30308@FreeBSD.org> References: <200604110439.k3B4dTOD072774@repoman.freebsd.org> <200604111803.27889.jhb@freebsd.org> <443C76A0.30308@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > >>> > >>> 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 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: > > http://people.freebsd.org/~sobomax/acpi.out > > 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 really. -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200604121032.07279.jhb>