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)]