Bug#720272: unbootable and lead to data loss?
On Wed, 2013-08-21 at 11:11 +0100, Ben Hutchings wrote:
> On Wed, 2013-08-21 at 10:53 +0100, Ian Campbell wrote:
> > On Wed, 2013-08-21 at 11:30 +0200, Bastian Blank wrote:
> > > On Wed, Aug 21, 2013 at 09:00:14AM +0100, Ian Campbell wrote:
> > > > On Tue, 2013-08-20 at 22:51 +0800, jidanni@jidanni.org wrote:
> > > > > product: Intel(R) Celeron(R) M processor 1.40GHz
> > > > > capabilities: fpu fpu_exception wp vme de pse tsc msr mce cx8 sep mtrr pge mca cmov clflush dts acpi mmx fxsr sse sse2 ss tm pbe up bts
> > > > The kernel will always either boot or not boot (with a message from the
> > > > very early loader about lack of PAE). On the system above it looks like
> > > > it wouldn't boot due to lack of PAE.
> > >
> > > It is quite possible that this CPU actually supports PAE. They don't
> > > show it until you try to enable it.
> >
> > Ah, I wasn't sure if the kernel would check for the CPUID bit and just
> > fail or do something more clever to see if it worked.
> >
> > In any case my main point is that it will either work or not. There is
> > no half working/data corrupting case.
>
> There might be if the CPUs that don't advertise PAE also weren't tested
> for PAE functionality at manufacturing time.
Hrm, that's true I guess. I'm a bit surprised that the upstream guys
just enable PAE blindy on systems which don't advertise it TBH, that's
not very conservative, I could better imagine them whitelisting some
machines which were known good.
Looking at the kernel though, if CONFIG_X86_PAE is set then NEED_PAE is
set, this is then included in REQUIRED_MASK0. If I'm reading it right
then arch/x86/boot/cpucheck.c seems to want to require these bits to be
set and it will eventually crap out in validate_cpu. I don't actually
have a non-pae system to try this on though...
> But if we make the 686-pae kernel refuse to boot without PAE advertised,
> we'll also break currently working systems.
Ian.
Reply to: