5.1, Data Corruption, Intel, Oh my! [patch]

[If you're not interested in the history and technical information,
 and just want to try this out, please scroll down to after the [*]].

Hi,

  Over the past few months, it seems that some of our 5.x users have
  been plagued by various random data corruption problems on some
  version(s) of the Intel Pentium IV chip (and in another form, on
  some version(s) of the Intel Pentium Pro and Pentium II chips).

  While in several instances the problem has been traced to faulty
  memory, in some others a work-around solution has been in use.  That
  workaround was to include the DISABLE_PSE and DISABLE_PG_G options in
  the kernel.  It appears to have "solved" the problem.

  Although not documented (at least not publically from what I could
  find), there does appear to be [a] bug[s] on some Intel chips that has
  to do with PSE, PG, and how their co-existence with legacy 4K
  page mappings.  While the exact details of the bug are to me unknown,
  some others have come up with reasonable hypothesis and detailed
  accounts (over my head, but Terry has a fairly consistent one).

  Regardless, I have come up with a patch that hopefully solves the data
  corruption problem for those of you who have been running with
  DISABLE_PSE and DISABLE_PG_G in your kernels.  The patch is attached
  to this Email.

  What the patch does does not directly uncover the true nature of the
  bug (as I don't know that myself), but it does appear to solve the
  problem at least for a couple of users I've been confirming with.  The
  first thing it does is load the kernel at 0x400000 instead of 0x100000
  (this part was implemented by Peter Wemm who sent it to me
  a little over a year ago now).  The next thing it does is write a page
  table for the kernel pages that would - given the right pde - map the
  entire kernel in 4K pages.  However, if PSE is enabled, the page
  table is not used[*] and instead a pde for a 4M page (or several)
  mapping the kernel in its entirety is[are] written before paging is
  ever turned on (that's it, in a nutshell).  I don't want to go into
  much detail on the rationale of all this unless you are really
  interested, at even then only to a point (please Email privately).

[*] In some cases it's still used for a P==V mapping required to boot
    the APs.

  Ok, so now that all that is out of the way, I'd like to request a
  massive movement to help test this change. :-)

What has been done:
  
  Georg-W. Koltermann <g.w.k [at] web.de> - who has experienced the
  above-mentionned data corruption problems on his P4, was able to
  reproduce them fairly reliably, and has been running with DISABLE_PSE
  and DISABLE_PG_G - has tested the patch and confirmed that it solves
  his data corruption problem without having to require the two DISABLE
  options.

  I have tested this patch (and have been running with it for a week
  now) on my -current workstation at the office (although I never
  experienced the aformentionned data corruption problems).

  Robert Watson has tested this patch on one of his SMP machines and it
  has now been confirmed to work there as well.

  We have not yet tested this patch with PAE turned on.

  
What needs to be done:

  If you've had random data corruption problems while running -current
  on Intel, please try this patch WITHOUT the DISABLE_PSE _nor_ the
  DISABLE_PG_G options in your kernel and let me know if the problem
  goes away.  (If it does not go away, then suspect bad RAM...)

  If you have -current running on Intel, PLEASE TEST THIS patch.  This
  includes UP, SMP, PAE, and any combination of said features.  With
  regards to PAE in particular, I'd like to know if you can boot this
  thing as I have not yet attempted it.

  The information I'd like to see, if possible (private mail is OK):

  1) Your hardware, UP or SMP.
  
  2) Whether you have PAE turned on.
  
  3) If you had the data corruption problem, does the patch solve it?
     Please make sure you do NOT include the DISABLE_PSE and
     DISABLE_PG_G options when you test for this, as they should no
     longer be needed.

  If for some reason you continue to see data corruption problems with
  this patch, then make sure that they really do go away with
  DISABLE_PSE and DISABLE_PG_G before you contact me; it could just be
  bad RAM.

  If I commit this, I want it to have the longest "Tested By" list ever
  written in a commit message to date. Please help. :-)
  
Regards,
-- 
Bosko Milekic  *  bmilekic_at_technokratis.com  *  bmilekic_at_FreeBSD.org
TECHNOkRATIS Consulting Services  *  http://www.technokratis.com/