From: Randy Dunlap
[ Upstream commit e2af9da4f867a1a54f1252bf3abc1a5c63951778 ]
Fix IA64 discontig.c Section mismatch warnings.
When CONFIG_SPARSEMEM=y and CONFIG_MEMORY_HOTPLUG=y, the functions
computer_pernodesize() and scatter_node_data() should not be marked as
__meminit because they are ne
From: Randy Dunlap
[ Upstream commit e2af9da4f867a1a54f1252bf3abc1a5c63951778 ]
Fix IA64 discontig.c Section mismatch warnings.
When CONFIG_SPARSEMEM=y and CONFIG_MEMORY_HOTPLUG=y, the functions
computer_pernodesize() and scatter_node_data() should not be marked as
__meminit because they are ne
From: Randy Dunlap
[ Upstream commit e2af9da4f867a1a54f1252bf3abc1a5c63951778 ]
Fix IA64 discontig.c Section mismatch warnings.
When CONFIG_SPARSEMEM=y and CONFIG_MEMORY_HOTPLUG=y, the functions
computer_pernodesize() and scatter_node_data() should not be marked as
__meminit because they are ne
From: Randy Dunlap
[ Upstream commit e2af9da4f867a1a54f1252bf3abc1a5c63951778 ]
Fix IA64 discontig.c Section mismatch warnings.
When CONFIG_SPARSEMEM=y and CONFIG_MEMORY_HOTPLUG=y, the functions
computer_pernodesize() and scatter_node_data() should not be marked as
__meminit because they are ne
From: Randy Dunlap
[ Upstream commit e2af9da4f867a1a54f1252bf3abc1a5c63951778 ]
Fix IA64 discontig.c Section mismatch warnings.
When CONFIG_SPARSEMEM=y and CONFIG_MEMORY_HOTPLUG=y, the functions
computer_pernodesize() and scatter_node_data() should not be marked as
__meminit because they are ne
From: Randy Dunlap
[ Upstream commit e2af9da4f867a1a54f1252bf3abc1a5c63951778 ]
Fix IA64 discontig.c Section mismatch warnings.
When CONFIG_SPARSEMEM=y and CONFIG_MEMORY_HOTPLUG=y, the functions
computer_pernodesize() and scatter_node_data() should not be marked as
__meminit because they are ne
From: Randy Dunlap
[ Upstream commit e2af9da4f867a1a54f1252bf3abc1a5c63951778 ]
Fix IA64 discontig.c Section mismatch warnings.
When CONFIG_SPARSEMEM=y and CONFIG_MEMORY_HOTPLUG=y, the functions
computer_pernodesize() and scatter_node_data() should not be marked as
__meminit because they are ne
Fix IA64 discontig.c Section mismatch warnings.
When CONFIG_SPARSEMEM=y and CONFIG_MEMORY_HOTPLUG=y, the functions
computer_pernodesize() and scatter_node_data() should not be marked
as __meminit because they are needed after init, on any memory
hotplug event. Also, early_nr_cpus_node() is called
On Tue, Dec 29, 2020 at 10:11:07PM +, Marc Zyngier wrote:
> On 2020-12-29 21:43, Nathan Chancellor wrote:
> > Commit fa8c3d65538a ("KVM: arm64: Keep nVHE EL2 vector installed")
> > inadvertently changed clang's inlining decisions around
> > hyp_cpu_pm_{init,exit}, causing the following section
On 2020-12-29 21:43, Nathan Chancellor wrote:
Commit fa8c3d65538a ("KVM: arm64: Keep nVHE EL2 vector installed")
inadvertently changed clang's inlining decisions around
hyp_cpu_pm_{init,exit}, causing the following section mismatch
warnings:
WARNING: modpost: vmlinux.o(.text+0x95c6c): Section
Commit fa8c3d65538a ("KVM: arm64: Keep nVHE EL2 vector installed")
inadvertently changed clang's inlining decisions around
hyp_cpu_pm_{init,exit}, causing the following section mismatch warnings:
WARNING: modpost: vmlinux.o(.text+0x95c6c): Section mismatch in
reference from the function kvm_arch_i
case 'N':
allow_missing_ns_imports = 1;
@@ -2640,8 +2640,8 @@ int main(int argc, char **argv)
if (dump_write)
write_dump(dump_write);
- if (sec_mismatch_count && sec_mismatch_fatal)
- fatal("Section m
3.18-stable review patch. If anyone has any objections, please let me know.
--
From: Helge Deller
[ Upstream commit b819439fea305a0bfd6ca23a7994fd1a8847c0d8 ]
Fix two section mismatches in drivers.c:
1) Section mismatch in reference from the function alloc_tree_node() to
4.16-stable review patch. If anyone has any objections, please let me know.
--
From: Helge Deller
[ Upstream commit b819439fea305a0bfd6ca23a7994fd1a8847c0d8 ]
Fix two section mismatches in drivers.c:
1) Section mismatch in reference from the function alloc_tree_node() to
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Helge Deller
[ Upstream commit b819439fea305a0bfd6ca23a7994fd1a8847c0d8 ]
Fix two section mismatches in drivers.c:
1) Section mismatch in reference from the function alloc_tree_node() to
an also be
> called after boot completed - with all __init/__initdata/__initconst
> sections freed by the kernel - therefore functions called by them (and
> the data they refer to) must not be marked as
> __init/__initdata/__initconst lest compilation triggers section
> mismatches
t
sections freed by the kernel - therefore functions called by them (and
the data they refer to) must not be marked as
__init/__initdata/__initconst lest compilation triggers section
mismatches warnings.
Fix all the boards files map_irq() hooks by simply removing the
respective __init/__initdata/_
o be
> called after boot completed - with all __init/__initdata/__initconst
> sections freed by the kernel - therefore functions called by them (and
> the data they refer to) must not be marked as
> __init/__initdata/__initconst lest compilation triggers section
> mismatches warn
t
sections freed by the kernel - therefore functions called by them (and
the data they refer to) must not be marked as
__init/__initdata/__initconst lest compilation triggers section
mismatches warnings.
Fix all the boards files map_irq() hooks by simply removing the
respective __init/__initdata/_
Signed-off-by: Matt Turner
---
arch/alpha/kernel/core_marvel.c | 4 ++--
arch/alpha/kernel/smp.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/alpha/kernel/core_marvel.c b/arch/alpha/kernel/core_marvel.c
index db72356714c1..03ff832b1cb4 100644
--- a/arch/alph
Hi Elaine,
Am Dienstag, 23. Februar 2016, 15:58:42 schrieb Elaine Zhang:
> To model the muxes downstream of fractional dividers we introduced the
> child property, allowing to describe a direct child clock.
> The first implementation seems to cause section warnings, as the core
> clock-tree is mar
To model the muxes downstream of fractional dividers we introduced the
child property, allowing to describe a direct child clock.
The first implementation seems to cause section warnings, as the core
clock-tree is marked as initdata while the data pointed to from the
child element is not.
While th
On 11/10/2015 02:04 PM, Guenter Roeck wrote:
Section mismatches can now cause build failures, such as for
cris:allnoconfig. Rename affected variables to end with _console
to make section mismatch checks happy.
Signed-off-by: Guenter Roeck
ping ...
cris:allnoconfig still fails to build in
On Tue, Nov 10, 2015 at 02:04:35PM -0800, Guenter Roeck wrote:
> Section mismatches can now cause build failures, such as for
> cris:allnoconfig. Rename affected variables to end with _console
> to make section mismatch checks happy.
>
> Signed-off-by: Guenter Roeck
Folks
On 11/13/15, Laura Abbott wrote:
> Hi,
>
> There seem to be section mismatches coming from head_64.S
>
> WARNING: vmlinux.o(.text+0x8994): Section mismatch in reference from the
> variable __boot_from_prom to the function .init.text:prom_init()
> The function __boot_from_pr
Hi Laura,
On Thu, 2015-11-12 at 13:39 -0800, Laura Abbott wrote:
> Hi,
> There seem to be section mismatches coming from head_64.S
>
> WARNING: vmlinux.o(.text+0x8994): Section mismatch in reference from the
> variable __boot_from_prom to the function .init.text:prom_init()
Section mismatches can now cause build failures, such as for
cris:allnoconfig. Rename affected variables to end with _console
to make section mismatch checks happy.
Signed-off-by: Guenter Roeck
---
arch/cris/arch-v10/kernel/debugport.c | 22 +++---
1 file changed, 11 insertions
Section mismatches can now result in build failures.
As result, cris:allnoconfig fails to build as follows.
WARNING: modpost: Found 7 section mismatch(es).
To see full details build your kernel with:
'make CONFIG_DEBUG_SECTION_MISMATCH=y'
FATAL: modpost: Section mismatches det
; non-fatal, since there are a number of section mismatches when using
> allmodconfig on some architectures, and we do not want to break these
> builds by default.
>
> Signed-off-by: Nicolas Boichat
>
> Change-Id: Ic346706e3297c9f0d790e3552aa94e5cff9897a6
Thanks, applied.
Cheers,
Rus
The section mismatch warning can be easy to miss during the kernel build
process. Allow it to be marked as fatal to be easily caught and prevent
bugs from slipping in.
Setting CONFIG_SECTION_MISMATCH_WARN_ONLY=y causes these warnings to be
non-fatal, since there are a number of section mismatches
fatal, since there are a number of section mismatches when using
> allmodconfig on some architectures, and we do not want to break these
> builds by default.
>
> Signed-off-by: Nicolas Boichat
>
> Change-Id: Ic346706e3297c9f0d790e3552aa94e5cff9897a6
> ---
>
> I'm
The section mismatch warning can be easy to miss during the kernel build
process. Allow it to be marked as fatal to be easily caught and prevent
bugs from slipping in.
Setting CONFIG_SECTION_MISMATCH_WARNING=y causes these warnings to be
non-fatal, since there are a number of section mismatches
David Long writes:
> From: "David A. Long"
>
> Add processing for normally encountered thumb relocation types so that
> section mismatches will be detected.
>
> Signed-off-by: David A. Long
Happiest for this to go through an ARM tree, so:
Acked-by: R
From: "David A. Long"
Add processing for normally encountered thumb relocation types so that
section mismatches will be detected.
Signed-off-by: David A. Long
---
scripts/mod/modpost.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/scripts/mod/modpost.c b/s
st for?
We still have section mismatches in allmodconfig. With a Kconfig option
to make them fatal, allmodconfig would select it and fail.
Michal
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.
On Tue, Jan 08, 2013 at 02:38:10PM -0500, Jonathan Kliegman wrote:
> On Tue, Jan 8, 2013 at 2:16 PM, Sam Ravnborg wrote:
> > On Sun, Jan 06, 2013 at 03:22:39PM -0500, Jonathan Kliegman wrote:
> >> On Sun, Jan 6, 2013 at 4:36 AM, Sam Ravnborg wrote:
> >> > Hi Jonathan.
> >> >
> >> >> The section m
On Tue, Jan 8, 2013 at 2:16 PM, Sam Ravnborg wrote:
> On Sun, Jan 06, 2013 at 03:22:39PM -0500, Jonathan Kliegman wrote:
>> On Sun, Jan 6, 2013 at 4:36 AM, Sam Ravnborg wrote:
>> > Hi Jonathan.
>> >
>> >> The section mismatch warning can be easy to miss during the kernel build
>> >> process. All
On Sun, Jan 06, 2013 at 03:22:39PM -0500, Jonathan Kliegman wrote:
> On Sun, Jan 6, 2013 at 4:36 AM, Sam Ravnborg wrote:
> > Hi Jonathan.
> >
> >> The section mismatch warning can be easy to miss during the kernel build
> >> process. Allow it to be marked as fatal to be easily caught and prevent
On Sun, Jan 6, 2013 at 4:36 AM, Sam Ravnborg wrote:
> Hi Jonathan.
>
>> The section mismatch warning can be easy to miss during the kernel build
>> process. Allow it to be marked as fatal to be easily caught and prevent
>> bugs from slipping in.
>>
>> Signed-off-by: Jonathan Kliegman
>
> Another
Hi Jonathan.
> The section mismatch warning can be easy to miss during the kernel build
> process. Allow it to be marked as fatal to be easily caught and prevent
> bugs from slipping in.
>
> Signed-off-by: Jonathan Kliegman
Another way to make them much more visible would be to make
the warnin
On Thu, Jan 3, 2013 at 4:06 AM, Michal Marek wrote:
>
> Dne 3.1.2013 00:56, Rusty Russell napsal(a):
> > Jonathan Kliegman writes:
> >> The section mismatch warning can be easy to miss during the kernel build
> >> process. Allow it to be marked as fatal to be easily caught and prevent
> >> bugs
Dne 3.1.2013 00:56, Rusty Russell napsal(a):
> Jonathan Kliegman writes:
>> The section mismatch warning can be easy to miss during the kernel build
>> process. Allow it to be marked as fatal to be easily caught and prevent
>> bugs from slipping in.
>>
>> Signed-off-by: Jonathan Kliegman
>
> Hm
Jonathan Kliegman writes:
> The section mismatch warning can be easy to miss during the kernel build
> process. Allow it to be marked as fatal to be easily caught and prevent
> bugs from slipping in.
>
> Signed-off-by: Jonathan Kliegman
Hmm, a CONFIG option with no Kconfig entry? That seems we
e CONFIG_DEBUG_SECTION_MISMATCH=y'\n",
+ sec_mismatch_count);
+ }
+ if (sec_mismatch_fatal) {
+ fatal("modpost: Section mismatches detected.\n"
+ "Unset CONFIG_SECTION_MISMATCH_FATAL to
On Thu, Nov 29, 2012 at 10:45:02AM -0800, Greg Kroah-Hartman wrote:
> From: Greg Kroah-Hartman
>
> Now that the __dev* sections are not being generated, we don't need to
> check for them in modpost.c.
>
> Signed-off-by: Greg Kroah-Hartman
Acked-by: Sam Ravnborg
--
To unsubscribe from this list
From: Greg Kroah-Hartman
Now that the __dev* sections are not being generated, we don't need to
check for them in modpost.c.
Signed-off-by: Greg Kroah-Hartman
---
scripts/mod/modpost.c | 24 ++--
1 file changed, 10 insertions(+), 14 deletions(-)
diff --git a/scripts/mod
On Mon, Feb 25, 2008 at 11:45:12AM +0300, Andrey Borzenkov wrote:
> During compilation:
>
> LD [M] drivers/pcmcia/pcmcia_core.o
> WARNING: drivers/pcmcia/pcmcia_core.o(.data+0x1d4): Section mismatch in
> reference from the variable pccard_sysfs_interface to the function
> .devinit.text:pccard
During compilation:
LD [M] drivers/pcmcia/pcmcia_core.o
WARNING: drivers/pcmcia/pcmcia_core.o(.data+0x1d4): Section mismatch in
reference from the variable pccard_sysfs_interface to the function
.devinit.text:pccard_sysfs_add_socket()
The variable pccard_sysfs_interface references
the functio
Following patch set fix all section mismatches for a
allnoconfig, allyesconfig, defconfig build of x86 - 64bit.
The builds were all done with CONFIG_DEBUG_SECTION_MISMATCH
enabled.
The fixes are spread all over the tree but none of them are
invasive in nature.
diffstat for the full patchset
From: Heiko Carstens <[EMAIL PROTECTED]>
Fix couple of section mismatches. And since we touch the code
anyway change the IPL code to use C99 initializers.
Cc: Michael Holzheu <[EMAIL PROTECTED]>
Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]>
Signed-off-by: Martin Schwidefsky
> > > 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 bori
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 Rav
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 +01
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 messa
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:
> > ...
>
On Sat, Feb 02, 2008 at 05:42:23PM +0100, Geert Uytterhoeven wrote:
> On Fri, 1 Feb 2008, Sam Ravnborg wrote:
> > On Fri, Feb 01, 2008 at 10:22:13PM +0100, Geert Uytterhoeven wrote:
> > > On Fri, 1 Feb 2008, Sam Ravnborg wrote:
> > > > On Fri, Feb 01, 2008 at 02:30:44PM +0100, Geert Uytterhoeven wr
On Fri, 1 Feb 2008, Sam Ravnborg wrote:
> On Fri, Feb 01, 2008 at 10:22:13PM +0100, Geert Uytterhoeven wrote:
> > On Fri, 1 Feb 2008, Sam Ravnborg wrote:
> > > On Fri, Feb 01, 2008 at 02:30:44PM +0100, Geert Uytterhoeven wrote:
> > > > BTW, on m68k I get ca. 160 of them. Most seem to originate in
>
On Fri, Feb 01, 2008 at 10:51:14PM +0100, Jan Engelhardt wrote:
>
> On Feb 1 2008 12:10, Andi Kleen wrote:
> >On Friday 01 February 2008 11:47:18 Sam Ravnborg wrote:
> >> James said in a related posting that the Section mismatch
> >> warnings were getting out of control.
> >
> >My question is: whe
On Feb 1 2008 23:40, Sam Ravnborg wrote:
>>
>> checkpatch does not parse C, it uses heuristical regexes.
>>
>> That makes it very different from sparse or the section mismatch
>> finder which do not output false positives.
>
>Unfortunately I most correct you. Section mismatch checks seldoms find
On Fri, Feb 01, 2008 at 10:47:25PM +0100, Jan Engelhardt wrote:
>
> On Feb 1 2008 03:21, Harvey Harrison wrote:
> >>
> >> Question is: why do people keep adding new ones when they are so easy to
> >> detect and fix?
> >>
> >> Asnwer: because neither they nor their patch integrators are doing ade
On Fri, Feb 01, 2008 at 03:24:05PM -0500, Jeff Garzik wrote:
> Sam Ravnborg wrote:
> >One can ignore or one can fix...
> >I decided to spend some of my friday on fixing section mismatch
> >warnings as I've got a bit irritated over people spending time
> >complaining but failing to provide patches.
On Fri, Feb 01, 2008 at 10:22:13PM +0100, Geert Uytterhoeven wrote:
> On Fri, 1 Feb 2008, Sam Ravnborg wrote:
> > On Fri, Feb 01, 2008 at 02:30:44PM +0100, Geert Uytterhoeven wrote:
> > > BTW, on m68k I get ca. 160 of them. Most seem to originate in
> > > drivers/isdn/. Doesn't look unsurmountable
On Fri, 2008-02-01 at 22:47 +0100, Jan Engelhardt wrote:
> On Feb 1 2008 03:21, Harvey Harrison wrote:
> >>
> >> Question is: why do people keep adding new ones when they are so easy to
> >> detect and fix?
> >>
> >> Asnwer: because neither they nor their patch integrators are doing adequate
> >
On Feb 1 2008 12:10, Andi Kleen wrote:
>On Friday 01 February 2008 11:47:18 Sam Ravnborg wrote:
>> James said in a related posting that the Section mismatch
>> warnings were getting out of control.
>
>My question is: where are crashes? If the sections were
>really in such bad shape and since we po
On Feb 1 2008 03:21, Harvey Harrison wrote:
>>
>> Question is: why do people keep adding new ones when they are so easy to
>> detect and fix?
>>
>> Asnwer: because neither they nor their patch integrators are doing adequate
>> compilation testing.
>
>[...]
>Unless they break the build, or if the
On Fri, 1 Feb 2008, Sam Ravnborg wrote:
> On Fri, Feb 01, 2008 at 02:30:44PM +0100, Geert Uytterhoeven wrote:
> > BTW, on m68k I get ca. 160 of them. Most seem to originate in
> > drivers/isdn/. Doesn't look unsurmountable compared to the number of
> > other compile warnings fixed during the last f
Sam Ravnborg wrote:
One can ignore or one can fix...
I decided to spend some of my friday on fixing section mismatch
warnings as I've got a bit irritated over people spending time
complaining but failing to provide patches.
Sam - who expected more people to actually fix this stuff :-(
> Another way to look at it... All of a sudden, different from 2.6.24,
> kernel 2.6.25-git build spews so many warnings that I need to disable
> section mismatch checking completely, because there is so much noise
> that __normal build messages scroll off the screen__.
One can ignore or one ca
Hi Dave.
On Fri, Feb 01, 2008 at 06:06:58PM +, Dave Haywood wrote:
> PROBLEM: Section mismatches in kernel v2.6.24-6314-g24e1c13 build
>
> Hi,
>
> I see the folllowing section mismatches in the latest Linus kernel git
> tree build:
...
Thanks for the report. These are b
> Subject to someone _making_ it an issue, can't see it changing.
Actually I think that Sam's recent improvements to the section
mismatch detection should make it easy to get at least all of the
driver issues fixed -- the problem in the past was that many warnings
would only show with certain con
Andrew Morton wrote:
On Fri, 1 Feb 2008 11:47:18 +0100 Sam Ravnborg <[EMAIL PROTECTED]> wrote:
James said in a related posting that the Section mismatch
warnings were getting out of control.
eh. They're easy - the build system tells you about them!
The list is here:
Question is: why do p
On Fri, 2008-02-01 at 03:03 -0800, Andrew Morton wrote:
> On Fri, 1 Feb 2008 11:47:18 +0100 Sam Ravnborg <[EMAIL PROTECTED]> wrote:
>
> > James said in a related posting that the Section mismatch
> > warnings were getting out of control.
>
> eh. They're easy - the build system tells you about th
On Fri, 2008-02-01 at 11:47 +0100, Sam Ravnborg wrote:
> James said in a related posting that the Section mismatch
> warnings were getting out of control.
What I actually said was that the churn in the source base caused by
these sectional mismatches was getting out of hand.
What I questioned was
Hi,
Andrew Morton <[EMAIL PROTECTED]> writes:
> Question is: why do people keep adding new ones when they are so easy to
> detect and fix?
>
> Asnwer: because neither they nor their patch integrators are doing adequate
> compilation testing.
How about adding an Untested-by tag for psychological
On Fri, Feb 01, 2008 at 02:30:44PM +0100, Geert Uytterhoeven wrote:
> On Fri, 1 Feb 2008, Harvey Harrison wrote:
> > On Fri, 2008-02-01 at 03:03 -0800, Andrew Morton wrote:
> > > On Fri, 1 Feb 2008 11:47:18 +0100 Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> > > > James said in a related posting that t
On Fri, 1 Feb 2008, Harvey Harrison wrote:
> On Fri, 2008-02-01 at 03:03 -0800, Andrew Morton wrote:
> > On Fri, 1 Feb 2008 11:47:18 +0100 Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> > > James said in a related posting that the Section mismatch
> > > warnings were getting out of control.
> >
> > eh.
On Fri, 2008-02-01 at 03:03 -0800, Andrew Morton wrote:
> On Fri, 1 Feb 2008 11:47:18 +0100 Sam Ravnborg <[EMAIL PROTECTED]> wrote:
>
> > James said in a related posting that the Section mismatch
> > warnings were getting out of control.
>
> eh. They're easy - the build system tells you about th
On Friday 01 February 2008 11:47:18 Sam Ravnborg wrote:
> James said in a related posting that the Section mismatch
> warnings were getting out of control.
My question is: where are crashes? If the sections were
really in such bad shape and since we poison (and sometimes
even unmap) init after boo
On Fri, 1 Feb 2008 11:47:18 +0100 Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> James said in a related posting that the Section mismatch
> warnings were getting out of control.
eh. They're easy - the build system tells you about them!
> The list is here:
Question is: why do people keep adding new
James said in a related posting that the Section mismatch
warnings were getting out of control.
So I decided to take a closer look at current
status. Latest mainline with Adrian + mine fixes applied.
Target was x86 - an allyesconfig build.
I looked at the reported Section mismatch warnings per
di
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
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
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 i
At Tue, 15 Jan 2008 13:25:46 -0800,
Randy Dunlap wrote:
>
> From: Randy Dunlap <[EMAIL PROTECTED]>
>
> Fix section mismatch in caiaq: these __devinit functions can be
> called at any time so they should not be __devinit.
>
> WARNING: vmlinux.o(.text+0x10a8dae): Section mismatch: reference to
>
From: Randy Dunlap <[EMAIL PROTECTED]>
Fix section mismatch in caiaq: these __devinit functions can be
called at any time so they should not be __devinit.
WARNING: vmlinux.o(.text+0x10a8dae): Section mismatch: reference to
.init.text:snd_usb_caiaq_audio_init (between 'setup_card' and 'create_car
From: Randy Dunlap <[EMAIL PROTECTED]>
Fix section mismatches in mts64 by making a static variable __devinitdata.
WARNING: vmlinux.o(.data+0x2e33f0): Section mismatch: reference to
.init.data:mts64_ctl_smpte_switch (between 'control.19929' and
'snd_mts64_rawmidi_output_ops
On Sat, Dec 29, 2007 at 01:18:02AM -0800, David Miller wrote:
> From: Adrian Bunk <[EMAIL PROTECTED]>
> Date: Sat, 29 Dec 2007 11:06:19 +0200
>
> > On Sat, Dec 29, 2007 at 12:54:08AM -0800, David Miller wrote:
> > > From: Adrian Bunk <[EMAIL PROTECTED]>
> > > Date: Sat, 29 Dec 2007 10:48:46 +0200
From: Adrian Bunk <[EMAIL PROTECTED]>
Date: Sat, 29 Dec 2007 11:06:19 +0200
> On Sat, Dec 29, 2007 at 12:54:08AM -0800, David Miller wrote:
> > From: Adrian Bunk <[EMAIL PROTECTED]>
> > Date: Sat, 29 Dec 2007 10:48:46 +0200
> >
> > > On Sat, Dec 29, 2007 at 12:14:11AM -0800, David Miller wrote:
>
From: David Miller <[EMAIL PROTECTED]>
Date: Sat, 29 Dec 2007 00:54:08 -0800 (PST)
> From: Adrian Bunk <[EMAIL PROTECTED]>
> Date: Sat, 29 Dec 2007 10:48:46 +0200
>
> > On Sat, Dec 29, 2007 at 12:14:11AM -0800, David Miller wrote:
> > > That's why I'm not worried about this issue and it's not cri
On Sat, Dec 29, 2007 at 12:54:08AM -0800, David Miller wrote:
> From: Adrian Bunk <[EMAIL PROTECTED]>
> Date: Sat, 29 Dec 2007 10:48:46 +0200
>
> > On Sat, Dec 29, 2007 at 12:14:11AM -0800, David Miller wrote:
> > > That's why I'm not worried about this issue and it's not critical at
> > > all.
>
From: Adrian Bunk <[EMAIL PROTECTED]>
Date: Sat, 29 Dec 2007 10:48:46 +0200
> On Sat, Dec 29, 2007 at 12:14:11AM -0800, David Miller wrote:
> > That's why I'm not worried about this issue and it's not critical at
> > all.
>
> If a module calls sunserial_console_match() that's an Oops.
That's tru
On Sat, Dec 29, 2007 at 12:14:11AM -0800, David Miller wrote:
> From: Adrian Bunk <[EMAIL PROTECTED]>
> Date: Sat, 29 Dec 2007 01:22:56 +0200
>
> > At least the sunserial_console_match() one is an obvious Oops
> > (EXPORT_SYMBOL of an __init function).
> >
> > The comment in the description of
>
From: David Miller <[EMAIL PROTECTED]>
Date: Sat, 29 Dec 2007 00:14:11 -0800 (PST)
> You can't do that, the FOO_CONSOLE config options depend upon
> FOO=y.
>
> That's why I'm not worried about this issue and it's not critical at
> all.
Adrian, if you're interested in tackling this "fun" problem,
From: Adrian Bunk <[EMAIL PROTECTED]>
Date: Sat, 29 Dec 2007 01:22:56 +0200
> At least the sunserial_console_match() one is an obvious Oops
> (EXPORT_SYMBOL of an __init function).
>
> The comment in the description of
> commit 58d784a5c754cd66ecd4791222162504d3c16c74 the warning was bogus
>
On Wed, Dec 26, 2007 at 07:05:04PM -0800, David Miller wrote:
> From: Mariusz Kozlowski <[EMAIL PROTECTED]>
> Date: Wed, 26 Dec 2007 13:29:07 +0100
>
> > WARNING: vmlinux.o(.text+0x46b04): Section mismatch: reference to
> > .init.text:sun4v_ktsb_register (between 'smp_callin' and
> > 'smp_fill_i
From: Mariusz Kozlowski <[EMAIL PROTECTED]>
Date: Wed, 26 Dec 2007 13:29:07 +0100
> WARNING: vmlinux.o(.text+0x46b04): Section mismatch: reference to
> .init.text:sun4v_ktsb_register (between 'smp_callin' and
> 'smp_fill_in_sib_core_maps')
Well known and I see them every build and so does every
Hello,
WARNING: vmlinux.o(.text+0x46b04): Section mismatch: reference to
.init.text:sun4v_ktsb_register (between 'smp_callin' and
'smp_fill_in_sib_core_maps')
WARNING: vmlinux.o(.text+0x4756c): Section mismatch: reference to
.init.text:sun4v_register_mondo_queues (between 'after_lock_tlb' and
[EMAIL PROTECTED] wrote:
On Thu, 13 Dec 2007 02:40:50 PST, Andrew Morton said:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc5/2.6.24-rc5-mm1/
git-net.patch (I'm guessing one of Daniel's commits, but not sure which one)
causes some complaints:
LD vmlinux.o
MO
On Thu, 13 Dec 2007 02:40:50 PST, Andrew Morton said:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc5/2.6.24-rc5-mm1/
git-net.patch (I'm guessing one of Daniel's commits, but not sure which one)
causes some complaints:
LD vmlinux.o
MODPOST vmlinux.o
WARNING: v
On Mon, Oct 29, 2007 at 01:49:47PM +0100, Adrian Bunk wrote:
> This patch fixes the following section mismatches:
>
> <-- snip -->
>
> ...
> WARNING: vmlinux.o(.text+0x5b5c2): Section mismatch: reference to
> .init.text:memmap_init_zone (between 'memma
1 - 100 of 146 matches
Mail list logo
