x86/PAT: Fix Xorg regression on CPUs that don't support PAT

tip:x86/urgent Doug Smythies 2 participants 3 messages May 31, 2017 – Jun 1, 2017

Subsystems (2)

x86 x86 MM

lore

Share & tools

lore

Doug Smythies

author

2017-05-31 00:53 UTC #0 lore raw

Note Before:
I might not have the address list correct, as I have re-created this e-mail from the web page archive, having found the thread after bisecting the kernel.

Quoted 6 lines · On 2017.05.29 18:50:57 -0400 (EDT) Mikulas Patocka wrote:

Quoted 5 lines · Andy Lutomirski
Quoted 4 lines · Bernhard Held
Hi,
this patch breaks the boot of my kernel. The last message is "Booting the kernel.".

It breaks my kernel boot also, and I know of at least two others with the same, or similar, problem as of kernel 4.12-rc3.

Quoted 3 lines

Quoted 3 lines
Quoted 3 lines
My setup might be unusual: I'm running a Xenon E5450 (LGA 771) in a Gigbayte G33-DS3R board (LGA 775). The BIOS is patched with the microcode of the E5450 and recognizes the CPU.

I do not think my test server setup is unusual. I use Ubuntu 16.04.2 server edition as my distro, and steal Ubuntu kernel configurations for compiling. My processor is an older model i7
(Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz)

Quoted 10 lines

Hi
Please do the following three tests and test if the kernel boots.
1. use the PAT patch and revert the change to the function pat_enabled()
- i.e. change it to the original:
bool pat_enabled(void)
{
	return !!__pat_enabled;
}

Test 1 result: fail

Quoted 6 lines

2. use the PAT patch and revert the change to the function pat_ap_init
- i.e. change it to the original:
static void pat_ap_init(u64 pat)
{
	if (!boot_cpu_has(X86_FEATURE_PAT)) {

Test 2 result: pass

Quoted 2 lines

3. use the full PAT patch and apply the below patch on the top of it.

Test 3 result: fail

Quoted 27 lines

Quoted 11 lines
I think this patch is bogus. pat_enabled() sure looks like it's supposed to return true if PAT is *enabled*, and these days PAT is "enabled" even if there's no HW PAT support. Even if the patch were somehow correct, it should have been split up into two patches, one to change pat_enabled() and one to use this_cpu_has().
Ingo, I'd suggest reverting the patch, cc-ing stable on the revert so -stable knows not to backport it, and starting over with the fix. From very brief inspection, the right fix is to make sure that pat_init(), or at least init_cache_modes(), gets called on the
pat_init() needs to be called with cache disabled - and the cache disable code (functions prepare_set() and post_set()) exists in arch/x86/kernel/cpu/mtrr/generic.c - it may not be compiled if CONFIG_MTRR is not set.
Though, it is possible to call init_cache_modes() - see the patch below. init_cache_modes() does nothing if it is called multiple times.
Quoted 8 lines
affected CPUs.
As a future cleanup, I think that pat_enabled() could be deleted outright and, if needed, replaced by functions like have_memtype_wc() or similar. (Do we already have helpers like that?) Toshi, am I right?
--Andy

Ian W MORRISON

2017-06-01 07:49 UTC #1 lore raw

Quoted 7 lines · Doug Smythies

Note Before:
I might not have the address list correct, as I have re-created this e-mail from the web page archive, having found the thread after bisecting the kernel.
Quoted 1 line · On 2017.05.29 18:50:57 -0400 (EDT) Mikulas Patocka wrote:
On Sun, 28 May 2017, Andy Lutomirski wrote:

Quoted 9 lines

Quoted 5 lines
Quoted 5 lines · Bernhard Held
Quoted 4 lines
Hi,
this patch breaks the boot of my kernel. The last message is "Booting the kernel.".
It breaks my kernel boot also, and I know of at least two others with the same, or similar, problem as of kernel 4.12-rc3.

Just to add that I cannot boot v4.12-rc3 kernel with any Intel Atom (BYT and CHT) Intel Compute Sticks. Adding 'earlyprintk=efi' confirms kernel panic with

[ 0.000000] Kernel panic - not syncing: x86/PAT: PAT enabled, but not

supported by secondary CPU

<snip>

Ian W MORRISON

2017-06-01 14:48 UTC #2 lore raw

Quoted 18 lines · Ian W MORRISON

Quoted 7 lines · Doug Smythies
Note Before:
I might not have the address list correct, as I have re-created this e-mail from the web page archive, having found the thread after bisecting the kernel.
Quoted 1 line · On 2017.05.29 18:50:57 -0400 (EDT) Mikulas Patocka wrote:
On Sun, 28 May 2017, Andy Lutomirski wrote:
Quoted 9 lines
Quoted 5 lines
Quoted 5 lines · Bernhard Held
Quoted 4 lines
Hi,
this patch breaks the boot of my kernel. The last message is "Booting the kernel.".
It breaks my kernel boot also, and I know of at least two others with the same, or similar, problem as of kernel 4.12-rc3.

Quoted 9 lines

Just to add that I cannot boot v4.12-rc3 kernel with any Intel Atom (BYT and CHT) Intel Compute Sticks. Adding 'earlyprintk=efi' confirms kernel panic with
[ 0.000000] Kernel panic - not syncing: x86/PAT: PAT enabled, but not
supported by secondary CPU
<snip>

Confirmed that following patch fixes boot of v4.12-rc3 for Intel Atom Compute Sticks:

[PATCH] Fix X86_FEATURE_PAT regression bug

Early kernel panic caused by checking for X86_FEATURE_PAT when enabled but not supported by secondary CPU.

Fixes cbed27cdf0e3 ("x86/PAT: Fix Xorg regression on CPUs that don't support PAT")

Signed-off-by Ian W Morrison <[email protected]>

---
 arch/x86/mm/pat.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/x86/mm/pat.c +1 -1

index 83a59a6..c537bfb 100644
@@ -234,7 +234,7 @@ static void pat_bsp_init(u64 pat)
 
 static void pat_ap_init(u64 pat)
 {
-	if (!this_cpu_has(X86_FEATURE_PAT)) {
+	if (!boot_cpu_has(X86_FEATURE_PAT)) {
 		/*
 		 * If this happens we are on a secondary CPU, but switched to
 		 * PAT on the boot CPU. We have no way to undo PAT.

Signature · 1 line

1.9.1