Re: [tip:x86/urgent] x86/PAT: Fix Xorg regression on CPUs that don't support PAT

[Ian W MORRISON]

On 2 June 2017 at 00:48, Ian W MORRISON  wrote:
> On 6/1/17 5:49 PM, Ian W MORRISON wrote:
>> On 31 May 2017 at 10:53, Doug Smythies  wrote:
>>> 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.
>>>
>>> On 2017.05.29 18:50:57 -0400 (EDT) Mikulas Patocka wrote:
 On Sun, 28 May 2017, Andy Lutomirski wrote:
> On Sun, May 28, 2017 at 11:18 AM, Bernhard Held  wrote:
>> 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.00] Kernel panic - not syncing: x86/PAT: PAT enabled, but not
>> supported by secondary CPU
>>
>>
>> 
>>
>
> Confirmed that following patch fixes boot of v4.12-rc3 for Intel Atom Compute 
> Sticks:
>
> [PATCH] Fix X86_FEATURE_PAT regression bug
>



And for the sake of completeness, the revert patch
(https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?h=x86/urgent)
also fixes the boot of v4.12-rc3 for Intel Atom Compute Sticks (as
expected and now tested - yay).

Re: [tip:x86/urgent] x86/PAT: Fix Xorg regression on CPUs that don't support PAT

[Ian W MORRISON]

On 2 June 2017 at 00:48, Ian W MORRISON  wrote:
> On 6/1/17 5:49 PM, Ian W MORRISON wrote:
>> On 31 May 2017 at 10:53, Doug Smythies  wrote:
>>> 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.
>>>
>>> On 2017.05.29 18:50:57 -0400 (EDT) Mikulas Patocka wrote:
 On Sun, 28 May 2017, Andy Lutomirski wrote:
> On Sun, May 28, 2017 at 11:18 AM, Bernhard Held  wrote:
>> 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.00] Kernel panic - not syncing: x86/PAT: PAT enabled, but not
>> supported by secondary CPU
>>
>>
>> 
>>
>
> Confirmed that following patch fixes boot of v4.12-rc3 for Intel Atom Compute 
> Sticks:
>
> [PATCH] Fix X86_FEATURE_PAT regression bug
>



And for the sake of completeness, the revert patch
(https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?h=x86/urgent)
also fixes the boot of v4.12-rc3 for Intel Atom Compute Sticks (as
expected and now tested - yay).

Re: [tip:x86/urgent] x86/PAT: Fix Xorg regression on CPUs that don't support PAT

[Ian W MORRISON]

On 6/1/17 5:49 PM, Ian W MORRISON wrote:
> On 31 May 2017 at 10:53, Doug Smythies  wrote:
>> 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.
>>
>> On 2017.05.29 18:50:57 -0400 (EDT) Mikulas Patocka wrote:
>>> On Sun, 28 May 2017, Andy Lutomirski wrote:
 On Sun, May 28, 2017 at 11:18 AM, Bernhard Held  wrote:
> 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.00] Kernel panic - not syncing: x86/PAT: PAT enabled, but not
> supported by secondary CPU
> 
> 
> 
> 

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 
---
 arch/x86/mm/pat.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
index 83a59a6..c537bfb 100644
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -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.
-- 
1.9.1

Re: [tip:x86/urgent] x86/PAT: Fix Xorg regression on CPUs that don't support PAT

[Ian W MORRISON]

On 6/1/17 5:49 PM, Ian W MORRISON wrote:
> On 31 May 2017 at 10:53, Doug Smythies  wrote:
>> 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.
>>
>> On 2017.05.29 18:50:57 -0400 (EDT) Mikulas Patocka wrote:
>>> On Sun, 28 May 2017, Andy Lutomirski wrote:
 On Sun, May 28, 2017 at 11:18 AM, Bernhard Held  wrote:
> 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.00] Kernel panic - not syncing: x86/PAT: PAT enabled, but not
> supported by secondary CPU
> 
> 
> 
> 

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 
---
 arch/x86/mm/pat.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
index 83a59a6..c537bfb 100644
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -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.
-- 
1.9.1

Re: [tip:x86/urgent] x86/PAT: Fix Xorg regression on CPUs that don't support PAT

[Ian W MORRISON]

On 31 May 2017 at 10:53, Doug Smythies  wrote:
> 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.
>
> On 2017.05.29 18:50:57 -0400 (EDT) Mikulas Patocka wrote:
>> On Sun, 28 May 2017, Andy Lutomirski wrote:
>>> On Sun, May 28, 2017 at 11:18 AM, Bernhard Held  wrote:
 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.00] Kernel panic - not syncing: x86/PAT: PAT enabled, but not
supported by secondary CPU

Re: [tip:x86/urgent] x86/PAT: Fix Xorg regression on CPUs that don't support PAT

[Ian W MORRISON]

On 31 May 2017 at 10:53, Doug Smythies  wrote:
> 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.
>
> On 2017.05.29 18:50:57 -0400 (EDT) Mikulas Patocka wrote:
>> On Sun, 28 May 2017, Andy Lutomirski wrote:
>>> On Sun, May 28, 2017 at 11:18 AM, Bernhard Held  wrote:
 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.00] Kernel panic - not syncing: x86/PAT: PAT enabled, but not
supported by secondary CPU

Re: [tip:x86/urgent] x86/PAT: Fix Xorg regression on CPUs that don't support PAT

[Junichi Nomura]

