# Kernel doesn't boot (2.6.36) with newer compiler [SOLVED]

## acarstoiu

Hello,

I'm in a totally unpleasant situation where precisely the same kernel (i.e sys-kernel/gentoo-sources-2.6.36-r5, which is marked as "stable" for x86) has a different behaviour depending on the compiler it is built with. The formerly compiled kernel image boots fine, while the newly compiled kernel image does not boot at all, yielding a black screen and no apparent computer activity.

My gcc was updated recently (the only package that I keyworded -~x86, all others are "unstable"  :Smile:  )

```
genlop gcc           

 * sys-devel/gcc

     Wed Oct 27 18:15:16 2010 >>> sys-devel/gcc-4.4.4-r2

     Mon Dec  6 00:28:44 2010 >>> sys-devel/gcc-4.4.4-r2

     Mon Dec 27 14:35:36 2010 >>> sys-devel/gcc-4.4.4-r2

     Sun Mar  6 17:21:20 2011 >>> sys-devel/gcc-4.4.5

     Wed Mar  9 18:59:29 2011 >>> sys-devel/gcc-4.4.5
```

 but I ran 

```
fix_libtool_files.sh 4.4.4
```

 and 

```
emerge -e system
```

 afterwords. Rebooted, too.

The funny thing is that I'm running just fine the old kernel image with newly compiled modules  :Shocked:  ...but using identical kernel configuration:

```
diff new_config old_config 

3,4c3,4

< # Linux kernel version: 2.6.36-gentoo-r5

< # Fri Mar 11 11:34:14 2011

---

> # Linux kernel version: 2.6.36-gentoo-r3

> # Sun Dec  5 15:57:03 2010

```

I ran into this issue while updating the kernel to version 2.6.36-r8 and trying to set CONFIG_USB_SUSPEND=y as required by udisks. Kernel 2.6.37-r1 didn't prove useful either, no newly compiled kernel boots at all. Anyway, it's a local problem, it has nothing to with the kernel I suppose. But with what   :Question: Last edited by acarstoiu on Sun Mar 13, 2011 7:04 am; edited 1 time in total

----------

## DONAHUE

 *Quote:*   

> does not boot at all, yielding a black screen and no apparent computer activity.nt computer activity.

 Are you set to boot directly to a GUI? Have you included KMS in your kernel configuration?

 *Quote:*   

> CONFIG_USB_SUSPEND=y as required by udisks. Kernel 2.6.37-r1

 Got a couple of Kernel 2.6.37-r1(gentoo-sources) around, no CONFIG_USB_SUSPEND in any of them, no udisks problem

----------

## acarstoiu

 *DONAHUE wrote:*   

> Are you set to boot directly to a GUI? Have you included KMS in your kernel configuration?

 

No, I don't boot in GUI, but in a high resolution console. I'm not sure what you mean by KMS (I know what is stands for), but my boot line reads like this since "ages" ago:

```
kernel (hd0,0)/boot/bzImage-2.6.36-gentoo-r5 root=/dev/sda1 vga=0x31B video=vesafb:ywrap,mtrr:3 nopat
```

 *DONAHUE wrote:*   

> Got a couple of Kernel 2.6.37-r1(gentoo-sources) around, no CONFIG_USB_SUSPEND in any of them, no udisks problem

 

Yes, it's just a recommendation that was given here and also a warning message issued during udisks emerge.

The big question is WHY THE DIFFERENCE between the two kernel images? How can I investigate what causes the total freeze?

----------

## DONAHUE

first thought:

did you 

```
emerge -pv xorg-server $(qlist -IC x11-drivers)
```

for the new kernels?

second thought:

did you  edit grub.conf to remove any video augments as in:

 *Quote:*   

> #splashimage (hd0,0)/boot/grub/splash.xpm.gz
> 
> kernel (hd0,0)/boot/bzImage-2.6.37-gentoo-r1 root=/dev/sda1 nopat

 

and boot 2.6.37-gentoo-r1 

More info: 

```
eselect kernel set linux-2.6.37-gentoo-r1

awk '/Graphics support/,/CONFIG_SOUND/' /usr/src/linux/.config

lspci -k
```

post outputs

----------

## Aquous

Try to remove the VGA and video lines in your kernel argument line and see if it makes any difference. It may help pinpointing the source of the problem.

----------

## acarstoiu

