pm-cps code uses uninitialized cpu_data fields

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Paul,

On a multicore interAptiv system, I noticed that booting with "nosmp"
generated a warning:

[    0.116000] ------------[ cut here ]------------
[    0.116000] WARNING: CPU: 0 PID: 1 at
/mnt/host/source/src/third_party/kernel/v3.14/arch/mips/kernel/pm-cps.c:270
cps_pm_init+0x798/0xd68()
[    0.116000] pm-cps: FSB flush unsupported for this CPU
[    0.116000] Modules linked in:
[    0.116000] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.14.0 #23
[    0.116000] Stack : 00000000 00000034 00000006 8048afdc 00000000
00000005 00000006 00000000
[    0.116000]  00000000 00000000 00000000 00000000 80c3054a 00000034
00000000 80ba0000
[    0.116000]  80b00000 8f8683c8 80a5ec48 00000001 00000000 80ba3604
80afea00 80b9b980
[    0.116000]  00000001 809b4c30 80ba3604 80432538 00000000 80b00000
80a64efc 8f863d0c
[    0.116000]  8f863d0c 0085b507 00000000 00000000 00000000 00000000
00000000 00000000
[    0.116000]  ...
[    0.116000] Call Trace:
[    0.116000] [<80409e44>] show_stack+0x6c/0xac
[    0.120000] [<809b54c4>] dump_stack+0xb0/0xd4
[    0.120000] [<804326c8>] warn_slowpath_common+0x98/0xc8
[    0.120000] [<80432744>] warn_slowpath_fmt+0x4c/0x70
[    0.120000] [<80b4193c>] cps_pm_init+0x798/0xd68
[    0.120000] [<80400540>] do_one_initcall+0x7c/0x1cc
[    0.120000] [<80b3bbcc>] kernel_init_freeable+0x168/0x220
[    0.120000] [<809b3a04>] kernel_init+0x24/0x114
[    0.120000] [<804034f8>] ret_from_kernel_thread+0x14/0x1c
[    0.120000]
[    0.120000] ---[ end trace 69ce861cf7aa6d6e ]---
[    0.120000] Failed to generate core 1 state 1 entry

This happened because cps_gen_core_entries() was being called for CPUs
that have not been booted:

for_each_present_cpu(cpu) {
    err = cps_gen_core_entries(cpu);
    if (err)
        return err;
}

and so fields like cpu_info->cputype and cpu_info->dcache.linesz were still 0.

I worked around it temporarily by using for_each_online_cpu instead,
but I'm not sure this will do the right thing if the CPUs are brought
up later.

Another possibility is to copy over the CPU type / cache info from
CPU0 if the secondary CPUs are not up yet.

Your thoughts?





[Index of Archives]     [Linux MIPS Home]     [LKML Archive]     [Linux ARM Kernel]     [Linux ARM]     [Linux]     [Git]     [Yosemite News]     [Linux SCSI]     [Linux Hams]

  Powered by Linux