On 05/31/17 02:59, Mikulas Patocka wrote:
>>> 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)) {
>>
>> Joy.
> 
> It is interesting - does it mean that the boot cpu does have PAT and the 
> secondary CPUs don't?

It seems pat_init() is called twice for boot cpu, from mtrr_bp_pat_init()
and generic_set_all(). The 2nd call ends up calling pat_ap_init() and it's
before boot_cpu_data is copied to cpu_data[0].

-- 
Jun'ichi Nomura, NEC Corporation / NEC Solution Innovators, Ltd.

Re: [tip:x86/urgent] x86/PAT: Fix Xorg regression on CPUs that don't support PAT

[Junichi Nomura]

On 05/31/17 02:59, Mikulas Patocka wrote:
>>> 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)) {
>>
>> Joy.
> 
> It is interesting - does it mean that the boot cpu does have PAT and the 
> secondary CPUs don't?

It seems pat_init() is called twice for boot cpu, from mtrr_bp_pat_init()
and generic_set_all(). The 2nd call ends up calling pat_ap_init() and it's
before boot_cpu_data is copied to cpu_data[0].

-- 
Jun'ichi Nomura, NEC Corporation / NEC Solution Innovators, Ltd.

Re: [tip:x86/urgent] x86/PAT: Fix Xorg regression on CPUs that don't support PAT

[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.

On 2017.05.29 18:50:57 -0400 (EDT) Mikulas Patocka wrote:
> On Sun, 28 May 2017, Andy Lutomirski wrote:
>> On Sun, May 28, 2017 at 11:18 AM, Bernhard Held  wrote:
>>> 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.

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

> 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

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

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

Test 3 result: fail

>> 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.
>
>> 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

Re: [tip:x86/urgent] x86/PAT: Fix Xorg regression on CPUs that don't support PAT

[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.

On 2017.05.29 18:50:57 -0400 (EDT) Mikulas Patocka wrote:
> On Sun, 28 May 2017, Andy Lutomirski wrote:
>> On Sun, May 28, 2017 at 11:18 AM, Bernhard Held  wrote:
>>> 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.

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

> 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

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

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

Test 3 result: fail

>> 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.
>
>> 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

Re: [tip:x86/urgent] x86/PAT: Fix Xorg regression on CPUs that don't support PAT

[Bernhard Held]

On 05/30/2017 at 07:59 PM, Mikulas Patocka wrote:



On Tue, 30 May 2017, Dominik Brodowski wrote:


Same boot problem here (Intel(R) Core(TM) i5-5200U CPU on a Dell XPS 13),
git-bisected to the same patch...

On Mon, May 29, 2017 at 06:50:57PM -0400, Mikulas Patocka wrote:

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;
}


No joy.


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


Joy.


It is interesting - does it mean that the boot cpu does have PAT and the
secondary CPUs don't? Please send /proc/cpuinfo with all the cores active.

This part of the patch is not required anyway, so I will resubmit the
patch with this part disabled (and with an added call to
init_cache_modes() as Andy suggested).

Mikulas


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


No joy.


Same result here., only #2 boots.

processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 23
model name  : Intel(R) Xeon(R) CPU   E5450  @ 3.00GHz
stepping: 10
microcode   : 0xa0b
cpu MHz : 2000.000
cache size  : 6144 KB
physical id : 0
siblings: 4
core id : 0
cpu cores   : 4
apicid  : 0
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 13
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm 
constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64 
monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 xsave lahf_lm 
tpr_shadow vnmi flexpriority dtherm
bugs:
bogomips: 5999.70
clflush size: 64
cache_alignment : 64
address sizes   : 38 bits physical, 48 bits virtual
power management:

processor   : 1
vendor_id   : GenuineIntel
cpu family  : 6
model   : 23
model name  : Intel(R) Xeon(R) CPU   E5450  @ 3.00GHz
stepping: 10
microcode   : 0xa0b
cpu MHz : 2000.000
cache size  : 6144 KB
physical id : 0
siblings: 4
core id : 3
cpu cores   : 4
apicid  : 3
initial apicid  : 3
fpu : yes
fpu_exception   : yes
cpuid level : 13
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm 
constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64 
monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 xsave lahf_lm 
tpr_shadow vnmi flexpriority dtherm
bugs:
bogomips: 5999.98
clflush size: 64
cache_alignment : 64
address sizes   : 38 bits physical, 48 bits virtual
power management:

processor   : 2
vendor_id   : GenuineIntel
cpu family  : 6
model   : 23
model name  : Intel(R) Xeon(R) CPU   E5450  @ 3.00GHz
stepping: 10
microcode   : 0xa0b
cpu MHz : 2000.000
cache size  : 6144 KB
physical id : 0
siblings: 4
core id : 2
cpu cores   : 4
apicid  : 2
initial apicid  : 2
fpu : yes
fpu_exception   : yes
cpuid level : 13
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm 
constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64 
monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 xsave lahf_lm 
tpr_shadow vnmi flexpriority dtherm
bugs:
bogomips: 5900.00
clflush size: 64
cache_alignment : 64
address sizes   : 38 bits physical, 48 bits virtual
power management:

processor   : 3
vendor_id   : GenuineIntel
cpu family  : 6
model   : 23
model name  : Intel(R) Xeon(R) CPU   E5450  @ 3.00GHz
stepping: 10
microcode   : 0xa0b
cpu MHz : 2000.000
cache size  : 6144 KB
physical id : 0
siblings: 4
core id : 1
cpu cores   : 4
apicid  : 1
initial apicid  : 1
fpu : yes
fpu_exception   : yes
cpuid level : 13
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm 
constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64 
monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 xsave lahf_lm 
tpr_shadow vnmi flexpriority dtherm
bugs:
bogomips: 5999.98
clflush size: 64
cache_alignment : 64
address sizes   : 38 bits physical, 48 bits virtual
power 

Re: [tip:x86/urgent] x86/PAT: Fix Xorg regression on CPUs that don't support PAT

[Bernhard Held]

On 05/30/2017 at 07:59 PM, Mikulas Patocka wrote:



On Tue, 30 May 2017, Dominik Brodowski wrote:


Same boot problem here (Intel(R) Core(TM) i5-5200U CPU on a Dell XPS 13),
git-bisected to the same patch...

On Mon, May 29, 2017 at 06:50:57PM -0400, Mikulas Patocka wrote:

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;
}


No joy.


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


Joy.


It is interesting - does it mean that the boot cpu does have PAT and the
secondary CPUs don't? Please send /proc/cpuinfo with all the cores active.

This part of the patch is not required anyway, so I will resubmit the
patch with this part disabled (and with an added call to
init_cache_modes() as Andy suggested).

Mikulas


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


No joy.


Same result here., only #2 boots.

processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 23
model name  : Intel(R) Xeon(R) CPU   E5450  @ 3.00GHz
stepping: 10
microcode   : 0xa0b
cpu MHz : 2000.000
cache size  : 6144 KB
physical id : 0
siblings: 4
core id : 0
cpu cores   : 4
apicid  : 0
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 13
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm 
constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64 
monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 xsave lahf_lm 
tpr_shadow vnmi flexpriority dtherm
bugs:
bogomips: 5999.70
clflush size: 64
cache_alignment : 64
address sizes   : 38 bits physical, 48 bits virtual
power management:

processor   : 1
vendor_id   : GenuineIntel
cpu family  : 6
model   : 23
model name  : Intel(R) Xeon(R) CPU   E5450  @ 3.00GHz
stepping: 10
microcode   : 0xa0b
cpu MHz : 2000.000
cache size  : 6144 KB
physical id : 0
siblings: 4
core id : 3
cpu cores   : 4
apicid  : 3
initial apicid  : 3
fpu : yes
fpu_exception   : yes
cpuid level : 13
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm 
constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64 
monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 xsave lahf_lm 
tpr_shadow vnmi flexpriority dtherm
bugs:
bogomips: 5999.98
clflush size: 64
cache_alignment : 64
address sizes   : 38 bits physical, 48 bits virtual
power management:

processor   : 2
vendor_id   : GenuineIntel
cpu family  : 6
model   : 23
model name  : Intel(R) Xeon(R) CPU   E5450  @ 3.00GHz
stepping: 10
microcode   : 0xa0b
cpu MHz : 2000.000
cache size  : 6144 KB
physical id : 0
siblings: 4
core id : 2
cpu cores   : 4
apicid  : 2
initial apicid  : 2
fpu : yes
fpu_exception   : yes
cpuid level : 13
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm 
constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64 
monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 xsave lahf_lm 
tpr_shadow vnmi flexpriority dtherm
bugs:
bogomips: 5900.00
clflush size: 64
cache_alignment : 64
address sizes   : 38 bits physical, 48 bits virtual
power management:

processor   : 3
vendor_id   : GenuineIntel
cpu family  : 6
model   : 23
model name  : Intel(R) Xeon(R) CPU   E5450  @ 3.00GHz
stepping: 10
microcode   : 0xa0b
cpu MHz : 2000.000
cache size  : 6144 KB
physical id : 0
siblings: 4
core id : 1
cpu cores   : 4
apicid  : 1
initial apicid  : 1
fpu : yes
fpu_exception   : yes
cpuid level : 13
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm 
constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64 
monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 xsave lahf_lm 
tpr_shadow vnmi flexpriority dtherm
bugs:
bogomips: 5999.98
clflush size: 64
cache_alignment : 64
address sizes   : 38 bits physical, 48 bits virtual
power 

Re: [tip:x86/urgent] x86/PAT: Fix Xorg regression on CPUs that don't support PAT

[Dominik Brodowski]

On Tue, May 30, 2017 at 01:59:41PM -0400, Mikulas Patocka wrote:
> On Tue, 30 May 2017, Dominik Brodowski wrote:
> 
> > Same boot problem here (Intel(R) Core(TM) i5-5200U CPU on a Dell XPS 13),
> > git-bisected to the same patch...
> > 
> > On Mon, May 29, 2017 at 06:50:57PM -0400, Mikulas Patocka wrote:
> > > 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;
> > > }
> > 
> > No joy.
> > 
> > > 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)) {
> > 
> > Joy.
> 
> It is interesting - does it mean that the boot cpu does have PAT and the 
> secondary CPUs don't? Please send /proc/cpuinfo with all the cores active.

This physical CPU has PAT on all cores / siblings:

processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 61
model name  : Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz
stepping: 4
microcode   : 0x24
cpu MHz : 800.158
cache size  : 3072 KB
physical id : 0
siblings: 4
core id : 0
cpu cores   : 2
apicid  : 0
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 20
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb 
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology 
nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 
ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt 
tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch 
cpuid_fault epb intel_pt tpr_shadow vnmi flexpriority ept vpid fsgsbase 
tsc_adjust bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap xsaveopt dtherm ida 
arat pln pts
bugs:
bogomips: 4389.80
clflush size: 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:

processor   : 1
vendor_id   : GenuineIntel
cpu family  : 6
model   : 61
model name  : Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz
stepping: 4
microcode   : 0x24
cpu MHz : 800.158
cache size  : 3072 KB
physical id : 0
siblings: 4
core id : 1
cpu cores   : 2
apicid  : 2
initial apicid  : 2
fpu : yes
fpu_exception   : yes
cpuid level : 20
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb 
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology 
nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 
ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt 
tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch 
cpuid_fault epb intel_pt tpr_shadow vnmi flexpriority ept vpid fsgsbase 
tsc_adjust bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap xsaveopt dtherm ida 
arat pln pts
bugs:
bogomips: 4436.14
clflush size: 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:

processor   : 2
vendor_id   : GenuineIntel
cpu family  : 6
model   : 61
model name  : Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz
stepping: 4
microcode   : 0x24
cpu MHz : 800.024
cache size  : 3072 KB
physical id : 0
siblings: 4
core id : 0
cpu cores   : 2
apicid  : 1
initial apicid  : 1
fpu : yes
fpu_exception   : yes
cpuid level : 20
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb 
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology 
nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 
ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt 
tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch 
cpuid_fault epb intel_pt tpr_shadow vnmi flexpriority ept vpid fsgsbase 
tsc_adjust bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap xsaveopt dtherm ida 
arat pln pts
bugs:
bogomips: 4397.30
clflush size: 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:

processor   : 3
vendor_id   : GenuineIntel
cpu family  : 6
model   : 61
model name  : Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz
stepping: 4
microcode   : 0x24
cpu MHz : 799.890
cache size  : 3072 KB
physical id : 0
siblings: 

Re: [tip:x86/urgent] x86/PAT: Fix Xorg regression on CPUs that don't support PAT

[Dominik Brodowski]

On Tue, May 30, 2017 at 01:59:41PM -0400, Mikulas Patocka wrote:
> On Tue, 30 May 2017, Dominik Brodowski wrote:
> 
> > Same boot problem here (Intel(R) Core(TM) i5-5200U CPU on a Dell XPS 13),
> > git-bisected to the same patch...
> > 
> > On Mon, May 29, 2017 at 06:50:57PM -0400, Mikulas Patocka wrote:
> > > 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;
> > > }
> > 
> > No joy.
> > 
> > > 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)) {
> > 
> > Joy.
> 
> It is interesting - does it mean that the boot cpu does have PAT and the 
> secondary CPUs don't? Please send /proc/cpuinfo with all the cores active.

This physical CPU has PAT on all cores / siblings:

processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 61
model name  : Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz
stepping: 4
microcode   : 0x24
cpu MHz : 800.158
cache size  : 3072 KB
physical id : 0
siblings: 4
core id : 0
cpu cores   : 2
apicid  : 0
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 20
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb 
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology 
nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 
ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt 
tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch 
cpuid_fault epb intel_pt tpr_shadow vnmi flexpriority ept vpid fsgsbase 
tsc_adjust bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap xsaveopt dtherm ida 
arat pln pts
bugs:
bogomips: 4389.80
clflush size: 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:

processor   : 1
vendor_id   : GenuineIntel
cpu family  : 6
model   : 61
model name  : Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz
stepping: 4
microcode   : 0x24
cpu MHz : 800.158
cache size  : 3072 KB
physical id : 0
siblings: 4
core id : 1
cpu cores   : 2
apicid  : 2
initial apicid  : 2
fpu : yes
fpu_exception   : yes
cpuid level : 20
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb 
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology 
nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 
ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt 
tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch 
cpuid_fault epb intel_pt tpr_shadow vnmi flexpriority ept vpid fsgsbase 
tsc_adjust bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap xsaveopt dtherm ida 
arat pln pts
bugs:
bogomips: 4436.14
clflush size: 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:

processor   : 2
vendor_id   : GenuineIntel
cpu family  : 6
model   : 61
model name  : Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz
stepping: 4
microcode   : 0x24
cpu MHz : 800.024
cache size  : 3072 KB
physical id : 0
siblings: 4
core id : 0
cpu cores   : 2
apicid  : 1
initial apicid  : 1
fpu : yes
fpu_exception   : yes
cpuid level : 20
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb 
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology 
nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 
ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt 
tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch 
cpuid_fault epb intel_pt tpr_shadow vnmi flexpriority ept vpid fsgsbase 
tsc_adjust bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap xsaveopt dtherm ida 
arat pln pts
bugs:
bogomips: 4397.30
clflush size: 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:

processor   : 3
vendor_id   : GenuineIntel
cpu family  : 6
model   : 61
model name  : Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz
stepping: 4
microcode   : 0x24
cpu MHz : 799.890
cache size  : 3072 KB
physical id : 0
siblings: 

Re: [tip:x86/urgent] x86/PAT: Fix Xorg regression on CPUs that don't support PAT

[Mikulas Patocka]

On Tue, 30 May 2017, Dominik Brodowski wrote:

> Same boot problem here (Intel(R) Core(TM) i5-5200U CPU on a Dell XPS 13),
> git-bisected to the same patch...
> 
> On Mon, May 29, 2017 at 06:50:57PM -0400, Mikulas Patocka wrote:
> > 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;
> > }
> 
> No joy.
> 
> > 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)) {
> 
> Joy.

It is interesting - does it mean that the boot cpu does have PAT and the 
secondary CPUs don't? Please send /proc/cpuinfo with all the cores active.

This part of the patch is not required anyway, so I will resubmit the 
patch with this part disabled (and with an added call to 
init_cache_modes() as Andy suggested).

Mikulas

> > 3. use the full PAT patch and apply the below patch on the top of it.
> 
> No joy.
> 
> 
> Best,
>   Dominik
> 

Re: [tip:x86/urgent] x86/PAT: Fix Xorg regression on CPUs that don't support PAT

[Mikulas Patocka]

On Tue, 30 May 2017, Dominik Brodowski wrote:

> Same boot problem here (Intel(R) Core(TM) i5-5200U CPU on a Dell XPS 13),
> git-bisected to the same patch...
> 
> On Mon, May 29, 2017 at 06:50:57PM -0400, Mikulas Patocka wrote:
> > 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;
> > }
> 
> No joy.
> 
> > 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)) {
> 
> Joy.

It is interesting - does it mean that the boot cpu does have PAT and the 
secondary CPUs don't? Please send /proc/cpuinfo with all the cores active.

This part of the patch is not required anyway, so I will resubmit the 
patch with this part disabled (and with an added call to 
init_cache_modes() as Andy suggested).

Mikulas

> > 3. use the full PAT patch and apply the below patch on the top of it.
> 
> No joy.
> 
> 
> Best,
>   Dominik
> 

Re: [tip:x86/urgent] x86/PAT: Fix Xorg regression on CPUs that don't support PAT

[Dominik Brodowski]

Same boot problem here (Intel(R) Core(TM) i5-5200U CPU on a Dell XPS 13),
git-bisected to the same patch...

On Mon, May 29, 2017 at 06:50:57PM -0400, Mikulas Patocka wrote:
> 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;
> }

