Booting such a kernel on classic Pentium machine fails just after "BIOS check data successful". Machine resets before "Decompressing Linux".
Steps to Reproduce:
1. Compile vanilla linux kernel >= 2.6.23-rc1 using any gcc-4.1.2 and binutils-2.18-r1 (these are currently stable on x86). make allnoconfig and change to i586 subarch is sufficient
2. Boot it on ancient Pentium machine
3. System resets just before uncompressing the kernel image
Kernel build on Gentoo is broken.
Booting should continue with message "Uncompressing Linux"
My last bootable kernel is 184.108.40.206 built on Feb 12 17:56:01 CET 2008. If I use the same source code and the same .config now, I will get kernel which does not boot. The only change in my toolchain was recompilation of gcc-4.1.2. However I can't find any change description in sys-devel/gcc/Changelog.
I tried compilation on two x86 Gentoo boxes (AMD thurbderbird-like and Pentium4), both produce broken kernel. I tried compilation with other gcc versions (3.4.6, 4.1.2, 4.2.3), all of them produce broken kernel.
I found first unbootable kernel is linux-2.6.23-rc1. Version 2.6.22 boots up O.k.
However compilation on Fedora distribution (GCC 4.1.2 20070925 (Red Hat 4.1.2-33), binutils 220.127.116.11.18-1 20070731) makes bootable images.
So I think the problem lies somewhere in Gentoo patches for sys-devel/gcc.
do you always use the same .config file.
Can you post it please?
Yes, I'm sure I used the same config. Actually, I compiled tens of kernels to identify problematic option. However, the problem is just between 2.6.22 and 2.6.23-rc1 source code even If I disable all options.
As I said use "make allnoconfig" which produce minimal configuration for current architecture. Then, justify subarchitecture to i586 (e.g. CONFIG_M586TSC). Also Pentium MMX, or i486 or i386 have the same effect. Finally call "make bzImage".
Machine where it crashes is:
# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 5
model : 2
model name : Pentium 75 - 200
stepping : 12
cpu MHz : 198.952
cache size : 0 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 mce cx8
bogomips : 398.65
clflush size : 32
Created attachment 157153 [details]
.config for 2.6.23-rc1
Minimal config for i586TSC.
Can you reproduce this when gcc is compiled with USE=vanilla?
Unfortunately yes. Linux 2.6.13-rc1 compiled with USE="fortran mudflap nls vanilla" gcc-4.1.2 with minimal configuration doesn't boot either.
So probably, RedHat has some patches that are not part of official gcc.
I don't really know where to start on this one. Perhaps you could test a newer gcc version (4.3.2?) against a newer kernel version (2.6.27?) and if it still doesn't help, we could report this to upstream kernel developers.
If you're really keen and have some time to spare, you could use this process to track down the exact commit which introduced the boot failure:
Use v2.6.22 as good and v2.6.23-rc1 as bad.
> I don't really know where to start on this one.
It would be nice if somebody were able to reproduce this bug to be sure my hardware is not just broken.
(Just curious coincidence: Last month I was trying to compile glibc on PentiumII with -march=pentium2 without success. I have tried different GCC, binutils and glibc versions. All failed. I have solved the problem by downgrading optimization to -march=pentium-mmx. So, support for older processors in GCC may be broken.)
> Perhaps you could test...
I'm going to do it when I have free time and access to the machine (this is machine in production and it's placed in locked in room).
> we could report this to upstream kernel developers.
That's the problem. I don't know whether the bug is kernel, or in tool-chain.
(In reply to comment #7)
> It would be nice if somebody were able to reproduce this bug to be sure my
> hardware is not just broken.
I don't have the hardware to test, but I could compile a kernel image for a set .config for you. Would you test it if so? I could use the .config you have already posted.
(In reply to comment #8)
> I don't have the hardware to test, but I could compile a kernel image for a set
> .config for you. Would you test it if so? I could use the .config you have
> already posted.
It's not necessary, I can do it either. However if you want, you can compile some. Just use minimal config I have posted here.
Next test window opens for me this Friday (I hope), so I can perform some boot tests.
Vanilla linux-18.104.22.168 compiled with gcc-4.3.2 with Gentoo patches still fails.
I'll dig into RedHat GCC patches.
OK, I think now that you have tested the latest stuff, you could send an email upstream, at least to inform them of this. Maybe they have hints or have heard of it before.
I would suggest sending a plain-text email to email@example.com with firstname.lastname@example.org on CC (no subscription required). Try and summarise succinctly but make sure you include enough detail (don't just link to this bug, but by all means link to it as supplementary info).
Petr, did you have a chance to send that email?
This bug sitting around doesn't do any good. I'm sorry that we can't help further but we do need upstream's help on this one.
Please feel free to reopen if more details do appear, and we'll then backport any patches or poke any appropriate upstreams. Thanks!
Hello. i am using binutils-2.20.1-r1 and i386-gentoo-linux-uclibc-4.4.4
and i encounter exactly same problem when compiling 22.214.171.124 kernel.
any ideas what one can do to at least work-around this bug?
i've tried experimenting bit more, i've downgraded
both gcc and binutils as far as i could
but no luck. exactly same symptoms - hang and then reboot even before 'uncompressing linux' appears (sometimes after longer while, sometimes not) i can't go any lower, older gcc versions do not compile anymore/are considered obsoleted.
if i choose LZMA compressed kernel crash is bit different - i get random colour blocks on the display.
also, i've tried compiling 126.96.36.199 kernel using gcc 4.1.2 - it decompresses and boots fine.
i will try to bisect and post more info.
solidstate linux-git # git bisect bad
dd0ec16fa6cf2498b831663a543e1b67fce6e155 is the first bad commit
Author: Vivek Goyal <email@example.com>
Date: Fri Jan 5 16:36:30 2007 -0800
[PATCH] i386: Restore CONFIG_PHYSICAL_START option
o Relocatable bzImage support had got rid of CONFIG_PHYSICAL_START option
thinking that now this option is not required as people can build a
second kernel as relocatable and load it anywhere. So need of compiling
the kernel for a custom address was gone. But Magnus uses vmlinux images
for second kernel in Xen environment and he wants to continue to use
o Restoring the CONFIG_PHYSICAL_START option for the time being. I think
down the line we can get rid of it.
Signed-off-by: Vivek Goyal <firstname.lastname@example.org>
Cc: "Eric W. Biederman" <email@example.com>
Cc: Andi Kleen <firstname.lastname@example.org>
Signed-off-by: Andrew Morton <email@example.com>
Signed-off-by: Linus Torvalds <firstname.lastname@example.org>
:040000 040000 d50bb46de6c71353e214d59f862e11a33a3e48e0 900d9afe1afd054821d3a23c814adf25d47e18ba M arch
:040000 040000 5318298e270197d0b8626ca7b39b310f5663bf33 6d48d791c18cac19862cb8e2203f33147dc8039a M include
it seems it's nailed.
ok, excuse me the noise :)
few more details - obviously this patch introduces adress @ which kernel is loaded or aligned.
so , it's not just problem with 'ancient pentiums' but any system with less than 16M of ram, as the defaults load kernel exactly at 16th megabyte, as this value was typed by someone - i guess 'out of the blue' assuming 'modern' systems have at least 32Megs or sth.
changing the default values to i.e. 0x0100000 (the first megabyte) make 'uncompressing linux' appear even on 188.8.131.52 kernel :) so hurray.
i am not sure what this value _should_ be. previously it somehow worked automagically ;) even on 4M machines...
My machine has 96 MiB (0x6000000 B) physical memory. And according dmesg, running vanilla kernel compiled with Debian toolchain is located at 16 MB:
Linux version 184.108.40.206 (email@example.com) (gcc version 4.4.5 (Debian 4.4.5
-2) ) #2 Fri Oct 15 17:19:45 CEST 2010
kernel direct mapping tables up to 6000000 @ 7000-b000
ACPI Error: A valid RSDP was not found (20100428/tbxfroot-219)
96MB LOWMEM available.
Subtract (19 early reservations)
#0 [0001000000 - 000138a9e0] TEXT DATA BSS