From owner-freebsd-current@FreeBSD.ORG Tue May 13 21:54:49 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 13CE537B401; Tue, 13 May 2003 21:54:49 -0700 (PDT) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3CEC743F3F; Tue, 13 May 2003 21:54:48 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0275.cvx40-bradley.dialup.earthlink.net ([216.244.43.20] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19FoHs-0004XI-00; Tue, 13 May 2003 21:54:45 -0700 Message-ID: <3EC1CBC8.E263A9EF@mindspring.com> Date: Tue, 13 May 2003 21:53:28 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Heiko Schaefer References: <20030513215348.K14785@daneel.foundation.hs> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4bf1b2b75d530bc9b1d08412e7763ef98666fa475841a1c7a350badd9bab72f9c350badd9bab72f9c cc: re@FreeBSD.org cc: Robert Watson cc: current@FreeBSD.org Subject: Re: 5.1-RELEASE TODO X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2003 04:54:49 -0000 Heiko Schaefer wrote: > Hi Robert, > > There's a lot of worry that this is simply masking the bug, as opposed to > > fixing it, as it's believed we already have workarounds for most of the > > Intel bugs being discussed. So we'd like to leave these out for now until > > it's clear that they fix the bug rather than masking it on some machines > > (and making it pop up on others). BTW, at least once instance of the > > "Intel bug" that has been proferred as a cause of these sorts of problems > > was resolved by recently driver fixes in if_bge. > > masking would indeed be very unpleasant. This is the first I've heard of it being able to mask driver bugs; maybe we should rename the options "RUNRIGHT" instead. ;^). > i can only speak for myself, but on my amd xp 1800+ cpu, the amount of > data corruption i got was way beyond acceptable (i.e. clearly > 0). with > those two options the problem apparently went away. > > if this is (and it seems to clearly be) something that is going wrong > because of freebsd's code (in the widest sense ... other OSes somehow work > around the relevant shortcomings in cpus, i gather), then to me, releasing > freebsd with that knowledge is entirely wrong. Other OS's do *not* work around the problem. Windows has a registery entry which is equivalent to DISABLE_PSE. The DISABLE_PG_G, as I said in a previous posting, works around an order of operation problem that needs to clear PG in %CR0 while it does it's thing, after which there's no problem with enabling it. See "IA-32 Intel Architecture Software Developer's Manual, Volume 3: System Programming Guide for more details on PG_G, the PG bit in %CR0, and the effect on TLB flushing; look specifically at Section 10.9 of "Memory Cache Control", which is entitled "Invalidating The TRanslation Lookaside Buffers". Specifically, writing %CR3 doesn't invalidate pages with PG_G set on them if PG is set in %CR0. > > That said, we are actively discussing what, if any, workarounds are > > appropriate, including some alternative workarounds from the ones > > currently present. > > bosko (who was mentioned here various time, regarding a patch to work > around this) has contacted me, and i am looking forward to try his patch. > assuming that the patch is correct (whatever that would mean in this > context), and there is some chance of accepting it anytime soon, maybe it > would be sensible to try to get that into the release - or delay the > release until this is sorted out ?! > > wouldn't a release that corrupts data in many, relevant, cases (i consider > the box i had the trouble with entirely mainstream) be worse than no > release at all? Bosko's fix raises the minimum memory requirements by 3M. It's probably worth it for most people, but it will probably annoy other people... -- Terry