No joy.

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

Joy.

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

No joy.


Best,
Dominik


signature.asc
Description: PGP signature

Re: [tip:x86/urgent] x86/PAT: Fix Xorg regression on CPUs that don't support PAT

[Dominik Brodowski]

Same boot problem here (Intel(R) Core(TM) i5-5200U CPU on a Dell XPS 13),
git-bisected to the same patch...

On Mon, May 29, 2017 at 06:50:57PM -0400, Mikulas Patocka wrote:
> 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;
> }

No joy.

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

Joy.

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

No joy.


Best,
Dominik


signature.asc
Description: PGP signature

Re: [tip:x86/urgent] x86/PAT: Fix Xorg regression on CPUs that don't support PAT

[Mikulas Patocka]

On Sun, 28 May 2017, Andy Lutomirski wrote:

> On Sun, May 28, 2017 at 11:18 AM, Bernhard Held  wrote:
> > Hi,
> >
> > this patch breaks the boot of my kernel. The last message is "Booting
> > the kernel.".
> >
> > 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.
> >
> > Please find below the dmesg of a the latest kernel w/o the PAT-patch.
> > I'm happy to provide more information or to test patches.

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;
}

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

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

> 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.

> 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


---
 arch/x86/include/asm/pat.h |1 +
 arch/x86/kernel/setup.c|1 +
 arch/x86/mm/pat.c  |3 +--
 3 files changed, 3 insertions(+), 2 deletions(-)

