[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080506114839.GD32591@elte.hu>
Date: Tue, 6 May 2008 13:48:39 +0200
From: Ingo Molnar <mingo@...e.hu>
To: Mikael Pettersson <mikpe@...uu.se>
Cc: tglx@...utronix.de, mingo@...hat.com, hpa@...or.com,
venkatesh.pallipadi@...el.com, linux-kernel@...r.kernel.org
Subject: Re: 2.6.26-rc1 lies about PAT not being available
* Mikael Pettersson <mikpe@...uu.se> wrote:
> Booting 2.6.26-rc1 on an old Coppermine PIII, I'm greeted with:
>
> >Linux version 2.6.26-rc1 (mikpe@...hop) (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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists