Cannot boot any HIGHMEM kernel (kernel panic - not syncing)

Cannot boot any HIGHMEM kernel (kernel panic - not syncing)

[Michael Elsdörfer]

This is an etch server machine with 3GB of RAM, and I seem unable to
boot into any kernel (precompiled images from the Debian and OpenVZ 
repositories, I have so far avoided to compile one myself) that has 
HIGHMEM enabled, i.e.:

zoidberg:/# dmesg | head
Warning only 896MB will be used.
Use a HIGHMEM enabled kernel.
896MB LOWMEM available.

Specifically, the only kernel image that seems to work is
linux-image-2.6.18-6-486 (or the OpenVZ version fzakernel-2.6.18-486)

Everything else seems to fail with:

Setting up standard PCI resources
ACPI: Interpreter enabled
ACPI: PCI Root Bridge [PCI0] (0000:00)
CPU 0: Machine Check Exception: 0000000000000007
Bank 3: b40000000000083b at 000000fdfc000cfc
Kernel panic - not syncing: Unable to continue

Specifically, I tried at least the following images from the Debian and
OpenVZ repositories:

config-2.6.18-openvz-k7
linux-image-2.6.18-6-686
fzakernel-2.6.18-686
fzakernel-2.6.18-686-bigmem

Now, Machine Check Exception seems to point towards a hardware error,
but not only does the 486 kernel appear to work flawlessly, the server
was perfectly happy running a self-compiled sarge kernel (with HIGHMEM)
just a couple of days ago.

Here's the processor info:

zoidberg:/boot# cat /proc/cpuinfo
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 5
model name      : AMD Opteron(tm) Processor 244
stepping        : 10
cpu MHz         : 1794.546
cache size      : 1024 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm
3dnowext 3dnow ts fid vid ttp
bogomips        : 3591.45

Does anybody know what the issue might be, e.g. what exactly in the 
non-486 kernels might cause the error?

Thanks,

Michael

Re: Cannot boot any HIGHMEM kernel (kernel panic - not syncing)

[Andi Kleen]

Michael Elsdörfer <michael@elsdoerfer.info> writes:
>
> Now, Machine Check Exception seems to point towards a hardware error,

It not only seems to, it does.

> but not only does the 486 kernel appear to work flawlessly, the server
> was perfectly happy running a self-compiled sarge kernel (with HIGHMEM)
> just a couple of days ago.

The non highmem kernel will simply not use most of your memory, so if 
the machine check happens accessing memory you will not see it.

-Andi

Re: Cannot boot any HIGHMEM kernel (kernel panic - not syncing)

[Michael Elsdörfer]

 >> Now, Machine Check Exception seems to point towards a hardware error,
 >
 > It not only seems to, it does.
 > The non highmem kernel will simply not use most of your memory, so if
 > the machine check happens accessing memory you will not see it.

Thanks Andi.

So the problem would be defective RAM in the machine?

I'm still wondering though while the previous kernel (a self-compiled 
2.6.17.11) worked then. Laxer checks?

Michael

Re: Cannot boot any HIGHMEM kernel (kernel panic - not syncing)

[Dan Noe]

On 5/8/2008 07:57, Michael Elsdörfer wrote:
> So the problem would be defective RAM in the machine?

Especially with an MCE versus evidence of random bit flipping, I would 
also check to verify that all your memory modules are seated correctly. 
  If you are only using one of the DIMMs with LOWMEM only then you may 
be avoiding one which has a flakey connection.

I have solved at least one other mysterious MCE problem by reseating the 
DIMMS.

Cheers,
Dan

-- 
                     /--------------- - -  -  -   -   -
                     |  Daniel Noe
                     |  http://isomerica.net/~dpn/

Re: Cannot boot any HIGHMEM kernel (kernel panic - not syncing)

[Andi Kleen]

Michael Elsdörfer wrote:
>>> Now, Machine Check Exception seems to point towards a hardware error,
>>
>> It not only seems to, it does.
>> The non highmem kernel will simply not use most of your memory, so if
>> the machine check happens accessing memory you will not see it.
> 
> Thanks Andi.
> 
> So the problem would be defective RAM in the machine?
> 
> I'm still wondering though while the previous kernel (a self-compiled
> 2.6.17.11) worked then. Laxer checks?

Memory access patterns change between kernels. Likely if you had filled
your memory with some program you would have seen it too.

I always use ftp://ftp.firstfloor.org/pub/ak/memeat.c for testing for
such problems. It simply allocates all free memory and reads and writes
it in a loop.


-Andi