No one seems to believe me. I'm compiling the very same kernel sources. I have extracted the configuration parameters from the two kernel images and compared them: identical (see my first message)! The compilers are different by a very minor upgrade (4.4.4 -> 4.4.5).

An old Romanian saying goes like this: "if two persons tell you you're drunken, you just go to sleep". So I removed without much hope the vga parameter from the boot line and surprise   :Shocked:   Where the formerly compiled kernel image says:

```
ENABLING IO-APIC IRQs                                                                                                     

init IO_APIC IRQs                                                                                                         

 2-0 (apicid-pin) not connected                                                                                           

IOAPIC[0]: Set routing entry (2-1 -> 0x31 -> IRQ 1 Mode:0 Active:0)                                                       

IOAPIC[0]: Set routing entry (2-2 -> 0x30 -> IRQ 0 Mode:0 Active:0)                                                       

IOAPIC[0]: Set routing entry (2-3 -> 0x33 -> IRQ 3 Mode:0 Active:0)                                                       

IOAPIC[0]: Set routing entry (2-4 -> 0x34 -> IRQ 4 Mode:0 Active:0)                                                       

IOAPIC[0]: Set routing entry (2-5 -> 0x35 -> IRQ 5 Mode:0 Active:0)                                                       

IOAPIC[0]: Set routing entry (2-6 -> 0x36 -> IRQ 6 Mode:0 Active:0)                                                       

IOAPIC[0]: Set routing entry (2-7 -> 0x37 -> IRQ 7 Mode:0 Active:0)                                                       

IOAPIC[0]: Set routing entry (2-8 -> 0x38 -> IRQ 8 Mode:0 Active:0)                                                       

IOAPIC[0]: Set routing entry (2-9 -> 0x39 -> IRQ 9 Mode:1 Active:0)                                                       

IOAPIC[0]: Set routing entry (2-10 -> 0x3a -> IRQ 10 Mode:0 Active:0)                                                     

IOAPIC[0]: Set routing entry (2-11 -> 0x3b -> IRQ 11 Mode:0 Active:0)                                                     

IOAPIC[0]: Set routing entry (2-12 -> 0x3c -> IRQ 12 Mode:0 Active:0)                                                     

IOAPIC[0]: Set routing entry (2-13 -> 0x3d -> IRQ 13 Mode:0 Active:0)                                                     

IOAPIC[0]: Set routing entry (2-14 -> 0x3e -> IRQ 14 Mode:0 Active:0)                                                     

IOAPIC[0]: Set routing entry (2-15 -> 0x3f -> IRQ 15 Mode:0 Active:0)                                                     

 2-16 2-17 2-18 2-19 2-20 2-21 2-22 2-23 (apicid-pin) not connected                                                       

..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1

```

the newly compiled one says:

```
ENABLING IO-APIC IRQs

..TIMER: vector =0x30 apic1=0 pin1=2 apic2=-1 pin2=-1

..MP-BIOS bug: 8254 timer not connected to IO-APIC

...trying to set up timer (IRQ0) through the 8259A ...

..... (found apic 0 pin 2) ...

....... failed.

...trying to set up timer as Virtual Wire IRQ...

..... failed.

...trying to set up timer as ExtINT IRQ...

..... failed :(.

Kernel panic - not syncing: IO-APIC + timer doesn't work!

```

followed by a stack trace from "Pid 1, comm:swapper".

How can exactly the same code produce totally different results on the same hardware? Does anyone really understand the above messages? Is it a bug in GCC? I have a dual core Athlon64 processor, if that helps.

Thanks.

----------

## Hu

Although possible, it is exceedingly rare for a minor version upgrade to introduce a regression that affects one package for one user.  Therefore, most people consider other options first.  Now that you have output demonstrating the nature of the failure, it should be easier to determine what went wrong.  Could you provide a disassembly of the relevant function(s), as seen in both the working and non-working kernels?

----------

## Anon-E-moose

post the .config file that you used to build the kernel

and post what "emerge -pv gcc" returns

----------

## acarstoiu

Hurray, it was this quite disputed bug. Which in turn refers to this one.

Moral of the story: the culprit was not only binutils-2.21 itself, but also the appropriate compiler version (i.e. 4.4.5 as opposed to the former 4.4.4-r2) that exhibited the binutils bug.

As a side note, CONFIG_RELOCATABLE seemed so appealing at the time when I enabled it...   :Smile: 

Thanks for your time.

----------

