Info: mapping multiple BARs. Your kernel is fine.

Info: mapping multiple BARs. Your kernel is fine.

[Borislav Petkov]

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
...

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

Re: Info: mapping multiple BARs. Your kernel is fine.

[Borislav Petkov]

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

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

Re: Info: mapping multiple BARs. Your kernel is fine.

[H. Peter Anvin]

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

Re: Info: mapping multiple BARs. Your kernel is fine.

[Stephane Eranian]

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
>

Re: Info: mapping multiple BARs. Your kernel is fine.

[Borislav Petkov]

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.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

Re: Info: mapping multiple BARs. Your kernel is fine.

[Stephane Eranian]

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.
> --

Re: Info: mapping multiple BARs. Your kernel is fine.

[Borislav Petkov]

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.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

Re: Info: mapping multiple BARs. Your kernel is fine.

[Stephane Eranian]

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.
> --

Re: Info: mapping multiple BARs. Your kernel is fine.

[Borislav Petkov]

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...?

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

Re: Info: mapping multiple BARs. Your kernel is fine.

[Stephane Eranian]

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.

Re: Info: mapping multiple BARs. Your kernel is fine.

[Borislav Petkov]

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.
--

Re: Info: mapping multiple BARs. Your kernel is fine.

[Stephane Eranian]

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.
> --

Re: Info: mapping multiple BARs. Your kernel is fine.

[Borislav Petkov]

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

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

Re: Info: mapping multiple BARs. Your kernel is fine.

[Peter Zijlstra]

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.

Re: Info: mapping multiple BARs. Your kernel is fine.

[Borislav Petkov]

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.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

Re: Info: mapping multiple BARs. Your kernel is fine.

[Rafael J. Wysocki]

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
> ...
> 
> 

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: Info: mapping multiple BARs. Your kernel is fine.

[Stephane Eranian]

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.
> --

Re: Info: mapping multiple BARs. Your kernel is fine.

[Borislav Petkov]

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.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

Re: Info: mapping multiple BARs. Your kernel is fine.

[Peter Zijlstra]

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.

Re: Info: mapping multiple BARs. Your kernel is fine.

[Stephane Eranian]

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.

Re: Info: mapping multiple BARs. Your kernel is fine.

[Peter Zijlstra]

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.

Re: Info: mapping multiple BARs. Your kernel is fine.

[Stephane Eranian]

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.

Re: Info: mapping multiple BARs. Your kernel is fine.

[Rafael J. Wysocki]

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

Re: Info: mapping multiple BARs. Your kernel is fine.

[Borislav Petkov]

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.
--

Re: Info: mapping multiple BARs. Your kernel is fine.

[Stephane Eranian]

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.
> --