Index: linux-stable/arch/x86/include/asm/pat.h
===
--- linux-stable.orig/arch/x86/include/asm/pat.h
+++ linux-stable/arch/x86/include/asm/pat.h
@@ -8,6 +8,7 @@
 
 void pat_disable(const char *reason);
 extern void pat_init(void);
+extern void init_cache_modes(void);
 
 extern int reserve_memtype(u64 start, u64 end,
enum page_cache_mode req_pcm, enum page_cache_mode *ret_pcm);
Index: linux-stable/arch/x86/kernel/setup.c
===
--- linux-stable.orig/arch/x86/kernel/setup.c
+++ linux-stable/arch/x86/kernel/setup.c
@@ -1074,6 +1074,7 @@ void __init setup_arch(char **cmdline_p)
 
/* update e820 for memory not covered by WB MTRRs */
mtrr_bp_init();
+   init_cache_modes();
if (mtrr_trim_uncached_memory(max_pfn))
max_pfn = e820_end_of_ram_pfn();
 
Index: linux-stable/arch/x86/mm/pat.c
===
--- linux-stable.orig/arch/x86/mm/pat.c
+++ linux-stable/arch/x86/mm/pat.c
@@ -39,7 +39,6 @@
 static bool boot_cpu_done;
 
 static int __read_mostly __pat_enabled = IS_ENABLED(CONFIG_X86_PAT);
