Date: Tue, 13 May 2003 21:53:28 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Heiko Schaefer <hschaefer@fto.de> Cc: current@FreeBSD.org Subject: Re: 5.1-RELEASE TODO Message-ID: <3EC1CBC8.E263A9EF@mindspring.com> References: <Pine.NEB.3.96L.1030513145309.72145R-100000@fledge.watson.org> <20030513215348.K14785@daneel.foundation.hs>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3EC1CBC8.E263A9EF>