Skip site navigation (1)Skip section navigation (2)
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-current" 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>