-static void init_cache_modes(void);
 
 void pat_disable(const char *reason)
 {
@@ -237,7 +236,7 @@ static void pat_ap_init(u64 pat)
wrmsrl(MSR_IA32_CR_PAT, pat);
 }
 
-static void init_cache_modes(void)
+void init_cache_modes(void)
 {
u64 pat = 0;
static int init_cm_done;

Re: [tip:x86/urgent] x86/PAT: Fix Xorg regression on CPUs that don't support PAT

[Mikulas Patocka]

On Sun, 28 May 2017, Andy Lutomirski wrote:

> On Sun, May 28, 2017 at 11:18 AM, Bernhard Held  wrote:
> > Hi,
> >
> > this patch breaks the boot of my kernel. The last message is "Booting
> > the kernel.".
> >
> > 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.
> >
> > Please find below the dmesg of a the latest kernel w/o the PAT-patch.
> > I'm happy to provide more information or to test patches.

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;
}

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

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

> 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.

> 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


---
 arch/x86/include/asm/pat.h |1 +
 arch/x86/kernel/setup.c|1 +
 arch/x86/mm/pat.c  |3 +--
 3 files changed, 3 insertions(+), 2 deletions(-)

Index: linux-stable/arch/x86/include/asm/pat.h
===
--- linux-stable.orig/arch/x86/include/asm/pat.h
+++ linux-stable/arch/x86/include/asm/pat.h
@@ -8,6 +8,7 @@
 
 void pat_disable(const char *reason);
 extern void pat_init(void);
