# Kernel 2.6.26 (vanilla) - section mismatch [SOLVED]

## HeXiLeD

While compiling 2.6.26 kernel  i got the following errors:

```
WARNING: vmlinux.o(.text+0x1778a): Section mismatch in reference from the function kvm_setup_secondary_clock() to the function .cpuinit.text:setup_secondary_APIC_clock()

The function kvm_setup_secondary_clock() references

the function __cpuinit setup_secondary_APIC_clock().

This is often because kvm_setup_secondary_clock lacks a __cpuinit 

annotation or the annotation of setup_secondary_APIC_clock is wrong.

WARNING: vmlinux.o(.text+0x1eecb): Section mismatch in reference from the function arch_setup_additional_pages() to the variable .init.data:vdso_end

The function arch_setup_additional_pages() references

the variable __initdata vdso_end.

This is often because arch_setup_additional_pages lacks a __initdata 

annotation or the annotation of vdso_end is wrong.

WARNING: vmlinux.o(.text+0x1eed8): Section mismatch in reference from the function arch_setup_additional_pages() to the variable .init.data:vdso_start

The function arch_setup_additional_pages() references

the variable __initdata vdso_start.

This is often because arch_setup_additional_pages lacks a __initdata 

annotation or the annotation of vdso_start is wrong.

WARNING: vmlinux.o(.cpuinit.text+0x46f9): Section mismatch in reference from the function uv_cpu_init() to the function .init.text:uv_system_init()

The function __cpuinit uv_cpu_init() references

a function __init uv_system_init().

If uv_system_init is only used by uv_cpu_init then

annotate uv_system_init with a matching annotation.
```

I am a bit lost with this output. 

What is causing it and if possible how to avoid it or remove it.

I have tried to recompile with other options to see if i could get this solved; but it kinda didnt solve the problem.

my kernel config is here

Any ideas?

----------

## alex.blackbit

unfortunately section mismatches are... well... normal these days.

don't care about them. hopefully they will go away soon.

----------

## pappy_mcfae

Agreed. Try out your kernel and see if it works. I got at least five of those messages from all three machines as I was compiling their kernels. Fortunately, all three machines are working fine.

Blessed be!

Pappy

----------

## HeXiLeD

What do they mean ? and how about removing settings that might or are causing these mismatches ?

----------

## pappy_mcfae

They go by so quickly, it's hard to even make them out, much less try to divine a meaning from the messages. If you want, you could write a bug report to the kernel devs (if it's vanilla), or gentoo (gentoo-sources).

Blessed be!

Pappy

----------

## alex.blackbit

this applies to both gentoo- and vanilla-sources.

there is already a bug for that.

google knows about that too.

there were patches up for inclusion in .26, maybe they will make it in .27.

somebody really curious could try out a -rc version.

----------

## alex.blackbit

on -rc1 the mismatches still exist.

----------

## HeXiLeD

After all this, I rebooted ... recompiled and the 2.6.26 mismatches were gone.

SOLVED

----------

## pappy_mcfae

I also have news on this issue. It seems that after moving a kernel up via make oldconfig, sometimes errors travel along in the code of .config. Since the kernel that was running on this machine came into being around 2.6.18.x, that's a lot of time to pick up a lot of errors. That's 8 major version changes that config had been through.

So, what I did was to use the old .config as a pattern, but to create completely new kernel .configs using make defconfig. I put two make xconfig sessions side by side; the new one and the old pattern, and just clicked all the options that were listed. I also took the time to do some more experimentation with my kernels.

When I compiled the new .configs into kernels, there were no mismatch errors. Also, the new kernel design seems to be working ok, too. That's a good thing!

So, there is a way to stop the mismatch errors; create a new config from your old one instead of doing a make oldconfig.

I think I'm only going to worry about that when it becomes problematic again. It's a PITA to rebuild a kernel from the ashes of the old.

Blessed be!

Pappy

----------

