2.6.24-git7: section mismatches woes

2.6.24-git7: section mismatches woes

[Rafael J. Wysocki]

Hi,

I get these messages, the majority of which seem to be false-positives:

  MODPOST vmlinux.o
WARNING: vmlinux.o(.text+0x8fef): Section mismatch in reference from the function arch_register_cpu() to the function .devinit.text:register_cpu()
WARNING: vmlinux.o(.text+0x1115f): Section mismatch in reference from the function acpi_map_lsapic() to the function .cpuinit.text:mp_register_lapic()
WARNING: vmlinux.o(.text+0x14d4f): Section mismatch in reference from the function remove_cpu_from_maps() to the variable .cpuinit.data:cpu_initialized
WARNING: vmlinux.o(.text+0x14fcc): Section mismatch in reference from the function __cpu_disable() to the variable .cpuinit.data:cpu_initialized
WARNING: vmlinux.o(.text+0x4b7e5): Section mismatch in reference from the function enable_nonboot_cpus() to the function .cpuinit.text:_cpu_up()
WARNING: vmlinux.o(.text+0x4b846): Section mismatch in reference from the function take_cpu_down() to the variable .cpuinit.data:cpu_chain
WARNING: vmlinux.o(.text+0x4b8e7): Section mismatch in reference from the function _cpu_down() to the variable .cpuinit.data:cpu_chain
WARNING: vmlinux.o(.text+0x4b90a): Section mismatch in reference from the function _cpu_down() to the variable .cpuinit.data:cpu_chain
WARNING: vmlinux.o(.text+0x4b9b8): Section mismatch in reference from the function _cpu_down() to the variable .cpuinit.data:cpu_chain
WARNING: vmlinux.o(.text+0x4ba07): Section mismatch in reference from the function _cpu_down() to the variable .cpuinit.data:cpu_chain
WARNING: vmlinux.o(.text+0x4bb26): Section mismatch in reference from the function unregister_cpu_notifier() to the variable .cpuinit.data:cpu_chain
WARNING: vmlinux.o(.text+0x110ca7): Section mismatch in reference from the function pci_scan_child_bus() to the function .devinit.text:pcibios_fixup_bus()
WARNING: vmlinux.o(.text+0x1521b9): Section mismatch in reference from the function acpi_pci_root_add() to the function .devinit.text:pci_acpi_scan_root()
WARNING: vmlinux.o(.text+0x180448): Section mismatch in reference from the function store_online() to the function .cpuinit.text:cpu_up()
WARNING: vmlinux.o(.text+0x1bad42): Section mismatch in reference from the function cpufreq_unregister_driver() to the variable .cpuinit.data:cpufreq_cpu_notifier
WARNING: vmlinux.o(.text+0x1baedc): Section mismatch in reference from the function cpufreq_register_driver() to the variable .cpuinit.data:cpufreq_cpu_notifier
WARNING: vmlinux.o(.text+0x1baee1): Section mismatch in reference from the function cpufreq_register_driver() to the function .cpuinit.text:register_cpu_notifier()
WARNING: vmlinux.o(__ksymtab+0x15d0): Section mismatch in reference from the variable __ksymtab_register_cpu_notifier to the function .cpuinit.text:register_cpu_notifier()
WARNING: vmlinux.o(__ksymtab+0x5660): Section mismatch in reference from the variable __ksymtab_pci_do_scan_bus to the function .devinit.text:pci_do_scan_bus()
WARNING: vmlinux.o(.data+0x29b0): Section mismatch in reference from the variable cpu_vsyscall_notifier_nb.11336 to the function .cpuinit.text:cpu_vsyscall_notifier()
WARNING: vmlinux.o(.data+0x58b0): Section mismatch in reference from the variable profile_cpu_callback_nb.15831 to the function .devinit.text:profile_cpu_callback()
WARNING: vmlinux.o(.data+0x86c0): Section mismatch in reference from the variable workqueue_cpu_callback_nb.13223 to the function .devinit.text:workqueue_cpu_callback()
WARNING: vmlinux.o(.data+0x22790): Section mismatch in reference from the variable cpu_callback_nb.22476 to the function .devinit.text:cpu_callback()
WARNING: vmlinux.o(.data+0x2c7e0): Section mismatch in reference from the variable percpu_counter_hotcpu_callback_nb.9364 to the function .cpuinit.text:percpu_counter_hotcpu_callback()
WARNING: vmlinux.o(.data+0x35328): Section mismatch in reference from the variable pci_serial_quirks to the function .devexit.text:pci_ite887x_exit()
WARNING: vmlinux.o(.data+0x35350): Section mismatch in reference from the variable pci_serial_quirks to the function .devexit.text:pci_plx9050_exit()
WARNING: vmlinux.o(.data+0x35378): Section mismatch in reference from the variable pci_serial_quirks to the function .devexit.text:pci_plx9050_exit()
WARNING: vmlinux.o(.data+0x353c8): Section mismatch in reference from the variable pci_serial_quirks to the function .devexit.text:pci_plx9050_exit()
WARNING: vmlinux.o(.data+0x353f0): Section mismatch in reference from the variable pci_serial_quirks to the function .devexit.text:pci_plx9050_exit()
WARNING: vmlinux.o(.data+0x35418): Section mismatch in reference from the variable pci_serial_quirks to the function .devexit.text:pci_plx9050_exit()
WARNING: vmlinux.o(.data+0x35440): Section mismatch in reference from the variable pci_serial_quirks to the function .devexit.text:sbs_exit()
WARNING: vmlinux.o(.data+0x35468): Section mismatch in reference from the variable pci_serial_quirks to the function .devexit.text:sbs_exit()
WARNING: vmlinux.o(.data+0x35490): Section mismatch in reference from the variable pci_serial_quirks to the function .devexit.text:sbs_exit()
WARNING: vmlinux.o(.data+0x354b8): Section mismatch in reference from the variable pci_serial_quirks to the function .devexit.text:sbs_exit()
WARNING: vmlinux.o(.data+0x37500): Section mismatch in reference from the variable topology_cpu_callback_nb.10813 to the function .cpuinit.text:topology_cpu_callback()
modpost: Found 35 section mismatch(es).
To see additional details select "Enable full Section mismatch analysis"
in the Kernel Hacking menu (CONFIG_SECTION_MISMATCH).

