Date: Tue, 13 May 2003 22:02:51 +0200 (CEST) From: Heiko Schaefer <hschaefer@fto.de> To: Robert Watson <rwatson@FreeBSD.org> Cc: current@FreeBSD.org Subject: Re: 5.1-RELEASE TODO Message-ID: <20030513215348.K14785@daneel.foundation.hs> In-Reply-To: <Pine.NEB.3.96L.1030513145309.72145R-100000@fledge.watson.org> References: <Pine.NEB.3.96L.1030513145309.72145R-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Robert, > > this might be the wrong way or place, but i want to state again (as i > > already stated in my thread about data corruption), that in my opinion > > it would be not a good idea to make a release of freebsd with the > > GENERIC kernel config as it is. > > > > not having the options > > > > options DISABLE_PSE > > options DISABLE_PG_G > > > > in the kernel config caused me data corruption which took hours of > > testing (and bothering people on this list) to figure out. apparently > > this problem is widespread and not only relevant to exotic fringe-case > > systems. > > 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. 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. > 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? regards, Heiko -- Free Software. Why put up with inferior code and antisocial corporations? http://www.gnu.org/philosophy/why-free.html
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030513215348.K14785>