Re: 5.1-RELEASE TODO

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