| Message ID | 20140225173946.GH24636@pd.tnic (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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 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 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. > --
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);
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: for model 58, IVB, works around the issue. Thanks.