On Sun, 25 Jun 2006 10:51:55 +0200
"Rafael J. Wysocki" <[email protected]> wrote:
> > >
> >
> > My guess would be that cpufreq_register_driver() is being called after it
> > has been unloaded from the kernel.
> >
> > Do you have CONFIG_CPU_FREQ=y?
>
> Yes.
>
> > Does removal of the __cpuinit from cpufreq_register_driver() fix it (or
> > move the crash elsewhere)?
>
> Yes (makes it go away).
Well it would appear that the new __cpuinit on cpufreq_register_driver() is
causing the problem, although I'm surprised that you don't have
CONFIG_HOTPLUG_CPU set, if it's a swsusp requirement??
> > Do you get any section mismatch warnings at build-time?
>
> Only this one:
> WARNING: drivers/acpi/processor.o - Section mismatch: reference to .init.data: from .text between 'acpi_processor_power_init' (at offset 0x1164) and 'acpi_processor_power_exit'
>
That's a false-positive - the code in there is, I think, OK:
static int first_run;
...
if (!first_run) {
dmi_check_system(processor_power_dmi_table);
...
first_run++;
}
The warning is about the reference to processor_power_dmi_table. But as
long as the first call to acpi_processor_power_init() happens prior to
free_initmem(), we won't actually try to touch the unloaded memory.
It's fragile and nasty though - it'd be nice to sort it out.
Anyway. It's regrettable that the new section-checking code didn't
complain about the bug. It looks like this is because the call to
cpufreq_register_driver() happened at modprobe-time, and we don't check for
that. Which is rather bad.
Sam, would it be possible to check for references from modules into
statically-linked __init code? It's always wrong...
Rusty/Randy/whoever looks after modules: it also seems wrong that it's
possible to load a module which refers to now-unloaded symbols. In fact,
it's surprising - sorry if I'm misinterpreting this. If I'm not, it should
be pretty easy to barf if a module is trying to get at symbols which lie
between __init_begin and __init_end?
Chandra, this is scary stuff. I'll tempdrop those patches until we can get
the kbuild/modprobe infrastructure in place which will allow us to fully
check your sectioning changes at depmod/modprobe time.
<thinks>
Actually, it should still be possible to do this - simply do a `make
allyesconfig; make' with the patches unapplied, then do it with the patches
applied and then look for the differences in the warnings.
Need to do this with various combinations of CONFIG_MODULES,
CONFIG_HOTPLUG, CONFIG_HOTPLUG_CPU, CONFIG_MEMORY_HOTPLUG,
CONFIG_ACPI_HOTPLUG_MEMORY and CONFIG_ACPI_HOTPLUG_MEMORY_MODULE.
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
