Date: Wed, 6 Nov 2002 05:39:23 -0800 From: David Schultz <dschultz@uclink.Berkeley.EDU> To: Glenn Johnson <gjohnson@srrc.ars.usda.gov> Cc: stable@FreeBSD.ORG, current@FreeBSD.ORG, iwasaki@FreeBSD.ORG Subject: Re: SMP broken on PPro Message-ID: <20021106133923.GA61564@HAL9000.homeunix.com> In-Reply-To: <20021105201738.GA86056@node1.cluster.srrc.usda.gov> References: <20021104230032.GA3217@node1.cluster.srrc.usda.gov> <20021105105146.GB57295@HAL9000.homeunix.com> <20021105201738.GA86056@node1.cluster.srrc.usda.gov>
next in thread | previous in thread | raw e-mail | index | archive | help
Thus spake Glenn Johnson <gjohnson@srrc.ars.usda.gov>: > > I have had no trouble with UP -STABLE running on a dual PPro system, > > but I'm getting an early panic in UP and SMP -CURRENT on the same > > system. I will post details to current@ soon if I can't figure out > > the problem. > > The problem on -STABLE is with /sys/i386/i386/machdep.c, revision > 1.385.2.26. I am not smart enough to know exactly what is wrong > with the diff but reverting back to revision 1.385.2.25 of > /sys/i386/i386/machdep.c fixes the problem. Aah yes, this is an MFC of revision 1.544, which broke -CURRENT as well. The patch should probably be un-MFC'd until a better solution is found. The old code said: 1) set up some PTEs for the BIOS just before the 640K mark if the BIOS may be using that space 2) call int 15 function E820 to get the memory map from the BIOS The new code reverses the order of these operations, so it causes a segfault in the BIOS interrupt handler. I recall a thread about this change on current@ a little while ago, but I forget exactly what problem it was supposed to solve. As for the fix, I'm not a PC BIOS expert, but I don't see any reason why it's necessary to call 15:E820 *before* good old int12, which ought to work on any BIOS dating back to the original PC-XT. If there's some problem I don't know about, I should note that the machine that triggers this bug for me works fine on the first 15:E820 call but not the second. If other BIOSes behave similarly, one possible fix would be to interpret the return value from the first 15:E820 call specially, e.g. if (smap->base == 0 && smap->length < 640*1024) set up some PTEs for the gap; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021106133923.GA61564>