Re: [LKP] [x86/intel/quark] 8bbc2a135b6: WARNING: CPU: 0 PID: 1 at arch/x86/platform/intel-quark/imr.c:358 imr_add_range+0x2b4/0x370()

From: Bryan O'Donoghue
Date: Mon Mar 30 2015 - 04:15:10 EST



[ 0.752570] [<c1ab0845>] dump_stack+0x16/0x18
[ 0.752570] [<c1ab0845>] dump_stack+0x16/0x18
[ 0.753420] [<c103bb27>] warn_slowpath_common+0x87/0xc0
[ 0.753420] [<c103bb27>] warn_slowpath_common+0x87/0xc0
[ 0.754429] [<c1038674>] ? imr_add_range+0x2b4/0x370
[ 0.754429] [<c1038674>] ? imr_add_range+0x2b4/0x370
[ 0.755384] [<c1038674>] ? imr_add_range+0x2b4/0x370
[ 0.755384] [<c1038674>] ? imr_add_range+0x2b4/0x370
[ 0.756335] [<c103bbc3>] warn_slowpath_fmt+0x33/0x40
[ 0.756335] [<c103bbc3>] warn_slowpath_fmt+0x33/0x40
[ 0.757293] [<c1038674>] imr_add_range+0x2b4/0x370
[ 0.757293] [<c1038674>] imr_add_range+0x2b4/0x370
[ 0.758219] [<c103057c>] ? slow_virt_to_phys+0x2c/0x90
[ 0.758219] [<c103057c>] ? slow_virt_to_phys+0x2c/0x90
[ 0.759200] [<c103209a>] ? __phys_addr+0x3a/0x90
[ 0.759200] [<c103209a>] ? __phys_addr+0x3a/0x90
[ 0.760090] [<c106e4de>] ? debug_check_no_locks_freed+0x9e/0x160
[ 0.760090] [<c106e4de>] ? debug_check_no_locks_freed+0x9e/0x160
[ 0.761361] [<c103057c>] ? slow_virt_to_phys+0x2c/0x90
[ 0.761361] [<c103057c>] ? slow_virt_to_phys+0x2c/0x90
[ 0.762419] [<c1fb836a>] imr_self_test_init+0x40/0x1d9
[ 0.762419] [<c1fb836a>] imr_self_test_init+0x40/0x1d9
[ 0.763439] [<c1fb832a>] ? imr_self_test_result+0x4e/0x4e
[ 0.763439] [<c1fb832a>] ? imr_self_test_result+0x4e/0x4e
[ 0.764477] [<c1fa7d03>] do_one_initcall+0x180/0x193
[ 0.764477] [<c1fa7d03>] do_one_initcall+0x180/0x193
[ 0.765443] [<c10568bb>] ? parse_args+0x25b/0x530
[ 0.765443] [<c10568bb>] ? parse_args+0x25b/0x530
[ 0.766350] [<c1fa7dec>] kernel_init_freeable+0xd6/0x153
[ 0.766350] [<c1fa7dec>] kernel_init_freeable+0xd6/0x153
[ 0.767370] [<c1fa7dec>] ? kernel_init_freeable+0xd6/0x153
[ 0.767370] [<c1fa7dec>] ? kernel_init_freeable+0xd6/0x153
[ 0.768426] [<c1aab7a0>] kernel_init+0x10/0xe0
[ 0.768426] [<c1aab7a0>] kernel_init+0x10/0xe0
[ 0.769296] [<c1061445>] ? schedule_tail+0x25/0x70
[ 0.769296] [<c1061445>] ? schedule_tail+0x25/0x70
[ 0.770424] [<c1abe060>] ret_from_kernel_thread+0x20/0x30
[ 0.770424] [<c1abe060>] ret_from_kernel_thread+0x20/0x30
[ 0.771456] [<c1aab790>] ? rest_init+0xb0/0xb0
[ 0.771456] [<c1aab790>] ? rest_init+0xb0/0xb0
[ 0.772362] ---[ end trace e098947396137dbd ]---
[ 0.772362] ---[ end trace e098947396137dbd ]---

Well the self test fails like it should on hardware without IMR support :)

Curious what the QEMU setup is like ?

To get to the self test code we need to get past this

static const struct x86_cpu_id imr_ids[] __initconst = {
{ X86_VENDOR_INTEL, 5, 9 }, /* Intel Quark SoC X1000. */
{}
};
MODULE_DEVICE_TABLE(x86cpu, imr_ids);

if (!x86_match_cpu(imr_ids) || !iosf_mbi_available())
return -ENODEV;

Looks to me like a version of QEMU that reports iosf_mbi available, cpuid 5/9 but lacks full IMR support ?

How do I replicate this setup ?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/