+extern void init_cache_modes(void);
 
 extern int reserve_memtype(u64 start, u64 end,
enum page_cache_mode req_pcm, enum page_cache_mode *ret_pcm);
Index: linux-stable/arch/x86/kernel/setup.c
===
--- linux-stable.orig/arch/x86/kernel/setup.c
+++ linux-stable/arch/x86/kernel/setup.c
@@ -1074,6 +1074,7 @@ void __init setup_arch(char **cmdline_p)
 
/* update e820 for memory not covered by WB MTRRs */
mtrr_bp_init();
+   init_cache_modes();
if (mtrr_trim_uncached_memory(max_pfn))
max_pfn = e820_end_of_ram_pfn();
 
Index: linux-stable/arch/x86/mm/pat.c
===
--- linux-stable.orig/arch/x86/mm/pat.c
+++ linux-stable/arch/x86/mm/pat.c
@@ -39,7 +39,6 @@
 static bool boot_cpu_done;
 
 static int __read_mostly __pat_enabled = IS_ENABLED(CONFIG_X86_PAT);
-static void init_cache_modes(void);
 
 void pat_disable(const char *reason)
 {
@@ -237,7 +236,7 @@ static void pat_ap_init(u64 pat)
wrmsrl(MSR_IA32_CR_PAT, pat);
 }
 
-static void init_cache_modes(void)
+void init_cache_modes(void)
 {
u64 pat = 0;
static int init_cm_done;

Re: [tip:x86/urgent] x86/PAT: Fix Xorg regression on CPUs that don't support PAT

[Andy Lutomirski]

On Sun, May 28, 2017 at 11:18 AM, Bernhard Held  wrote:
> Hi,
>
> this patch breaks the boot of my kernel. The last message is "Booting
> the kernel.".
>
> 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.
>
> Please find below the dmesg of a the latest kernel w/o the PAT-patch.
> I'm happy to provide more information or to test patches.

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

Re: [tip:x86/urgent] x86/PAT: Fix Xorg regression on CPUs that don't support PAT

[Andy Lutomirski]

On Sun, May 28, 2017 at 11:18 AM, Bernhard Held  wrote:
> Hi,
>
> this patch breaks the boot of my kernel. The last message is "Booting
> the kernel.".
>
> 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.
>
> Please find below the dmesg of a the latest kernel w/o the PAT-patch.
> I'm happy to provide more information or to test patches.

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

Re: [tip:x86/urgent] x86/PAT: Fix Xorg regression on CPUs that don't support PAT

[Bernhard Held]

Hi,

this patch breaks the boot of my kernel. The last message is "Booting
the kernel.".

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.

Please find below the dmesg of a the latest kernel w/o the PAT-patch.
I'm happy to provide more information or to test patches.

Have fun,
Bernhard

[0.00] Linux version 4.12.0-rc2-linus+ (berny@quad) (gcc version 6.3.1 
20170202 [gcc-6-branch revision 245119] (SUSE Linux) ) #152 SMP PREEMPT Sun May 
28 19:26:20 CEST 2017
[0.00] Command line: BOOT_IMAGE=/vmlinuz-4.12.0-rc2-linus+ 
root=/dev/mapper/VGMX300-root resume=/dev/sda2 showopts radeon.dpm=1 
memmap=1$0xe4fd net.ifnames=0
[0.00] KERNEL supported cpus:
[0.00]   Intel GenuineIntel
[0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point 
registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[0.00] x86/fpu: Enabled xstate features 0x3, context size is 576 bytes, 
using 'standard' format.
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009dbff] usable
[0.00] BIOS-e820: [mem 0x0009f800-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000f-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0xcfed] usable
[0.00] BIOS-e820: [mem 0xcfee-0xcfee2fff] ACPI NVS
[0.00] BIOS-e820: [mem 0xcfee3000-0xcfee] ACPI data
[0.00] BIOS-e820: [mem 0xcfef-0xcfef] reserved
[0.00] BIOS-e820: [mem 0xd000-0xdfff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x0001afff] usable
[0.00] NX (Execute Disable) protection: active
[0.00] e820: user-defined physical RAM map:
[0.00] user: [mem 0x-0xe4fc] usable
[0.00] user: [mem 0xe4fd-0xe4fd] reserved
[0.00] user: [mem 0xe4fe-0x0009dbff] usable
[0.00] user: [mem 0x0009f800-0x0009] reserved
[0.00] user: [mem 0x000f-0x000f] reserved
[0.00] user: [mem 0x0010-0xcfed] usable
[0.00] user: [mem 0xcfee-0xcfee2fff] ACPI NVS
[0.00] user: [mem 0xcfee3000-0xcfee] ACPI data
[0.00] user: [mem 0xcfef-0xcfef] reserved
[0.00] user: [mem 0xd000-0xdfff] reserved
[0.00] user: [mem 0xfec0-0x] reserved
[0.00] user: [mem 0x0001-0x0001afff] usable
[0.00] SMBIOS 2.4 present.
[0.00] DMI: Gigabyte Technology Co., Ltd. G33-DS3R/G33-DS3R, BIOS F7L 
07/31/2009
[0.00] tsc: Fast TSC calibration using PIT
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] e820: last_pfn = 0x1b max_arch_pfn = 0x4
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-CDFFF write-protect
[0.00]   CE000-E uncachable
[0.00]   F-F write-through
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 00 mask 0F write-back
[0.00]   1 base 00E000 mask 0FE000 uncachable
[0.00]   2 base 00D000 mask 0FF000 uncachable
[0.00]   3 base 01 mask 0F write-back
[0.00]   4 base 01C000 mask 0FC000 uncachable
[0.00]   5 base 01B000 mask 0FF000 uncachable
[0.00]   6 base 00CFF0 mask 00 uncachable
[0.00]   7 disabled
[0.00] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WC  UC- WT
[0.00] mtrr: your BIOS has configured an incorrect mask, fixing it.
[0.00] mtrr: your BIOS has configured an incorrect mask, fixing it.
[0.00] mtrr: your BIOS has configured an incorrect mask, fixing it.
[0.00] mtrr: your BIOS has configured an incorrect mask, fixing it.
[0.00] mtrr: your BIOS has configured an incorrect mask, fixing it.
[0.00] mtrr: your BIOS has configured an incorrect mask, fixing it.
[0.00] mtrr: your BIOS has configured an incorrect mask, fixing it.
[0.00] total RAM covered: 6143M
[0.00] Found optimal setting for mtrr clean up
[0.00]  gran_size: 64K  chunk_size: 2M  num_reg: 7  lose cover RAM: 
0G
[0.00] e820: update [mem 0xcff0-0x] usable ==> reserved
[0.00] 