and if I compile the kernel with CONFIG_SECTION_MISMATCH, it breaks resuming
from RAM.

Greetings,
Rafael

Re: 2.6.24-git7: section mismatches woes

[Sam Ravnborg]

On Wed, Jan 30, 2008 at 07:50:43PM +0100, Rafael J. Wysocki wrote:
> Hi,
> 
> I get these messages, the majority of which seem to be false-positives:
...
> modpost: Found 35 section mismatch(es).
> To see additional details select "Enable full Section mismatch analysis"
> in the Kernel Hacking menu (CONFIG_SECTION_MISMATCH).
Looking in to these atm.

> 
> and if I compile the kernel with CONFIG_SECTION_MISMATCH, it breaks resuming
> from RAM.

The only functional difference when you enable CONFIG_SECTION_MISMATCH is the
addition of the -fno-inline-functions-called-once to CFLAGS.
So we have some code somewhere that breaks if it is not inlined by gcc.

It would be nice to sort out where.
If you have a rough idea where to look you could use the following trick.
Drop CONFIG_SECTION_MISMATCH and build a kernel.

Then for the file/directory where you think the no-inle makes
a difference do:

# To build the dir/file
rm dir/*.o
make KBUILD_NOCMDDEP=1 KCFLAGS=-fno-inline-functions-called-once dir/
# And then link the kernel
make KBUILD_NOCMDDEP=1

The KBUILD_NOCMDDEP=1 tell kbuild to ignore any commandline differences
so kbuild will not rebuild due to changed gcc flags.

Let me know if you need assistance with this.

	Sam

Re: 2.6.24-git7: section mismatches woes

[Rafael J. Wysocki]

On Wednesday, 30 of January 2008, Sam Ravnborg wrote:
> On Wed, Jan 30, 2008 at 07:50:43PM +0100, Rafael J. Wysocki wrote:
> > Hi,
> > 
> > I get these messages, the majority of which seem to be false-positives:
> ...
> > modpost: Found 35 section mismatch(es).
> > To see additional details select "Enable full Section mismatch analysis"
> > in the Kernel Hacking menu (CONFIG_SECTION_MISMATCH).
> Looking in to these atm.
> 
> > 
> > and if I compile the kernel with CONFIG_SECTION_MISMATCH, it breaks resuming
> > from RAM.
> 
> The only functional difference when you enable CONFIG_SECTION_MISMATCH is the
> addition of the -fno-inline-functions-called-once to CFLAGS.
> So we have some code somewhere that breaks if it is not inlined by gcc.
> 
> It would be nice to sort out where.
> If you have a rough idea where to look

No, I don't.

It looks like there's somewhere in arch/x86, since I ruled out kernel/power and
drivers/acpi already.

Thanks,
Rafael

Re: 2.6.24-git7: section mismatches woes

[Sam Ravnborg]

On Wed, Jan 30, 2008 at 10:32:52PM +0100, Rafael J. Wysocki wrote:
> On Wednesday, 30 of January 2008, Sam Ravnborg wrote:
> > On Wed, Jan 30, 2008 at 07:50:43PM +0100, Rafael J. Wysocki wrote:
> > > Hi,
> > > 
> > > I get these messages, the majority of which seem to be false-positives:
> > ...
> > > modpost: Found 35 section mismatch(es).
> > > To see additional details select "Enable full Section mismatch analysis"
> > > in the Kernel Hacking menu (CONFIG_SECTION_MISMATCH).
> > Looking in to these atm.
> > 
> > > 
> > > and if I compile the kernel with CONFIG_SECTION_MISMATCH, it breaks resuming
> > > from RAM.
> > 
> > The only functional difference when you enable CONFIG_SECTION_MISMATCH is the
> > addition of the -fno-inline-functions-called-once to CFLAGS.
> > So we have some code somewhere that breaks if it is not inlined by gcc.
> > 
> > It would be nice to sort out where.
> > If you have a rough idea where to look
> 
> No, I don't.
> 
> It looks like there's somewhere in arch/x86, since I ruled out kernel/power and
> drivers/acpi already.

Hi Rafael.

Do you plan to look closer into this or do you have an easy receipe so
I can test myself (on a x86 64 bit box)?

	Sam

Re: 2.6.24-git7: section mismatches woes

[Rafael J. Wysocki]

On Saturday, 2 of February 2008, Sam Ravnborg wrote:
> On Wed, Jan 30, 2008 at 10:32:52PM +0100, Rafael J. Wysocki wrote:
> > On Wednesday, 30 of January 2008, Sam Ravnborg wrote:
> > > On Wed, Jan 30, 2008 at 07:50:43PM +0100, Rafael J. Wysocki wrote:
> > > > Hi,
> > > > 
> > > > I get these messages, the majority of which seem to be false-positives:
> > > ...
> > > > modpost: Found 35 section mismatch(es).
> > > > To see additional details select "Enable full Section mismatch analysis"
> > > > in the Kernel Hacking menu (CONFIG_SECTION_MISMATCH).
> > > Looking in to these atm.
> > > 
> > > > 
> > > > and if I compile the kernel with CONFIG_SECTION_MISMATCH, it breaks resuming
> > > > from RAM.
> > > 
> > > The only functional difference when you enable CONFIG_SECTION_MISMATCH is the
> > > addition of the -fno-inline-functions-called-once to CFLAGS.
> > > So we have some code somewhere that breaks if it is not inlined by gcc.
> > > 
> > > It would be nice to sort out where.
> > > If you have a rough idea where to look
> > 
> > No, I don't.
> > 
> > It looks like there's somewhere in arch/x86, since I ruled out kernel/power and
> > drivers/acpi already.
> 
> Hi Rafael.

Hi,

> Do you plan to look closer into this or do you have an easy receipe so
> I can test myself (on a x86 64 bit box)?

Well, I really don't know how to approach this.  Do you have an x86-64 box with
suspend to RAM working?

Rafael

Re: 2.6.24-git7: section mismatches woes

[Sam Ravnborg]

On Sat, Feb 02, 2008 at 11:47:29PM +0100, Rafael J. Wysocki wrote:
> On Saturday, 2 of February 2008, Sam Ravnborg wrote:
> > On Wed, Jan 30, 2008 at 10:32:52PM +0100, Rafael J. Wysocki wrote:
> > > On Wednesday, 30 of January 2008, Sam Ravnborg wrote:
> > > > On Wed, Jan 30, 2008 at 07:50:43PM +0100, Rafael J. Wysocki wrote:
> > > > > Hi,
> > > > > 
> > > > > I get these messages, the majority of which seem to be false-positives:
> > > > ...
> > > > > modpost: Found 35 section mismatch(es).
> > > > > To see additional details select "Enable full Section mismatch analysis"
> > > > > in the Kernel Hacking menu (CONFIG_SECTION_MISMATCH).
> > > > Looking in to these atm.
> > > > 
> > > > > 
> > > > > and if I compile the kernel with CONFIG_SECTION_MISMATCH, it breaks resuming
> > > > > from RAM.
> > > > 
> > > > The only functional difference when you enable CONFIG_SECTION_MISMATCH is the
> > > > addition of the -fno-inline-functions-called-once to CFLAGS.
> > > > So we have some code somewhere that breaks if it is not inlined by gcc.
> > > > 
> > > > It would be nice to sort out where.
> > > > If you have a rough idea where to look
> > > 
> > > No, I don't.
> > > 
> > > It looks like there's somewhere in arch/x86, since I ruled out kernel/power and
> > > drivers/acpi already.
> > 
> > Hi Rafael.
> 
> Hi,
> 
> > Do you plan to look closer into this or do you have an easy receipe so
> > I can test myself (on a x86 64 bit box)?
> 
> Well, I really don't know how to approach this.  Do you have an x86-64 box with
> suspend to RAM working?
I dunno - never used it I'm afraid. And do not know how to do it either.
Feel free to call me ignorant :-(

I have in latest kbuild.git made DEBUG_SECTION_MISMATCH so it cannot be selected,
partly due to this regression but mostly due to the noise it creates.

The way to approach it is straightforward but boring.

You can add:
ccflags-y += -fno-inline-functions-called-once
to the Makefiles where you think this can have caused troubles until
you find the problematic directory.
kbuild will pick up that gcc options changed and rebuild
all relevant files.

When the problematic directory is located then
remove the ccflags-y assignment and do it file-by-file
using the CFLAGS_xxx.o syntax:

CFLAGS_file.o := -fno-inline-functions-called-once

This is probarly not the highest priority thing to look into
but I am afraid that it could show up under other circumstances too.


	Sam

Re: 2.6.24-git7: section mismatches woes

[Rafael J. Wysocki]

On Sunday, 3 of February 2008, Sam Ravnborg wrote:
> On Sat, Feb 02, 2008 at 11:47:29PM +0100, Rafael J. Wysocki wrote:
> > On Saturday, 2 of February 2008, Sam Ravnborg wrote:
> > > On Wed, Jan 30, 2008 at 10:32:52PM +0100, Rafael J. Wysocki wrote:
> > > > On Wednesday, 30 of January 2008, Sam Ravnborg wrote:
> > > > > On Wed, Jan 30, 2008 at 07:50:43PM +0100, Rafael J. Wysocki wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > I get these messages, the majority of which seem to be false-positives:
> > > > > ...
> > > > > > modpost: Found 35 section mismatch(es).
> > > > > > To see additional details select "Enable full Section mismatch analysis"
> > > > > > in the Kernel Hacking menu (CONFIG_SECTION_MISMATCH).
> > > > > Looking in to these atm.
> > > > > 
> > > > > > 
> > > > > > and if I compile the kernel with CONFIG_SECTION_MISMATCH, it breaks resuming
> > > > > > from RAM.
> > > > > 
> > > > > The only functional difference when you enable CONFIG_SECTION_MISMATCH is the
> > > > > addition of the -fno-inline-functions-called-once to CFLAGS.
> > > > > So we have some code somewhere that breaks if it is not inlined by gcc.
> > > > > 
> > > > > It would be nice to sort out where.
> > > > > If you have a rough idea where to look
> > > > 
> > > > No, I don't.
> > > > 
> > > > It looks like there's somewhere in arch/x86, since I ruled out kernel/power and
> > > > drivers/acpi already.
> > > 
> > > Hi Rafael.
> > 
> > Hi,
> > 
> > > Do you plan to look closer into this or do you have an easy receipe so
> > > I can test myself (on a x86 64 bit box)?
> > 
> > Well, I really don't know how to approach this.  Do you have an x86-64 box with
> > suspend to RAM working?
> I dunno - never used it I'm afraid. And do not know how to do it either.

# echo mem > /sys/power/state

(better do it after a fresh boot for the first time in case it fails).

> Feel free to call me ignorant :-(
> 
> I have in latest kbuild.git made DEBUG_SECTION_MISMATCH so it cannot be selected,
> partly due to this regression but mostly due to the noise it creates.
> 
> The way to approach it is straightforward but boring.
> 
> You can add:
> ccflags-y += -fno-inline-functions-called-once
> to the Makefiles where you think this can have caused troubles until
> you find the problematic directory.
> kbuild will pick up that gcc options changed and rebuild
> all relevant files.
> 
> When the problematic directory is located then
> remove the ccflags-y assignment and do it file-by-file
> using the CFLAGS_xxx.o syntax:
> 
> CFLAGS_file.o := -fno-inline-functions-called-once

Do I have to pass any special options to "make"?

> This is probarly not the highest priority thing to look into
> but I am afraid that it could show up under other circumstances too.

Yes, probably.

Thanks,
Rafael

Re: 2.6.24-git7: section mismatches woes

[Sam Ravnborg]

> > > suspend to RAM working?
> > I dunno - never used it I'm afraid. And do not know how to do it either.
> 
> # echo mem > /sys/power/state
> 
> (better do it after a fresh boot for the first time in case it fails).

Will try later - thanks.

> > The way to approach it is straightforward but boring.
> > 
> > You can add:
> > ccflags-y += -fno-inline-functions-called-once
> > to the Makefiles where you think this can have caused troubles until
> > you find the problematic directory.
> > kbuild will pick up that gcc options changed and rebuild
> > all relevant files.
> > 
> > When the problematic directory is located then
> > remove the ccflags-y assignment and do it file-by-file
> > using the CFLAGS_xxx.o syntax:
> > 
> > CFLAGS_file.o := -fno-inline-functions-called-once
> 
> Do I have to pass any special options to "make"?

When you do it this way by tweaking the Makefiles - no.
And you do not have to delete .o files manually to get them
rebuild.

	Sam