Re: 5.1-RELEASE TODO

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