Re: [tip:x86/urgent] x86/PAT: Fix Xorg regression on CPUs that don't support PAT

[Bernhard Held]

Hi,

this patch breaks the boot of my kernel. The last message is "Booting
the kernel.".

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.

Please find below the dmesg of a the latest kernel w/o the PAT-patch.
I'm happy to provide more information or to test patches.

Have fun,
Bernhard

[0.00] Linux version 4.12.0-rc2-linus+ (berny@quad) (gcc version 6.3.1 
20170202 [gcc-6-branch revision 245119] (SUSE Linux) ) #152 SMP PREEMPT Sun May 
28 19:26:20 CEST 2017
[0.00] Command line: BOOT_IMAGE=/vmlinuz-4.12.0-rc2-linus+ 
root=/dev/mapper/VGMX300-root resume=/dev/sda2 showopts radeon.dpm=1 
memmap=1$0xe4fd net.ifnames=0
[0.00] KERNEL supported cpus:
[0.00]   Intel GenuineIntel
[0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point 
registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[0.00] x86/fpu: Enabled xstate features 0x3, context size is 576 bytes, 
using 'standard' format.
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009dbff] usable
[0.00] BIOS-e820: [mem 0x0009f800-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000f-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0xcfed] usable
[0.00] BIOS-e820: [mem 0xcfee-0xcfee2fff] ACPI NVS
[0.00] BIOS-e820: [mem 0xcfee3000-0xcfee] ACPI data
[0.00] BIOS-e820: [mem 0xcfef-0xcfef] reserved
[0.00] BIOS-e820: [mem 0xd000-0xdfff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x0001afff] usable
[0.00] NX (Execute Disable) protection: active
[0.00] e820: user-defined physical RAM map:
[0.00] user: [mem 0x-0xe4fc] usable
[0.00] user: [mem 0xe4fd-0xe4fd] reserved
[0.00] user: [mem 0xe4fe-0x0009dbff] usable
[0.00] user: [mem 0x0009f800-0x0009] reserved
[0.00] user: [mem 0x000f-0x000f] reserved
[0.00] user: [mem 0x0010-0xcfed] usable
[0.00] user: [mem 0xcfee-0xcfee2fff] ACPI NVS
[0.00] user: [mem 0xcfee3000-0xcfee] ACPI data
[0.00] user: [mem 0xcfef-0xcfef] reserved
[0.00] user: [mem 0xd000-0xdfff] reserved
[0.00] user: [mem 0xfec0-0x] reserved
[0.00] user: [mem 0x0001-0x0001afff] usable
[0.00] SMBIOS 2.4 present.
[0.00] DMI: Gigabyte Technology Co., Ltd. G33-DS3R/G33-DS3R, BIOS F7L 
07/31/2009
[0.00] tsc: Fast TSC calibration using PIT
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] e820: last_pfn = 0x1b max_arch_pfn = 0x4
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-CDFFF write-protect
[0.00]   CE000-E uncachable
[0.00]   F-F write-through
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 00 mask 0F write-back
[0.00]   1 base 00E000 mask 0FE000 uncachable
[0.00]   2 base 00D000 mask 0FF000 uncachable
[0.00]   3 base 01 mask 0F write-back
[0.00]   4 base 01C000 mask 0FC000 uncachable
[0.00]   5 base 01B000 mask 0FF000 uncachable
[0.00]   6 base 00CFF0 mask 00 uncachable
[0.00]   7 disabled
[0.00] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WC  UC- WT
[0.00] mtrr: your BIOS has configured an incorrect mask, fixing it.
[0.00] mtrr: your BIOS has configured an incorrect mask, fixing it.
[0.00] mtrr: your BIOS has configured an incorrect mask, fixing it.
[0.00] mtrr: your BIOS has configured an incorrect mask, fixing it.
[0.00] mtrr: your BIOS has configured an incorrect mask, fixing it.
[0.00] mtrr: your BIOS has configured an incorrect mask, fixing it.
[0.00] mtrr: your BIOS has configured an incorrect mask, fixing it.
[0.00] total RAM covered: 6143M
[0.00] Found optimal setting for mtrr clean up
[0.00]  gran_size: 64K  chunk_size: 2M  num_reg: 7  lose cover RAM: 
0G
[0.00] e820: update [mem 0xcff0-0x] usable ==> reserved
[0.00] 

