[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f359fc2e-0ef3-3173-5e78-36bcb5a04316@zytor.com>
Date: Tue, 18 Apr 2017 12:28:20 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: Mikulas Patocka <mpatocka@...hat.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>
Cc: x86@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] X86: don't report PAT on CPUs that don't support it
On 04/18/17 12:07, Mikulas Patocka wrote:
> In the file arch/x86/mm/pat.c, there's a variable __pat_enabled. The
> variable is set to 1 by default and the function pat_init() sets
> __pat_enabled to 0 if the CPU doesn't support PAT.
>
> However, on AMD K6-3 CPU, the processor initialization code never calls
> pat_init() and so __pat_enabled stays 1 and the function pat_enabled()
> returns true, even though the K6-3 CPU doesn't support PAT.
>
> The result of this bug is that this warning is produced when attemting to
> start the Xserver and the Xserver doesn't start (fork() returns ENOMEM).
> Another symptom of this bug is that the framebuffer driver doesn't set the
> K6-3 MTRR registers.
>
> This patch changes pat_enabled() so that it returns true only if pat
> initialization was actually done.
>
> Also, I changed boot_cpu_has(X86_FEATURE_PAT) to
> this_cpu_has(X86_FEATURE_PAT) in pat_ap_init, so that we check the PAT
> feature on the processor that is being initialized.
>
I'm thinking it would be better to replace __pat_enabled with
static_cpu_has(X86_FEATURE_PAT) and disable the feature bit if the user
has disabled it on the command line, just as we do with other features.
-hpa
Powered by blists - more mailing lists