[Fwd: Re: [PATCH] x86: Relegate CONFIG_PAT to EMBEDDED]

Daniel J Blueman daniel.blueman at gmail.com
Tue Oct 13 14:15:33 UTC 2009


On Tue, Oct 13, 2009 at 2:10 PM, Tim Gardner <tim.gardner at canonical.com> wrote:
> Daniel J Blueman wrote:
>> On Tue, Oct 13, 2009 at 2:18 AM, Tim Gardner <tim.gardner at canonical.com> wrote:
>>> Tim Gardner wrote:
>>>> Andy, Stefan - Why _is_ it that we don't have PAT enabled? Wasn't it
>>>> originally a prerequisite for KMS back in Jaunty days?
>>>>
>>>> There are some comments on LKML pointing out that we _should_ have PAT
>>>> enabled, e.g., "[RFC Patch] use MTRR for write combining if PAT is not
>>>> available"
>>>>
>>>> rtg
>>>>
>>> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-karmic.git;a=commit;h=a611fa50121f1698bd367b991f66e2268eb10824
>>
>> Excellent. Is the idea that this will be a karmic beta update in a
>> couple of days, and we have a get-out-of-jail of disabling it (or
>> default boot with 'nopat') before the final release is cut?
>>
>> Or, is this simply too late to make the final release?
>>
>> Daniel
>
> Kernel freeze is Thursday. With the addition of stable and other
> miscellaneous patches, today's upload is going to be the last one
> (unless some OMG kitten killer gets in my face).

Ok, great.

Still of importance, so worth mentioning here, CONFIG_X86_MCE gives
visibility of otherwise silent memory controller and/or internal
processor state (including processor passing critical temperature
thresholds).

This is particularly crucial for servers with lots of memory
(therefore higher chance of cell failure), but also modern desktops
having larger amounts of memory. From a support perspective, detected
memory errors are logged to the kernel log. From a user perspective
(particularly for ubuntu-server), the user knows more when they have
eg failing/faulty memory. I'd think twice about deploying critical
services on a server where (un)correctable ECC errors *silently*
occur...

Since this feature has been around really a long time, it carries no
risk. Thoughts?
-- 
Daniel J Blueman




More information about the kernel-team mailing list