[tip:x86/urgent] x86/PAT: Fix Xorg regression on CPUs that don't support PAT

[tip-bot for Mikulas Patocka]

Commit-ID:  cbed27cdf0e3f7ea3b2259e86b9e34df02be3fe4
Gitweb: http://git.kernel.org/tip/cbed27cdf0e3f7ea3b2259e86b9e34df02be3fe4
Author: Mikulas Patocka 
AuthorDate: Tue, 18 Apr 2017 15:07:11 -0400
Committer:  Ingo Molnar 
CommitDate: Wed, 24 May 2017 10:17:23 +0200

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

In the file arch/x86/mm/pat.c, there's a '__pat_enabled' variable. 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 CPUs, 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 a kernel warning is produced when attempting 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:

  x86/PAT: Xorg:3891 map pfn expected mapping type uncached-minus for [mem 
0xe400-0xe5ff], got write-combining
  [ cut here ]
  WARNING: CPU: 0 PID: 3891 at arch/x86/mm/pat.c:1020 untrack_pfn+0x5c/0x9f
  ...
  x86/PAT: Xorg:3891 map pfn expected mapping type uncached-minus for [mem 
0xe400-0xe5ff], got write-combining

To fix the bug change 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.

Signed-off-by: Mikulas Patocka 
Cc: Andrew Morton 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Luis R. Rodriguez 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Toshi Kani 
Cc: sta...@vger.kernel.org # v4.2+
Link: 
http://lkml.kernel.org/r/alpine.lrh.2.02.1704181501450.26...@file01.intranet.prod.int.rdu2.redhat.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/mm/pat.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
index 9b78685..83a59a6 100644
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -65,9 +65,11 @@ static int __init nopat(char *str)
 }
 early_param("nopat", nopat);
 
+static bool __read_mostly __pat_initialized = false;
+
 bool pat_enabled(void)
 {
-   return !!__pat_enabled;
+   return __pat_initialized;
 }
 EXPORT_SYMBOL_GPL(pat_enabled);
 
@@ -225,13 +227,14 @@ static void pat_bsp_init(u64 pat)
}
 
wrmsrl(MSR_IA32_CR_PAT, pat);
+   __pat_initialized = true;
 
__init_cache_modes(pat);
 }
 
 static void pat_ap_init(u64 pat)
 {
-   if (!boot_cpu_has(X86_FEATURE_PAT)) {
+   if (!this_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.
@@ -306,7 +309,7 @@ void pat_init(void)
u64 pat;
struct cpuinfo_x86 *c = _cpu_data;
 
-   if (!pat_enabled()) {
+   if (!__pat_enabled) {
init_cache_modes();
return;
}

[tip:x86/urgent] x86/PAT: Fix Xorg regression on CPUs that don't support PAT

[tip-bot for Mikulas Patocka]

Commit-ID:  cbed27cdf0e3f7ea3b2259e86b9e34df02be3fe4
Gitweb: http://git.kernel.org/tip/cbed27cdf0e3f7ea3b2259e86b9e34df02be3fe4
Author: Mikulas Patocka 
AuthorDate: Tue, 18 Apr 2017 15:07:11 -0400
Committer:  Ingo Molnar 
CommitDate: Wed, 24 May 2017 10:17:23 +0200

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

In the file arch/x86/mm/pat.c, there's a '__pat_enabled' variable. 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 CPUs, 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 a kernel warning is produced when attempting 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:

  x86/PAT: Xorg:3891 map pfn expected mapping type uncached-minus for [mem 
0xe400-0xe5ff], got write-combining
  [ cut here ]
  WARNING: CPU: 0 PID: 3891 at arch/x86/mm/pat.c:1020 untrack_pfn+0x5c/0x9f
  ...
  x86/PAT: Xorg:3891 map pfn expected mapping type uncached-minus for [mem 
0xe400-0xe5ff], got write-combining

To fix the bug change 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.

Signed-off-by: Mikulas Patocka 
Cc: Andrew Morton 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Luis R. Rodriguez 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Toshi Kani 
Cc: sta...@vger.kernel.org # v4.2+
Link: 
http://lkml.kernel.org/r/alpine.lrh.2.02.1704181501450.26...@file01.intranet.prod.int.rdu2.redhat.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/mm/pat.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
index 9b78685..83a59a6 100644
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -65,9 +65,11 @@ static int __init nopat(char *str)
 }
 early_param("nopat", nopat);
 
+static bool __read_mostly __pat_initialized = false;
+
 bool pat_enabled(void)
 {
-   return !!__pat_enabled;
+   return __pat_initialized;
 }
 EXPORT_SYMBOL_GPL(pat_enabled);
 
@@ -225,13 +227,14 @@ static void pat_bsp_init(u64 pat)
}
 
wrmsrl(MSR_IA32_CR_PAT, pat);
+   __pat_initialized = true;
 
__init_cache_modes(pat);
 }
 
 static void pat_ap_init(u64 pat)
 {
-   if (!boot_cpu_has(X86_FEATURE_PAT)) {
+   if (!this_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.
@@ -306,7 +309,7 @@ void pat_init(void)
u64 pat;
struct cpuinfo_x86 *c = _cpu_data;
 
-   if (!pat_enabled()) {
+   if (!__pat_enabled) {
init_cache_modes();
return;
}