lkml.org 
[lkml]   [2006]   [Jun]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 2.6.17-mm2
    On Sun, 25 Jun 2006 10:51:55 +0200
    "Rafael J. Wysocki" <rjw@sisk.pl> 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 majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-06-25 12:29    [W:3.300 / U:0.104 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site