As spotted by one of our Fedora users, we sometimes
oops during shutdown (http://www.roberthancock.com/kerneloops.png)
because disable_IO_APIC() wants to call find_isa_irq_pin(),
which we threw away during init.
Signed-off-by: Dave Jones <[email protected]>
--- linux-2.6.8/arch/i386/kernel/io_apic.c~ 2004-10-10 18:54:27.490567168 -0400
+++ linux-2.6.8/arch/i386/kernel/io_apic.c 2004-10-10 18:54:44.660956872 -0400
@@ -745,7 +745,7 @@ static int __init find_irq_entry(int api
/*
* Find the pin to which IRQ[irq] (ISA) is connected
*/
-static int __init find_isa_irq_pin(int irq, int type)
+static int find_isa_irq_pin(int irq, int type)
{
int i;
Confirmed, taking the __init off find_isa_irq_pin prevents the oops on
reboot for me.
----- Original Message -----
From: "Dave Jones" <[email protected]>
Newsgroups: fa.linux.kernel
To: <[email protected]>; <[email protected]>
Cc: <[email protected]>
Sent: Sunday, October 10, 2004 4:58 PM
Subject: [PATCH] find_isa_irq_pin can't be __init
> As spotted by one of our Fedora users, we sometimes
> oops during shutdown (http://www.roberthancock.com/kerneloops.png)
> because disable_IO_APIC() wants to call find_isa_irq_pin(),
> which we threw away during init.
>
> Signed-off-by: Dave Jones <[email protected]>
>
> --- linux-2.6.8/arch/i386/kernel/io_apic.c~ 2004-10-10
> 18:54:27.490567168 -0400
> +++ linux-2.6.8/arch/i386/kernel/io_apic.c 2004-10-10
> 18:54:44.660956872 -0400
> @@ -745,7 +745,7 @@ static int __init find_irq_entry(int api
> /*
> * Find the pin to which IRQ[irq] (ISA) is connected
> */
> -static int __init find_isa_irq_pin(int irq, int type)
> +static int find_isa_irq_pin(int irq, int type)
> {
> int i;
>
> -
> 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/
On Sun, 10 Oct 2004, Dave Jones wrote:
> As spotted by one of our Fedora users, we sometimes
> oops during shutdown (http://www.roberthancock.com/kerneloops.png)
> because disable_IO_APIC() wants to call find_isa_irq_pin(),
> which we threw away during init.
I guess it's about time for a tool to autodetect __init dependencies?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Geert Uytterhoeven <[email protected]> wrote:
>
> I guess it's about time for a tool to autodetect __init dependencies?
`make buildcheck' does this. Looks like nobody is using it.
On Mon, Oct 11, 2004 at 12:12:25PM -0700, Andrew Morton wrote:
> Geert Uytterhoeven <[email protected]> wrote:
> >
> > I guess it's about time for a tool to autodetect __init dependencies?
>
> `make buildcheck' does this. Looks like nobody is using it.
Actually, aparently I goofed, and that patch is only needed in
our Fedora kernels. It won't hurt in mainline though, and I'll
push the other bits after 2.6.9
Dave
Andrew Morton wrote:
> Geert Uytterhoeven <[email protected]> wrote:
>
>>I guess it's about time for a tool to autodetect __init dependencies?
>
>
> `make buildcheck' does this. Looks like nobody is using it.
I have asked that one of the forever-building machines here (OSDL)
do that.
I'll get back to that request....
--
~Randy
MOTD: Always include version info.
(Again. Sometimes I think ln -s /usr/src/linux/.config .signature)
Randy.Dunlap wrote:
> Andrew Morton wrote:
>
>> Geert Uytterhoeven <[email protected]> wrote:
>>
>>> I guess it's about time for a tool to autodetect __init dependencies?
>>
>>
>>
>> `make buildcheck' does this. Looks like nobody is using it.
>
>
> I have asked that one of the forever-building machines here (OSDL)
> do that.
> I'll get back to that request....
John Cherry has been running 'make buildcheck' regularly,
but apparently nobody has been looking.
Latest (2.6.9-rc4) is here:
http://developer.osdl.org/cherry/compile/2.6/linux-2.6.9-rc4.results/2.6.9-rc4.reference_init26.bzImage.txt
My experience with output of buildcheck is that it's verbose and has
lots of false positives. (Yes, I have used it and generated patches
from it.) First thing I do is delete all lines that match
"data.*init" or "data.*exit". These are (usually -- famous word) OK.
Then someone can look at the entries that really need to be checked,
such as this list, derived from the larger list above:
http://developer.osdl.org/rddunlap/doc/2.6.9-rc4.reference_init26.bzImage.txt
I'll look over it in the next few days.
--
~Randy
"Randy.Dunlap" <[email protected]> wrote:
>
> My experience with output of buildcheck is that it's verbose and has
> lots of false positives.
I berated Keith over that a while back and he shot me down. umm...
> On Mon, 31 May 2004 23:52:14 -0700,
> Andrew Morton <[email protected]> wrote:
> >
> >gad, reference_init generates so much stuff I wonder if it's worth using.
> >Are all these for real?
>
> Apart from altinstructions, yes. Mainly because people have not been
> checking them.
>
> >perl scripts/reference_init.pl
> >Finding objects, 1411 objects, ignoring 122 module(s)
> >Finding conglomerates, ignoring 137 conglomerate(s)
> >Scanning objects
> >Error: ./arch/i386/kernel/apic.o .data refers to 0000009c R_386_32 .init.text
>
> arch/i386/kernel/apic.c
> void (*wait_timer_tick)(void) = wait_8254_wraparound;
> wait_8254_wraparound is __init. wait_timer_tick should be __initdata,
> which flows onto several other functions.
>
> >Error: ./arch/i386/kernel/cpu/mtrr/centaur.o .data refers to 00000008 R_386_32 .init.text
>
> That is real, centaur_mtrr_ops.init = centaur_mcr_init. Like a lot of
> this initialization code, we get away with the dangling reference
> because the code is only executed at boot.
>
> >Error: ./arch/i386/kernel/cpu/mtrr/centaur.o .eh_frame refers to 000000dc R_386_32 .init.text
>
> I don't see any .eh_frame references in 2.6.7-rc2 using gcc version
> 3.3.3 20040412 (Red Hat Linux 3.3.3-7). Where are they coming from?
>
> >Error: ./arch/i386/kernel/cpu/mtrr/cyrix.o .data refers to 00000028 R_386_32 .init.text
>
> Same as centaur.
>
> >Error: ./arch/i386/kernel/cpu/mtrr/generic.o .text refers to 0000038f R_386_32 .init.data
>
> arch/i386/kernel/cpu/mtrr/generic.c
> generic_set_all() uses __intdata smp_changes_mask.
>
> >Error: ./arch/i386/kernel/smpboot.o .altinstructions refers to 00000000 R_386_32 .init.text
>
> altinstructions is a false positive, tweak reference_init.pl
>
> --- reference_init.pl.orig 2004-06-01 20:30:27.000000000 +1000
> +++ reference_init.pl 2004-06-01 20:31:01.000000000 +1000
> @@ -93,6 +93,7 @@
> $from !~ /\.stab$/ &&
> $from !~ /\.rodata$/ &&
> $from !~ /\.text\.lock$/ &&
> + $from !~ /\.altinstructions$/ &&
> $from !~ /\.debug_/)) {
> printf("Error: %s %s refers to %s\n", $object, $from, $line);
> }
>
> The rest of the warnings look real, apart from the strange eh_frame.
>
So what you think are false positives may well not be.
On Mon, 11 Oct 2004 21:04:46 -0700,
"Randy.Dunlap" <[email protected]> wrote:
>Randy.Dunlap wrote:
>> Andrew Morton wrote:
>>
>>> Geert Uytterhoeven <[email protected]> wrote:
>>>
>>>> I guess it's about time for a tool to autodetect __init dependencies?
>>>
>>> `make buildcheck' does this. Looks like nobody is using it.
>
>John Cherry has been running 'make buildcheck' regularly,
>but apparently nobody has been looking.
>
>Latest (2.6.9-rc4) is here:
>http://developer.osdl.org/cherry/compile/2.6/linux-2.6.9-rc4.results/2.6.9-rc4.reference_init26.bzImage.txt
>
>My experience with output of buildcheck is that it's verbose and has
>lots of false positives. (Yes, I have used it and generated patches
>from it.) First thing I do is delete all lines that match
>"data.*init" or "data.*exit". These are (usually -- famous word) OK.
They may only be OK because the code is never run more than once.
Normal code that refers to data.*init and is run more than once is a
bug just waiting to bite you.
Andrew - small fix for reference_init.pl, against 2.6.9-rc4.
------------------------------------------------------------
Treat .pci_fixup entries the same as .init code/data.
Signed off by: Keith Owens <[email protected]>
Index: linux/scripts/reference_init.pl
===================================================================
--- linux.orig/scripts/reference_init.pl Sat Aug 14 15:37:37 2004
+++ linux/scripts/reference_init.pl Tue Oct 12 15:59:39 2004
@@ -93,6 +93,8 @@ foreach $object (sort(keys(%object))) {
$from !~ /\.stab$/ &&
$from !~ /\.rodata$/ &&
$from !~ /\.text\.lock$/ &&
+ $from !~ /\.pci_fixup_header$/ &&
+ $from !~ /\.pci_fixup_final$/ &&
$from !~ /\.debug_/)) {
printf("Error: %s %s refers to %s\n", $object, $from, $line);
}
Keith Owens wrote:
>
>
> They may only be OK because the code is never run more than once.
> Normal code that refers to data.*init and is run more than once is a
> bug just waiting to bite you.
>
> Andrew - small fix for reference_init.pl, against 2.6.9-rc4.
>
> ------------------------------------------------------------
>
> Treat .pci_fixup entries the same as .init code/data.
>
> Signed off by: Keith Owens <[email protected]>
>
> Index: linux/scripts/reference_init.pl
> ===================================================================
> --- linux.orig/scripts/reference_init.pl Sat Aug 14 15:37:37 2004
> +++ linux/scripts/reference_init.pl Tue Oct 12 15:59:39 2004
> @@ -93,6 +93,8 @@ foreach $object (sort(keys(%object))) {
> $from !~ /\.stab$/ &&
> $from !~ /\.rodata$/ &&
> $from !~ /\.text\.lock$/ &&
> + $from !~ /\.pci_fixup_header$/ &&
> + $from !~ /\.pci_fixup_final$/ &&
> $from !~ /\.debug_/)) {
> printf("Error: %s %s refers to %s\n", $object, $from, $line);
> }
Keith,
It looks like __param section references can also be safely
ignored by 'reference_init.pl', since they are not discarded AFAIK.
Or am I wrong about that one?
Patch attached -- applies on top of yours.
--
~Randy
){kind=link}