Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 227271 - gcc-4.1.2 and binutils-2.18-r1 produce linux >=2.6.23_rc1 kernels which don't boot on classic pentium
Summary: gcc-4.1.2 and binutils-2.18-r1 produce linux >=2.6.23_rc1 kernels which don't...
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: x86 Linux
: High normal (vote)
Assignee: Gentoo Kernel Bug Wranglers and Kernel Maintainers
Depends on:
Reported: 2008-06-15 17:55 UTC by Petr Pisar
Modified: 2011-01-02 18:16 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---

.config for 2.6.23-rc1 (.config,10.51 KB, text/plain)
2008-06-16 20:54 UTC, Petr Pisar

Note You need to log in before you can comment on or make changes to this bug.
Description Petr Pisar 2008-06-15 17:55:29 UTC
Booting such a kernel on classic Pentium machine fails just after "BIOS check data successful". Machine resets before "Decompressing Linux".

Reproducible: Always

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

Actual Results:  
Kernel build on Gentoo is broken.

Expected Results:  
Booting should continue with message "Uncompressing Linux"

My last bootable kernel is 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 20070731) makes bootable images.

So I think the problem lies somewhere in Gentoo patches for sys-devel/gcc.
Comment 1 manuels 2008-06-15 21:34:05 UTC
do you always use the same .config file.

Can you post it please?
Comment 2 Petr Pisar 2008-06-16 20:50:17 UTC
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
Comment 3 Petr Pisar 2008-06-16 20:54:24 UTC
Created attachment 157153 [details]
.config for 2.6.23-rc1

Minimal config for i586TSC.
Comment 4 Daniel Drake (RETIRED) gentoo-dev 2008-06-29 16:41:04 UTC
Can you reproduce this when gcc is compiled with USE=vanilla?
Comment 5 Petr Pisar 2008-07-05 17:01:10 UTC
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.
Comment 6 Daniel Drake (RETIRED) gentoo-dev 2008-10-31 11:54:23 UTC
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.
Comment 7 Petr Pisar 2008-11-02 19:37:54 UTC
> 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.
Comment 8 Daniel Drake (RETIRED) gentoo-dev 2008-11-02 21:24:20 UTC
(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.
Comment 9 Petr Pisar 2008-11-02 21:48:51 UTC
(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. 
Comment 10 Petr Pisar 2008-11-10 16:47:49 UTC
Vanilla linux- compiled with gcc-4.3.2 with Gentoo patches still fails.

I'll dig into RedHat GCC patches.
Comment 11 Daniel Drake (RETIRED) gentoo-dev 2008-11-17 23:36:32 UTC
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 with 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).
Comment 12 Daniel Drake (RETIRED) gentoo-dev 2008-12-02 17:51:16 UTC
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!
Comment 13 Piotr Curious Slawinski 2010-12-31 12:20:54 UTC
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 kernel.

any ideas what one can do to at least work-around this bug?

Comment 14 Piotr Curious Slawinski 2011-01-01 05:05:54 UTC
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 kernel using gcc 4.1.2 - it decompresses and boots fine.

i will try to bisect and post more info.

Comment 15 Piotr Curious Slawinski 2011-01-02 13:49:30 UTC
solidstate linux-git # git bisect bad
dd0ec16fa6cf2498b831663a543e1b67fce6e155 is the first bad commit
commit dd0ec16fa6cf2498b831663a543e1b67fce6e155
Author: Vivek Goyal <>
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 <>
    Cc: "Eric W. Biederman" <>
    Cc: Andi Kleen <>
    Signed-off-by: Andrew Morton <>
    Signed-off-by: Linus Torvalds <>

:040000 040000 d50bb46de6c71353e214d59f862e11a33a3e48e0 900d9afe1afd054821d3a23c814adf25d47e18ba M      arch
:040000 040000 5318298e270197d0b8626ca7b39b310f5663bf33 6d48d791c18cac19862cb8e2203f33147dc8039a M      include

it seems it's nailed. 
Comment 16 Piotr Curious Slawinski 2011-01-02 14:19:34 UTC
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 kernel :) so hurray. 
i am not sure what this value _should_ be. previously it somehow worked automagically ;) even on 4M machines...
Comment 17 Petr Pisar 2011-01-02 18:16:29 UTC
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 ( (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.
Initializing CPU#0
Subtract (19 early reservations)
  #0 [0001000000 - 000138a9e0]   TEXT DATA BSS