2.6.26-rc1 lies about PAT not being available

2.6.26-rc1 lies about PAT not being available

[Mikael Pettersson]

Booting 2.6.26-rc1 on an old Coppermine PIII, I'm greeted with:

>Linux version 2.6.26-rc1 (mikpe@dryhop) (gcc version 4.2.3) #1 Mon May 5 21:49:49 CEST 2008
>BIOS-provided physical RAM map:
> BIOS-e820: 0000000000000000 - 000000000009c000 (usable)
> BIOS-e820: 000000000009c000 - 00000000000a0000 (reserved)
> BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
> BIOS-e820: 0000000000100000 - 000000002ffec000 (usable)
> BIOS-e820: 000000002ffec000 - 000000002ffef000 (ACPI data)
> BIOS-e820: 000000002ffef000 - 000000002ffff000 (reserved)
> BIOS-e820: 000000002ffff000 - 0000000030000000 (ACPI NVS)
> BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
>CPU and/or kernel does not support PAT.

I know about Intel's PAT erratum (only 4 PAT entries work) and
understand that the kernel might not want to use a half-broken
PAT implementation, but the statement above is blatantly false:
the kernel IS built with PAT support and the CPU DOES have
(half-broken) PAT HW support as /proc/cpuinfo from earlier kernels
confirms.

arch/x86/kernel/cpu/common.c unconditionally disables PAT and
then reenables it for certain vendor/family/model combinations.(*)
Then mm/pat.c comes along, finds !cpu_has_pat, and prints the
bogus message above.

IMO, it would be a lot nicer if common.c printed a warning when
it disables PAT due to the erratum, then the printk() in pat.c
could be something like "PAT support absent or disabled".

(*) common.c enables PAT for all Intel family 15 CPUs. Is that
correct? I don't have the spec updates in front of me, but I
seem to recall the PAT erratum existed also in early P4s.

/Mikael

Re: 2.6.26-rc1 lies about PAT not being available

[Ingo Molnar]

* Mikael Pettersson <mikpe@it.uu.se> wrote:

> Booting 2.6.26-rc1 on an old Coppermine PIII, I'm greeted with:
> 
> >Linux version 2.6.26-rc1 (mikpe@dryhop) (gcc version 4.2.3) #1 Mon May 5 21:49:49 CEST 2008
> >BIOS-provided physical RAM map:
> > BIOS-e820: 0000000000000000 - 000000000009c000 (usable)
> > BIOS-e820: 000000000009c000 - 00000000000a0000 (reserved)
> > BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
> > BIOS-e820: 0000000000100000 - 000000002ffec000 (usable)
> > BIOS-e820: 000000002ffec000 - 000000002ffef000 (ACPI data)
> > BIOS-e820: 000000002ffef000 - 000000002ffff000 (reserved)
> > BIOS-e820: 000000002ffff000 - 0000000030000000 (ACPI NVS)
> > BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
> >CPU and/or kernel does not support PAT.
> 
> I know about Intel's PAT erratum (only 4 PAT entries work) and 
> understand that the kernel might not want to use a half-broken PAT 
> implementation, but the statement above is blatantly false: the kernel 
> IS built with PAT support and the CPU DOES have (half-broken) PAT HW 
> support as /proc/cpuinfo from earlier kernels confirms.

well the code is just being overly conservative, and the message is 
right: the kernel does not support PAT on that hw. Yet.

Please send us a patch and test whether it's working on your box? That's 
how the PAT code evolved: it initially was only enabled on a very small 
subset of CPUs. We can enable it on more CPUs if people test it.

To be conservative, please make the code emit a printk that this is PAT 
on not fully-working hw platform (only 4 PAT entries work). If there 
_is_ some erratum on that CPU affecting PAT reliability down the line, 
we at least want to have some clue in the syslog.

	Ingo

Re: 2.6.26-rc1 lies about PAT not being available

[H. Peter Anvin]

Ingo Molnar wrote:
>> I know about Intel's PAT erratum (only 4 PAT entries work) and 
>> understand that the kernel might not want to use a half-broken PAT 
>> implementation, but the statement above is blatantly false: the kernel 
>> IS built with PAT support and the CPU DOES have (half-broken) PAT HW 
>> support as /proc/cpuinfo from earlier kernels confirms.
> 
> well the code is just being overly conservative, and the message is 
> right: the kernel does not support PAT on that hw. Yet.
> 
> Please send us a patch and test whether it's working on your box? That's 
> how the PAT code evolved: it initially was only enabled on a very small 
> subset of CPUs. We can enable it on more CPUs if people test it.
> 
> To be conservative, please make the code emit a printk that this is PAT 
> on not fully-working hw platform (only 4 PAT entries work). If there 
> _is_ some erratum on that CPU affecting PAT reliability down the line, 
> we at least want to have some clue in the syslog.
> 

For what it's worth, we only use four PAT entries, so it doesn't matter 
that only four work.

	-hpa