[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200802031332.01827.rjw@sisk.pl>
Date: Sun, 3 Feb 2008 13:32:01 +0100
From: "Rafael J. Wysocki" <rjw@...k.pl>
To: Sam Ravnborg <sam@...nborg.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Ingo Molnar <mingo@...e.hu>,
Linus Torvalds <torvalds@...ux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: 2.6.24-git7: section mismatches woes
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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists