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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/