Date: Thu, 22 Aug 2002 17:55:09 -0700
From: Terry Lambert <tlambert2@mindspring.com>
To: Will Andrews <will@csociety.org>
Cc: Peter Wemm <peter@wemm.org>, current@FreeBSD.ORG
Subject: Re: Memory corruption in -CURRENT [was Re: Plea to committers to only commit to HEAD if you run -current {from developers@FreeBSD.org}]
Message-ID: <3D6587ED.F602F06@mindspring.com>
References: <20020822233846.GJ90596@procyon.firepipe.net> <20020823002846.BBF082A7D6@canning.wemm.org> <20020823004257.GM90596@procyon.firepipe.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Will Andrews wrote: > > Note that the old SMP code never had PG_G active for SMP before the last > > round of pmap changes. DISABLE_PG_G almost goes back to the old way for > > SMP systems. DISABLE_PSE should be irrelevant since we've been using it all > > along. > > > > I've become aware of some nasty races in the pmap code for SMP boxes about > > a week ago while working on PAE stuff. DISABLE_PG_G *might* minimize the > > effect of them but they are still there. > > Well, I'm rebuilding without DISABLE_PSE to see whether it had > any effect on the outcome. Regardless, hopefully the information > I can provide will help squash this annoying bug. DISABLE_PSE is a 1:6 probability; DISABLE_PG_G is a 1:100 (both estimates, but on that order), so mixing and matching them will not usually give any additional information. Martin got "lucky" with his machine... it seems to require both. The problem is a hardware bug in most Pentium on up processors, which gets worse in newer CPUs (P4, AMD) as they try to optimize certain things. It's like writing ANSI C without "volatile". If you don't get the bug after your rebuild, I think that fact shouldn't be considered significant. -- Terry 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?3D6587ED.F602F06>