5.1-RELEASE TODO

[Don Lewis]

On 13 May, Robert Watson wrote:
> 
> On Tue, 13 May 2003, Heiko Schaefer wrote:
> 
>> > 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? 
> 
> You don't need to argue to me that we need stability (I'm a fan of it
> myself): what I need is evidence that some set of changes is actually
> solving the problem, not masking it.  If there exists a patch that
> substantially improves stability on some set of systems (and not at the
> cost of another set), I think you can rest assured that we'll get it into
> the release.  As with you, we're very concerned by the recent spate of
> instability, especially in the beta cycle, and how to address that is very
> much on our minds. 

Both my AMD system running -current and PII system running -stable are
afflicted with these data corruption problems.  The limited amount of
information that I've seen about these problems leads me to believe that
in order to use the 4 MB page feature without danger to system integrity
is to relocate the kernel.  If this is the case, then it would seem to
make sense to disable the use of 4 MB pages by adding the DISABLE_PSE
option until the system is patched.

PG_G is probably different.  A better case can be made that using this
option is only masking software bugs that should be fixable.  The
problem is that these bugs are only rarely triggered, look a lot like
flakey hardware, and it's just about impossible for most FreeBSD users
to track the problem to its root cause.