This started happening this morning after booting -rc4+tip, let's add *everybody* to CC :-)
We have intel_uncore_init, snb_uncore_imc_init_box, uncore_pci_probe and other goodies on the stack.
... [ 0.488998] software IO TLB [mem 0xcac30000-0xcec30000] (64MB) mapped at [ffff8800cac30000-ffff8800cec2ffff] [ 0.489975] resource map sanity check conflict: 0xfed10000 0xfed15fff 0xfed10000 0xfed13fff pnp 00:01 [ 0.490079] ------------[ cut here ]------------ [ 0.490204] WARNING: CPU: 2 PID: 1 at arch/x86/mm/ioremap.c:171 __ioremap_caller+0x372/0x380() [ 0.490306] Info: mapping multiple BARs. Your kernel is fine. [ 0.490371] Modules linked in: [ 0.490558] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 3.14.0-rc4+ #1 [ 0.490642] Hardware name: LENOVO 2320CTO/2320CTO, BIOS G2ET86WW (2.06 ) 11/13/2012 [ 0.490742] 00000000000000ab ffff880213d01ad8 ffffffff816112e3 0000000000000006 [ 0.491032] ffff880213d01b28 ffff880213d01b18 ffffffff8104e9bc ffff880213d01b08 [ 0.491343] ffffc90000c58000 00000000fed10000 00000000fed10000 0000000000006000 [ 0.491631] Call Trace: [ 0.493337] [<ffffffff816112e3>] dump_stack+0x4f/0x7c [ 0.493420] [<ffffffff8104e9bc>] warn_slowpath_common+0x8c/0xc0 [ 0.493503] [<ffffffff8104eaa6>] warn_slowpath_fmt+0x46/0x50 [ 0.493588] [<ffffffff8103f1e2>] __ioremap_caller+0x372/0x380 [ 0.493674] [<ffffffff810211a2>] ? snb_uncore_imc_init_box+0x62/0x90 [ 0.493761] [<ffffffff8103f247>] ioremap_nocache+0x17/0x20 [ 0.493846] [<ffffffff810211a2>] snb_uncore_imc_init_box+0x62/0x90 [ 0.493933] [<ffffffff81022925>] uncore_pci_probe+0xe5/0x1e0 [ 0.494020] [<ffffffff812d487e>] local_pci_probe+0x4e/0xa0 [ 0.494104] [<ffffffff81418a59>] ? get_device+0x19/0x20 [ 0.494213] [<ffffffff812d5cd1>] pci_device_probe+0xe1/0x130 [ 0.494300] [<ffffffff8141d3cb>] driver_probe_device+0x7b/0x240 [ 0.494385] [<ffffffff8141d63b>] __driver_attach+0xab/0xb0 [ 0.494469] [<ffffffff8141d590>] ? driver_probe_device+0x240/0x240 [ 0.494551] [<ffffffff8141b71e>] bus_for_each_dev+0x5e/0x90 [ 0.494634] [<ffffffff8141cede>] driver_attach+0x1e/0x20 [ 0.494718] [<ffffffff8141ca57>] bus_add_driver+0x117/0x230 [ 0.494802] [<ffffffff8141dd34>] driver_register+0x64/0xf0 [ 0.494884] [<ffffffff812d4c14>] __pci_register_driver+0x64/0x70 [ 0.494972] [<ffffffff81d0319b>] ? uncore_types_init+0x19c/0x19c [ 0.495056] [<ffffffff81d03312>] intel_uncore_init+0x177/0x41c [ 0.495155] [<ffffffff81d0319b>] ? uncore_types_init+0x19c/0x19c [ 0.495242] [<ffffffff8100029e>] do_one_initcall+0x4e/0x170 [ 0.495326] [<ffffffff81071100>] ? parse_args+0x60/0x360 [ 0.495411] [<ffffffff81cfbfb8>] kernel_init_freeable+0x106/0x19a [ 0.495497] [<ffffffff81cfb83b>] ? do_early_param+0x86/0x86 [ 0.495582] [<ffffffff81607ef0>] ? rest_init+0xd0/0xd0 [ 0.495666] [<ffffffff81607efe>] kernel_init+0xe/0xf0 [ 0.495749] [<ffffffff81621f6c>] ret_from_fork+0x7c/0xb0 [ 0.495831] [<ffffffff81607ef0>] ? rest_init+0xd0/0xd0 [ 0.495921] ---[ end trace 428f365c054d9a01 ]--- [ 0.496196] RAPL PMU detected, hw unit 2^-16 Joules, API unit is 2^-32 Joules, 3 fixed counters 163840 ms ovfl timer [ 0.498598] futex hash table entries: 1024 (order: 5, 131072 bytes) [ 0.498833] audit: initializing netlink subsys (disabled) [ 0.499024] audit: type=2000 audit(1393259866.477:1): initialized ...
Btw,
I don't know whether the following observation is related or not, but it so happens that after resume from suspend-to-disk, I see the booting up of the resume kernel on the console but when it is time for the original kernel to take over and switch to graphics, the screen remains black but the machine is responsive over the network.
And this doesn't happen on every resume but only sporadically.
And yep, -rc3 was fine.
On Mon, Feb 24, 2014 at 05:24:00PM +0100, Borislav Petkov wrote:
This started happening this morning after booting -rc4+tip, let's add *everybody* to CC :-)
We have intel_uncore_init, snb_uncore_imc_init_box, uncore_pci_probe and other goodies on the stack.
... [ 0.488998] software IO TLB [mem 0xcac30000-0xcec30000] (64MB) mapped at [ffff8800cac30000-ffff8800cec2ffff] [ 0.489975] resource map sanity check conflict: 0xfed10000 0xfed15fff 0xfed10000 0xfed13fff pnp 00:01 [ 0.490079] ------------[ cut here ]------------ [ 0.490204] WARNING: CPU: 2 PID: 1 at arch/x86/mm/ioremap.c:171 __ioremap_caller+0x372/0x380() [ 0.490306] Info: mapping multiple BARs. Your kernel is fine. [ 0.490371] Modules linked in: [ 0.490558] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 3.14.0-rc4+ #1 [ 0.490642] Hardware name: LENOVO 2320CTO/2320CTO, BIOS G2ET86WW (2.06 ) 11/13/2012 [ 0.490742] 00000000000000ab ffff880213d01ad8 ffffffff816112e3 0000000000000006 [ 0.491032] ffff880213d01b28 ffff880213d01b18 ffffffff8104e9bc ffff880213d01b08 [ 0.491343] ffffc90000c58000 00000000fed10000 00000000fed10000 0000000000006000 [ 0.491631] Call Trace: [ 0.493337] [<ffffffff816112e3>] dump_stack+0x4f/0x7c [ 0.493420] [<ffffffff8104e9bc>] warn_slowpath_common+0x8c/0xc0 [ 0.493503] [<ffffffff8104eaa6>] warn_slowpath_fmt+0x46/0x50 [ 0.493588] [<ffffffff8103f1e2>] __ioremap_caller+0x372/0x380 [ 0.493674] [<ffffffff810211a2>] ? snb_uncore_imc_init_box+0x62/0x90 [ 0.493761] [<ffffffff8103f247>] ioremap_nocache+0x17/0x20 [ 0.493846] [<ffffffff810211a2>] snb_uncore_imc_init_box+0x62/0x90 [ 0.493933] [<ffffffff81022925>] uncore_pci_probe+0xe5/0x1e0 [ 0.494020] [<ffffffff812d487e>] local_pci_probe+0x4e/0xa0 [ 0.494104] [<ffffffff81418a59>] ? get_device+0x19/0x20 [ 0.494213] [<ffffffff812d5cd1>] pci_device_probe+0xe1/0x130 [ 0.494300] [<ffffffff8141d3cb>] driver_probe_device+0x7b/0x240 [ 0.494385] [<ffffffff8141d63b>] __driver_attach+0xab/0xb0 [ 0.494469] [<ffffffff8141d590>] ? driver_probe_device+0x240/0x240 [ 0.494551] [<ffffffff8141b71e>] bus_for_each_dev+0x5e/0x90 [ 0.494634] [<ffffffff8141cede>] driver_attach+0x1e/0x20 [ 0.494718] [<ffffffff8141ca57>] bus_add_driver+0x117/0x230 [ 0.494802] [<ffffffff8141dd34>] driver_register+0x64/0xf0 [ 0.494884] [<ffffffff812d4c14>] __pci_register_driver+0x64/0x70 [ 0.494972] [<ffffffff81d0319b>] ? uncore_types_init+0x19c/0x19c [ 0.495056] [<ffffffff81d03312>] intel_uncore_init+0x177/0x41c [ 0.495155] [<ffffffff81d0319b>] ? uncore_types_init+0x19c/0x19c [ 0.495242] [<ffffffff8100029e>] do_one_initcall+0x4e/0x170 [ 0.495326] [<ffffffff81071100>] ? parse_args+0x60/0x360 [ 0.495411] [<ffffffff81cfbfb8>] kernel_init_freeable+0x106/0x19a [ 0.495497] [<ffffffff81cfb83b>] ? do_early_param+0x86/0x86 [ 0.495582] [<ffffffff81607ef0>] ? rest_init+0xd0/0xd0 [ 0.495666] [<ffffffff81607efe>] kernel_init+0xe/0xf0 [ 0.495749] [<ffffffff81621f6c>] ret_from_fork+0x7c/0xb0 [ 0.495831] [<ffffffff81607ef0>] ? rest_init+0xd0/0xd0 [ 0.495921] ---[ end trace 428f365c054d9a01 ]--- [ 0.496196] RAPL PMU detected, hw unit 2^-16 Joules, API unit is 2^-32 Joules, 3 fixed counters 163840 ms ovfl timer [ 0.498598] futex hash table entries: 1024 (order: 5, 131072 bytes) [ 0.498833] audit: initializing netlink subsys (disabled) [ 0.499024] audit: type=2000 audit(1393259866.477:1): initialized
On 02/24/2014 12:19 PM, Borislav Petkov wrote:
Btw,
I don't know whether the following observation is related or not, but it so happens that after resume from suspend-to-disk, I see the booting up of the resume kernel on the console but when it is time for the original kernel to take over and switch to graphics, the screen remains black but the machine is responsive over the network.
And this doesn't happen on every resume but only sporadically.
And yep, -rc3 was fine.
On Mon, Feb 24, 2014 at 05:24:00PM +0100, Borislav Petkov wrote:
This started happening this morning after booting -rc4+tip, let's add *everybody* to CC :-)
We have intel_uncore_init, snb_uncore_imc_init_box, uncore_pci_probe and other goodies on the stack.
snb_uncore_imc_init_box() is introduced new in tip:perf/core, and is a relatively recent commit (b9e1ab6d4c0582cad97699285a6b3cf992251b00), so I suspect that that wasn't in whatever -rc3 mix you were testing.
I am wondering if backing/disabling out that support (perhaps by removing the relevant PCI ID) fixes the problem?
-hpa
Hi,
I am trying to understand your test case. Were you actually measure uncore_imc events at the time you suspended?
I tried on my IvyBridge Lenovo and it works fine with 3.14-rc4+ (tip.git). I used: echo -n disk >/sys/power/state
On Tue, Feb 25, 2014 at 4:48 PM, H. Peter Anvin hpa@zytor.com wrote:
On 02/24/2014 12:19 PM, Borislav Petkov wrote:
Btw,
I don't know whether the following observation is related or not, but it so happens that after resume from suspend-to-disk, I see the booting up of the resume kernel on the console but when it is time for the original kernel to take over and switch to graphics, the screen remains black but the machine is responsive over the network.
And this doesn't happen on every resume but only sporadically.
And yep, -rc3 was fine.
On Mon, Feb 24, 2014 at 05:24:00PM +0100, Borislav Petkov wrote:
This started happening this morning after booting -rc4+tip, let's add *everybody* to CC :-)
We have intel_uncore_init, snb_uncore_imc_init_box, uncore_pci_probe and other goodies on the stack.
snb_uncore_imc_init_box() is introduced new in tip:perf/core, and is a relatively recent commit (b9e1ab6d4c0582cad97699285a6b3cf992251b00), so I suspect that that wasn't in whatever -rc3 mix you were testing.
I am wondering if backing/disabling out that support (perhaps by removing the relevant PCI ID) fixes the problem?
-hpa
On Tue, Feb 25, 2014 at 05:14:01PM +0100, Stephane Eranian wrote:
I am trying to understand your test case. Were you actually measure uncore_imc events at the time you suspended?
No test case, just the machine booting; look at the printk timestamps.
I tried on my IvyBridge Lenovo and it works fine with 3.14-rc4+ (tip.git). I used: echo -n disk >/sys/power/state
That's an x230 too, right? What I do is, I take linus/master, merge tip/master, Matt's efi/next tree and my edac/for-next tree into it and then boot that.
I don't think that the edac and efi trees interfere though. I'll do a fresh merge of only current tip/master into linus/master to test hpa's suggestion in the other mail.
Thanks.
On Tue, Feb 25, 2014 at 5:30 PM, Borislav Petkov bp@alien8.de wrote:
On Tue, Feb 25, 2014 at 05:14:01PM +0100, Stephane Eranian wrote:
I am trying to understand your test case. Were you actually measure uncore_imc events at the time you suspended?
No test case, just the machine booting; look at the printk timestamps.
I tried on my IvyBridge Lenovo and it works fine with 3.14-rc4+ (tip.git). I used: echo -n disk >/sys/power/state
That's an x230 too, right? What I do is, I take linus/master, merge tip/master, Matt's efi/next tree and my edac/for-next tree into it and then boot that.
No, it's a T430s. What happens if you boot vanilla tip.git?
I don't think that the edac and efi trees interfere though. I'll do a fresh merge of only current tip/master into linus/master to test hpa's suggestion in the other mail.
Thanks.
-- Regards/Gruss, Boris.
Sent from a fat crate under my desk. Formatting is fine.
On Tue, Feb 25, 2014 at 05:33:13PM +0100, Stephane Eranian wrote:
No, it's a T430s. What happens if you boot vanilla tip.git?
linus/master + tip/master -> fails tip/master -> fails
All trees are from today, like an hour ago or so.
Doing what hpa suggested:
diff --git a/arch/x86/kernel/cpu/perf_event_intel_uncore.c b/arch/x86/kernel/cpu/perf_event_intel_uncore.c index b262c6124cf3..ec217d2d28dd 100644 --- a/arch/x86/kernel/cpu/perf_event_intel_uncore.c +++ b/arch/x86/kernel/cpu/perf_event_intel_uncore.c @@ -3871,6 +3871,7 @@ static int __init uncore_pci_init(void) pci_uncores = snb_pci_uncores; uncore_pci_driver = &snb_uncore_pci_driver; break; +#if 0 case 58: /* Ivy Bridge */ ret = snb_pci2phy_map_init(PCI_DEVICE_ID_INTEL_IVB_IMC); if (ret) @@ -3878,6 +3879,7 @@ static int __init uncore_pci_init(void) pci_uncores = snb_pci_uncores; uncore_pci_driver = &ivb_uncore_pci_driver; break; +#endif case 60: /* Haswell */ case 69: /* Haswell Celeron */ ret = snb_pci2phy_map_init(PCI_DEVICE_ID_INTEL_HSW_IMC);
for model 58, IVB, works around the issue.
Thanks.
On Tue, Feb 25, 2014 at 6:39 PM, Borislav Petkov bp@alien8.de wrote:
On Tue, Feb 25, 2014 at 05:33:13PM +0100, Stephane Eranian wrote:
No, it's a T430s. What happens if you boot vanilla tip.git?
linus/master + tip/master -> fails tip/master -> fails
All trees are from today, like an hour ago or so.
Doing what hpa suggested:
I am on tip.git at cfbf8d4 Linux 3.14-rc4 and I don't see the problem (using Ubuntu Saucy).
Given what you commented out, it seems like you're saying something goes wrong with pci_get_device(). Am I missing some pm callbacks?
The uncore IMC is not used internally.
diff --git a/arch/x86/kernel/cpu/perf_event_intel_uncore.c b/arch/x86/kernel/cpu/perf_event_intel_uncore.c index b262c6124cf3..ec217d2d28dd 100644 --- a/arch/x86/kernel/cpu/perf_event_intel_uncore.c +++ b/arch/x86/kernel/cpu/perf_event_intel_uncore.c @@ -3871,6 +3871,7 @@ static int __init uncore_pci_init(void) pci_uncores = snb_pci_uncores; uncore_pci_driver = &snb_uncore_pci_driver; break; +#if 0 case 58: /* Ivy Bridge */ ret = snb_pci2phy_map_init(PCI_DEVICE_ID_INTEL_IVB_IMC); if (ret) @@ -3878,6 +3879,7 @@ static int __init uncore_pci_init(void) pci_uncores = snb_pci_uncores; uncore_pci_driver = &ivb_uncore_pci_driver; break; +#endif case 60: /* Haswell */ case 69: /* Haswell Celeron */ ret = snb_pci2phy_map_init(PCI_DEVICE_ID_INTEL_HSW_IMC);
for model 58, IVB, works around the issue.
Thanks.
-- Regards/Gruss, Boris.
Sent from a fat crate under my desk. Formatting is fine.
On Tue, Feb 25, 2014 at 07:54:53PM +0100, Stephane Eranian wrote:
I am on tip.git at cfbf8d4 Linux 3.14-rc4. and I don't see the problem (using Ubuntu Saucy).
Also IVB, model 58?
Given what you commented out, it seems like you're saying something goes wrong with pci_get_device().
Probably. I'll add some debug printk's tomorrow to shed some more light on the matter.
Am I missing some pm callbacks?
Dunno. What do you mean by "pm callbacks" exactly? I don't know that code so I have to ask.
The uncore IMC is not used internally.
By IMC I'm assuming this PIC dev:
#define PCI_DEVICE_ID_INTEL_IVB_IMC 0x0154
?
And "internally" means by BIOS or something behind the curtains like SMM...?
Hi,
On Tue, Feb 25, 2014 at 11:10 PM, Borislav Petkov bp@alien8.de wrote:
On Tue, Feb 25, 2014 at 07:54:53PM +0100, Stephane Eranian wrote:
I am on tip.git at cfbf8d4 Linux 3.14-rc4. and I don't see the problem (using Ubuntu Saucy).
Also IVB, model 58?
Yes.
Given what you commented out, it seems like you're saying something goes wrong with pci_get_device().
Probably. I'll add some debug printk's tomorrow to shed some more light on the matter.
Am I missing some pm callbacks?
Dunno. What do you mean by "pm callbacks" exactly? I don't know that code so I have to ask.
power management callbacks.
The uncore IMC is not used internally.
By IMC I'm assuming this PIC dev:
#define PCI_DEVICE_ID_INTEL_IVB_IMC 0x0154
?
Yes. Needs to point to the DRAM controller.
And "internally" means by BIOS or something behind the curtains like SMM...?
I meant by the kernel.
On Wed, Feb 26, 2014 at 07:56:58AM +0100, Stephane Eranian wrote:
Also IVB, model 58?
Yes.
Right, so it must be chipset-specific.
Dunno. What do you mean by "pm callbacks" exactly? I don't know that code so I have to ask.
power management callbacks.
Ok, just as I thought. But why would they be relevant if this happens very early during boot?
#define PCI_DEVICE_ID_INTEL_IVB_IMC 0x0154
Yes. Needs to point to the DRAM controller.
It seems I have it :-)
$ lspci -xxx -s 00.0 00:00.0 Host bridge: Intel Corporation 3rd Gen Core processor DRAM Controller (rev 09) 00: 86 80 54 01 06 00 90 20 09 00 00 06 00 00 00 00 ^^^^^
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 aa 17 fa 21 30: 00 00 00 00 e0 00 00 00 00 00 00 00 00 00 00 00 40: 01 90 d1 fe 00 00 00 00 01 00 d1 fe 00 00 00 00 50: 11 02 00 00 11 00 00 00 07 00 90 df 01 00 00 db 60: 05 00 00 f8 00 00 00 00 01 80 d1 fe 00 00 00 00 70: 00 00 00 fe 01 00 00 00 00 0c 00 fe 7f 00 00 00 80: 10 11 11 11 11 11 11 00 1a 00 00 00 00 00 00 00 90: 01 00 00 fe 01 00 00 00 01 00 50 1e 02 00 00 00 a0: 01 00 00 00 02 00 00 00 01 00 60 1e 02 00 00 00 b0: 01 00 a0 db 01 00 80 db 01 00 00 db 01 00 a0 df c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 09 00 0c 01 9b 61 00 e2 d0 00 e8 76 00 00 00 00 f0: 00 00 00 01 00 00 00 00 c8 0f 09 00 00 00 00 00
Anyway, here's some more debugging output and some more staring:
So we're correctly getting 0x154 and then snb_uncore_imc_init_box() tries to ioremap 0xfed10000 but this fails the resource map check with:
[ 0.485356] resource map sanity check conflict: 0xfed10000 0xfed15fff 0xfed10000 0xfed13fff pnp 00:01
and the pnp 00:01 device already partially occupies that range (from /proc/iomem):
fed10000-fed13fff : pnp 00:01
Oh, and snb_uncore_imc_init_box() gets that address from SNB_UNCORE_PCI_IMC_BAR_OFFSET and SNB_UNCORE_PCI_IMC_BAR_OFFSET+4 and they start at offset 0x48 in the PCI config space above, i.e.
40: 01 90 d1 fe 00 00 00 00 01 00 d1 fe 00 00 00 00 ^^^^^^^^^^^^^^^^^^^^^^^
which is 0x000000fed10001 (the 0x1 bit disappears after addr &= ~(PAGE_SIZE - 1);)
So I'm guessing it is time to talk to platform guys and ask them why they're putting SNB_UNCORE_PCI_IMC_BAR_OFFSET{,+4} in an overlapping range with pnp 00:01.
[ 0.484023] PCI-DMA: Using software bounce buffering for IO (SWIOTLB) [ 0.484108] software IO TLB [mem 0xcac30000-0xcec30000] (64MB) mapped at [ffff8800cac30000-ffff8800cec2ffff] [ 0.484971] DBG: will get device: 0x8086:154 [ 0.485054] DBG: Got device, bus: 0x0 [ 0.485254] DBG: ioremapping addr: 0xfed10000 [ 0.485356] resource map sanity check conflict: 0xfed10000 0xfed15fff 0xfed10000 0xfed13fff pnp 00:01 [ 0.485460] ------------[ cut here ]------------ [ 0.485544] WARNING: CPU: 2 PID: 1 at arch/x86/mm/ioremap.c:171 __ioremap_caller+0x372/0x380() [ 0.485643] Info: mapping multiple BARs. Your kernel is fine. [ 0.485709] Modules linked in: [ 0.485935] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 3.14.0-rc4+ #6 [ 0.486019] Hardware name: LENOVO 2320CTO/2320CTO, BIOS G2ET86WW (2.06 ) 11/13/2012 [ 0.486117] 00000000000000ab ffff880213d01ad8 ffffffff81611339 0000000000000006 [ 0.486411] ffff880213d01b28 ffff880213d01b18 ffffffff8104e9cc ffff880213d01b08 [ 0.488308] ffffc90000c58000 00000000fed10000 00000000fed10000 0000000000006000 [ 0.488595] Call Trace: [ 0.488671] [<ffffffff81611339>] dump_stack+0x4f/0x7c [ 0.488754] [<ffffffff8104e9cc>] warn_slowpath_common+0x8c/0xc0 [ 0.488877] [<ffffffff8104eab6>] warn_slowpath_fmt+0x46/0x50 [ 0.488966] [<ffffffff8103f1f2>] __ioremap_caller+0x372/0x380 [ 0.489052] [<ffffffff810211b6>] ? snb_uncore_imc_init_box+0x76/0xa0 [ 0.489137] [<ffffffff8103f257>] ioremap_nocache+0x17/0x20 [ 0.489221] [<ffffffff810211b6>] snb_uncore_imc_init_box+0x76/0xa0 [ 0.489307] [<ffffffff81022935>] uncore_pci_probe+0xe5/0x1e0 [ 0.489391] [<ffffffff812d488e>] local_pci_probe+0x4e/0xa0 [ 0.489474] [<ffffffff81418a69>] ? get_device+0x19/0x20 [ 0.489558] [<ffffffff812d5ce1>] pci_device_probe+0xe1/0x130 [ 0.489642] [<ffffffff8141d3db>] driver_probe_device+0x7b/0x240 [ 0.489726] [<ffffffff8141d64b>] __driver_attach+0xab/0xb0 [ 0.489834] [<ffffffff8141d5a0>] ? driver_probe_device+0x240/0x240 [ 0.489920] [<ffffffff8141b72e>] bus_for_each_dev+0x5e/0x90 [ 0.490003] [<ffffffff8141ceee>] driver_attach+0x1e/0x20 [ 0.490086] [<ffffffff8141ca67>] bus_add_driver+0x117/0x230 [ 0.490170] [<ffffffff8141dd44>] driver_register+0x64/0xf0 [ 0.490251] [<ffffffff812d4c24>] __pci_register_driver+0x64/0x70 [ 0.490337] [<ffffffff81d0319b>] ? uncore_types_init+0x19c/0x19c [ 0.490421] [<ffffffff81d03331>] intel_uncore_init+0x196/0x462 [ 0.490504] [<ffffffff81d0319b>] ? uncore_types_init+0x19c/0x19c [ 0.490591] [<ffffffff8100029e>] do_one_initcall+0x4e/0x170 [ 0.490676] [<ffffffff81071100>] ? parse_args+0x50/0x360 [ 0.490762] [<ffffffff81cfbfb8>] kernel_init_freeable+0x106/0x19a [ 0.490863] [<ffffffff81cfb83b>] ? do_early_param+0x86/0x86 [ 0.490948] [<ffffffff81607f00>] ? rest_init+0xd0/0xd0 [ 0.491032] [<ffffffff81607f0e>] kernel_init+0xe/0xf0 [ 0.491116] [<ffffffff81621fac>] ret_from_fork+0x7c/0xb0 [ 0.491199] [<ffffffff81607f00>] ? rest_init+0xd0/0xd0 [ 0.491289] ---[ end trace b31a7f760e34b24a ]--- [ 0.491547] RAPL PMU detected, hw unit 2^-16 Joules, API unit is 2^-32 Joules, 3 fixed counters 163840 ms ovfl timer [ 0.493962] futex hash table entries: 1024 (order: 5, 131072 bytes)
Hi,
Ok, so I am getting the same error message as you. I checked my syslog now.
I have my uncore_imc addr=0xfed10000 (after masking)
And I also have pnp 00:01 overlapping the imc range completely.
What pnp device does it really represent? the DRAM controller?
So I think my laptop behaves like yours.
On Wed, Feb 26, 2014 at 10:29 AM, Borislav Petkov bp@alien8.de wrote:
On Wed, Feb 26, 2014 at 07:56:58AM +0100, Stephane Eranian wrote:
Also IVB, model 58?
Yes.
Right, so it must be chipset-specific.
Dunno. What do you mean by "pm callbacks" exactly? I don't know that code so I have to ask.
power management callbacks.
Ok, just as I thought. But why would they be relevant if this happens very early during boot?
#define PCI_DEVICE_ID_INTEL_IVB_IMC 0x0154
Yes. Needs to point to the DRAM controller.
It seems I have it :-)
$ lspci -xxx -s 00.0 00:00.0 Host bridge: Intel Corporation 3rd Gen Core processor DRAM Controller (rev 09) 00: 86 80 54 01 06 00 90 20 09 00 00 06 00 00 00 00 ^^^^^
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 aa 17 fa 21 30: 00 00 00 00 e0 00 00 00 00 00 00 00 00 00 00 00 40: 01 90 d1 fe 00 00 00 00 01 00 d1 fe 00 00 00 00 50: 11 02 00 00 11 00 00 00 07 00 90 df 01 00 00 db 60: 05 00 00 f8 00 00 00 00 01 80 d1 fe 00 00 00 00 70: 00 00 00 fe 01 00 00 00 00 0c 00 fe 7f 00 00 00 80: 10 11 11 11 11 11 11 00 1a 00 00 00 00 00 00 00 90: 01 00 00 fe 01 00 00 00 01 00 50 1e 02 00 00 00 a0: 01 00 00 00 02 00 00 00 01 00 60 1e 02 00 00 00 b0: 01 00 a0 db 01 00 80 db 01 00 00 db 01 00 a0 df c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 09 00 0c 01 9b 61 00 e2 d0 00 e8 76 00 00 00 00 f0: 00 00 00 01 00 00 00 00 c8 0f 09 00 00 00 00 00
Anyway, here's some more debugging output and some more staring:
So we're correctly getting 0x154 and then snb_uncore_imc_init_box() tries to ioremap 0xfed10000 but this fails the resource map check with:
[ 0.485356] resource map sanity check conflict: 0xfed10000 0xfed15fff 0xfed10000 0xfed13fff pnp 00:01
and the pnp 00:01 device already partially occupies that range (from /proc/iomem):
fed10000-fed13fff : pnp 00:01
Oh, and snb_uncore_imc_init_box() gets that address from SNB_UNCORE_PCI_IMC_BAR_OFFSET and SNB_UNCORE_PCI_IMC_BAR_OFFSET+4 and they start at offset 0x48 in the PCI config space above, i.e.
40: 01 90 d1 fe 00 00 00 00 01 00 d1 fe 00 00 00 00 ^^^^^^^^^^^^^^^^^^^^^^^
which is 0x000000fed10001 (the 0x1 bit disappears after addr &= ~(PAGE_SIZE - 1);)
So I'm guessing it is time to talk to platform guys and ask them why they're putting SNB_UNCORE_PCI_IMC_BAR_OFFSET{,+4} in an overlapping range with pnp 00:01.
[ 0.484023] PCI-DMA: Using software bounce buffering for IO (SWIOTLB) [ 0.484108] software IO TLB [mem 0xcac30000-0xcec30000] (64MB) mapped at [ffff8800cac30000-ffff8800cec2ffff] [ 0.484971] DBG: will get device: 0x8086:154 [ 0.485054] DBG: Got device, bus: 0x0 [ 0.485254] DBG: ioremapping addr: 0xfed10000 [ 0.485356] resource map sanity check conflict: 0xfed10000 0xfed15fff 0xfed10000 0xfed13fff pnp 00:01 [ 0.485460] ------------[ cut here ]------------ [ 0.485544] WARNING: CPU: 2 PID: 1 at arch/x86/mm/ioremap.c:171 __ioremap_caller+0x372/0x380() [ 0.485643] Info: mapping multiple BARs. Your kernel is fine. [ 0.485709] Modules linked in: [ 0.485935] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 3.14.0-rc4+ #6 [ 0.486019] Hardware name: LENOVO 2320CTO/2320CTO, BIOS G2ET86WW (2.06 ) 11/13/2012 [ 0.486117] 00000000000000ab ffff880213d01ad8 ffffffff81611339 0000000000000006 [ 0.486411] ffff880213d01b28 ffff880213d01b18 ffffffff8104e9cc ffff880213d01b08 [ 0.488308] ffffc90000c58000 00000000fed10000 00000000fed10000 0000000000006000 [ 0.488595] Call Trace: [ 0.488671] [<ffffffff81611339>] dump_stack+0x4f/0x7c [ 0.488754] [<ffffffff8104e9cc>] warn_slowpath_common+0x8c/0xc0 [ 0.488877] [<ffffffff8104eab6>] warn_slowpath_fmt+0x46/0x50 [ 0.488966] [<ffffffff8103f1f2>] __ioremap_caller+0x372/0x380 [ 0.489052] [<ffffffff810211b6>] ? snb_uncore_imc_init_box+0x76/0xa0 [ 0.489137] [<ffffffff8103f257>] ioremap_nocache+0x17/0x20 [ 0.489221] [<ffffffff810211b6>] snb_uncore_imc_init_box+0x76/0xa0 [ 0.489307] [<ffffffff81022935>] uncore_pci_probe+0xe5/0x1e0 [ 0.489391] [<ffffffff812d488e>] local_pci_probe+0x4e/0xa0 [ 0.489474] [<ffffffff81418a69>] ? get_device+0x19/0x20 [ 0.489558] [<ffffffff812d5ce1>] pci_device_probe+0xe1/0x130 [ 0.489642] [<ffffffff8141d3db>] driver_probe_device+0x7b/0x240 [ 0.489726] [<ffffffff8141d64b>] __driver_attach+0xab/0xb0 [ 0.489834] [<ffffffff8141d5a0>] ? driver_probe_device+0x240/0x240 [ 0.489920] [<ffffffff8141b72e>] bus_for_each_dev+0x5e/0x90 [ 0.490003] [<ffffffff8141ceee>] driver_attach+0x1e/0x20 [ 0.490086] [<ffffffff8141ca67>] bus_add_driver+0x117/0x230 [ 0.490170] [<ffffffff8141dd44>] driver_register+0x64/0xf0 [ 0.490251] [<ffffffff812d4c24>] __pci_register_driver+0x64/0x70 [ 0.490337] [<ffffffff81d0319b>] ? uncore_types_init+0x19c/0x19c [ 0.490421] [<ffffffff81d03331>] intel_uncore_init+0x196/0x462 [ 0.490504] [<ffffffff81d0319b>] ? uncore_types_init+0x19c/0x19c [ 0.490591] [<ffffffff8100029e>] do_one_initcall+0x4e/0x170 [ 0.490676] [<ffffffff81071100>] ? parse_args+0x50/0x360 [ 0.490762] [<ffffffff81cfbfb8>] kernel_init_freeable+0x106/0x19a [ 0.490863] [<ffffffff81cfb83b>] ? do_early_param+0x86/0x86 [ 0.490948] [<ffffffff81607f00>] ? rest_init+0xd0/0xd0 [ 0.491032] [<ffffffff81607f0e>] kernel_init+0xe/0xf0 [ 0.491116] [<ffffffff81621fac>] ret_from_fork+0x7c/0xb0 [ 0.491199] [<ffffffff81607f00>] ? rest_init+0xd0/0xd0 [ 0.491289] ---[ end trace b31a7f760e34b24a ]--- [ 0.491547] RAPL PMU detected, hw unit 2^-16 Joules, API unit is 2^-32 Joules, 3 fixed counters 163840 ms ovfl timer [ 0.493962] futex hash table entries: 1024 (order: 5, 131072 bytes)
-- Regards/Gruss, Boris.
Sent from a fat crate under my desk. Formatting is fine.
Can you please, pretty please, not top-post...
On Wed, Feb 26, 2014 at 10:47:05AM +0100, Stephane Eranian wrote:
Hi,
Ok, so I am getting the same error message as you. I checked my syslog now.
I have my uncore_imc addr=0xfed10000 (after masking)
And I also have pnp 00:01 overlapping the imc range completely.
What pnp device does it really represent? the DRAM controller?
So I think my laptop behaves like yours.
grep -Er . /sys/devices/pnp0/00:01/* 2>/dev/null /sys/devices/pnp0/00:01/firmware_node/hid:PNP0C02 ...
so this PNP0C02 is
[ 0.363943] system 00:01: Plug and Play ACPI device, IDs PNP0c02 (active)
@Rafael, can you please make sense of this whole ACPI gunk?
We have a resource conflict with pnp 00:01, analysis here: http://lkml.kernel.org/r/20140226092903.GA22639@pd.tnic
This is the rest of the 00:01 info from sysfs:
/sys/devices/pnp0/00:01/firmware_node/uid:0 /sys/devices/pnp0/00:01/firmware_node/path:_SB_.PCI0.LPC_.SIO_ /sys/devices/pnp0/00:01/firmware_node/power/control:auto /sys/devices/pnp0/00:01/firmware_node/power/runtime_active_time:0 /sys/devices/pnp0/00:01/firmware_node/power/runtime_status:unsupported /sys/devices/pnp0/00:01/firmware_node/power/runtime_suspended_time:0 /sys/devices/pnp0/00:01/firmware_node/modalias:acpi:PNP0C02: /sys/devices/pnp0/00:01/firmware_node/uevent:MODALIAS=acpi:PNP0C02: /sys/devices/pnp0/00:01/id:PNP0c02 /sys/devices/pnp0/00:01/power/control:auto /sys/devices/pnp0/00:01/power/runtime_active_time:0 /sys/devices/pnp0/00:01/power/runtime_status:unsupported /sys/devices/pnp0/00:01/power/runtime_suspended_time:0 /sys/devices/pnp0/00:01/resources:state = active /sys/devices/pnp0/00:01/resources:io 0x10-0x1f /sys/devices/pnp0/00:01/resources:io 0x90-0x9f /sys/devices/pnp0/00:01/resources:io 0x24-0x25 /sys/devices/pnp0/00:01/resources:io 0x28-0x29 /sys/devices/pnp0/00:01/resources:io 0x2c-0x2d /sys/devices/pnp0/00:01/resources:io 0x30-0x31 /sys/devices/pnp0/00:01/resources:io 0x34-0x35 /sys/devices/pnp0/00:01/resources:io 0x38-0x39 /sys/devices/pnp0/00:01/resources:io 0x3c-0x3d /sys/devices/pnp0/00:01/resources:io 0xa4-0xa5 /sys/devices/pnp0/00:01/resources:io 0xa8-0xa9 /sys/devices/pnp0/00:01/resources:io 0xac-0xad /sys/devices/pnp0/00:01/resources:io 0xb0-0xb5 /sys/devices/pnp0/00:01/resources:io 0xb8-0xb9 /sys/devices/pnp0/00:01/resources:io 0xbc-0xbd /sys/devices/pnp0/00:01/resources:io 0x50-0x53 /sys/devices/pnp0/00:01/resources:io 0x72-0x77 /sys/devices/pnp0/00:01/resources:io 0x400-0x47f /sys/devices/pnp0/00:01/resources:io 0x500-0x57f /sys/devices/pnp0/00:01/resources:io 0x800-0x80f /sys/devices/pnp0/00:01/resources:io 0x15e0-0x15ef /sys/devices/pnp0/00:01/resources:io 0x1600-0x167f /sys/devices/pnp0/00:01/resources:mem 0xf8000000-0xfbffffff /sys/devices/pnp0/00:01/resources:mem 0xfffff000-0xffffffff /sys/devices/pnp0/00:01/resources:mem 0xfed1c000-0xfed1ffff /sys/devices/pnp0/00:01/resources:mem 0xfed10000-0xfed13fff /sys/devices/pnp0/00:01/resources:mem 0xfed18000-0xfed18fff /sys/devices/pnp0/00:01/resources:mem 0xfed19000-0xfed19fff /sys/devices/pnp0/00:01/resources:mem 0xfed45000-0xfed4bfff /sys/devices/pnp0/00:01/resources:mem 0xfed40000-0xfed44fff /sys/devices/pnp0/00:01/subsystem/drivers_autoprobe:1 /sys/devices/pnp0/00:01/uevent:DRIVER=system
On Wed, Feb 26, 2014 at 10:59 AM, Borislav Petkov bp@alien8.de wrote:
Can you please, pretty please, not top-post...
On Wed, Feb 26, 2014 at 10:47:05AM +0100, Stephane Eranian wrote:
Hi,
Ok, so I am getting the same error message as you. I checked my syslog now.
I have my uncore_imc addr=0xfed10000 (after masking)
And I also have pnp 00:01 overlapping the imc range completely.
What pnp device does it really represent? the DRAM controller?
So I think my laptop behaves like yours.
grep -Er . /sys/devices/pnp0/00:01/* 2>/dev/null /sys/devices/pnp0/00:01/firmware_node/hid:PNP0C02 ...
so this PNP0C02 is
[ 0.363943] system 00:01: Plug and Play ACPI device, IDs PNP0c02 (active)
My Lenovo IVB is like yours. But I tried on my SandyBridge desktop and there to BAR is at a completely different address. Same thing on my Haswell desktop system.
As a asides, my SNB and HSW desktops with 3.14-rc4 are totally unstable. They hang if I type make in my kernel tree. Whereas 3.14-rc3 is stable. I am not so sure this is all related to the uncore IMC support, though.
@Rafael, can you please make sense of this whole ACPI gunk?
We have a resource conflict with pnp 00:01, analysis here: http://lkml.kernel.org/r/20140226092903.GA22639@pd.tnic
This is the rest of the 00:01 info from sysfs:
/sys/devices/pnp0/00:01/firmware_node/uid:0 /sys/devices/pnp0/00:01/firmware_node/path:_SB_.PCI0.LPC_.SIO_ /sys/devices/pnp0/00:01/firmware_node/power/control:auto /sys/devices/pnp0/00:01/firmware_node/power/runtime_active_time:0 /sys/devices/pnp0/00:01/firmware_node/power/runtime_status:unsupported /sys/devices/pnp0/00:01/firmware_node/power/runtime_suspended_time:0 /sys/devices/pnp0/00:01/firmware_node/modalias:acpi:PNP0C02: /sys/devices/pnp0/00:01/firmware_node/uevent:MODALIAS=acpi:PNP0C02: /sys/devices/pnp0/00:01/id:PNP0c02 /sys/devices/pnp0/00:01/power/control:auto /sys/devices/pnp0/00:01/power/runtime_active_time:0 /sys/devices/pnp0/00:01/power/runtime_status:unsupported /sys/devices/pnp0/00:01/power/runtime_suspended_time:0 /sys/devices/pnp0/00:01/resources:state = active /sys/devices/pnp0/00:01/resources:io 0x10-0x1f /sys/devices/pnp0/00:01/resources:io 0x90-0x9f /sys/devices/pnp0/00:01/resources:io 0x24-0x25 /sys/devices/pnp0/00:01/resources:io 0x28-0x29 /sys/devices/pnp0/00:01/resources:io 0x2c-0x2d /sys/devices/pnp0/00:01/resources:io 0x30-0x31 /sys/devices/pnp0/00:01/resources:io 0x34-0x35 /sys/devices/pnp0/00:01/resources:io 0x38-0x39 /sys/devices/pnp0/00:01/resources:io 0x3c-0x3d /sys/devices/pnp0/00:01/resources:io 0xa4-0xa5 /sys/devices/pnp0/00:01/resources:io 0xa8-0xa9 /sys/devices/pnp0/00:01/resources:io 0xac-0xad /sys/devices/pnp0/00:01/resources:io 0xb0-0xb5 /sys/devices/pnp0/00:01/resources:io 0xb8-0xb9 /sys/devices/pnp0/00:01/resources:io 0xbc-0xbd /sys/devices/pnp0/00:01/resources:io 0x50-0x53 /sys/devices/pnp0/00:01/resources:io 0x72-0x77 /sys/devices/pnp0/00:01/resources:io 0x400-0x47f /sys/devices/pnp0/00:01/resources:io 0x500-0x57f /sys/devices/pnp0/00:01/resources:io 0x800-0x80f /sys/devices/pnp0/00:01/resources:io 0x15e0-0x15ef /sys/devices/pnp0/00:01/resources:io 0x1600-0x167f /sys/devices/pnp0/00:01/resources:mem 0xf8000000-0xfbffffff /sys/devices/pnp0/00:01/resources:mem 0xfffff000-0xffffffff /sys/devices/pnp0/00:01/resources:mem 0xfed1c000-0xfed1ffff /sys/devices/pnp0/00:01/resources:mem 0xfed10000-0xfed13fff /sys/devices/pnp0/00:01/resources:mem 0xfed18000-0xfed18fff /sys/devices/pnp0/00:01/resources:mem 0xfed19000-0xfed19fff /sys/devices/pnp0/00:01/resources:mem 0xfed45000-0xfed4bfff /sys/devices/pnp0/00:01/resources:mem 0xfed40000-0xfed44fff /sys/devices/pnp0/00:01/subsystem/drivers_autoprobe:1 /sys/devices/pnp0/00:01/uevent:DRIVER=system
-- Regards/Gruss, Boris.
Sent from a fat crate under my desk. Formatting is fine.
On Thu, Feb 27, 2014 at 11:12:32AM +0100, Stephane Eranian wrote:
My Lenovo IVB is like yours. But I tried on my SandyBridge desktop and there to BAR is at a completely different address. Same thing on my Haswell desktop system.
Hrrm, I'd like to see what Rafael finds out, whether what we're reading from PCI config space is even sane.
As a asides, my SNB and HSW desktops with 3.14-rc4 are totally unstable. They hang if I type make in my kernel tree. Whereas 3.14-rc3 is stable. I am not so sure this is all related to the uncore IMC support, though.
Easy to test - just disable the uncore thing.
On Thursday, February 27, 2014 11:27:22 AM Borislav Petkov wrote:
On Thu, Feb 27, 2014 at 11:12:32AM +0100, Stephane Eranian wrote:
My Lenovo IVB is like yours. But I tried on my SandyBridge desktop and there to BAR is at a completely different address. Same thing on my Haswell desktop system.
Hrrm, I'd like to see what Rafael finds out, whether what we're reading from PCI config space is even sane.
I won't be able to look at that before Monday I'm afraid (personal stuff).
Rafael
On Thu, Feb 27, 2014 at 11:12:17PM +0100, Rafael J. Wysocki wrote:
I won't be able to look at that before Monday I'm afraid (personal stuff).
No worries, sir, whenever. It can wait.
Thanks a lot!
Hi,
Any update on this problem?
On Thu, Feb 27, 2014 at 11:21 PM, Borislav Petkov bp@alien8.de wrote:
On Thu, Feb 27, 2014 at 11:12:17PM +0100, Rafael J. Wysocki wrote:
I won't be able to look at that before Monday I'm afraid (personal stuff).
No worries, sir, whenever. It can wait.
Thanks a lot!
-- Regards/Gruss, Boris.
Sent from a fat crate under my desk. Formatting is fine.
On Thu, Feb 27, 2014 at 11:12:32AM +0100, Stephane Eranian wrote:
As a asides, my SNB and HSW desktops with 3.14-rc4 are totally unstable. They hang if I type make in my kernel tree. Whereas 3.14-rc3 is stable. I am not so sure this is all related to the uncore IMC support, though.
Unstable with 3.14-rc4-tip you mean? Yeah, there's a rather crucial patch missing. I'll try and get Thomas to merge it if Ingo doesn't show up soon.
On Thu, Feb 27, 2014 at 11:30 AM, Peter Zijlstra peterz@infradead.org wrote:
On Thu, Feb 27, 2014 at 11:12:32AM +0100, Stephane Eranian wrote:
As a asides, my SNB and HSW desktops with 3.14-rc4 are totally unstable. They hang if I type make in my kernel tree. Whereas 3.14-rc3 is stable. I am not so sure this is all related to the uncore IMC support, though.
Unstable with 3.14-rc4-tip you mean? Yeah, there's a rather crucial patch missing. I'll try and get Thomas to merge it if Ingo doesn't show up soon.
Yes, I mean from tip.git.
On Thu, Feb 27, 2014 at 11:32:58AM +0100, Stephane Eranian wrote:
On Thu, Feb 27, 2014 at 11:30 AM, Peter Zijlstra peterz@infradead.org wrote:
On Thu, Feb 27, 2014 at 11:12:32AM +0100, Stephane Eranian wrote:
As a asides, my SNB and HSW desktops with 3.14-rc4 are totally unstable. They hang if I type make in my kernel tree. Whereas 3.14-rc3 is stable. I am not so sure this is all related to the uncore IMC support, though.
Unstable with 3.14-rc4-tip you mean? Yeah, there's a rather crucial patch missing. I'll try and get Thomas to merge it if Ingo doesn't show up soon.
Yes, I mean from tip.git.
lkml.kernel.org/r/20140224121218.GR15586@twins.programming.kicks-ass.net
Should cure things; unless there's more borkage.
On Thu, Feb 27, 2014 at 12:08 PM, Peter Zijlstra peterz@infradead.org wrote:
On Thu, Feb 27, 2014 at 11:32:58AM +0100, Stephane Eranian wrote:
On Thu, Feb 27, 2014 at 11:30 AM, Peter Zijlstra peterz@infradead.org wrote:
On Thu, Feb 27, 2014 at 11:12:32AM +0100, Stephane Eranian wrote:
As a asides, my SNB and HSW desktops with 3.14-rc4 are totally unstable. They hang if I type make in my kernel tree. Whereas 3.14-rc3 is stable. I am not so sure this is all related to the uncore IMC support, though.
Unstable with 3.14-rc4-tip you mean? Yeah, there's a rather crucial patch missing. I'll try and get Thomas to merge it if Ingo doesn't show up soon.
Yes, I mean from tip.git.
lkml.kernel.org/r/20140224121218.GR15586@twins.programming.kicks-ass.net
Should cure things; unless there's more borkage.
Works again now with your patch. Thanks.
On Monday, February 24, 2014 05:24:00 PM Borislav Petkov wrote:
This started happening this morning after booting -rc4+tip, let's add *everybody* to CC :-)
What about -rc4 without tip?
We have intel_uncore_init, snb_uncore_imc_init_box, uncore_pci_probe and other goodies on the stack.
... [ 0.488998] software IO TLB [mem 0xcac30000-0xcec30000] (64MB) mapped at [ffff8800cac30000-ffff8800cec2ffff] [ 0.489975] resource map sanity check conflict: 0xfed10000 0xfed15fff 0xfed10000 0xfed13fff pnp 00:01 [ 0.490079] ------------[ cut here ]------------ [ 0.490204] WARNING: CPU: 2 PID: 1 at arch/x86/mm/ioremap.c:171 __ioremap_caller+0x372/0x380() [ 0.490306] Info: mapping multiple BARs. Your kernel is fine. [ 0.490371] Modules linked in: [ 0.490558] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 3.14.0-rc4+ #1 [ 0.490642] Hardware name: LENOVO 2320CTO/2320CTO, BIOS G2ET86WW (2.06 ) 11/13/2012 [ 0.490742] 00000000000000ab ffff880213d01ad8 ffffffff816112e3 0000000000000006 [ 0.491032] ffff880213d01b28 ffff880213d01b18 ffffffff8104e9bc ffff880213d01b08 [ 0.491343] ffffc90000c58000 00000000fed10000 00000000fed10000 0000000000006000 [ 0.491631] Call Trace: [ 0.493337] [<ffffffff816112e3>] dump_stack+0x4f/0x7c [ 0.493420] [<ffffffff8104e9bc>] warn_slowpath_common+0x8c/0xc0 [ 0.493503] [<ffffffff8104eaa6>] warn_slowpath_fmt+0x46/0x50 [ 0.493588] [<ffffffff8103f1e2>] __ioremap_caller+0x372/0x380 [ 0.493674] [<ffffffff810211a2>] ? snb_uncore_imc_init_box+0x62/0x90 [ 0.493761] [<ffffffff8103f247>] ioremap_nocache+0x17/0x20 [ 0.493846] [<ffffffff810211a2>] snb_uncore_imc_init_box+0x62/0x90 [ 0.493933] [<ffffffff81022925>] uncore_pci_probe+0xe5/0x1e0 [ 0.494020] [<ffffffff812d487e>] local_pci_probe+0x4e/0xa0 [ 0.494104] [<ffffffff81418a59>] ? get_device+0x19/0x20 [ 0.494213] [<ffffffff812d5cd1>] pci_device_probe+0xe1/0x130 [ 0.494300] [<ffffffff8141d3cb>] driver_probe_device+0x7b/0x240 [ 0.494385] [<ffffffff8141d63b>] __driver_attach+0xab/0xb0 [ 0.494469] [<ffffffff8141d590>] ? driver_probe_device+0x240/0x240 [ 0.494551] [<ffffffff8141b71e>] bus_for_each_dev+0x5e/0x90 [ 0.494634] [<ffffffff8141cede>] driver_attach+0x1e/0x20 [ 0.494718] [<ffffffff8141ca57>] bus_add_driver+0x117/0x230 [ 0.494802] [<ffffffff8141dd34>] driver_register+0x64/0xf0 [ 0.494884] [<ffffffff812d4c14>] __pci_register_driver+0x64/0x70 [ 0.494972] [<ffffffff81d0319b>] ? uncore_types_init+0x19c/0x19c [ 0.495056] [<ffffffff81d03312>] intel_uncore_init+0x177/0x41c [ 0.495155] [<ffffffff81d0319b>] ? uncore_types_init+0x19c/0x19c [ 0.495242] [<ffffffff8100029e>] do_one_initcall+0x4e/0x170 [ 0.495326] [<ffffffff81071100>] ? parse_args+0x60/0x360 [ 0.495411] [<ffffffff81cfbfb8>] kernel_init_freeable+0x106/0x19a [ 0.495497] [<ffffffff81cfb83b>] ? do_early_param+0x86/0x86 [ 0.495582] [<ffffffff81607ef0>] ? rest_init+0xd0/0xd0 [ 0.495666] [<ffffffff81607efe>] kernel_init+0xe/0xf0 [ 0.495749] [<ffffffff81621f6c>] ret_from_fork+0x7c/0xb0 [ 0.495831] [<ffffffff81607ef0>] ? rest_init+0xd0/0xd0 [ 0.495921] ---[ end trace 428f365c054d9a01 ]--- [ 0.496196] RAPL PMU detected, hw unit 2^-16 Joules, API unit is 2^-32 Joules, 3 fixed counters 163840 ms ovfl timer [ 0.498598] futex hash table entries: 1024 (order: 5, 131072 bytes) [ 0.498833] audit: initializing netlink subsys (disabled) [ 0.499024] audit: type=2000 audit(1393259866.477:1): initialized ...
On Wed, Feb 26, 2014 at 02:57:16PM +0100, Rafael J. Wysocki wrote:
On Monday, February 24, 2014 05:24:00 PM Borislav Petkov wrote:
This started happening this morning after booting -rc4+tip, let's add *everybody* to CC :-)
What about -rc4 without tip?
The driver causing this is new and lives in -tip.
On Wed, Feb 26, 2014 at 02:57:16PM +0100, Rafael J. Wysocki wrote:
On Monday, February 24, 2014 05:24:00 PM Borislav Petkov wrote:
This started happening this morning after booting -rc4+tip, let's add *everybody* to CC :-)
What about -rc4 without tip?
I don't think so because
commit b9e1ab6d4c0582cad97699285a6b3cf992251b00 Author: Stephane Eranian eranian@google.com Date: Tue Feb 11 16:20:12 2014 +0100
perf/x86/uncore: add SNB/IVB/HSW client uncore memory controller support
in -tip introduces that snb_uncore_imc_init_box() thing which causes the ioremap conflict.
Btw, see my last email on this thread for more details about what I'm seeing here.
dri-devel@lists.freedesktop.org
-
Borislav Petkov -
H. Peter Anvin -
Peter Zijlstra -
Rafael J. Wysocki -
Stephane Eranian