login
Search
Bosko Milekic recently posted a patch to the freebsd-current mailing list apparently solving some random data corruption problems that have been seen in FreeBSD 5.1 for the past few months. The actual bug is still rather ill-defined, and the workaround to date has been to include the 'DISABLE_PSE' and 'DISABLE_PG_G' options when building the kernel. With Bosko's fix, neither option is now required to prevent data corruption. He explains:
"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".
Bosko's complete description of the problem follows, including the related FreeBSD history of the past few months, details of testing so far, and what's left to be tested.
From: Bosko Milekic [email blocked]
To: freebsd-current
Subject: 5.1, Data Corruption, Intel, Oh my! [patch]
Date: Mon, 11 Aug 2003 10:05:49 +0000
[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 lt;g.w.k [at] web.degt; - 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 * [email blocked] * [email blocked]
TECHNOkRATIS Consulting Services * http://www.technokratis.com/
[4mb_new.diff text/plain (12472 bytes)]
