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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
