2.6.11.7-2.1.5 boots just after image load

[maple]

Hello Brad and others!

I have weird problem with 2.1.5-2.6.11.7-200504111924
When booting, kernel reboots immediately or almost immediately after kernel image loaded. I cant figure exact place where it boots, it remote machine with slow KVM console. plain 2.6.11.7 boots perfectly, with grsec patch, even if _all_ grsecurity disabled - reboot.
Tried gcc-3.3, gcc-2.95, changing cpu types, played with smp, acpi, apic, kernel parameters, direct pci access, googled and read this forum - no luck. Seems it depends from hardware, because on another machines it boots without problems.
kernel failing only on
2 x Intel(R) Xeon(TM) CPU 3.00GHz, 4G ram, supermicro

I have no more ideas what to do to make it work
Maybe you can show me direction...

cpuinfo shows

cpu family : 15
model : 4
model name : Intel(R) Xeon(TM) CPU 3.00GHz
stepping : 1
cpu MHz : 3000.230
cache size : 1024 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clfl
ush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm pni monitor ds_cpl cid

part of lspci
0000:00:00.0 Host bridge: Intel Corp. Server Memory Controller Hub (rev 0c)
0000:00:00.1 ff00: Intel Corp. Memory Controller Hub Error Reporting Register (rev 0c)
0000:00:02.0 PCI bridge: Intel Corp. Memory Controller Hub PCI Express Port A0 (rev 0c)
0000:00:04.0 PCI bridge: Intel Corp. Memory Controller Hub PCI Express Port B0 (rev 0c)
0000:00:06.0 PCI bridge: Intel Corp. Memory Controller Hub PCI Express Port C0 (rev 0c)
0000:00:1c.0 PCI bridge: Intel Corp. 6300ESB 64-bit PCI-X Bridge (rev 02)
0000:00:1d.4 System peripheral: Intel Corp. 6300ESB Watchdog Timer (rev 02)
0000:00:1d.5 PIC: Intel Corp. 6300ESB I/O Advanced Programmable Interrupt Controller (rev 02)
0000:00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev 0a)
0000:00:1f.0 ISA bridge: Intel Corp. 6300ESB LPC Interface Controller (rev 02)
0000:00:1f.1 IDE interface: Intel Corp. 6300ESB PATA Storage Controller (rev 02)
0000:00:1f.3 SMBus: Intel Corp. 6300ESB SMBus Controller (rev 02)
0000:01:00.0 PCI bridge: Intel Corp. PCI Bridge Hub A (rev 09)
0000:01:00.1 PIC: Intel Corp. PCI Bridge Hub I/OxAPIC Interrupt Controller A (rev 09)
0000:01:00.2 PCI bridge: Intel Corp. PCI Bridge Hub B (rev 09)
0000:01:00.3 PIC: Intel Corp. PCI Bridge Hub I/OxAPIC Interrupt Controller B (rev 09)

[PaX Team]

I have weird problem with 2.1.5-2.6.11.7-200504111924
When booting, kernel reboots immediately or almost immediately after kernel image loaded. I cant figure exact place where it boots, it remote machine with slow KVM console. plain 2.6.11.7 boots perfectly, with grsec patch, even if _all_ grsecurity disabled - reboot.

1. can you try it with the PaX patch alone? 2. what highmem config settings did you try (in particular, was the 64GB support on)?

[maple]

changing highmem support from 64g to 4g helps
Big thanks!

[PaX Team]

changing highmem support from 64g to 4g helps
Big thanks!

not that good 'cos it means that my changes to PAE mode don't quite work with your config. i take it that this box is in production and you can't do much debugging, but just to be sure, can you try the PaX patch alone one day and also boot with mem=3G (or anything less than 4G)? also, do the other boxes have 4GB (or more) memory as well? and last, can you post the PaX parts of your .config (or just the status of KERNEXEC)?

[maple]

not that good 'cos it means that my changes to PAE mode don't quite work with your config. i take it that this box is in production and you can't do much debugging, but just to be sure, can you try the PaX patch alone one day and also boot with mem=3G (or anything less than 4G)? also, do the other boxes have 4GB (or more) memory as well? and last, can you post the PaX parts of your .config (or just the status KERNEXEC)?

Hello,
pax part of config (i've not found KERNEXEC in .config):
# grep PAX /boot/config-2.6.11.8-grsec | grep -v '^#'
CONFIG_PAX=y
CONFIG_PAX_HAVE_ACL_FLAGS=y
CONFIG_PAX_NOEXEC=y
CONFIG_PAX_SEGMEXEC=y
CONFIG_PAX_MPROTECT=y
CONFIG_PAX_ASLR=y
CONFIG_PAX_RANDUSTACK=y
CONFIG_PAX_RANDMMAP=y

booting with 64G support on and mem=3G leads to same immediate reboot. machines booting succesfully have similar hardware, not more than 4G of ram.
i tried to use pax alone, but it failing to compile kernel:
fs/built-in.o(.text+0x2da5f): In function `load_elf_binary':
fs/binfmt_elf.c:1031: undefined reference to `pax_set_initial_flags'
tried 2.6.11, 2.6.11.8 with
http://pax.grsecurity.net/pax-linux-2.6 ... 1330.patch

[PaX Team]

booting with 64G support on and mem=3G leads to same immediate reboot. machines booting succesfully have similar hardware, not more than 4G of ram.

thanks for the info.

i tried to use pax alone, but it failing to compile kernel:
fs/built-in.o(.text+0x2da5f): In function `load_elf_binary':
fs/binfmt_elf.c:1031: undefined reference to `pax_set_initial_flags'
tried 2.6.11, 2.6.11.8 with
http://pax.grsecurity.net/pax-linux-2.6 ... 1330.patch

disable CONFIG_PAX_HAVE_ACL_FLAGS (set MAC system integration to 'none' in menuconfig, then you'll get CONFIG_PAX_NO_ACL_FLAGS enabled).

[maple]

with only pax patch - reboot. with pax and mem=3G - same reboot

[insano]

Just curious if this thread ever went anywhere. I'm experiencing the exact same problems as Maple was experiencing, and at the moment I've gone ahead and used the 4 Gb RAM spec for less than 4 Gb RAM machines, and just removed grsec from the >64Gb machines, but if there were a fix I'd rather leave grsec on all my boxes ...

thanks a bunch!

[PaX Team]

Just curious if this thread ever went anywhere. I'm experiencing the exact same problems as Maple was experiencing, and at the moment I've gone ahead and used the 4 Gb RAM spec for less than 4 Gb RAM machines, and just removed grsec from the >64Gb machines, but if there were a fix I'd rather leave grsec on all my boxes ...

unfortunately i could neither reproduce nor fix it (don't have access to boxes with that much RAM and apparently that's a crucial factor in triggering the bug). if you can and are willing to spend some time on debugging this (mostly a binary search to find the place that probably triple faults the CPU) then contact me in email please.