* Info: mapping multiple BARs. Your kernel is fine. @ 2014-02-24 16:24 ` Borislav Petkov 0 siblings, 0 replies; 84+ messages in thread From: Borislav Petkov @ 2014-02-24 16:24 UTC (permalink / raw) To: lkml Cc: Peter Zijlstra, Paul Mackerras, Arnaldo Carvalho de Melo, x86, Daniel Vetter, Jani Nikula, David Airlie, intel-gfx, dri-devel 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. -- ^ permalink raw reply [flat|nested] 84+ messages in thread
* Info: mapping multiple BARs. Your kernel is fine. @ 2014-02-24 16:24 ` Borislav Petkov 0 siblings, 0 replies; 84+ messages in thread From: Borislav Petkov @ 2014-02-24 16:24 UTC (permalink / raw) To: lkml Cc: Peter Zijlstra, Daniel Vetter, intel-gfx, x86, Paul Mackerras, dri-devel, Arnaldo Carvalho de Melo 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. -- ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. 2014-02-24 16:24 ` Borislav Petkov @ 2014-02-24 20:19 ` Borislav Petkov -1 siblings, 0 replies; 84+ messages in thread From: Borislav Petkov @ 2014-02-24 20:19 UTC (permalink / raw) To: lkml Cc: Peter Zijlstra, Paul Mackerras, Arnaldo Carvalho de Melo, x86, Daniel Vetter, Jani Nikula, David Airlie, intel-gfx, dri-devel, Jiri Kosina 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. -- ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. @ 2014-02-24 20:19 ` Borislav Petkov 0 siblings, 0 replies; 84+ messages in thread From: Borislav Petkov @ 2014-02-24 20:19 UTC (permalink / raw) To: lkml Cc: Peter Zijlstra, Daniel Vetter, intel-gfx, x86, Paul Mackerras, dri-devel, Arnaldo Carvalho de Melo, Jiri Kosina 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. -- ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. 2014-02-24 20:19 ` Borislav Petkov (?) @ 2014-02-25 15:48 ` H. Peter Anvin 2014-02-25 16:14 ` Stephane Eranian -1 siblings, 1 reply; 84+ messages in thread From: H. Peter Anvin @ 2014-02-25 15:48 UTC (permalink / raw) To: Borislav Petkov, lkml Cc: Peter Zijlstra, Paul Mackerras, Arnaldo Carvalho de Melo, x86, Daniel Vetter, Jani Nikula, David Airlie, intel-gfx, dri-devel, Jiri Kosina, Stephane Eranian 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 ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. 2014-02-25 15:48 ` H. Peter Anvin @ 2014-02-25 16:14 ` Stephane Eranian 2014-02-25 16:30 ` Borislav Petkov 0 siblings, 1 reply; 84+ messages in thread From: Stephane Eranian @ 2014-02-25 16:14 UTC (permalink / raw) To: H. Peter Anvin Cc: Borislav Petkov, lkml, Peter Zijlstra, Paul Mackerras, Arnaldo Carvalho de Melo, x86, Daniel Vetter, Jani Nikula, David Airlie, intel-gfx, dri-devel, Jiri Kosina 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 > ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. 2014-02-25 16:14 ` Stephane Eranian @ 2014-02-25 16:30 ` Borislav Petkov 0 siblings, 0 replies; 84+ messages in thread From: Borislav Petkov @ 2014-02-25 16:30 UTC (permalink / raw) To: Stephane Eranian Cc: H. Peter Anvin, lkml, Peter Zijlstra, Paul Mackerras, Arnaldo Carvalho de Melo, x86, Daniel Vetter, Jani Nikula, David Airlie, intel-gfx, dri-devel, Jiri Kosina 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. -- ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. @ 2014-02-25 16:30 ` Borislav Petkov 0 siblings, 0 replies; 84+ messages in thread From: Borislav Petkov @ 2014-02-25 16:30 UTC (permalink / raw) To: Stephane Eranian Cc: Peter Zijlstra, Jiri Kosina, Daniel Vetter, intel-gfx, x86, lkml, Paul Mackerras, dri-devel, Arnaldo Carvalho de Melo, H. Peter Anvin 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. -- ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. 2014-02-25 16:30 ` Borislav Petkov (?) @ 2014-02-25 16:33 ` Stephane Eranian 2014-02-25 17:39 ` Borislav Petkov -1 siblings, 1 reply; 84+ messages in thread From: Stephane Eranian @ 2014-02-25 16:33 UTC (permalink / raw) To: Borislav Petkov Cc: H. Peter Anvin, lkml, Peter Zijlstra, Paul Mackerras, Arnaldo Carvalho de Melo, x86, Daniel Vetter, Jani Nikula, David Airlie, intel-gfx, dri-devel, Jiri Kosina 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. > -- ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. 2014-02-25 16:33 ` Stephane Eranian @ 2014-02-25 17:39 ` Borislav Petkov 0 siblings, 0 replies; 84+ messages in thread From: Borislav Petkov @ 2014-02-25 17:39 UTC (permalink / raw) To: Stephane Eranian Cc: H. Peter Anvin, lkml, Peter Zijlstra, Paul Mackerras, Arnaldo Carvalho de Melo, x86, Daniel Vetter, Jani Nikula, David Airlie, intel-gfx, dri-devel, Jiri Kosina 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. -- ^ permalink raw reply related [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. @ 2014-02-25 17:39 ` Borislav Petkov 0 siblings, 0 replies; 84+ messages in thread From: Borislav Petkov @ 2014-02-25 17:39 UTC (permalink / raw) To: Stephane Eranian Cc: Peter Zijlstra, Jiri Kosina, David Airlie, Daniel Vetter, intel-gfx, x86, lkml, Paul Mackerras, dri-devel, Arnaldo Carvalho de Melo, H. Peter Anvin 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. -- ^ permalink raw reply related [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. 2014-02-25 17:39 ` Borislav Petkov (?) @ 2014-02-25 18:54 ` Stephane Eranian 2014-02-25 22:10 ` Borislav Petkov -1 siblings, 1 reply; 84+ messages in thread From: Stephane Eranian @ 2014-02-25 18:54 UTC (permalink / raw) To: Borislav Petkov Cc: H. Peter Anvin, lkml, Peter Zijlstra, Paul Mackerras, Arnaldo Carvalho de Melo, x86, Daniel Vetter, Jani Nikula, David Airlie, intel-gfx, dri-devel, Jiri Kosina 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. > -- ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. 2014-02-25 18:54 ` Stephane Eranian @ 2014-02-25 22:10 ` Borislav Petkov 0 siblings, 0 replies; 84+ messages in thread From: Borislav Petkov @ 2014-02-25 22:10 UTC (permalink / raw) To: Stephane Eranian Cc: H. Peter Anvin, lkml, Peter Zijlstra, Paul Mackerras, Arnaldo Carvalho de Melo, x86, Daniel Vetter, Jani Nikula, David Airlie, intel-gfx, dri-devel, Jiri Kosina 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. -- ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. @ 2014-02-25 22:10 ` Borislav Petkov 0 siblings, 0 replies; 84+ messages in thread From: Borislav Petkov @ 2014-02-25 22:10 UTC (permalink / raw) To: Stephane Eranian Cc: Peter Zijlstra, Jiri Kosina, David Airlie, Daniel Vetter, intel-gfx, x86, lkml, Paul Mackerras, dri-devel, Arnaldo Carvalho de Melo, H. Peter Anvin 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. -- ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. 2014-02-25 22:10 ` Borislav Petkov (?) @ 2014-02-26 6:56 ` Stephane Eranian 2014-02-26 9:29 ` Borislav Petkov -1 siblings, 1 reply; 84+ messages in thread From: Stephane Eranian @ 2014-02-26 6:56 UTC (permalink / raw) To: Borislav Petkov Cc: H. Peter Anvin, lkml, Peter Zijlstra, Paul Mackerras, Arnaldo Carvalho de Melo, x86, Daniel Vetter, Jani Nikula, David Airlie, intel-gfx, dri-devel, Jiri Kosina 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. ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. 2014-02-26 6:56 ` Stephane Eranian @ 2014-02-26 9:29 ` Borislav Petkov 0 siblings, 0 replies; 84+ messages in thread From: Borislav Petkov @ 2014-02-26 9:29 UTC (permalink / raw) To: Stephane Eranian Cc: H. Peter Anvin, lkml, Peter Zijlstra, Paul Mackerras, Arnaldo Carvalho de Melo, x86, Daniel Vetter, Jani Nikula, David Airlie, intel-gfx, dri-devel, Jiri Kosina 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. -- ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. @ 2014-02-26 9:29 ` Borislav Petkov 0 siblings, 0 replies; 84+ messages in thread From: Borislav Petkov @ 2014-02-26 9:29 UTC (permalink / raw) To: Stephane Eranian Cc: Peter Zijlstra, Jiri Kosina, David Airlie, Daniel Vetter, intel-gfx, x86, lkml, Paul Mackerras, dri-devel, Arnaldo Carvalho de Melo, H. Peter Anvin 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. -- ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. 2014-02-26 9:29 ` Borislav Petkov (?) @ 2014-02-26 9:47 ` Stephane Eranian 2014-02-26 9:59 ` Borislav Petkov -1 siblings, 1 reply; 84+ messages in thread From: Stephane Eranian @ 2014-02-26 9:47 UTC (permalink / raw) To: Borislav Petkov Cc: H. Peter Anvin, lkml, Peter Zijlstra, Paul Mackerras, Arnaldo Carvalho de Melo, x86, Daniel Vetter, Jani Nikula, David Airlie, intel-gfx, dri-devel, Jiri Kosina 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. > -- ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. 2014-02-26 9:47 ` Stephane Eranian @ 2014-02-26 9:59 ` Borislav Petkov 0 siblings, 0 replies; 84+ messages in thread From: Borislav Petkov @ 2014-02-26 9:59 UTC (permalink / raw) To: Stephane Eranian, Rafael J. Wysocki Cc: H. Peter Anvin, lkml, Peter Zijlstra, Paul Mackerras, Arnaldo Carvalho de Melo, x86, Daniel Vetter, Jani Nikula, David Airlie, intel-gfx, dri-devel, Jiri Kosina 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. -- ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. @ 2014-02-26 9:59 ` Borislav Petkov 0 siblings, 0 replies; 84+ messages in thread From: Borislav Petkov @ 2014-02-26 9:59 UTC (permalink / raw) To: Stephane Eranian, Rafael J. Wysocki Cc: Peter Zijlstra, Jiri Kosina, David Airlie, Daniel Vetter, intel-gfx, x86, lkml, Paul Mackerras, dri-devel, Arnaldo Carvalho de Melo, H. Peter Anvin 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. -- ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. 2014-02-26 9:59 ` Borislav Petkov (?) @ 2014-02-27 10:12 ` Stephane Eranian 2014-02-27 10:27 ` Borislav Petkov 2014-02-27 10:30 ` Peter Zijlstra -1 siblings, 2 replies; 84+ messages in thread From: Stephane Eranian @ 2014-02-27 10:12 UTC (permalink / raw) To: Borislav Petkov Cc: Rafael J. Wysocki, H. Peter Anvin, lkml, Peter Zijlstra, Paul Mackerras, Arnaldo Carvalho de Melo, x86, Daniel Vetter, Jani Nikula, David Airlie, intel-gfx, dri-devel, Jiri Kosina 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. > -- ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. 2014-02-27 10:12 ` Stephane Eranian @ 2014-02-27 10:27 ` Borislav Petkov 2014-02-27 10:30 ` Peter Zijlstra 1 sibling, 0 replies; 84+ messages in thread From: Borislav Petkov @ 2014-02-27 10:27 UTC (permalink / raw) To: Stephane Eranian Cc: Rafael J. Wysocki, H. Peter Anvin, lkml, Peter Zijlstra, Paul Mackerras, Arnaldo Carvalho de Melo, x86, Daniel Vetter, Jani Nikula, David Airlie, intel-gfx, dri-devel, Jiri Kosina 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. -- ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. @ 2014-02-27 10:27 ` Borislav Petkov 0 siblings, 0 replies; 84+ messages in thread From: Borislav Petkov @ 2014-02-27 10:27 UTC (permalink / raw) To: Stephane Eranian Cc: Peter Zijlstra, Jiri Kosina, Daniel Vetter, intel-gfx, x86, Rafael J. Wysocki, lkml, Paul Mackerras, dri-devel, Arnaldo Carvalho de Melo, H. Peter Anvin 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. -- ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. 2014-02-27 10:27 ` Borislav Petkov @ 2014-02-27 22:12 ` Rafael J. Wysocki -1 siblings, 0 replies; 84+ messages in thread From: Rafael J. Wysocki @ 2014-02-27 22:12 UTC (permalink / raw) To: Borislav Petkov Cc: Stephane Eranian, H. Peter Anvin, lkml, Peter Zijlstra, Paul Mackerras, Arnaldo Carvalho de Melo, x86, Daniel Vetter, Jani Nikula, David Airlie, intel-gfx, dri-devel, Jiri Kosina 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 ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. @ 2014-02-27 22:12 ` Rafael J. Wysocki 0 siblings, 0 replies; 84+ messages in thread From: Rafael J. Wysocki @ 2014-02-27 22:12 UTC (permalink / raw) To: Borislav Petkov Cc: dri-devel, Peter Zijlstra, Jiri Kosina, David Airlie, Daniel Vetter, intel-gfx, x86, lkml, Stephane Eranian, Paul Mackerras, Arnaldo Carvalho de Melo, H. Peter Anvin 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 ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. 2014-02-27 22:12 ` Rafael J. Wysocki @ 2014-02-27 22:21 ` Borislav Petkov -1 siblings, 0 replies; 84+ messages in thread From: Borislav Petkov @ 2014-02-27 22:21 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Stephane Eranian, H. Peter Anvin, lkml, Peter Zijlstra, Paul Mackerras, Arnaldo Carvalho de Melo, x86, Daniel Vetter, Jani Nikula, David Airlie, intel-gfx, dri-devel, Jiri Kosina 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. -- ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. @ 2014-02-27 22:21 ` Borislav Petkov 0 siblings, 0 replies; 84+ messages in thread From: Borislav Petkov @ 2014-02-27 22:21 UTC (permalink / raw) To: Rafael J. Wysocki Cc: dri-devel, Peter Zijlstra, Jiri Kosina, David Airlie, Daniel Vetter, intel-gfx, x86, lkml, Stephane Eranian, Paul Mackerras, Arnaldo Carvalho de Melo, H. Peter Anvin 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. -- ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. 2014-02-27 22:21 ` Borislav Petkov @ 2014-03-05 21:03 ` Stephane Eranian -1 siblings, 0 replies; 84+ messages in thread From: Stephane Eranian @ 2014-03-05 21:03 UTC (permalink / raw) To: Borislav Petkov Cc: Rafael J. Wysocki, H. Peter Anvin, lkml, Peter Zijlstra, Paul Mackerras, Arnaldo Carvalho de Melo, x86, Daniel Vetter, Jani Nikula, David Airlie, intel-gfx, dri-devel, Jiri Kosina 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. > -- ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. @ 2014-03-05 21:03 ` Stephane Eranian 0 siblings, 0 replies; 84+ messages in thread From: Stephane Eranian @ 2014-03-05 21:03 UTC (permalink / raw) To: Borislav Petkov Cc: Peter Zijlstra, Jiri Kosina, David Airlie, Daniel Vetter, intel-gfx, x86, Rafael J. Wysocki, lkml, Paul Mackerras, dri-devel, Arnaldo Carvalho de Melo, H. Peter Anvin 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. > -- ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. 2014-02-27 10:12 ` Stephane Eranian @ 2014-02-27 10:30 ` Peter Zijlstra 2014-02-27 10:30 ` Peter Zijlstra 1 sibling, 0 replies; 84+ messages in thread From: Peter Zijlstra @ 2014-02-27 10:30 UTC (permalink / raw) To: Stephane Eranian Cc: Borislav Petkov, Rafael J. Wysocki, H. Peter Anvin, lkml, Paul Mackerras, Arnaldo Carvalho de Melo, x86, Daniel Vetter, Jani Nikula, David Airlie, intel-gfx, dri-devel, Jiri Kosina 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. ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. @ 2014-02-27 10:30 ` Peter Zijlstra 0 siblings, 0 replies; 84+ messages in thread From: Peter Zijlstra @ 2014-02-27 10:30 UTC (permalink / raw) To: Stephane Eranian Cc: Jiri Kosina, David Airlie, Daniel Vetter, intel-gfx, x86, Rafael J. Wysocki, lkml, Borislav Petkov, dri-devel, Arnaldo Carvalho de Melo, H. Peter Anvin, Paul Mackerras 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. ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. 2014-02-27 10:30 ` Peter Zijlstra (?) @ 2014-02-27 10:32 ` Stephane Eranian 2014-02-27 11:08 ` Peter Zijlstra -1 siblings, 1 reply; 84+ messages in thread From: Stephane Eranian @ 2014-02-27 10:32 UTC (permalink / raw) To: Peter Zijlstra Cc: Borislav Petkov, Rafael J. Wysocki, H. Peter Anvin, lkml, Paul Mackerras, Arnaldo Carvalho de Melo, x86, Daniel Vetter, Jani Nikula, David Airlie, intel-gfx, dri-devel, Jiri Kosina 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. ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. 2014-02-27 10:32 ` Stephane Eranian @ 2014-02-27 11:08 ` Peter Zijlstra 0 siblings, 0 replies; 84+ messages in thread From: Peter Zijlstra @ 2014-02-27 11:08 UTC (permalink / raw) To: Stephane Eranian Cc: Borislav Petkov, Rafael J. Wysocki, H. Peter Anvin, lkml, Paul Mackerras, Arnaldo Carvalho de Melo, x86, Daniel Vetter, Jani Nikula, David Airlie, intel-gfx, dri-devel, Jiri Kosina 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. ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. @ 2014-02-27 11:08 ` Peter Zijlstra 0 siblings, 0 replies; 84+ messages in thread From: Peter Zijlstra @ 2014-02-27 11:08 UTC (permalink / raw) To: Stephane Eranian Cc: Jiri Kosina, David Airlie, Daniel Vetter, intel-gfx, x86, Rafael J. Wysocki, lkml, Borislav Petkov, dri-devel, Arnaldo Carvalho de Melo, H. Peter Anvin, Paul Mackerras 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. ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. 2014-02-27 11:08 ` Peter Zijlstra (?) @ 2014-02-27 12:20 ` Stephane Eranian -1 siblings, 0 replies; 84+ messages in thread From: Stephane Eranian @ 2014-02-27 12:20 UTC (permalink / raw) To: Peter Zijlstra Cc: Borislav Petkov, Rafael J. Wysocki, H. Peter Anvin, lkml, Paul Mackerras, Arnaldo Carvalho de Melo, x86, Daniel Vetter, Jani Nikula, David Airlie, intel-gfx, dri-devel, Jiri Kosina 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. ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. 2014-02-24 16:24 ` Borislav Petkov @ 2014-02-26 13:57 ` Rafael J. Wysocki -1 siblings, 0 replies; 84+ messages in thread From: Rafael J. Wysocki @ 2014-02-26 13:57 UTC (permalink / raw) To: Borislav Petkov Cc: lkml, Peter Zijlstra, Paul Mackerras, Arnaldo Carvalho de Melo, x86, Daniel Vetter, Jani Nikula, David Airlie, intel-gfx, dri-devel 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. ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. @ 2014-02-26 13:57 ` Rafael J. Wysocki 0 siblings, 0 replies; 84+ messages in thread From: Rafael J. Wysocki @ 2014-02-26 13:57 UTC (permalink / raw) To: Borislav Petkov Cc: Peter Zijlstra, David Airlie, Daniel Vetter, intel-gfx, x86, lkml, Paul Mackerras, dri-devel, Arnaldo Carvalho de Melo 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. ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. 2014-02-26 13:57 ` Rafael J. Wysocki @ 2014-02-26 13:50 ` Peter Zijlstra -1 siblings, 0 replies; 84+ messages in thread From: Peter Zijlstra @ 2014-02-26 13:50 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Borislav Petkov, lkml, Paul Mackerras, Arnaldo Carvalho de Melo, x86, Daniel Vetter, Jani Nikula, David Airlie, intel-gfx, dri-devel 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. ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. @ 2014-02-26 13:50 ` Peter Zijlstra 0 siblings, 0 replies; 84+ messages in thread From: Peter Zijlstra @ 2014-02-26 13:50 UTC (permalink / raw) To: Rafael J. Wysocki Cc: David Airlie, Daniel Vetter, intel-gfx, x86, lkml, Paul Mackerras, dri-devel, Arnaldo Carvalho de Melo, 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? The driver causing this is new and lives in -tip. ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. 2014-02-26 13:57 ` Rafael J. Wysocki @ 2014-02-26 13:52 ` Borislav Petkov -1 siblings, 0 replies; 84+ messages in thread From: Borislav Petkov @ 2014-02-26 13:52 UTC (permalink / raw) To: Rafael J. Wysocki Cc: lkml, Peter Zijlstra, Paul Mackerras, Arnaldo Carvalho de Melo, x86, Daniel Vetter, Jani Nikula, David Airlie, intel-gfx, dri-devel 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. -- ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. @ 2014-02-26 13:52 ` Borislav Petkov 0 siblings, 0 replies; 84+ messages in thread From: Borislav Petkov @ 2014-02-26 13:52 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Peter Zijlstra, David Airlie, Daniel Vetter, intel-gfx, x86, lkml, Paul Mackerras, dri-devel, Arnaldo Carvalho de Melo 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. -- ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. 2014-02-24 16:24 ` Borislav Petkov ` (2 preceding siblings ...) (?) @ 2014-03-15 14:15 ` Rafael J. Wysocki 2014-03-16 11:55 ` Borislav Petkov 2014-03-20 2:24 ` Aaron Lu -1 siblings, 2 replies; 84+ messages in thread From: Rafael J. Wysocki @ 2014-03-15 14:15 UTC (permalink / raw) To: Borislav Petkov Cc: lkml, x86, Bjorn Helgaas, Linux PCI, ACPI Devel Maling List, Zhang Rui, Yinghai Lu, H. Peter Anvin, Stephane Eranian [CC list rearranged] 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 :-) > > We have intel_uncore_init, snb_uncore_imc_init_box, uncore_pci_probe and > other goodies on the stack. I've just gone throught this. So the problem is that we have the PNP "system" driver whose only purpose seems to be to reserve system resources so that the PCI layer doesn't assign them to new devices on hotplug (disclaimer: I didn't invent it, I only read the code and comments in there). It does that for ACPI device objects having the "PNP0C02" and "PNP0C01" IDs. Apparently, snb_uncore_imc_init_box() steps on a range already reserved by that driver on your box. And this doesn't seem to be a coincidence, because the ACPI device object in question probably *does* correspond to the memory controller that the uncore driver attempts to use. I'm not sure how to address that right now to be honest. Arguably, the PNP "system" driver should be replaced with something saner, but still the resources it claims need to be kept out of reach of the PCI's resource allocation code. > ... > [ 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. ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. 2014-03-15 14:15 ` Rafael J. Wysocki @ 2014-03-16 11:55 ` Borislav Petkov 2014-03-16 13:08 ` Stephane Eranian 2014-03-20 2:24 ` Aaron Lu 1 sibling, 1 reply; 84+ messages in thread From: Borislav Petkov @ 2014-03-16 11:55 UTC (permalink / raw) To: Rafael J. Wysocki Cc: lkml, x86, Bjorn Helgaas, Linux PCI, ACPI Devel Maling List, Zhang Rui, Yinghai Lu, H. Peter Anvin, Stephane Eranian On Sat, Mar 15, 2014 at 03:15:04PM +0100, Rafael J. Wysocki wrote: > I've just gone throught this. Thanks. > So the problem is that we have the PNP "system" driver whose only purpose seems > to be to reserve system resources so that the PCI layer doesn't assign them to > new devices on hotplug (disclaimer: I didn't invent it, I only read the code and > comments in there). > > It does that for ACPI device objects having the "PNP0C02" and "PNP0C01" IDs. Right, pnp 00:01 is PNP0C02. > Apparently, snb_uncore_imc_init_box() steps on a range already reserved by that > driver on your box. And this doesn't seem to be a coincidence, because the ACPI > device object in question probably *does* correspond to the memory controller > that the uncore driver attempts to use. > > I'm not sure how to address that right now to be honest. Arguably, the PNP > "system" driver should be replaced with something saner, but still the > resources it claims need to be kept out of reach of the PCI's resource > allocation code. Well, I'm only conjecturing here but there should be a way for the uncore code to tell the PNP "system" driver to free this resource because uncore is going to use it now. Or something to that effect. Oh well. ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. 2014-03-16 11:55 ` Borislav Petkov @ 2014-03-16 13:08 ` Stephane Eranian 2014-03-17 0:09 ` Rafael J. Wysocki 0 siblings, 1 reply; 84+ messages in thread From: Stephane Eranian @ 2014-03-16 13:08 UTC (permalink / raw) To: Borislav Petkov Cc: Rafael J. Wysocki, lkml, x86, Bjorn Helgaas, Linux PCI, ACPI Devel Maling List, Zhang Rui, Yinghai Lu, H. Peter Anvin Rafael, Thanks for the analysis. On Sun, Mar 16, 2014 at 12:55 PM, Borislav Petkov <bp@alien8.de> wrote: > On Sat, Mar 15, 2014 at 03:15:04PM +0100, Rafael J. Wysocki wrote: >> I've just gone throught this. > > Thanks. > >> So the problem is that we have the PNP "system" driver whose only purpose seems >> to be to reserve system resources so that the PCI layer doesn't assign them to >> new devices on hotplug (disclaimer: I didn't invent it, I only read the code and >> comments in there). >> >> It does that for ACPI device objects having the "PNP0C02" and "PNP0C01" IDs. > > Right, pnp 00:01 is PNP0C02. > >> Apparently, snb_uncore_imc_init_box() steps on a range already reserved by that >> driver on your box. And this doesn't seem to be a coincidence, because the ACPI >> device object in question probably *does* correspond to the memory controller >> that the uncore driver attempts to use. >> >> I'm not sure how to address that right now to be honest. Arguably, the PNP >> "system" driver should be replaced with something saner, but still the >> resources it claims need to be kept out of reach of the PCI's resource >> allocation code. > > Well, I'm only conjecturing here but there should be a way for the > uncore code to tell the PNP "system" driver to free this resource > because uncore is going to use it now. Or something to that effect. > I agree. The snb_uncore_imc() is making real (good) use of the device. It needs to own it. So we need a way to free the resource from the PNP system or a way to tell PNP need to grab it on systems with the snb_uncore_imc() support. Does that kind of API exist? Where do I look to prevent PNP from grabbing the IMC? ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. 2014-03-16 13:08 ` Stephane Eranian @ 2014-03-17 0:09 ` Rafael J. Wysocki 2014-03-17 0:23 ` Rafael J. Wysocki 0 siblings, 1 reply; 84+ messages in thread From: Rafael J. Wysocki @ 2014-03-17 0:09 UTC (permalink / raw) To: Stephane Eranian Cc: Borislav Petkov, lkml, x86, Bjorn Helgaas, Linux PCI, ACPI Devel Maling List, Zhang Rui, Yinghai Lu, H. Peter Anvin On Sunday, March 16, 2014 02:08:16 PM Stephane Eranian wrote: > Rafael, > > Thanks for the analysis. > > On Sun, Mar 16, 2014 at 12:55 PM, Borislav Petkov <bp@alien8.de> wrote: > > On Sat, Mar 15, 2014 at 03:15:04PM +0100, Rafael J. Wysocki wrote: > >> I've just gone throught this. > > > > Thanks. > > > >> So the problem is that we have the PNP "system" driver whose only purpose seems > >> to be to reserve system resources so that the PCI layer doesn't assign them to > >> new devices on hotplug (disclaimer: I didn't invent it, I only read the code and > >> comments in there). > >> > >> It does that for ACPI device objects having the "PNP0C02" and "PNP0C01" IDs. > > > > Right, pnp 00:01 is PNP0C02. > > > >> Apparently, snb_uncore_imc_init_box() steps on a range already reserved by that > >> driver on your box. And this doesn't seem to be a coincidence, because the ACPI > >> device object in question probably *does* correspond to the memory controller > >> that the uncore driver attempts to use. > >> > >> I'm not sure how to address that right now to be honest. Arguably, the PNP > >> "system" driver should be replaced with something saner, but still the > >> resources it claims need to be kept out of reach of the PCI's resource > >> allocation code. > > > > Well, I'm only conjecturing here but there should be a way for the > > uncore code to tell the PNP "system" driver to free this resource > > because uncore is going to use it now. Or something to that effect. > > > I agree. The snb_uncore_imc() is making real (good) use of the device. > It needs to own it. So we need a way to free the resource from the PNP > system or a way to tell PNP need to grab it on systems with the > snb_uncore_imc() support. Does that kind of API exist? > > Where do I look to prevent PNP from grabbing the IMC? drivers/pnp/system.c is the driver in question and system_pnp_probe() makes the reservations via reserve_resources_of_dev(), so you'd need to modify that. I'm not sure what's the right way to go here, though. -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. 2014-03-17 0:09 ` Rafael J. Wysocki @ 2014-03-17 0:23 ` Rafael J. Wysocki 0 siblings, 0 replies; 84+ messages in thread From: Rafael J. Wysocki @ 2014-03-17 0:23 UTC (permalink / raw) To: Borislav Petkov Cc: Stephane Eranian, lkml, x86, Bjorn Helgaas, Linux PCI, ACPI Devel Maling List, Zhang Rui, Yinghai Lu, H. Peter Anvin On Monday, March 17, 2014 01:09:39 AM Rafael J. Wysocki wrote: > On Sunday, March 16, 2014 02:08:16 PM Stephane Eranian wrote: > > Rafael, > > > > Thanks for the analysis. > > > > On Sun, Mar 16, 2014 at 12:55 PM, Borislav Petkov <bp@alien8.de> wrote: > > > On Sat, Mar 15, 2014 at 03:15:04PM +0100, Rafael J. Wysocki wrote: > > >> I've just gone throught this. > > > > > > Thanks. > > > > > >> So the problem is that we have the PNP "system" driver whose only purpose seems > > >> to be to reserve system resources so that the PCI layer doesn't assign them to > > >> new devices on hotplug (disclaimer: I didn't invent it, I only read the code and > > >> comments in there). > > >> > > >> It does that for ACPI device objects having the "PNP0C02" and "PNP0C01" IDs. > > > > > > Right, pnp 00:01 is PNP0C02. > > > > > >> Apparently, snb_uncore_imc_init_box() steps on a range already reserved by that > > >> driver on your box. And this doesn't seem to be a coincidence, because the ACPI > > >> device object in question probably *does* correspond to the memory controller > > >> that the uncore driver attempts to use. > > >> > > >> I'm not sure how to address that right now to be honest. Arguably, the PNP > > >> "system" driver should be replaced with something saner, but still the > > >> resources it claims need to be kept out of reach of the PCI's resource > > >> allocation code. > > > > > > Well, I'm only conjecturing here but there should be a way for the > > > uncore code to tell the PNP "system" driver to free this resource > > > because uncore is going to use it now. Or something to that effect. > > > > > I agree. The snb_uncore_imc() is making real (good) use of the device. > > It needs to own it. So we need a way to free the resource from the PNP > > system or a way to tell PNP need to grab it on systems with the > > snb_uncore_imc() support. Does that kind of API exist? > > > > Where do I look to prevent PNP from grabbing the IMC? > > drivers/pnp/system.c is the driver in question and system_pnp_probe() makes > the reservations via reserve_resources_of_dev(), so you'd need to modify that. > > I'm not sure what's the right way to go here, though. Boris, can you please sent the acpidump output from that machine? -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. 2014-03-15 14:15 ` Rafael J. Wysocki 2014-03-16 11:55 ` Borislav Petkov @ 2014-03-20 2:24 ` Aaron Lu 2014-03-20 2:29 ` Stephane Eranian 2014-03-20 3:03 ` Zhang, Rui 1 sibling, 2 replies; 84+ messages in thread From: Aaron Lu @ 2014-03-20 2:24 UTC (permalink / raw) To: Rafael J. Wysocki, Borislav Petkov Cc: lkml, x86, Bjorn Helgaas, Linux PCI, ACPI Devel Maling List, Zhang Rui, Yinghai Lu, H. Peter Anvin, Stephane Eranian On 03/15/2014 10:15 PM, Rafael J. Wysocki wrote: > [CC list rearranged] > > 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 :-) >> >> We have intel_uncore_init, snb_uncore_imc_init_box, uncore_pci_probe and >> other goodies on the stack. > > I've just gone throught this. > > So the problem is that we have the PNP "system" driver whose only purpose seems > to be to reserve system resources so that the PCI layer doesn't assign them to > new devices on hotplug (disclaimer: I didn't invent it, I only read the code and > comments in there). And to PCI devices which have uninitialized BARs. > > It does that for ACPI device objects having the "PNP0C02" and "PNP0C01" IDs. > > Apparently, snb_uncore_imc_init_box() steps on a range already reserved by that > driver on your box. And this doesn't seem to be a coincidence, because the ACPI > device object in question probably *does* correspond to the memory controller > that the uncore driver attempts to use. > > I'm not sure how to address that right now to be honest. Arguably, the PNP > "system" driver should be replaced with something saner, but still the > resources it claims need to be kept out of reach of the PCI's resource > allocation code. The quirk_system_pci_resources is meant to disable PNP devices' resource if they collide with any known PCI device's BAR. I'm not sure why it doesn't work here, perhaps the uncore PCI device doesn't have a BAR that falls in the PNP device's resource window? Thanks, Aaron > >> ... >> [ 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 >> ... >> >> > ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. 2014-03-20 2:24 ` Aaron Lu @ 2014-03-20 2:29 ` Stephane Eranian 2014-03-20 3:03 ` Zhang, Rui 1 sibling, 0 replies; 84+ messages in thread From: Stephane Eranian @ 2014-03-20 2:29 UTC (permalink / raw) To: Aaron Lu Cc: Rafael J. Wysocki, Borislav Petkov, lkml, x86, Bjorn Helgaas, Linux PCI, ACPI Devel Maling List, Zhang Rui, Yinghai Lu, H. Peter Anvin On Thu, Mar 20, 2014 at 3:24 AM, Aaron Lu <aaron.lu@intel.com> wrote: > On 03/15/2014 10:15 PM, Rafael J. Wysocki wrote: >> [CC list rearranged] >> >> 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 :-) >>> >>> We have intel_uncore_init, snb_uncore_imc_init_box, uncore_pci_probe and >>> other goodies on the stack. >> >> I've just gone throught this. >> >> So the problem is that we have the PNP "system" driver whose only purpose seems >> to be to reserve system resources so that the PCI layer doesn't assign them to >> new devices on hotplug (disclaimer: I didn't invent it, I only read the code and >> comments in there). > > And to PCI devices which have uninitialized BARs. > >> >> It does that for ACPI device objects having the "PNP0C02" and "PNP0C01" IDs. >> >> Apparently, snb_uncore_imc_init_box() steps on a range already reserved by that >> driver on your box. And this doesn't seem to be a coincidence, because the ACPI >> device object in question probably *does* correspond to the memory controller >> that the uncore driver attempts to use. >> >> I'm not sure how to address that right now to be honest. Arguably, the PNP >> "system" driver should be replaced with something saner, but still the >> resources it claims need to be kept out of reach of the PCI's resource >> allocation code. > > The quirk_system_pci_resources is meant to disable PNP devices' resource if > they collide with any known PCI device's BAR. I'm not sure why it doesn't work > here, perhaps the uncore PCI device doesn't have a BAR that falls in the PNP > device's resource window? > Another hypothesis I am exploring with Bjorn is that the BIOS does not advertise this correctly or that this BAR has non-standard size or behavior. So far, we have observed the collision only on Lenovo IvyBridge laptops. I have tried on my desktop SNB, IVB, HSW machines and never saw the assertion. > Thanks, > Aaron > >> >>> ... >>> [ 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 >>> ... >>> >>> >> > ^ permalink raw reply [flat|nested] 84+ messages in thread
* RE: Info: mapping multiple BARs. Your kernel is fine. 2014-03-20 2:24 ` Aaron Lu 2014-03-20 2:29 ` Stephane Eranian @ 2014-03-20 3:03 ` Zhang, Rui 1 sibling, 0 replies; 84+ messages in thread From: Zhang, Rui @ 2014-03-20 3:03 UTC (permalink / raw) To: Lu, Aaron, Rafael J. Wysocki, Borislav Petkov Cc: lkml, x86, Bjorn Helgaas, Linux PCI, ACPI Devel Maling List, Yinghai Lu, H. Peter Anvin, Stephane Eranian, Yan, Zheng Z > -----Original Message----- > From: Lu, Aaron > Sent: Thursday, March 20, 2014 10:24 AM > To: Rafael J. Wysocki; Borislav Petkov > Cc: lkml; x86@kernel.org; Bjorn Helgaas; Linux PCI; ACPI Devel Maling > List; Zhang, Rui; Yinghai Lu; H. Peter Anvin; Stephane Eranian > Subject: Re: Info: mapping multiple BARs. Your kernel is fine. > Importance: High > > On 03/15/2014 10:15 PM, Rafael J. Wysocki wrote: > > [CC list rearranged] > > > > 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 :-) > >> > >> We have intel_uncore_init, snb_uncore_imc_init_box, uncore_pci_probe > >> and other goodies on the stack. > > > > I've just gone throught this. > > > > So the problem is that we have the PNP "system" driver whose only > > purpose seems to be to reserve system resources so that the PCI layer > > doesn't assign them to new devices on hotplug (disclaimer: I didn't > > invent it, I only read the code and comments in there). > > And to PCI devices which have uninitialized BARs. > > > > > It does that for ACPI device objects having the "PNP0C02" and > "PNP0C01" IDs. > > > > Apparently, snb_uncore_imc_init_box() steps on a range already > > reserved by that driver on your box. And this doesn't seem to be a > > coincidence, because the ACPI device object in question probably > > *does* correspond to the memory controller that the uncore driver > attempts to use. > > > > I'm not sure how to address that right now to be honest. Arguably, > > the PNP "system" driver should be replaced with something saner, but > > still the resources it claims need to be kept out of reach of the > > PCI's resource allocation code. > > The quirk_system_pci_resources is meant to disable PNP devices' > resource if they collide with any known PCI device's BAR. I'm not sure > why it doesn't work here, perhaps the uncore PCI device doesn't have a > BAR that falls in the PNP device's resource window? > I've talked with Yan Zheng, and I was told that this resource "0xfed10000 - 0xfed15fff" is got from PCI device register directly, which is not in its BAR range. Thus IMO, it is impossible for PNP layer to be aware of this resource. BTW, about drivers/pnp/system.c, if its ONLY purpose is to prevent those resources from being allocated to uninitialized PCI devices, then IMO, the best way to do this is make PCI bus handle those PNP0C01/PNP0C02 resources directly, probably via a platform callback, say, 1. make drivers/pnp/system.c a no-op for PNPACPI, by checking pnp_dev->protocol. 2. introduce acpi_check_reserved_resource() to parsing PNP0C01/PNP0C02 resources. 3. in PCI bus, invoke acpi_check_reserved_resource() when assigning resources to PCI devices. Thanks, rui > Thanks, > Aaron > > > > >> ... > >> [ 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 > >> ... > >> > >> > > ^ permalink raw reply [flat|nested] 84+ messages in thread
* RE: Info: mapping multiple BARs. Your kernel is fine. @ 2014-03-20 3:03 ` Zhang, Rui 0 siblings, 0 replies; 84+ messages in thread From: Zhang, Rui @ 2014-03-20 3:03 UTC (permalink / raw) To: Lu, Aaron, Rafael J. Wysocki, Borislav Petkov Cc: lkml, x86, Bjorn Helgaas, Linux PCI, ACPI Devel Maling List, Yinghai Lu, H. Peter Anvin, Stephane Eranian, Yan, Zheng Z DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTHUsIEFhcm9uDQo+IFNl bnQ6IFRodXJzZGF5LCBNYXJjaCAyMCwgMjAxNCAxMDoyNCBBTQ0KPiBUbzogUmFmYWVsIEouIFd5 c29ja2k7IEJvcmlzbGF2IFBldGtvdg0KPiBDYzogbGttbDsgeDg2QGtlcm5lbC5vcmc7IEJqb3Ju IEhlbGdhYXM7IExpbnV4IFBDSTsgQUNQSSBEZXZlbCBNYWxpbmcNCj4gTGlzdDsgWmhhbmcsIFJ1 aTsgWWluZ2hhaSBMdTsgSC4gUGV0ZXIgQW52aW47IFN0ZXBoYW5lIEVyYW5pYW4NCj4gU3ViamVj dDogUmU6IEluZm86IG1hcHBpbmcgbXVsdGlwbGUgQkFScy4gWW91ciBrZXJuZWwgaXMgZmluZS4N Cj4gSW1wb3J0YW5jZTogSGlnaA0KPiANCj4gT24gMDMvMTUvMjAxNCAxMDoxNSBQTSwgUmFmYWVs IEouIFd5c29ja2kgd3JvdGU6DQo+ID4gW0NDIGxpc3QgcmVhcnJhbmdlZF0NCj4gPg0KPiA+IE9u IE1vbmRheSwgRmVicnVhcnkgMjQsIDIwMTQgMDU6MjQ6MDAgUE0gQm9yaXNsYXYgUGV0a292IHdy b3RlOg0KPiA+PiBUaGlzIHN0YXJ0ZWQgaGFwcGVuaW5nIHRoaXMgbW9ybmluZyBhZnRlciBib290 aW5nIC1yYzQrdGlwLCBsZXQncw0KPiBhZGQNCj4gPj4gKmV2ZXJ5Ym9keSogdG8gQ0MgOi0pDQo+ ID4+DQo+ID4+IFdlIGhhdmUgaW50ZWxfdW5jb3JlX2luaXQsIHNuYl91bmNvcmVfaW1jX2luaXRf Ym94LCB1bmNvcmVfcGNpX3Byb2JlDQo+ID4+IGFuZCBvdGhlciBnb29kaWVzIG9uIHRoZSBzdGFj ay4NCj4gPg0KPiA+IEkndmUganVzdCBnb25lIHRocm91Z2h0IHRoaXMuDQo+ID4NCj4gPiBTbyB0 aGUgcHJvYmxlbSBpcyB0aGF0IHdlIGhhdmUgdGhlIFBOUCAic3lzdGVtIiBkcml2ZXIgd2hvc2Ug b25seQ0KPiA+IHB1cnBvc2Ugc2VlbXMgdG8gYmUgdG8gcmVzZXJ2ZSBzeXN0ZW0gcmVzb3VyY2Vz IHNvIHRoYXQgdGhlIFBDSSBsYXllcg0KPiA+IGRvZXNuJ3QgYXNzaWduIHRoZW0gdG8gbmV3IGRl dmljZXMgb24gaG90cGx1ZyAoZGlzY2xhaW1lcjogSSBkaWRuJ3QNCj4gPiBpbnZlbnQgaXQsIEkg b25seSByZWFkIHRoZSBjb2RlIGFuZCBjb21tZW50cyBpbiB0aGVyZSkuDQo+IA0KPiBBbmQgdG8g UENJIGRldmljZXMgd2hpY2ggaGF2ZSB1bmluaXRpYWxpemVkIEJBUnMuDQo+IA0KPiA+DQo+ID4g SXQgZG9lcyB0aGF0IGZvciBBQ1BJIGRldmljZSBvYmplY3RzIGhhdmluZyB0aGUgIlBOUDBDMDIi IGFuZA0KPiAiUE5QMEMwMSIgSURzLg0KPiA+DQo+ID4gQXBwYXJlbnRseSwgc25iX3VuY29yZV9p bWNfaW5pdF9ib3goKSBzdGVwcyBvbiBhIHJhbmdlIGFscmVhZHkNCj4gPiByZXNlcnZlZCBieSB0 aGF0IGRyaXZlciBvbiB5b3VyIGJveC4gIEFuZCB0aGlzIGRvZXNuJ3Qgc2VlbSB0byBiZSBhDQo+ ID4gY29pbmNpZGVuY2UsIGJlY2F1c2UgdGhlIEFDUEkgZGV2aWNlIG9iamVjdCBpbiBxdWVzdGlv biBwcm9iYWJseQ0KPiA+ICpkb2VzKiBjb3JyZXNwb25kIHRvIHRoZSBtZW1vcnkgY29udHJvbGxl ciB0aGF0IHRoZSB1bmNvcmUgZHJpdmVyDQo+IGF0dGVtcHRzIHRvIHVzZS4NCj4gPg0KPiA+IEkn bSBub3Qgc3VyZSBob3cgdG8gYWRkcmVzcyB0aGF0IHJpZ2h0IG5vdyB0byBiZSBob25lc3QuICBB cmd1YWJseSwNCj4gPiB0aGUgUE5QICJzeXN0ZW0iIGRyaXZlciBzaG91bGQgYmUgcmVwbGFjZWQg d2l0aCBzb21ldGhpbmcgc2FuZXIsIGJ1dA0KPiA+IHN0aWxsIHRoZSByZXNvdXJjZXMgaXQgY2xh aW1zIG5lZWQgdG8gYmUga2VwdCBvdXQgb2YgcmVhY2ggb2YgdGhlDQo+ID4gUENJJ3MgcmVzb3Vy Y2UgYWxsb2NhdGlvbiBjb2RlLg0KPiANCj4gVGhlIHF1aXJrX3N5c3RlbV9wY2lfcmVzb3VyY2Vz IGlzIG1lYW50IHRvIGRpc2FibGUgUE5QIGRldmljZXMnDQo+IHJlc291cmNlIGlmIHRoZXkgY29s bGlkZSB3aXRoIGFueSBrbm93biBQQ0kgZGV2aWNlJ3MgQkFSLiBJJ20gbm90IHN1cmUNCj4gd2h5 IGl0IGRvZXNuJ3Qgd29yayBoZXJlLCBwZXJoYXBzIHRoZSB1bmNvcmUgUENJIGRldmljZSBkb2Vz bid0IGhhdmUgYQ0KPiBCQVIgdGhhdCBmYWxscyBpbiB0aGUgUE5QIGRldmljZSdzIHJlc291cmNl IHdpbmRvdz8NCj4NCkkndmUgdGFsa2VkIHdpdGggWWFuIFpoZW5nLCBhbmQgSSB3YXMgdG9sZCB0 aGF0IHRoaXMgcmVzb3VyY2UgIjB4ZmVkMTAwMDAgLSAweGZlZDE1ZmZmIg0KaXMgZ290IGZyb20g UENJIGRldmljZSByZWdpc3RlciBkaXJlY3RseSwgd2hpY2ggaXMgbm90IGluIGl0cyBCQVIgcmFu Z2UuDQpUaHVzIElNTywgaXQgaXMgaW1wb3NzaWJsZSBmb3IgUE5QIGxheWVyIHRvIGJlIGF3YXJl IG9mIHRoaXMgcmVzb3VyY2UuDQoNCkJUVywgYWJvdXQgZHJpdmVycy9wbnAvc3lzdGVtLmMsIGlm IGl0cyBPTkxZIHB1cnBvc2UgaXMgdG8gcHJldmVudCB0aG9zZQ0KcmVzb3VyY2VzIGZyb20gYmVp bmcgYWxsb2NhdGVkIHRvIHVuaW5pdGlhbGl6ZWQgUENJIGRldmljZXMsIHRoZW4gSU1PLA0KdGhl IGJlc3Qgd2F5IHRvIGRvIHRoaXMgaXMgbWFrZSBQQ0kgYnVzIGhhbmRsZSB0aG9zZSBQTlAwQzAx L1BOUDBDMDINCnJlc291cmNlcyBkaXJlY3RseSwgcHJvYmFibHkgdmlhIGEgcGxhdGZvcm0gY2Fs bGJhY2ssIHNheSwNCjEuIG1ha2UgZHJpdmVycy9wbnAvc3lzdGVtLmMgYSBuby1vcCBmb3IgUE5Q QUNQSSwgYnkgY2hlY2tpbmcgcG5wX2Rldi0+cHJvdG9jb2wuDQoyLiBpbnRyb2R1Y2UgYWNwaV9j aGVja19yZXNlcnZlZF9yZXNvdXJjZSgpIHRvIHBhcnNpbmcgUE5QMEMwMS9QTlAwQzAyIHJlc291 cmNlcy4NCjMuIGluIFBDSSBidXMsIGludm9rZSBhY3BpX2NoZWNrX3Jlc2VydmVkX3Jlc291cmNl KCkgd2hlbiBhc3NpZ25pbmcNCiAgIHJlc291cmNlcyB0byBQQ0kgZGV2aWNlcy4NCg0KVGhhbmtz LA0KcnVpDQogDQo+IFRoYW5rcywNCj4gQWFyb24NCj4gDQo+ID4NCj4gPj4gLi4uDQo+ID4+IFsg ICAgMC40ODg5OThdIHNvZnR3YXJlIElPIFRMQiBbbWVtIDB4Y2FjMzAwMDAtMHhjZWMzMDAwMF0g KDY0TUIpDQo+IG1hcHBlZCBhdCBbZmZmZjg4MDBjYWMzMDAwMC1mZmZmODgwMGNlYzJmZmZmXQ0K PiA+PiBbICAgIDAuNDg5OTc1XSByZXNvdXJjZSBtYXAgc2FuaXR5IGNoZWNrIGNvbmZsaWN0OiAw eGZlZDEwMDAwDQo+IDB4ZmVkMTVmZmYgMHhmZWQxMDAwMCAweGZlZDEzZmZmIHBucCAwMDowMQ0K PiA+PiBbICAgIDAuNDkwMDc5XSAtLS0tLS0tLS0tLS1bIGN1dCBoZXJlIF0tLS0tLS0tLS0tLS0N Cj4gPj4gWyAgICAwLjQ5MDIwNF0gV0FSTklORzogQ1BVOiAyIFBJRDogMSBhdCBhcmNoL3g4Ni9t bS9pb3JlbWFwLmM6MTcxDQo+IF9faW9yZW1hcF9jYWxsZXIrMHgzNzIvMHgzODAoKQ0KPiA+PiBb ICAgIDAuNDkwMzA2XSBJbmZvOiBtYXBwaW5nIG11bHRpcGxlIEJBUnMuIFlvdXIga2VybmVsIGlz IGZpbmUuDQo+ID4+IFsgICAgMC40OTAzNzFdIE1vZHVsZXMgbGlua2VkIGluOg0KPiA+PiBbICAg IDAuNDkwNTU4XSBDUFU6IDIgUElEOiAxIENvbW06IHN3YXBwZXIvMCBOb3QgdGFpbnRlZCAzLjE0 LjAtcmM0Kw0KPiAjMQ0KPiA+PiBbICAgIDAuNDkwNjQyXSBIYXJkd2FyZSBuYW1lOiBMRU5PVk8g MjMyMENUTy8yMzIwQ1RPLCBCSU9TIEcyRVQ4NldXDQo+ICgyLjA2ICkgMTEvMTMvMjAxMg0KPiA+ PiBbICAgIDAuNDkwNzQyXSAgMDAwMDAwMDAwMDAwMDBhYiBmZmZmODgwMjEzZDAxYWQ4IGZmZmZm ZmZmODE2MTEyZTMNCj4gMDAwMDAwMDAwMDAwMDAwNg0KPiA+PiBbICAgIDAuNDkxMDMyXSAgZmZm Zjg4MDIxM2QwMWIyOCBmZmZmODgwMjEzZDAxYjE4IGZmZmZmZmZmODEwNGU5YmMNCj4gZmZmZjg4 MDIxM2QwMWIwOA0KPiA+PiBbICAgIDAuNDkxMzQzXSAgZmZmZmM5MDAwMGM1ODAwMCAwMDAwMDAw MGZlZDEwMDAwIDAwMDAwMDAwZmVkMTAwMDANCj4gMDAwMDAwMDAwMDAwNjAwMA0KPiA+PiBbICAg IDAuNDkxNjMxXSBDYWxsIFRyYWNlOg0KPiA+PiBbICAgIDAuNDkzMzM3XSAgWzxmZmZmZmZmZjgx NjExMmUzPl0gZHVtcF9zdGFjaysweDRmLzB4N2MNCj4gPj4gWyAgICAwLjQ5MzQyMF0gIFs8ZmZm ZmZmZmY4MTA0ZTliYz5dIHdhcm5fc2xvd3BhdGhfY29tbW9uKzB4OGMvMHhjMA0KPiA+PiBbICAg IDAuNDkzNTAzXSAgWzxmZmZmZmZmZjgxMDRlYWE2Pl0gd2Fybl9zbG93cGF0aF9mbXQrMHg0Ni8w eDUwDQo+ID4+IFsgICAgMC40OTM1ODhdICBbPGZmZmZmZmZmODEwM2YxZTI+XSBfX2lvcmVtYXBf Y2FsbGVyKzB4MzcyLzB4MzgwDQo+ID4+IFsgICAgMC40OTM2NzRdICBbPGZmZmZmZmZmODEwMjEx YTI+XSA/DQo+IHNuYl91bmNvcmVfaW1jX2luaXRfYm94KzB4NjIvMHg5MA0KPiA+PiBbICAgIDAu NDkzNzYxXSAgWzxmZmZmZmZmZjgxMDNmMjQ3Pl0gaW9yZW1hcF9ub2NhY2hlKzB4MTcvMHgyMA0K PiA+PiBbICAgIDAuNDkzODQ2XSAgWzxmZmZmZmZmZjgxMDIxMWEyPl0NCj4gc25iX3VuY29yZV9p bWNfaW5pdF9ib3grMHg2Mi8weDkwDQo+ID4+IFsgICAgMC40OTM5MzNdICBbPGZmZmZmZmZmODEw MjI5MjU+XSB1bmNvcmVfcGNpX3Byb2JlKzB4ZTUvMHgxZTANCj4gPj4gWyAgICAwLjQ5NDAyMF0g IFs8ZmZmZmZmZmY4MTJkNDg3ZT5dIGxvY2FsX3BjaV9wcm9iZSsweDRlLzB4YTANCj4gPj4gWyAg ICAwLjQ5NDEwNF0gIFs8ZmZmZmZmZmY4MTQxOGE1OT5dID8gZ2V0X2RldmljZSsweDE5LzB4MjAN Cj4gPj4gWyAgICAwLjQ5NDIxM10gIFs8ZmZmZmZmZmY4MTJkNWNkMT5dIHBjaV9kZXZpY2VfcHJv YmUrMHhlMS8weDEzMA0KPiA+PiBbICAgIDAuNDk0MzAwXSAgWzxmZmZmZmZmZjgxNDFkM2NiPl0g ZHJpdmVyX3Byb2JlX2RldmljZSsweDdiLzB4MjQwDQo+ID4+IFsgICAgMC40OTQzODVdICBbPGZm ZmZmZmZmODE0MWQ2M2I+XSBfX2RyaXZlcl9hdHRhY2grMHhhYi8weGIwDQo+ID4+IFsgICAgMC40 OTQ0NjldICBbPGZmZmZmZmZmODE0MWQ1OTA+XSA/DQo+IGRyaXZlcl9wcm9iZV9kZXZpY2UrMHgy NDAvMHgyNDANCj4gPj4gWyAgICAwLjQ5NDU1MV0gIFs8ZmZmZmZmZmY4MTQxYjcxZT5dIGJ1c19m b3JfZWFjaF9kZXYrMHg1ZS8weDkwDQo+ID4+IFsgICAgMC40OTQ2MzRdICBbPGZmZmZmZmZmODE0 MWNlZGU+XSBkcml2ZXJfYXR0YWNoKzB4MWUvMHgyMA0KPiA+PiBbICAgIDAuNDk0NzE4XSAgWzxm ZmZmZmZmZjgxNDFjYTU3Pl0gYnVzX2FkZF9kcml2ZXIrMHgxMTcvMHgyMzANCj4gPj4gWyAgICAw LjQ5NDgwMl0gIFs8ZmZmZmZmZmY4MTQxZGQzND5dIGRyaXZlcl9yZWdpc3RlcisweDY0LzB4ZjAN Cj4gPj4gWyAgICAwLjQ5NDg4NF0gIFs8ZmZmZmZmZmY4MTJkNGMxND5dIF9fcGNpX3JlZ2lzdGVy X2RyaXZlcisweDY0LzB4NzANCj4gPj4gWyAgICAwLjQ5NDk3Ml0gIFs8ZmZmZmZmZmY4MWQwMzE5 Yj5dID8gdW5jb3JlX3R5cGVzX2luaXQrMHgxOWMvMHgxOWMNCj4gPj4gWyAgICAwLjQ5NTA1Nl0g IFs8ZmZmZmZmZmY4MWQwMzMxMj5dIGludGVsX3VuY29yZV9pbml0KzB4MTc3LzB4NDFjDQo+ID4+ IFsgICAgMC40OTUxNTVdICBbPGZmZmZmZmZmODFkMDMxOWI+XSA/IHVuY29yZV90eXBlc19pbml0 KzB4MTljLzB4MTljDQo+ID4+IFsgICAgMC40OTUyNDJdICBbPGZmZmZmZmZmODEwMDAyOWU+XSBk b19vbmVfaW5pdGNhbGwrMHg0ZS8weDE3MA0KPiA+PiBbICAgIDAuNDk1MzI2XSAgWzxmZmZmZmZm ZjgxMDcxMTAwPl0gPyBwYXJzZV9hcmdzKzB4NjAvMHgzNjANCj4gPj4gWyAgICAwLjQ5NTQxMV0g IFs8ZmZmZmZmZmY4MWNmYmZiOD5dDQo+IGtlcm5lbF9pbml0X2ZyZWVhYmxlKzB4MTA2LzB4MTlh DQo+ID4+IFsgICAgMC40OTU0OTddICBbPGZmZmZmZmZmODFjZmI4M2I+XSA/IGRvX2Vhcmx5X3Bh cmFtKzB4ODYvMHg4Ng0KPiA+PiBbICAgIDAuNDk1NTgyXSAgWzxmZmZmZmZmZjgxNjA3ZWYwPl0g PyByZXN0X2luaXQrMHhkMC8weGQwDQo+ID4+IFsgICAgMC40OTU2NjZdICBbPGZmZmZmZmZmODE2 MDdlZmU+XSBrZXJuZWxfaW5pdCsweGUvMHhmMA0KPiA+PiBbICAgIDAuNDk1NzQ5XSAgWzxmZmZm ZmZmZjgxNjIxZjZjPl0gcmV0X2Zyb21fZm9yaysweDdjLzB4YjANCj4gPj4gWyAgICAwLjQ5NTgz MV0gIFs8ZmZmZmZmZmY4MTYwN2VmMD5dID8gcmVzdF9pbml0KzB4ZDAvMHhkMA0KPiA+PiBbICAg IDAuNDk1OTIxXSAtLS1bIGVuZCB0cmFjZSA0MjhmMzY1YzA1NGQ5YTAxIF0tLS0NCj4gPj4gWyAg ICAwLjQ5NjE5Nl0gUkFQTCBQTVUgZGV0ZWN0ZWQsIGh3IHVuaXQgMl4tMTYgSm91bGVzLCBBUEkg dW5pdCBpcw0KPiAyXi0zMiBKb3VsZXMsIDMgZml4ZWQgY291bnRlcnMgMTYzODQwIG1zIG92Zmwg dGltZXINCj4gPj4gWyAgICAwLjQ5ODU5OF0gZnV0ZXggaGFzaCB0YWJsZSBlbnRyaWVzOiAxMDI0 IChvcmRlcjogNSwgMTMxMDcyDQo+IGJ5dGVzKQ0KPiA+PiBbICAgIDAuNDk4ODMzXSBhdWRpdDog aW5pdGlhbGl6aW5nIG5ldGxpbmsgc3Vic3lzIChkaXNhYmxlZCkNCj4gPj4gWyAgICAwLjQ5OTAy NF0gYXVkaXQ6IHR5cGU9MjAwMCBhdWRpdCgxMzkzMjU5ODY2LjQ3NzoxKTogaW5pdGlhbGl6ZWQN Cj4gPj4gLi4uDQo+ID4+DQo+ID4+DQo+ID4NCg0K ^ permalink raw reply [flat|nested] 84+ messages in thread
* RE: Info: mapping multiple BARs. Your kernel is fine. @ 2014-03-20 3:03 ` Zhang, Rui 0 siblings, 0 replies; 84+ messages in thread From: Zhang, Rui @ 2014-03-20 3:03 UTC (permalink / raw) To: Lu, Aaron, Rafael J. Wysocki, Borislav Petkov Cc: lkml, x86, Bjorn Helgaas, Linux PCI, ACPI Devel Maling List, Yinghai Lu, H. Peter Anvin, Stephane Eranian, Yan, Zheng Z [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="utf-8", Size: 6493 bytes --] > -----Original Message----- > From: Lu, Aaron > Sent: Thursday, March 20, 2014 10:24 AM > To: Rafael J. Wysocki; Borislav Petkov > Cc: lkml; x86@kernel.org; Bjorn Helgaas; Linux PCI; ACPI Devel Maling > List; Zhang, Rui; Yinghai Lu; H. Peter Anvin; Stephane Eranian > Subject: Re: Info: mapping multiple BARs. Your kernel is fine. > Importance: High > > On 03/15/2014 10:15 PM, Rafael J. Wysocki wrote: > > [CC list rearranged] > > > > 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 :-) > >> > >> We have intel_uncore_init, snb_uncore_imc_init_box, uncore_pci_probe > >> and other goodies on the stack. > > > > I've just gone throught this. > > > > So the problem is that we have the PNP "system" driver whose only > > purpose seems to be to reserve system resources so that the PCI layer > > doesn't assign them to new devices on hotplug (disclaimer: I didn't > > invent it, I only read the code and comments in there). > > And to PCI devices which have uninitialized BARs. > > > > > It does that for ACPI device objects having the "PNP0C02" and > "PNP0C01" IDs. > > > > Apparently, snb_uncore_imc_init_box() steps on a range already > > reserved by that driver on your box. And this doesn't seem to be a > > coincidence, because the ACPI device object in question probably > > *does* correspond to the memory controller that the uncore driver > attempts to use. > > > > I'm not sure how to address that right now to be honest. Arguably, > > the PNP "system" driver should be replaced with something saner, but > > still the resources it claims need to be kept out of reach of the > > PCI's resource allocation code. > > The quirk_system_pci_resources is meant to disable PNP devices' > resource if they collide with any known PCI device's BAR. I'm not sure > why it doesn't work here, perhaps the uncore PCI device doesn't have a > BAR that falls in the PNP device's resource window? > I've talked with Yan Zheng, and I was told that this resource "0xfed10000 - 0xfed15fff" is got from PCI device register directly, which is not in its BAR range. Thus IMO, it is impossible for PNP layer to be aware of this resource. BTW, about drivers/pnp/system.c, if its ONLY purpose is to prevent those resources from being allocated to uninitialized PCI devices, then IMO, the best way to do this is make PCI bus handle those PNP0C01/PNP0C02 resources directly, probably via a platform callback, say, 1. make drivers/pnp/system.c a no-op for PNPACPI, by checking pnp_dev->protocol. 2. introduce acpi_check_reserved_resource() to parsing PNP0C01/PNP0C02 resources. 3. in PCI bus, invoke acpi_check_reserved_resource() when assigning resources to PCI devices. Thanks, rui > Thanks, > Aaron > > > > >> ... > >> [ 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 > >> ... > >> > >> > > ÿôèº{.nÇ+·®+%Ëÿ±éݶ\x17¥wÿº{.nÇ+·¥{±þG«éÿ{ayº\x1dÊÚë,j\a¢f£¢·hïêÿêçz_è®\x03(éÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?¨èÚ&£ø§~á¶iOæ¬z·vØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?I¥ ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. 2014-03-20 3:03 ` Zhang, Rui (?) (?) @ 2014-03-20 3:34 ` Stephane Eranian 2014-03-20 7:53 ` Zhang, Rui -1 siblings, 1 reply; 84+ messages in thread From: Stephane Eranian @ 2014-03-20 3:34 UTC (permalink / raw) To: Zhang, Rui Cc: Lu, Aaron, Rafael J. Wysocki, Borislav Petkov, lkml, x86, Bjorn Helgaas, Linux PCI, ACPI Devel Maling List, Yinghai Lu, H. Peter Anvin, Yan, Zheng Z On Thu, Mar 20, 2014 at 4:03 AM, Zhang, Rui <rui.zhang@intel.com> wrote: > > >> -----Original Message----- >> From: Lu, Aaron >> Sent: Thursday, March 20, 2014 10:24 AM >> To: Rafael J. Wysocki; Borislav Petkov >> Cc: lkml; x86@kernel.org; Bjorn Helgaas; Linux PCI; ACPI Devel Maling >> List; Zhang, Rui; Yinghai Lu; H. Peter Anvin; Stephane Eranian >> Subject: Re: Info: mapping multiple BARs. Your kernel is fine. >> Importance: High >> >> On 03/15/2014 10:15 PM, Rafael J. Wysocki wrote: >> > [CC list rearranged] >> > >> > 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 :-) >> >> >> >> We have intel_uncore_init, snb_uncore_imc_init_box, uncore_pci_probe >> >> and other goodies on the stack. >> > >> > I've just gone throught this. >> > >> > So the problem is that we have the PNP "system" driver whose only >> > purpose seems to be to reserve system resources so that the PCI layer >> > doesn't assign them to new devices on hotplug (disclaimer: I didn't >> > invent it, I only read the code and comments in there). >> >> And to PCI devices which have uninitialized BARs. >> >> > >> > It does that for ACPI device objects having the "PNP0C02" and >> "PNP0C01" IDs. >> > >> > Apparently, snb_uncore_imc_init_box() steps on a range already >> > reserved by that driver on your box. And this doesn't seem to be a >> > coincidence, because the ACPI device object in question probably >> > *does* correspond to the memory controller that the uncore driver >> attempts to use. >> > >> > I'm not sure how to address that right now to be honest. Arguably, >> > the PNP "system" driver should be replaced with something saner, but >> > still the resources it claims need to be kept out of reach of the >> > PCI's resource allocation code. >> >> The quirk_system_pci_resources is meant to disable PNP devices' >> resource if they collide with any known PCI device's BAR. I'm not sure >> why it doesn't work here, perhaps the uncore PCI device doesn't have a >> BAR that falls in the PNP device's resource window? >> > I've talked with Yan Zheng, and I was told that this resource "0xfed10000 - 0xfed15fff" > is got from PCI device register directly, which is not in its BAR range. > Thus IMO, it is impossible for PNP layer to be aware of this resource. > That is not what the perf_event code does. Nothing is hardcoded except the IMC PCI device ids. The BAR offset is hardcoded that's all. The 0xfed10000 is discovered. > BTW, about drivers/pnp/system.c, if its ONLY purpose is to prevent those > resources from being allocated to uninitialized PCI devices, then IMO, > the best way to do this is make PCI bus handle those PNP0C01/PNP0C02 > resources directly, probably via a platform callback, say, > 1. make drivers/pnp/system.c a no-op for PNPACPI, by checking pnp_dev->protocol. > 2. introduce acpi_check_reserved_resource() to parsing PNP0C01/PNP0C02 resources. > 3. in PCI bus, invoke acpi_check_reserved_resource() when assigning > resources to PCI devices. > > Thanks, > rui > >> Thanks, >> Aaron >> >> > >> >> ... >> >> [ 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 >> >> ... >> >> >> >> >> > > ^ permalink raw reply [flat|nested] 84+ messages in thread
* RE: Info: mapping multiple BARs. Your kernel is fine. 2014-03-20 3:34 ` Stephane Eranian 2014-03-20 7:53 ` Zhang, Rui @ 2014-03-20 7:53 ` Zhang, Rui 0 siblings, 0 replies; 84+ messages in thread From: Zhang, Rui @ 2014-03-20 7:53 UTC (permalink / raw) To: Stephane Eranian Cc: Lu, Aaron, Rafael J. Wysocki, Borislav Petkov, lkml, x86, Bjorn Helgaas, Linux PCI, ACPI Devel Maling List, Yinghai Lu, H. Peter Anvin, Yan, Zheng Z > -----Original Message----- > From: Stephane Eranian [mailto:eranian@google.com] > Sent: Thursday, March 20, 2014 11:35 AM > To: Zhang, Rui > Cc: Lu, Aaron; Rafael J. Wysocki; Borislav Petkov; lkml; x86@kernel.org; > Bjorn Helgaas; Linux PCI; ACPI Devel Maling List; Yinghai Lu; H. Peter > Anvin; Yan, Zheng Z > Subject: Re: Info: mapping multiple BARs. Your kernel is fine. > Importance: High > > On Thu, Mar 20, 2014 at 4:03 AM, Zhang, Rui <rui.zhang@intel.com> wrote: > > > > > >> -----Original Message----- > >> From: Lu, Aaron > >> Sent: Thursday, March 20, 2014 10:24 AM > >> To: Rafael J. Wysocki; Borislav Petkov > >> Cc: lkml; x86@kernel.org; Bjorn Helgaas; Linux PCI; ACPI Devel > Maling > >> List; Zhang, Rui; Yinghai Lu; H. Peter Anvin; Stephane Eranian > >> Subject: Re: Info: mapping multiple BARs. Your kernel is fine. > >> Importance: High > >> > >> On 03/15/2014 10:15 PM, Rafael J. Wysocki wrote: > >> > [CC list rearranged] > >> > > >> > 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 :-) > >> >> > >> >> We have intel_uncore_init, snb_uncore_imc_init_box, > >> >> uncore_pci_probe and other goodies on the stack. > >> > > >> > I've just gone throught this. > >> > > >> > So the problem is that we have the PNP "system" driver whose only > >> > purpose seems to be to reserve system resources so that the PCI > >> > layer doesn't assign them to new devices on hotplug (disclaimer: I > >> > didn't invent it, I only read the code and comments in there). > >> > >> And to PCI devices which have uninitialized BARs. > >> > >> > > >> > It does that for ACPI device objects having the "PNP0C02" and > >> "PNP0C01" IDs. > >> > > >> > Apparently, snb_uncore_imc_init_box() steps on a range already > >> > reserved by that driver on your box. And this doesn't seem to be > a > >> > coincidence, because the ACPI device object in question probably > >> > *does* correspond to the memory controller that the uncore driver > >> attempts to use. > >> > > >> > I'm not sure how to address that right now to be honest. Arguably, > >> > the PNP "system" driver should be replaced with something saner, > >> > but still the resources it claims need to be kept out of reach of > >> > the PCI's resource allocation code. > >> > >> The quirk_system_pci_resources is meant to disable PNP devices' > >> resource if they collide with any known PCI device's BAR. I'm not > >> sure why it doesn't work here, perhaps the uncore PCI device doesn't > >> have a BAR that falls in the PNP device's resource window? > >> > > I've talked with Yan Zheng, and I was told that this resource > "0xfed10000 - 0xfed15fff" > > is got from PCI device register directly, which is not in its BAR > range. > > Thus IMO, it is impossible for PNP layer to be aware of this resource. > > > That is not what the perf_event code does. Nothing is hardcoded except > the IMC PCI device ids. The BAR offset is hardcoded that's all. The > 0xfed10000 is discovered. > The resource length is also hardcoded to 0x6000, right? This is probably a problem, because only if the resource length read from PCI config space is larger than 0x4000, drivers/pnp/quirks.c will detect the conflict and disable the PNP0C02 resource 0xfed10000 - 0xfed13fff, and the PCI device can request this resource successfully. In order to check this, can you please attach the dmesg output after boot? Thanks, rui > > BTW, about drivers/pnp/system.c, if its ONLY purpose is to prevent > > those resources from being allocated to uninitialized PCI devices, > > then IMO, the best way to do this is make PCI bus handle those > > PNP0C01/PNP0C02 resources directly, probably via a platform callback, > > say, 1. make drivers/pnp/system.c a no-op for PNPACPI, by checking > pnp_dev->protocol. > > 2. introduce acpi_check_reserved_resource() to parsing > PNP0C01/PNP0C02 resources. > > 3. in PCI bus, invoke acpi_check_reserved_resource() when assigning > > resources to PCI devices. > > > > Thanks, > > rui > > > >> Thanks, > >> Aaron > >> > >> > > >> >> ... > >> >> [ 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 > >> >> ... > >> >> > >> >> > >> > > > ^ permalink raw reply [flat|nested] 84+ messages in thread
* RE: Info: mapping multiple BARs. Your kernel is fine. @ 2014-03-20 7:53 ` Zhang, Rui 0 siblings, 0 replies; 84+ messages in thread From: Zhang, Rui @ 2014-03-20 7:53 UTC (permalink / raw) To: Stephane Eranian Cc: Lu, Aaron, Rafael J. Wysocki, Borislav Petkov, lkml, x86, Bjorn Helgaas, Linux PCI, ACPI Devel Maling List, Yinghai Lu, H. Peter Anvin, Yan, Zheng Z DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogU3RlcGhhbmUgRXJhbmlh biBbbWFpbHRvOmVyYW5pYW5AZ29vZ2xlLmNvbV0NCj4gU2VudDogVGh1cnNkYXksIE1hcmNoIDIw LCAyMDE0IDExOjM1IEFNDQo+IFRvOiBaaGFuZywgUnVpDQo+IENjOiBMdSwgQWFyb247IFJhZmFl bCBKLiBXeXNvY2tpOyBCb3Jpc2xhdiBQZXRrb3Y7IGxrbWw7IHg4NkBrZXJuZWwub3JnOw0KPiBC am9ybiBIZWxnYWFzOyBMaW51eCBQQ0k7IEFDUEkgRGV2ZWwgTWFsaW5nIExpc3Q7IFlpbmdoYWkg THU7IEguIFBldGVyDQo+IEFudmluOyBZYW4sIFpoZW5nIFoNCj4gU3ViamVjdDogUmU6IEluZm86 IG1hcHBpbmcgbXVsdGlwbGUgQkFScy4gWW91ciBrZXJuZWwgaXMgZmluZS4NCj4gSW1wb3J0YW5j ZTogSGlnaA0KPiANCj4gT24gVGh1LCBNYXIgMjAsIDIwMTQgYXQgNDowMyBBTSwgWmhhbmcsIFJ1 aSA8cnVpLnpoYW5nQGludGVsLmNvbT4gd3JvdGU6DQo+ID4NCj4gPg0KPiA+PiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBMdSwgQWFyb24NCj4gPj4gU2VudDogVGh1cnNk YXksIE1hcmNoIDIwLCAyMDE0IDEwOjI0IEFNDQo+ID4+IFRvOiBSYWZhZWwgSi4gV3lzb2NraTsg Qm9yaXNsYXYgUGV0a292DQo+ID4+IENjOiBsa21sOyB4ODZAa2VybmVsLm9yZzsgQmpvcm4gSGVs Z2FhczsgTGludXggUENJOyBBQ1BJIERldmVsDQo+IE1hbGluZw0KPiA+PiBMaXN0OyBaaGFuZywg UnVpOyBZaW5naGFpIEx1OyBILiBQZXRlciBBbnZpbjsgU3RlcGhhbmUgRXJhbmlhbg0KPiA+PiBT dWJqZWN0OiBSZTogSW5mbzogbWFwcGluZyBtdWx0aXBsZSBCQVJzLiBZb3VyIGtlcm5lbCBpcyBm aW5lLg0KPiA+PiBJbXBvcnRhbmNlOiBIaWdoDQo+ID4+DQo+ID4+IE9uIDAzLzE1LzIwMTQgMTA6 MTUgUE0sIFJhZmFlbCBKLiBXeXNvY2tpIHdyb3RlOg0KPiA+PiA+IFtDQyBsaXN0IHJlYXJyYW5n ZWRdDQo+ID4+ID4NCj4gPj4gPiBPbiBNb25kYXksIEZlYnJ1YXJ5IDI0LCAyMDE0IDA1OjI0OjAw IFBNIEJvcmlzbGF2IFBldGtvdiB3cm90ZToNCj4gPj4gPj4gVGhpcyBzdGFydGVkIGhhcHBlbmlu ZyB0aGlzIG1vcm5pbmcgYWZ0ZXIgYm9vdGluZyAtcmM0K3RpcCwgbGV0J3MNCj4gPj4gYWRkDQo+ ID4+ID4+ICpldmVyeWJvZHkqIHRvIENDIDotKQ0KPiA+PiA+Pg0KPiA+PiA+PiBXZSBoYXZlIGlu dGVsX3VuY29yZV9pbml0LCBzbmJfdW5jb3JlX2ltY19pbml0X2JveCwNCj4gPj4gPj4gdW5jb3Jl X3BjaV9wcm9iZSBhbmQgb3RoZXIgZ29vZGllcyBvbiB0aGUgc3RhY2suDQo+ID4+ID4NCj4gPj4g PiBJJ3ZlIGp1c3QgZ29uZSB0aHJvdWdodCB0aGlzLg0KPiA+PiA+DQo+ID4+ID4gU28gdGhlIHBy b2JsZW0gaXMgdGhhdCB3ZSBoYXZlIHRoZSBQTlAgInN5c3RlbSIgZHJpdmVyIHdob3NlIG9ubHkN Cj4gPj4gPiBwdXJwb3NlIHNlZW1zIHRvIGJlIHRvIHJlc2VydmUgc3lzdGVtIHJlc291cmNlcyBz byB0aGF0IHRoZSBQQ0kNCj4gPj4gPiBsYXllciBkb2Vzbid0IGFzc2lnbiB0aGVtIHRvIG5ldyBk ZXZpY2VzIG9uIGhvdHBsdWcgKGRpc2NsYWltZXI6IEkNCj4gPj4gPiBkaWRuJ3QgaW52ZW50IGl0 LCBJIG9ubHkgcmVhZCB0aGUgY29kZSBhbmQgY29tbWVudHMgaW4gdGhlcmUpLg0KPiA+Pg0KPiA+ PiBBbmQgdG8gUENJIGRldmljZXMgd2hpY2ggaGF2ZSB1bmluaXRpYWxpemVkIEJBUnMuDQo+ID4+ DQo+ID4+ID4NCj4gPj4gPiBJdCBkb2VzIHRoYXQgZm9yIEFDUEkgZGV2aWNlIG9iamVjdHMgaGF2 aW5nIHRoZSAiUE5QMEMwMiIgYW5kDQo+ID4+ICJQTlAwQzAxIiBJRHMuDQo+ID4+ID4NCj4gPj4g PiBBcHBhcmVudGx5LCBzbmJfdW5jb3JlX2ltY19pbml0X2JveCgpIHN0ZXBzIG9uIGEgcmFuZ2Ug YWxyZWFkeQ0KPiA+PiA+IHJlc2VydmVkIGJ5IHRoYXQgZHJpdmVyIG9uIHlvdXIgYm94LiAgQW5k IHRoaXMgZG9lc24ndCBzZWVtIHRvIGJlDQo+IGENCj4gPj4gPiBjb2luY2lkZW5jZSwgYmVjYXVz ZSB0aGUgQUNQSSBkZXZpY2Ugb2JqZWN0IGluIHF1ZXN0aW9uIHByb2JhYmx5DQo+ID4+ID4gKmRv ZXMqIGNvcnJlc3BvbmQgdG8gdGhlIG1lbW9yeSBjb250cm9sbGVyIHRoYXQgdGhlIHVuY29yZSBk cml2ZXINCj4gPj4gYXR0ZW1wdHMgdG8gdXNlLg0KPiA+PiA+DQo+ID4+ID4gSSdtIG5vdCBzdXJl IGhvdyB0byBhZGRyZXNzIHRoYXQgcmlnaHQgbm93IHRvIGJlIGhvbmVzdC4gIEFyZ3VhYmx5LA0K PiA+PiA+IHRoZSBQTlAgInN5c3RlbSIgZHJpdmVyIHNob3VsZCBiZSByZXBsYWNlZCB3aXRoIHNv bWV0aGluZyBzYW5lciwNCj4gPj4gPiBidXQgc3RpbGwgdGhlIHJlc291cmNlcyBpdCBjbGFpbXMg bmVlZCB0byBiZSBrZXB0IG91dCBvZiByZWFjaCBvZg0KPiA+PiA+IHRoZSBQQ0kncyByZXNvdXJj ZSBhbGxvY2F0aW9uIGNvZGUuDQo+ID4+DQo+ID4+IFRoZSBxdWlya19zeXN0ZW1fcGNpX3Jlc291 cmNlcyBpcyBtZWFudCB0byBkaXNhYmxlIFBOUCBkZXZpY2VzJw0KPiA+PiByZXNvdXJjZSBpZiB0 aGV5IGNvbGxpZGUgd2l0aCBhbnkga25vd24gUENJIGRldmljZSdzIEJBUi4gSSdtIG5vdA0KPiA+ PiBzdXJlIHdoeSBpdCBkb2Vzbid0IHdvcmsgaGVyZSwgcGVyaGFwcyB0aGUgdW5jb3JlIFBDSSBk ZXZpY2UgZG9lc24ndA0KPiA+PiBoYXZlIGEgQkFSIHRoYXQgZmFsbHMgaW4gdGhlIFBOUCBkZXZp Y2UncyByZXNvdXJjZSB3aW5kb3c/DQo+ID4+DQo+ID4gSSd2ZSB0YWxrZWQgd2l0aCBZYW4gWmhl bmcsIGFuZCBJIHdhcyB0b2xkIHRoYXQgdGhpcyByZXNvdXJjZQ0KPiAiMHhmZWQxMDAwMCAtIDB4 ZmVkMTVmZmYiDQo+ID4gaXMgZ290IGZyb20gUENJIGRldmljZSByZWdpc3RlciBkaXJlY3RseSwg d2hpY2ggaXMgbm90IGluIGl0cyBCQVINCj4gcmFuZ2UuDQo+ID4gVGh1cyBJTU8sIGl0IGlzIGlt cG9zc2libGUgZm9yIFBOUCBsYXllciB0byBiZSBhd2FyZSBvZiB0aGlzIHJlc291cmNlLg0KPiA+ DQo+IFRoYXQgaXMgbm90IHdoYXQgdGhlIHBlcmZfZXZlbnQgY29kZSBkb2VzLiBOb3RoaW5nIGlz IGhhcmRjb2RlZCBleGNlcHQNCj4gdGhlIElNQyBQQ0kgZGV2aWNlIGlkcy4gVGhlIEJBUiBvZmZz ZXQgaXMgaGFyZGNvZGVkIHRoYXQncyBhbGwuIFRoZQ0KPiAweGZlZDEwMDAwIGlzIGRpc2NvdmVy ZWQuDQo+IA0KVGhlIHJlc291cmNlIGxlbmd0aCBpcyBhbHNvIGhhcmRjb2RlZCB0byAweDYwMDAs IHJpZ2h0Pw0KVGhpcyBpcyBwcm9iYWJseSBhIHByb2JsZW0sIGJlY2F1c2UNCm9ubHkgaWYgdGhl IHJlc291cmNlIGxlbmd0aCByZWFkIGZyb20gUENJIGNvbmZpZyBzcGFjZSBpcyBsYXJnZXIgdGhh biAweDQwMDAsDQpkcml2ZXJzL3BucC9xdWlya3MuYyB3aWxsIGRldGVjdCB0aGUgY29uZmxpY3Qg YW5kIGRpc2FibGUgdGhlIFBOUDBDMDINCnJlc291cmNlIDB4ZmVkMTAwMDAgLSAweGZlZDEzZmZm LCBhbmQgdGhlIFBDSSBkZXZpY2UgY2FuIHJlcXVlc3QgdGhpcw0KcmVzb3VyY2Ugc3VjY2Vzc2Z1 bGx5Lg0KSW4gb3JkZXIgdG8gY2hlY2sgdGhpcywgY2FuIHlvdSBwbGVhc2UgYXR0YWNoIHRoZSBk bWVzZyBvdXRwdXQgYWZ0ZXIgYm9vdD8NCg0KVGhhbmtzLA0KcnVpDQoNCj4gPiBCVFcsIGFib3V0 IGRyaXZlcnMvcG5wL3N5c3RlbS5jLCBpZiBpdHMgT05MWSBwdXJwb3NlIGlzIHRvIHByZXZlbnQN Cj4gPiB0aG9zZSByZXNvdXJjZXMgZnJvbSBiZWluZyBhbGxvY2F0ZWQgdG8gdW5pbml0aWFsaXpl ZCBQQ0kgZGV2aWNlcywNCj4gPiB0aGVuIElNTywgdGhlIGJlc3Qgd2F5IHRvIGRvIHRoaXMgaXMg bWFrZSBQQ0kgYnVzIGhhbmRsZSB0aG9zZQ0KPiA+IFBOUDBDMDEvUE5QMEMwMiByZXNvdXJjZXMg ZGlyZWN0bHksIHByb2JhYmx5IHZpYSBhIHBsYXRmb3JtIGNhbGxiYWNrLA0KPiA+IHNheSwgMS4g bWFrZSBkcml2ZXJzL3BucC9zeXN0ZW0uYyBhIG5vLW9wIGZvciBQTlBBQ1BJLCBieSBjaGVja2lu Zw0KPiBwbnBfZGV2LT5wcm90b2NvbC4NCj4gPiAyLiBpbnRyb2R1Y2UgYWNwaV9jaGVja19yZXNl cnZlZF9yZXNvdXJjZSgpIHRvIHBhcnNpbmcNCj4gUE5QMEMwMS9QTlAwQzAyIHJlc291cmNlcy4N Cj4gPiAzLiBpbiBQQ0kgYnVzLCBpbnZva2UgYWNwaV9jaGVja19yZXNlcnZlZF9yZXNvdXJjZSgp IHdoZW4gYXNzaWduaW5nDQo+ID4gICAgcmVzb3VyY2VzIHRvIFBDSSBkZXZpY2VzLg0KPiA+DQo+ ID4gVGhhbmtzLA0KPiA+IHJ1aQ0KPiA+DQo+ID4+IFRoYW5rcywNCj4gPj4gQWFyb24NCj4gPj4N Cj4gPj4gPg0KPiA+PiA+PiAuLi4NCj4gPj4gPj4gWyAgICAwLjQ4ODk5OF0gc29mdHdhcmUgSU8g VExCIFttZW0gMHhjYWMzMDAwMC0weGNlYzMwMDAwXSAoNjRNQikNCj4gPj4gbWFwcGVkIGF0IFtm ZmZmODgwMGNhYzMwMDAwLWZmZmY4ODAwY2VjMmZmZmZdDQo+ID4+ID4+IFsgICAgMC40ODk5NzVd IHJlc291cmNlIG1hcCBzYW5pdHkgY2hlY2sgY29uZmxpY3Q6IDB4ZmVkMTAwMDANCj4gPj4gMHhm ZWQxNWZmZiAweGZlZDEwMDAwIDB4ZmVkMTNmZmYgcG5wIDAwOjAxDQo+ID4+ID4+IFsgICAgMC40 OTAwNzldIC0tLS0tLS0tLS0tLVsgY3V0IGhlcmUgXS0tLS0tLS0tLS0tLQ0KPiA+PiA+PiBbICAg IDAuNDkwMjA0XSBXQVJOSU5HOiBDUFU6IDIgUElEOiAxIGF0DQo+IGFyY2gveDg2L21tL2lvcmVt YXAuYzoxNzENCj4gPj4gX19pb3JlbWFwX2NhbGxlcisweDM3Mi8weDM4MCgpDQo+ID4+ID4+IFsg ICAgMC40OTAzMDZdIEluZm86IG1hcHBpbmcgbXVsdGlwbGUgQkFScy4gWW91ciBrZXJuZWwgaXMg ZmluZS4NCj4gPj4gPj4gWyAgICAwLjQ5MDM3MV0gTW9kdWxlcyBsaW5rZWQgaW46DQo+ID4+ID4+ IFsgICAgMC40OTA1NThdIENQVTogMiBQSUQ6IDEgQ29tbTogc3dhcHBlci8wIE5vdCB0YWludGVk IDMuMTQuMC0NCj4gcmM0Kw0KPiA+PiAjMQ0KPiA+PiA+PiBbICAgIDAuNDkwNjQyXSBIYXJkd2Fy ZSBuYW1lOiBMRU5PVk8gMjMyMENUTy8yMzIwQ1RPLCBCSU9TDQo+IEcyRVQ4NldXDQo+ID4+ICgy LjA2ICkgMTEvMTMvMjAxMg0KPiA+PiA+PiBbICAgIDAuNDkwNzQyXSAgMDAwMDAwMDAwMDAwMDBh YiBmZmZmODgwMjEzZDAxYWQ4DQo+IGZmZmZmZmZmODE2MTEyZTMNCj4gPj4gMDAwMDAwMDAwMDAw MDAwNg0KPiA+PiA+PiBbICAgIDAuNDkxMDMyXSAgZmZmZjg4MDIxM2QwMWIyOCBmZmZmODgwMjEz ZDAxYjE4DQo+IGZmZmZmZmZmODEwNGU5YmMNCj4gPj4gZmZmZjg4MDIxM2QwMWIwOA0KPiA+PiA+ PiBbICAgIDAuNDkxMzQzXSAgZmZmZmM5MDAwMGM1ODAwMCAwMDAwMDAwMGZlZDEwMDAwDQo+IDAw MDAwMDAwZmVkMTAwMDANCj4gPj4gMDAwMDAwMDAwMDAwNjAwMA0KPiA+PiA+PiBbICAgIDAuNDkx NjMxXSBDYWxsIFRyYWNlOg0KPiA+PiA+PiBbICAgIDAuNDkzMzM3XSAgWzxmZmZmZmZmZjgxNjEx MmUzPl0gZHVtcF9zdGFjaysweDRmLzB4N2MNCj4gPj4gPj4gWyAgICAwLjQ5MzQyMF0gIFs8ZmZm ZmZmZmY4MTA0ZTliYz5dDQo+IHdhcm5fc2xvd3BhdGhfY29tbW9uKzB4OGMvMHhjMA0KPiA+PiA+ PiBbICAgIDAuNDkzNTAzXSAgWzxmZmZmZmZmZjgxMDRlYWE2Pl0gd2Fybl9zbG93cGF0aF9mbXQr MHg0Ni8weDUwDQo+ID4+ID4+IFsgICAgMC40OTM1ODhdICBbPGZmZmZmZmZmODEwM2YxZTI+XSBf X2lvcmVtYXBfY2FsbGVyKzB4MzcyLzB4MzgwDQo+ID4+ID4+IFsgICAgMC40OTM2NzRdICBbPGZm ZmZmZmZmODEwMjExYTI+XSA/DQo+ID4+IHNuYl91bmNvcmVfaW1jX2luaXRfYm94KzB4NjIvMHg5 MA0KPiA+PiA+PiBbICAgIDAuNDkzNzYxXSAgWzxmZmZmZmZmZjgxMDNmMjQ3Pl0gaW9yZW1hcF9u b2NhY2hlKzB4MTcvMHgyMA0KPiA+PiA+PiBbICAgIDAuNDkzODQ2XSAgWzxmZmZmZmZmZjgxMDIx MWEyPl0NCj4gPj4gc25iX3VuY29yZV9pbWNfaW5pdF9ib3grMHg2Mi8weDkwDQo+ID4+ID4+IFsg ICAgMC40OTM5MzNdICBbPGZmZmZmZmZmODEwMjI5MjU+XSB1bmNvcmVfcGNpX3Byb2JlKzB4ZTUv MHgxZTANCj4gPj4gPj4gWyAgICAwLjQ5NDAyMF0gIFs8ZmZmZmZmZmY4MTJkNDg3ZT5dIGxvY2Fs X3BjaV9wcm9iZSsweDRlLzB4YTANCj4gPj4gPj4gWyAgICAwLjQ5NDEwNF0gIFs8ZmZmZmZmZmY4 MTQxOGE1OT5dID8gZ2V0X2RldmljZSsweDE5LzB4MjANCj4gPj4gPj4gWyAgICAwLjQ5NDIxM10g IFs8ZmZmZmZmZmY4MTJkNWNkMT5dIHBjaV9kZXZpY2VfcHJvYmUrMHhlMS8weDEzMA0KPiA+PiA+ PiBbICAgIDAuNDk0MzAwXSAgWzxmZmZmZmZmZjgxNDFkM2NiPl0NCj4gZHJpdmVyX3Byb2JlX2Rl dmljZSsweDdiLzB4MjQwDQo+ID4+ID4+IFsgICAgMC40OTQzODVdICBbPGZmZmZmZmZmODE0MWQ2 M2I+XSBfX2RyaXZlcl9hdHRhY2grMHhhYi8weGIwDQo+ID4+ID4+IFsgICAgMC40OTQ0NjldICBb PGZmZmZmZmZmODE0MWQ1OTA+XSA/DQo+ID4+IGRyaXZlcl9wcm9iZV9kZXZpY2UrMHgyNDAvMHgy NDANCj4gPj4gPj4gWyAgICAwLjQ5NDU1MV0gIFs8ZmZmZmZmZmY4MTQxYjcxZT5dIGJ1c19mb3Jf ZWFjaF9kZXYrMHg1ZS8weDkwDQo+ID4+ID4+IFsgICAgMC40OTQ2MzRdICBbPGZmZmZmZmZmODE0 MWNlZGU+XSBkcml2ZXJfYXR0YWNoKzB4MWUvMHgyMA0KPiA+PiA+PiBbICAgIDAuNDk0NzE4XSAg WzxmZmZmZmZmZjgxNDFjYTU3Pl0gYnVzX2FkZF9kcml2ZXIrMHgxMTcvMHgyMzANCj4gPj4gPj4g WyAgICAwLjQ5NDgwMl0gIFs8ZmZmZmZmZmY4MTQxZGQzND5dIGRyaXZlcl9yZWdpc3RlcisweDY0 LzB4ZjANCj4gPj4gPj4gWyAgICAwLjQ5NDg4NF0gIFs8ZmZmZmZmZmY4MTJkNGMxND5dDQo+IF9f cGNpX3JlZ2lzdGVyX2RyaXZlcisweDY0LzB4NzANCj4gPj4gPj4gWyAgICAwLjQ5NDk3Ml0gIFs8 ZmZmZmZmZmY4MWQwMzE5Yj5dID8NCj4gdW5jb3JlX3R5cGVzX2luaXQrMHgxOWMvMHgxOWMNCj4g Pj4gPj4gWyAgICAwLjQ5NTA1Nl0gIFs8ZmZmZmZmZmY4MWQwMzMxMj5dDQo+IGludGVsX3VuY29y ZV9pbml0KzB4MTc3LzB4NDFjDQo+ID4+ID4+IFsgICAgMC40OTUxNTVdICBbPGZmZmZmZmZmODFk MDMxOWI+XSA/DQo+IHVuY29yZV90eXBlc19pbml0KzB4MTljLzB4MTljDQo+ID4+ID4+IFsgICAg MC40OTUyNDJdICBbPGZmZmZmZmZmODEwMDAyOWU+XSBkb19vbmVfaW5pdGNhbGwrMHg0ZS8weDE3 MA0KPiA+PiA+PiBbICAgIDAuNDk1MzI2XSAgWzxmZmZmZmZmZjgxMDcxMTAwPl0gPyBwYXJzZV9h cmdzKzB4NjAvMHgzNjANCj4gPj4gPj4gWyAgICAwLjQ5NTQxMV0gIFs8ZmZmZmZmZmY4MWNmYmZi OD5dDQo+ID4+IGtlcm5lbF9pbml0X2ZyZWVhYmxlKzB4MTA2LzB4MTlhDQo+ID4+ID4+IFsgICAg MC40OTU0OTddICBbPGZmZmZmZmZmODFjZmI4M2I+XSA/IGRvX2Vhcmx5X3BhcmFtKzB4ODYvMHg4 Ng0KPiA+PiA+PiBbICAgIDAuNDk1NTgyXSAgWzxmZmZmZmZmZjgxNjA3ZWYwPl0gPyByZXN0X2lu aXQrMHhkMC8weGQwDQo+ID4+ID4+IFsgICAgMC40OTU2NjZdICBbPGZmZmZmZmZmODE2MDdlZmU+ XSBrZXJuZWxfaW5pdCsweGUvMHhmMA0KPiA+PiA+PiBbICAgIDAuNDk1NzQ5XSAgWzxmZmZmZmZm ZjgxNjIxZjZjPl0gcmV0X2Zyb21fZm9yaysweDdjLzB4YjANCj4gPj4gPj4gWyAgICAwLjQ5NTgz MV0gIFs8ZmZmZmZmZmY4MTYwN2VmMD5dID8gcmVzdF9pbml0KzB4ZDAvMHhkMA0KPiA+PiA+PiBb ICAgIDAuNDk1OTIxXSAtLS1bIGVuZCB0cmFjZSA0MjhmMzY1YzA1NGQ5YTAxIF0tLS0NCj4gPj4g Pj4gWyAgICAwLjQ5NjE5Nl0gUkFQTCBQTVUgZGV0ZWN0ZWQsIGh3IHVuaXQgMl4tMTYgSm91bGVz LCBBUEkgdW5pdA0KPiBpcw0KPiA+PiAyXi0zMiBKb3VsZXMsIDMgZml4ZWQgY291bnRlcnMgMTYz ODQwIG1zIG92ZmwgdGltZXINCj4gPj4gPj4gWyAgICAwLjQ5ODU5OF0gZnV0ZXggaGFzaCB0YWJs ZSBlbnRyaWVzOiAxMDI0IChvcmRlcjogNSwgMTMxMDcyDQo+ID4+IGJ5dGVzKQ0KPiA+PiA+PiBb ICAgIDAuNDk4ODMzXSBhdWRpdDogaW5pdGlhbGl6aW5nIG5ldGxpbmsgc3Vic3lzIChkaXNhYmxl ZCkNCj4gPj4gPj4gWyAgICAwLjQ5OTAyNF0gYXVkaXQ6IHR5cGU9MjAwMCBhdWRpdCgxMzkzMjU5 ODY2LjQ3NzoxKToNCj4gaW5pdGlhbGl6ZWQNCj4gPj4gPj4gLi4uDQo+ID4+ID4+DQo+ID4+ID4+ DQo+ID4+ID4NCj4gPg0K ^ permalink raw reply [flat|nested] 84+ messages in thread
* RE: Info: mapping multiple BARs. Your kernel is fine. @ 2014-03-20 7:53 ` Zhang, Rui 0 siblings, 0 replies; 84+ messages in thread From: Zhang, Rui @ 2014-03-20 7:53 UTC (permalink / raw) To: Stephane Eranian Cc: Lu, Aaron, Rafael J. Wysocki, Borislav Petkov, lkml, x86, Bjorn Helgaas, Linux PCI, ACPI Devel Maling List, Yinghai Lu, H. Peter Anvin, Yan, Zheng Z [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="utf-8", Size: 8026 bytes --] > -----Original Message----- > From: Stephane Eranian [mailto:eranian@google.com] > Sent: Thursday, March 20, 2014 11:35 AM > To: Zhang, Rui > Cc: Lu, Aaron; Rafael J. Wysocki; Borislav Petkov; lkml; x86@kernel.org; > Bjorn Helgaas; Linux PCI; ACPI Devel Maling List; Yinghai Lu; H. Peter > Anvin; Yan, Zheng Z > Subject: Re: Info: mapping multiple BARs. Your kernel is fine. > Importance: High > > On Thu, Mar 20, 2014 at 4:03 AM, Zhang, Rui <rui.zhang@intel.com> wrote: > > > > > >> -----Original Message----- > >> From: Lu, Aaron > >> Sent: Thursday, March 20, 2014 10:24 AM > >> To: Rafael J. Wysocki; Borislav Petkov > >> Cc: lkml; x86@kernel.org; Bjorn Helgaas; Linux PCI; ACPI Devel > Maling > >> List; Zhang, Rui; Yinghai Lu; H. Peter Anvin; Stephane Eranian > >> Subject: Re: Info: mapping multiple BARs. Your kernel is fine. > >> Importance: High > >> > >> On 03/15/2014 10:15 PM, Rafael J. Wysocki wrote: > >> > [CC list rearranged] > >> > > >> > 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 :-) > >> >> > >> >> We have intel_uncore_init, snb_uncore_imc_init_box, > >> >> uncore_pci_probe and other goodies on the stack. > >> > > >> > I've just gone throught this. > >> > > >> > So the problem is that we have the PNP "system" driver whose only > >> > purpose seems to be to reserve system resources so that the PCI > >> > layer doesn't assign them to new devices on hotplug (disclaimer: I > >> > didn't invent it, I only read the code and comments in there). > >> > >> And to PCI devices which have uninitialized BARs. > >> > >> > > >> > It does that for ACPI device objects having the "PNP0C02" and > >> "PNP0C01" IDs. > >> > > >> > Apparently, snb_uncore_imc_init_box() steps on a range already > >> > reserved by that driver on your box. And this doesn't seem to be > a > >> > coincidence, because the ACPI device object in question probably > >> > *does* correspond to the memory controller that the uncore driver > >> attempts to use. > >> > > >> > I'm not sure how to address that right now to be honest. Arguably, > >> > the PNP "system" driver should be replaced with something saner, > >> > but still the resources it claims need to be kept out of reach of > >> > the PCI's resource allocation code. > >> > >> The quirk_system_pci_resources is meant to disable PNP devices' > >> resource if they collide with any known PCI device's BAR. I'm not > >> sure why it doesn't work here, perhaps the uncore PCI device doesn't > >> have a BAR that falls in the PNP device's resource window? > >> > > I've talked with Yan Zheng, and I was told that this resource > "0xfed10000 - 0xfed15fff" > > is got from PCI device register directly, which is not in its BAR > range. > > Thus IMO, it is impossible for PNP layer to be aware of this resource. > > > That is not what the perf_event code does. Nothing is hardcoded except > the IMC PCI device ids. The BAR offset is hardcoded that's all. The > 0xfed10000 is discovered. > The resource length is also hardcoded to 0x6000, right? This is probably a problem, because only if the resource length read from PCI config space is larger than 0x4000, drivers/pnp/quirks.c will detect the conflict and disable the PNP0C02 resource 0xfed10000 - 0xfed13fff, and the PCI device can request this resource successfully. In order to check this, can you please attach the dmesg output after boot? Thanks, rui > > BTW, about drivers/pnp/system.c, if its ONLY purpose is to prevent > > those resources from being allocated to uninitialized PCI devices, > > then IMO, the best way to do this is make PCI bus handle those > > PNP0C01/PNP0C02 resources directly, probably via a platform callback, > > say, 1. make drivers/pnp/system.c a no-op for PNPACPI, by checking > pnp_dev->protocol. > > 2. introduce acpi_check_reserved_resource() to parsing > PNP0C01/PNP0C02 resources. > > 3. in PCI bus, invoke acpi_check_reserved_resource() when assigning > > resources to PCI devices. > > > > Thanks, > > rui > > > >> Thanks, > >> Aaron > >> > >> > > >> >> ... > >> >> [ 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 > >> >> ... > >> >> > >> >> > >> > > > ÿôèº{.nÇ+·®+%Ëÿ±éݶ\x17¥wÿº{.nÇ+·¥{±þG«éÿ{ayº\x1dÊÚë,j\a¢f£¢·hïêÿêçz_è®\x03(éÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?¨èÚ&£ø§~á¶iOæ¬z·vØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?I¥ ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. 2014-03-20 7:53 ` Zhang, Rui (?) (?) @ 2014-03-20 8:16 ` Yan, Zheng 2014-03-20 13:43 ` Zhang Rui 2014-03-20 16:03 ` Stephane Eranian -1 siblings, 2 replies; 84+ messages in thread From: Yan, Zheng @ 2014-03-20 8:16 UTC (permalink / raw) To: Zhang, Rui, Stephane Eranian Cc: Lu, Aaron, Rafael J. Wysocki, Borislav Petkov, lkml, x86, Bjorn Helgaas, Linux PCI, ACPI Devel Maling List, Yinghai Lu, H. Peter Anvin On 03/20/2014 03:53 PM, Zhang, Rui wrote: > The resource length is also hardcoded to 0x6000, right? > This is probably a problem, because > only if the resource length read from PCI config space is larger than 0x4000, > drivers/pnp/quirks.c will detect the conflict and disable the PNP0C02 > resource 0xfed10000 - 0xfed13fff, and the PCI device can request this > resource successfully. > In order to check this, can you please attach the dmesg output after boot? maybe the issue can be fixed by below untested patch --- diff --git a/arch/x86/kernel/cpu/perf_event_intel_uncore.c b/arch/x86/kernel/cpu/perf_event_intel_uncore.c index fd5e883..2b3d834 100644 --- a/arch/x86/kernel/cpu/perf_event_intel_uncore.c +++ b/arch/x86/kernel/cpu/perf_event_intel_uncore.c @@ -1701,7 +1701,7 @@ static struct uncore_event_desc snb_uncore_imc_events[] = { #define SNB_UNCORE_PCI_IMC_BAR_OFFSET 0x48 /* page size multiple covering all config regs */ -#define SNB_UNCORE_PCI_IMC_MAP_SIZE 0x6000 +#define SNB_UNCORE_PCI_IMC_MAP_SIZE 0x8 #define SNB_UNCORE_PCI_IMC_DATA_READS 0x1 #define SNB_UNCORE_PCI_IMC_DATA_READS_BASE 0x5050 @@ -1736,7 +1736,8 @@ static void snb_uncore_imc_init_box(struct intel_uncore_box *box) addr &= ~(PAGE_SIZE - 1); - box->io_addr = ioremap(addr, SNB_UNCORE_PCI_IMC_MAP_SIZE); + box->io_addr = ioremap(addr + SNB_UNCORE_PCI_IMC_CTR_BASE, + SNB_UNCORE_PCI_IMC_MAP_SIZE); box->hrtimer_duration = UNCORE_SNB_IMC_HRTIMER_INTERVAL; } @@ -1832,7 +1833,7 @@ static int snb_uncore_imc_event_init(struct perf_event *event) } /* must be done before validate_group */ - event->hw.event_base = base; + event->hw.event_base = base - SNB_UNCORE_PCI_IMC_CTR_BASE; event->hw.config = cfg; event->hw.idx = idx; ^ permalink raw reply related [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. 2014-03-20 8:16 ` Yan, Zheng @ 2014-03-20 13:43 ` Zhang Rui 2014-03-20 16:03 ` Stephane Eranian 1 sibling, 0 replies; 84+ messages in thread From: Zhang Rui @ 2014-03-20 13:43 UTC (permalink / raw) To: Yan, Zheng Cc: Stephane Eranian, Lu, Aaron, Rafael J. Wysocki, Borislav Petkov, lkml, x86, Bjorn Helgaas, Linux PCI, ACPI Devel Maling List, Yinghai Lu, H. Peter Anvin On Thu, 2014-03-20 at 16:16 +0800, Yan, Zheng wrote: > On 03/20/2014 03:53 PM, Zhang, Rui wrote: > > The resource length is also hardcoded to 0x6000, right? > > This is probably a problem, because > > only if the resource length read from PCI config space is larger than 0x4000, > > drivers/pnp/quirks.c will detect the conflict and disable the PNP0C02 > > resource 0xfed10000 - 0xfed13fff, and the PCI device can request this > > resource successfully. > > In order to check this, can you please attach the dmesg output after boot? > > maybe the issue can be fixed by below untested patch > > --- > diff --git a/arch/x86/kernel/cpu/perf_event_intel_uncore.c b/arch/x86/kernel/cpu/perf_event_intel_uncore.c > index fd5e883..2b3d834 100644 > --- a/arch/x86/kernel/cpu/perf_event_intel_uncore.c > +++ b/arch/x86/kernel/cpu/perf_event_intel_uncore.c > @@ -1701,7 +1701,7 @@ static struct uncore_event_desc snb_uncore_imc_events[] = { > #define SNB_UNCORE_PCI_IMC_BAR_OFFSET 0x48 > > /* page size multiple covering all config regs */ > -#define SNB_UNCORE_PCI_IMC_MAP_SIZE 0x6000 > +#define SNB_UNCORE_PCI_IMC_MAP_SIZE 0x8 > > #define SNB_UNCORE_PCI_IMC_DATA_READS 0x1 > #define SNB_UNCORE_PCI_IMC_DATA_READS_BASE 0x5050 > @@ -1736,7 +1736,8 @@ static void snb_uncore_imc_init_box(struct intel_uncore_box *box) > > addr &= ~(PAGE_SIZE - 1); > > - box->io_addr = ioremap(addr, SNB_UNCORE_PCI_IMC_MAP_SIZE); > + box->io_addr = ioremap(addr + SNB_UNCORE_PCI_IMC_CTR_BASE, > + SNB_UNCORE_PCI_IMC_MAP_SIZE); you're remapping 0xfed15050 - 0xfed1b04f instead of 0xfed10000 - 0xfed15fff ? I do not quite understand this, but apparently this is not a FIX. If it works for this problem, it is because 0xfed15050 - 0xfed1b04f happens to be not conflict with any resource reserved by PNP system driver, on this machine. thanks, rui > box->hrtimer_duration = UNCORE_SNB_IMC_HRTIMER_INTERVAL; > } > > @@ -1832,7 +1833,7 @@ static int snb_uncore_imc_event_init(struct perf_event *event) > } > > /* must be done before validate_group */ > - event->hw.event_base = base; > + event->hw.event_base = base - SNB_UNCORE_PCI_IMC_CTR_BASE; > event->hw.config = cfg; > event->hw.idx = idx; > ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. 2014-03-20 8:16 ` Yan, Zheng 2014-03-20 13:43 ` Zhang Rui @ 2014-03-20 16:03 ` Stephane Eranian 1 sibling, 0 replies; 84+ messages in thread From: Stephane Eranian @ 2014-03-20 16:03 UTC (permalink / raw) To: Yan, Zheng Cc: Zhang, Rui, Lu, Aaron, Rafael J. Wysocki, Borislav Petkov, lkml, x86, Bjorn Helgaas, Linux PCI, ACPI Devel Maling List, Yinghai Lu, H. Peter Anvin On Thu, Mar 20, 2014 at 9:16 AM, Yan, Zheng <zheng.z.yan@intel.com> wrote: > On 03/20/2014 03:53 PM, Zhang, Rui wrote: >> The resource length is also hardcoded to 0x6000, right? >> This is probably a problem, because >> only if the resource length read from PCI config space is larger than 0x4000, >> drivers/pnp/quirks.c will detect the conflict and disable the PNP0C02 >> resource 0xfed10000 - 0xfed13fff, and the PCI device can request this >> resource successfully. >> In order to check this, can you please attach the dmesg output after boot? > > maybe the issue can be fixed by below untested patch > > --- > diff --git a/arch/x86/kernel/cpu/perf_event_intel_uncore.c b/arch/x86/kernel/cpu/perf_event_intel_uncore.c > index fd5e883..2b3d834 100644 > --- a/arch/x86/kernel/cpu/perf_event_intel_uncore.c > +++ b/arch/x86/kernel/cpu/perf_event_intel_uncore.c > @@ -1701,7 +1701,7 @@ static struct uncore_event_desc snb_uncore_imc_events[] = { > #define SNB_UNCORE_PCI_IMC_BAR_OFFSET 0x48 > > /* page size multiple covering all config regs */ > -#define SNB_UNCORE_PCI_IMC_MAP_SIZE 0x6000 > +#define SNB_UNCORE_PCI_IMC_MAP_SIZE 0x8 > I assume ioremap() works on page boundaries. Eventually want to expose the other counters too, not just read and writes ( 8 bytes total). The size of 0x6000 comes from the counter offsets: BAR + 0x5040 to BAR + 0x5054. May be a better way of doing this would be to remap just the one page holding them instead of the 6 covering the entire BAR + counters. That would need changes in the read_counter() but that is okay. So that would something along the line of: addr = (addr + 0x5040) & (PAGE_SIZE - 1); ioremap(addr, 0x1000); > #define SNB_UNCORE_PCI_IMC_DATA_READS 0x1 > #define SNB_UNCORE_PCI_IMC_DATA_READS_BASE 0x5050 > @@ -1736,7 +1736,8 @@ static void snb_uncore_imc_init_box(struct intel_uncore_box *box) > > addr &= ~(PAGE_SIZE - 1); > > - box->io_addr = ioremap(addr, SNB_UNCORE_PCI_IMC_MAP_SIZE); > + box->io_addr = ioremap(addr + SNB_UNCORE_PCI_IMC_CTR_BASE, > + SNB_UNCORE_PCI_IMC_MAP_SIZE); > box->hrtimer_duration = UNCORE_SNB_IMC_HRTIMER_INTERVAL; > } > > @@ -1832,7 +1833,7 @@ static int snb_uncore_imc_event_init(struct perf_event *event) > } > > /* must be done before validate_group */ > - event->hw.event_base = base; > + event->hw.event_base = base - SNB_UNCORE_PCI_IMC_CTR_BASE; > event->hw.config = cfg; > event->hw.idx = idx; > ^ permalink raw reply [flat|nested] 84+ messages in thread
* RE: Info: mapping multiple BARs. Your kernel is fine. 2014-03-20 7:53 ` Zhang, Rui @ 2014-03-20 13:35 ` Zhang Rui -1 siblings, 0 replies; 84+ messages in thread From: Zhang Rui @ 2014-03-20 13:35 UTC (permalink / raw) To: Stephane Eranian Cc: Lu, Aaron, Rafael J. Wysocki, Borislav Petkov, lkml, x86, Bjorn Helgaas, Linux PCI, ACPI Devel Maling List, Yinghai Lu, H. Peter Anvin, Yan, Zheng Z On Thu, 2014-03-20 at 07:53 +0000, Zhang, Rui wrote: > > > -----Original Message----- > > From: Stephane Eranian [mailto:eranian@google.com] > > Sent: Thursday, March 20, 2014 11:35 AM > > To: Zhang, Rui > > Cc: Lu, Aaron; Rafael J. Wysocki; Borislav Petkov; lkml; x86@kernel.org; > > Bjorn Helgaas; Linux PCI; ACPI Devel Maling List; Yinghai Lu; H. Peter > > Anvin; Yan, Zheng Z > > Subject: Re: Info: mapping multiple BARs. Your kernel is fine. > > Importance: High > > > > On Thu, Mar 20, 2014 at 4:03 AM, Zhang, Rui <rui.zhang@intel.com> wrote: > > > > > > > > >> -----Original Message----- > > >> From: Lu, Aaron > > >> Sent: Thursday, March 20, 2014 10:24 AM > > >> To: Rafael J. Wysocki; Borislav Petkov > > >> Cc: lkml; x86@kernel.org; Bjorn Helgaas; Linux PCI; ACPI Devel > > Maling > > >> List; Zhang, Rui; Yinghai Lu; H. Peter Anvin; Stephane Eranian > > >> Subject: Re: Info: mapping multiple BARs. Your kernel is fine. > > >> Importance: High > > >> > > >> On 03/15/2014 10:15 PM, Rafael J. Wysocki wrote: > > >> > [CC list rearranged] > > >> > > > >> > 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 :-) > > >> >> > > >> >> We have intel_uncore_init, snb_uncore_imc_init_box, > > >> >> uncore_pci_probe and other goodies on the stack. > > >> > > > >> > I've just gone throught this. > > >> > > > >> > So the problem is that we have the PNP "system" driver whose only > > >> > purpose seems to be to reserve system resources so that the PCI > > >> > layer doesn't assign them to new devices on hotplug (disclaimer: I > > >> > didn't invent it, I only read the code and comments in there). > > >> > > >> And to PCI devices which have uninitialized BARs. > > >> > > >> > > > >> > It does that for ACPI device objects having the "PNP0C02" and > > >> "PNP0C01" IDs. > > >> > > > >> > Apparently, snb_uncore_imc_init_box() steps on a range already > > >> > reserved by that driver on your box. And this doesn't seem to be > > a > > >> > coincidence, because the ACPI device object in question probably > > >> > *does* correspond to the memory controller that the uncore driver > > >> attempts to use. > > >> > > > >> > I'm not sure how to address that right now to be honest. Arguably, > > >> > the PNP "system" driver should be replaced with something saner, > > >> > but still the resources it claims need to be kept out of reach of > > >> > the PCI's resource allocation code. > > >> > > >> The quirk_system_pci_resources is meant to disable PNP devices' > > >> resource if they collide with any known PCI device's BAR. I'm not > > >> sure why it doesn't work here, perhaps the uncore PCI device doesn't > > >> have a BAR that falls in the PNP device's resource window? > > >> > > > I've talked with Yan Zheng, and I was told that this resource > > "0xfed10000 - 0xfed15fff" > > > is got from PCI device register directly, which is not in its BAR > > range. > > > Thus IMO, it is impossible for PNP layer to be aware of this resource. > > > > > That is not what the perf_event code does. Nothing is hardcoded except > > the IMC PCI device ids. The BAR offset is hardcoded that's all. The > > 0xfed10000 is discovered. > > > The resource length is also hardcoded to 0x6000, right? > This is probably a problem, because > only if the resource length read from PCI config space is larger than 0x4000, > drivers/pnp/quirks.c will detect the conflict and disable the PNP0C02 > resource 0xfed10000 - 0xfed13fff, and the PCI device can request this > resource successfully. > In order to check this, can you please attach the dmesg output after boot? > sorry, one correction here, I should say, if the resource length read from PCI config space is smaller than 0x4000, the problem still exists because drivers/pnp/quirks.c do not think this is a conflict. But if the resource length read from PCI config space is larger than 0x4000, drivers/pnp/quirks.c can detect this conflict and prevent resource 0xfed10000 - 0xfed13fff from being reserved. thanks, rui > Thanks, > rui > > > > BTW, about drivers/pnp/system.c, if its ONLY purpose is to prevent > > > those resources from being allocated to uninitialized PCI devices, > > > then IMO, the best way to do this is make PCI bus handle those > > > PNP0C01/PNP0C02 resources directly, probably via a platform callback, > > > say, 1. make drivers/pnp/system.c a no-op for PNPACPI, by checking > > pnp_dev->protocol. > > > 2. introduce acpi_check_reserved_resource() to parsing > > PNP0C01/PNP0C02 resources. > > > 3. in PCI bus, invoke acpi_check_reserved_resource() when assigning > > > resources to PCI devices. > > > > > > Thanks, > > > rui > > > > > >> Thanks, > > >> Aaron > > >> > > >> > > > >> >> ... > > >> >> [ 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 > > >> >> ... > > >> >> > > >> >> > > >> > > > > > N�����r��y���b�X��ǧv�^�){.n�+����{�i�b�{ay�\x1dʇڙ�,j\a��f���h���z�\x1e�w���\f���j:+v���w�j�m����\a����zZ+�����ݢj"��!�i -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 84+ messages in thread
* RE: Info: mapping multiple BARs. Your kernel is fine. @ 2014-03-20 13:35 ` Zhang Rui 0 siblings, 0 replies; 84+ messages in thread From: Zhang Rui @ 2014-03-20 13:35 UTC (permalink / raw) To: Stephane Eranian Cc: Lu, Aaron, Rafael J. Wysocki, Borislav Petkov, lkml, x86, Bjorn Helgaas, Linux PCI, ACPI Devel Maling List, Yinghai Lu, H. Peter Anvin, Yan, Zheng Z On Thu, 2014-03-20 at 07:53 +0000, Zhang, Rui wrote: > > > -----Original Message----- > > From: Stephane Eranian [mailto:eranian@google.com] > > Sent: Thursday, March 20, 2014 11:35 AM > > To: Zhang, Rui > > Cc: Lu, Aaron; Rafael J. Wysocki; Borislav Petkov; lkml; x86@kernel.org; > > Bjorn Helgaas; Linux PCI; ACPI Devel Maling List; Yinghai Lu; H. Peter > > Anvin; Yan, Zheng Z > > Subject: Re: Info: mapping multiple BARs. Your kernel is fine. > > Importance: High > > > > On Thu, Mar 20, 2014 at 4:03 AM, Zhang, Rui <rui.zhang@intel.com> wrote: > > > > > > > > >> -----Original Message----- > > >> From: Lu, Aaron > > >> Sent: Thursday, March 20, 2014 10:24 AM > > >> To: Rafael J. Wysocki; Borislav Petkov > > >> Cc: lkml; x86@kernel.org; Bjorn Helgaas; Linux PCI; ACPI Devel > > Maling > > >> List; Zhang, Rui; Yinghai Lu; H. Peter Anvin; Stephane Eranian > > >> Subject: Re: Info: mapping multiple BARs. Your kernel is fine. > > >> Importance: High > > >> > > >> On 03/15/2014 10:15 PM, Rafael J. Wysocki wrote: > > >> > [CC list rearranged] > > >> > > > >> > 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 :-) > > >> >> > > >> >> We have intel_uncore_init, snb_uncore_imc_init_box, > > >> >> uncore_pci_probe and other goodies on the stack. > > >> > > > >> > I've just gone throught this. > > >> > > > >> > So the problem is that we have the PNP "system" driver whose only > > >> > purpose seems to be to reserve system resources so that the PCI > > >> > layer doesn't assign them to new devices on hotplug (disclaimer: I > > >> > didn't invent it, I only read the code and comments in there). > > >> > > >> And to PCI devices which have uninitialized BARs. > > >> > > >> > > > >> > It does that for ACPI device objects having the "PNP0C02" and > > >> "PNP0C01" IDs. > > >> > > > >> > Apparently, snb_uncore_imc_init_box() steps on a range already > > >> > reserved by that driver on your box. And this doesn't seem to be > > a > > >> > coincidence, because the ACPI device object in question probably > > >> > *does* correspond to the memory controller that the uncore driver > > >> attempts to use. > > >> > > > >> > I'm not sure how to address that right now to be honest. Arguably, > > >> > the PNP "system" driver should be replaced with something saner, > > >> > but still the resources it claims need to be kept out of reach of > > >> > the PCI's resource allocation code. > > >> > > >> The quirk_system_pci_resources is meant to disable PNP devices' > > >> resource if they collide with any known PCI device's BAR. I'm not > > >> sure why it doesn't work here, perhaps the uncore PCI device doesn't > > >> have a BAR that falls in the PNP device's resource window? > > >> > > > I've talked with Yan Zheng, and I was told that this resource > > "0xfed10000 - 0xfed15fff" > > > is got from PCI device register directly, which is not in its BAR > > range. > > > Thus IMO, it is impossible for PNP layer to be aware of this resource. > > > > > That is not what the perf_event code does. Nothing is hardcoded except > > the IMC PCI device ids. The BAR offset is hardcoded that's all. The > > 0xfed10000 is discovered. > > > The resource length is also hardcoded to 0x6000, right? > This is probably a problem, because > only if the resource length read from PCI config space is larger than 0x4000, > drivers/pnp/quirks.c will detect the conflict and disable the PNP0C02 > resource 0xfed10000 - 0xfed13fff, and the PCI device can request this > resource successfully. > In order to check this, can you please attach the dmesg output after boot? > sorry, one correction here, I should say, if the resource length read from PCI config space is smaller than 0x4000, the problem still exists because drivers/pnp/quirks.c do not think this is a conflict. But if the resource length read from PCI config space is larger than 0x4000, drivers/pnp/quirks.c can detect this conflict and prevent resource 0xfed10000 - 0xfed13fff from being reserved. thanks, rui > Thanks, > rui > > > > BTW, about drivers/pnp/system.c, if its ONLY purpose is to prevent > > > those resources from being allocated to uninitialized PCI devices, > > > then IMO, the best way to do this is make PCI bus handle those > > > PNP0C01/PNP0C02 resources directly, probably via a platform callback, > > > say, 1. make drivers/pnp/system.c a no-op for PNPACPI, by checking > > pnp_dev->protocol. > > > 2. introduce acpi_check_reserved_resource() to parsing > > PNP0C01/PNP0C02 resources. > > > 3. in PCI bus, invoke acpi_check_reserved_resource() when assigning > > > resources to PCI devices. > > > > > > Thanks, > > > rui > > > > > >> Thanks, > > >> Aaron > > >> > > >> > > > >> >> ... > > >> >> [ 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 > > >> >> ... > > >> >> > > >> >> > > >> > > > > > N�����r��y���b�X��ǧv�^�){.n�+����{�i�b�{ay�\x1dʇڙ�,j\a��f���h���z�\x1e�w���\f���j:+v���w�j�m����\a����zZ+�����ݢj"��!�i ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. 2014-03-20 3:03 ` Zhang, Rui ` (2 preceding siblings ...) (?) @ 2014-03-20 12:29 ` Rafael J. Wysocki -1 siblings, 0 replies; 84+ messages in thread From: Rafael J. Wysocki @ 2014-03-20 12:29 UTC (permalink / raw) To: Zhang, Rui Cc: Lu, Aaron, Borislav Petkov, lkml, x86, Bjorn Helgaas, Linux PCI, ACPI Devel Maling List, Yinghai Lu, H. Peter Anvin, Stephane Eranian, Yan, Zheng Z On Thursday, March 20, 2014 03:03:45 AM Zhang, Rui wrote: > > > -----Original Message----- > > From: Lu, Aaron > > Sent: Thursday, March 20, 2014 10:24 AM > > To: Rafael J. Wysocki; Borislav Petkov > > Cc: lkml; x86@kernel.org; Bjorn Helgaas; Linux PCI; ACPI Devel Maling > > List; Zhang, Rui; Yinghai Lu; H. Peter Anvin; Stephane Eranian > > Subject: Re: Info: mapping multiple BARs. Your kernel is fine. > > Importance: High > > > > On 03/15/2014 10:15 PM, Rafael J. Wysocki wrote: > > > [CC list rearranged] > > > > > > 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 :-) > > >> > > >> We have intel_uncore_init, snb_uncore_imc_init_box, uncore_pci_probe > > >> and other goodies on the stack. > > > > > > I've just gone throught this. > > > > > > So the problem is that we have the PNP "system" driver whose only > > > purpose seems to be to reserve system resources so that the PCI layer > > > doesn't assign them to new devices on hotplug (disclaimer: I didn't > > > invent it, I only read the code and comments in there). > > > > And to PCI devices which have uninitialized BARs. > > > > > > > > It does that for ACPI device objects having the "PNP0C02" and > > "PNP0C01" IDs. > > > > > > Apparently, snb_uncore_imc_init_box() steps on a range already > > > reserved by that driver on your box. And this doesn't seem to be a > > > coincidence, because the ACPI device object in question probably > > > *does* correspond to the memory controller that the uncore driver > > attempts to use. > > > > > > I'm not sure how to address that right now to be honest. Arguably, > > > the PNP "system" driver should be replaced with something saner, but > > > still the resources it claims need to be kept out of reach of the > > > PCI's resource allocation code. > > > > The quirk_system_pci_resources is meant to disable PNP devices' > > resource if they collide with any known PCI device's BAR. I'm not sure > > why it doesn't work here, perhaps the uncore PCI device doesn't have a > > BAR that falls in the PNP device's resource window? > > > I've talked with Yan Zheng, and I was told that this resource "0xfed10000 - 0xfed15fff" > is got from PCI device register directly, which is not in its BAR range. > Thus IMO, it is impossible for PNP layer to be aware of this resource. > > BTW, about drivers/pnp/system.c, if its ONLY purpose is to prevent those > resources from being allocated to uninitialized PCI devices, then IMO, > the best way to do this is make PCI bus handle those PNP0C01/PNP0C02 > resources directly, probably via a platform callback, say, > 1. make drivers/pnp/system.c a no-op for PNPACPI, by checking pnp_dev->protocol. Then we can drop drivers/pnp/system.c entirely I think. > 2. introduce acpi_check_reserved_resource() to parsing PNP0C01/PNP0C02 resources. > 3. in PCI bus, invoke acpi_check_reserved_resource() when assigning > resources to PCI devices. Well, sounds reasonable. > > > > > >> ... > > >> [ 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 > > >> ... > > >> > > >> > > > > > N�����r��y����b�X��ǧv�^�){.n�+����{�i�b�{ay�\x1dʇڙ�,j\a��f���h���z�\x1e�w���\f���j:+v���w�j�m����\a����zZ+�����ݢj"��!�ir -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. 2014-03-20 3:03 ` Zhang, Rui ` (3 preceding siblings ...) (?) @ 2014-03-20 16:45 ` Bjorn Helgaas 2014-03-20 20:55 ` Rafael J. Wysocki -1 siblings, 1 reply; 84+ messages in thread From: Bjorn Helgaas @ 2014-03-20 16:45 UTC (permalink / raw) To: Zhang, Rui Cc: Lu, Aaron, Rafael J. Wysocki, Borislav Petkov, lkml, x86, Linux PCI, ACPI Devel Maling List, Yinghai Lu, H. Peter Anvin, Stephane Eranian, Yan, Zheng Z On Wed, Mar 19, 2014 at 9:03 PM, Zhang, Rui <rui.zhang@intel.com> wrote: > I've talked with Yan Zheng, and I was told that this resource "0xfed10000 - 0xfed15fff" > is got from PCI device register directly, which is not in its BAR range. > Thus IMO, it is impossible for PNP layer to be aware of this resource. Slow down, this isn't quite correct. The *base* address (0xfed10000) is from a PCI config register (MCHBAR, at PCI config offset 0x48) [1]. This is a device-dependent register, so the PCI core knows neither the base nor the size. The device consumes address space that is not reported via the architected PCI mechanism, so the only way to report that space is via the PNP0C02 ACPI device. The BIOS has to determine the base and size based on its knowledge of the hardware. On this hardware, per the spec in [1], the region described by MCHBAR is 32KB in size. The 0x6000 (24KB) size of the region above comes from the driver and is actually less than what the device consumes. It is legal for a driver to request only the area it requires, but the entire area consumed by the device should be reported via the PNP0C02 device. The fact that PNP0C02 reports 16KB but the device actually consumes 32KB is a BIOS defect. This probably happened because previous versions of this chip consumed only 16KB, and the BIOS didn't get updated for the change. > BTW, about drivers/pnp/system.c, if its ONLY purpose is to prevent those > resources from being allocated to uninitialized PCI devices, then IMO, > the best way to do this is make PCI bus handle those PNP0C01/PNP0C02 > resources directly, probably via a platform callback, say, > 1. make drivers/pnp/system.c a no-op for PNPACPI, by checking pnp_dev->protocol. > 2. introduce acpi_check_reserved_resource() to parsing PNP0C01/PNP0C02 resources. > 3. in PCI bus, invoke acpi_check_reserved_resource() when assigning > resources to PCI devices. The purpose of system.c is indeed to prevent resources from being allocated to other devices. This is really a question for Rafael, but in my opinion this function (reserving resources of PNP/ACPI devices to prevent their allocation to other devices) should be done for *all* PNP and ACPI devices, not just the PNP0C01/PNP0C02 devices handled by system.c. So I think the best solution would be to move that into the ACPI core somehow so it happens for all devices. If we had that, we could get rid of system.c altogether, and we wouldn't have to do anything special in PCI. This is much easier to say than to do, however, because there are all kinds of issues with legacy resource reservations, and we currently can't really deal with overlapping resources. Bjorn [1] https://www-ssl.intel.com/content/www/us/en/processors/core/4th-gen-core-family-desktop-vol-2-datasheet, sec. 3.1.2 on p. 61 ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. 2014-03-20 16:45 ` Bjorn Helgaas @ 2014-03-20 20:55 ` Rafael J. Wysocki 2014-03-20 20:48 ` Bjorn Helgaas 0 siblings, 1 reply; 84+ messages in thread From: Rafael J. Wysocki @ 2014-03-20 20:55 UTC (permalink / raw) To: Bjorn Helgaas Cc: Zhang, Rui, Lu, Aaron, Borislav Petkov, lkml, x86, Linux PCI, ACPI Devel Maling List, Yinghai Lu, H. Peter Anvin, Stephane Eranian, Yan, Zheng Z On Thursday, March 20, 2014 10:45:52 AM Bjorn Helgaas wrote: > On Wed, Mar 19, 2014 at 9:03 PM, Zhang, Rui <rui.zhang@intel.com> wrote: > > > I've talked with Yan Zheng, and I was told that this resource "0xfed10000 - 0xfed15fff" > > is got from PCI device register directly, which is not in its BAR range. > > Thus IMO, it is impossible for PNP layer to be aware of this resource. > > Slow down, this isn't quite correct. The *base* address (0xfed10000) > is from a PCI config register (MCHBAR, at PCI config offset 0x48) [1]. > This is a device-dependent register, so the PCI core knows neither > the base nor the size. > > The device consumes address space that is not reported via the > architected PCI mechanism, so the only way to report that space is via > the PNP0C02 ACPI device. The BIOS has to determine the base and size > based on its knowledge of the hardware. On this hardware, per the > spec in [1], the region described by MCHBAR is 32KB in size. > > The 0x6000 (24KB) size of the region above comes from the driver and > is actually less than what the device consumes. It is legal for a > driver to request only the area it requires, but the entire area > consumed by the device should be reported via the PNP0C02 device. The > fact that PNP0C02 reports 16KB but the device actually consumes 32KB > is a BIOS defect. This probably happened because previous versions of > this chip consumed only 16KB, and the BIOS didn't get updated for the > change. > > > BTW, about drivers/pnp/system.c, if its ONLY purpose is to prevent those > > resources from being allocated to uninitialized PCI devices, then IMO, > > the best way to do this is make PCI bus handle those PNP0C01/PNP0C02 > > resources directly, probably via a platform callback, say, > > 1. make drivers/pnp/system.c a no-op for PNPACPI, by checking pnp_dev->protocol. > > 2. introduce acpi_check_reserved_resource() to parsing PNP0C01/PNP0C02 resources. > > 3. in PCI bus, invoke acpi_check_reserved_resource() when assigning > > resources to PCI devices. > > The purpose of system.c is indeed to prevent resources from being > allocated to other devices. This is really a question for Rafael, but > in my opinion this function (reserving resources of PNP/ACPI devices > to prevent their allocation to other devices) should be done for *all* > PNP and ACPI devices, not just the PNP0C01/PNP0C02 devices handled by > system.c. > > So I think the best solution would be to move that into the ACPI core > somehow so it happens for all devices. Well, I think you got to the bottom of this, but that's something we can do long-term. Still, we need to find a short-term solution for the particular issue at hand. > If we had that, we could get > rid of system.c altogether, and we wouldn't have to do anything > special in PCI. This is much easier to say than to do, however, > because there are all kinds of issues with legacy resource > reservations, and we currently can't really deal with overlapping > resources. Indeed. All above said, appended is the relevant piece of the DSDT from the machine in question (and that is in the PCI host bridge scope). So we have a PCI device with an ACPI object called LPC which has a child called SIO and the _HID of that child is "PNP0C02". I'm not sure if the way system.c handles this is correct in this particular case to be honest. Device (LPC) { Name (_ADR, 0x001F0000) Name (_S3D, 0x03) Name (RID, 0x00) Device (SIO) { Name (_HID, EisaId ("PNP0C02")) Name (_UID, 0x00) Name (SCRS, ResourceTemplate () { IO (Decode16, 0x0010, // Range Minimum 0x0010, // Range Maximum 0x01, // Alignment 0x10, // Length ) IO (Decode16, 0x0090, // Range Minimum 0x0090, // Range Maximum 0x01, // Alignment 0x10, // Length ) IO (Decode16, 0x0024, // Range Minimum 0x0024, // Range Maximum 0x01, // Alignment 0x02, // Length ) IO (Decode16, 0x0028, // Range Minimum 0x0028, // Range Maximum 0x01, // Alignment 0x02, // Length ) IO (Decode16, 0x002C, // Range Minimum 0x002C, // Range Maximum 0x01, // Alignment 0x02, // Length ) IO (Decode16, 0x0030, // Range Minimum 0x0030, // Range Maximum 0x01, // Alignment 0x02, // Length ) IO (Decode16, 0x0034, // Range Minimum 0x0034, // Range Maximum 0x01, // Alignment 0x02, // Length ) IO (Decode16, 0x0038, // Range Minimum 0x0038, // Range Maximum 0x01, // Alignment 0x02, // Length ) IO (Decode16, 0x003C, // Range Minimum 0x003C, // Range Maximum 0x01, // Alignment 0x02, // Length ) IO (Decode16, 0x00A4, // Range Minimum 0x00A4, // Range Maximum 0x01, // Alignment 0x02, // Length ) IO (Decode16, 0x00A8, // Range Minimum 0x00A8, // Range Maximum 0x01, // Alignment 0x02, // Length ) IO (Decode16, 0x00AC, // Range Minimum 0x00AC, // Range Maximum 0x01, // Alignment 0x02, // Length ) IO (Decode16, 0x00B0, // Range Minimum 0x00B0, // Range Maximum 0x01, // Alignment 0x06, // Length ) IO (Decode16, 0x00B8, // Range Minimum 0x00B8, // Range Maximum 0x01, // Alignment 0x02, // Length ) IO (Decode16, 0x00BC, // Range Minimum 0x00BC, // Range Maximum 0x01, // Alignment 0x02, // Length ) IO (Decode16, 0x0050, // Range Minimum 0x0050, // Range Maximum 0x01, // Alignment 0x04, // Length ) IO (Decode16, 0x0072, // Range Minimum 0x0072, // Range Maximum 0x01, // Alignment 0x06, // Length ) IO (Decode16, 0x0400, // Range Minimum 0x0400, // Range Maximum 0x01, // Alignment 0x80, // Length ) IO (Decode16, 0x0500, // Range Minimum 0x0500, // Range Maximum 0x01, // Alignment 0x80, // Length ) IO (Decode16, 0x0800, // Range Minimum 0x0800, // Range Maximum 0x01, // Alignment 0x10, // Length ) IO (Decode16, 0x15E0, // Range Minimum 0x15E0, // Range Maximum 0x01, // Alignment 0x10, // Length ) IO (Decode16, 0x1600, // Range Minimum 0x1600, // Range Maximum 0x01, // Alignment 0x80, // Length ) Memory32Fixed (ReadWrite, 0xF8000000, // Address Base 0x04000000, // Address Length ) Memory32Fixed (ReadWrite, 0x00000000, // Address Base 0x00001000, // Address Length _Y26) Memory32Fixed (ReadWrite, 0xFED1C000, // Address Base 0x00004000, // Address Length ) Memory32Fixed (ReadWrite, 0xFED10000, // Address Base 0x00004000, // Address Length ) Memory32Fixed (ReadWrite, 0xFED18000, // Address Base 0x00001000, // Address Length ) Memory32Fixed (ReadWrite, 0xFED19000, // Address Base 0x00001000, // Address Length ) Memory32Fixed (ReadWrite, 0xFED45000, // Address Base 0x00007000, // Address Length ) }) CreateDWordField (SCRS, \_SB.PCI0.LPC.SIO._Y26._BAS, TRMB) Method (_CRS, 0, NotSerialized) { Store (\TBAB, TRMB) If (LEqual (\_SB.PCI0.LPC.TPM._STA (), 0x0F)) { Return (SCRS) } Else { Subtract (SizeOf (SCRS), 0x02, Local0) Name (BUF0, Buffer (Local0) {}) Add (Local0, SizeOf (\_SB.PCI0.LPC.TPM.BUF1), Local0) Name (BUF1, Buffer (Local0) {}) Store (SCRS, BUF0) Concatenate (BUF0, \_SB.PCI0.LPC.TPM.BUF1, BUF1) Return (BUF1) } } } ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. 2014-03-20 20:55 ` Rafael J. Wysocki @ 2014-03-20 20:48 ` Bjorn Helgaas 2014-04-16 19:04 ` Borislav Petkov 0 siblings, 1 reply; 84+ messages in thread From: Bjorn Helgaas @ 2014-03-20 20:48 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Zhang, Rui, Lu, Aaron, Borislav Petkov, lkml, x86, Linux PCI, ACPI Devel Maling List, Yinghai Lu, H. Peter Anvin, Stephane Eranian, Yan, Zheng Z On Thu, Mar 20, 2014 at 2:55 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote: > On Thursday, March 20, 2014 10:45:52 AM Bjorn Helgaas wrote: >> The purpose of system.c is indeed to prevent resources from being >> allocated to other devices. This is really a question for Rafael, but >> in my opinion this function (reserving resources of PNP/ACPI devices >> to prevent their allocation to other devices) should be done for *all* >> PNP and ACPI devices, not just the PNP0C01/PNP0C02 devices handled by >> system.c. >> >> So I think the best solution would be to move that into the ACPI core >> somehow so it happens for all devices. > > Well, I think you got to the bottom of this, but that's something we can > do long-term. Still, we need to find a short-term solution for the > particular issue at hand. Right. Even if we had this long-term solution, we'd still have Stephane's current problem, because the PNP0C02 _CRS is still wrong. We do have a drivers/pnp/quirks.c where we could conceivably adjust the PNP resource if we found the matching PCI device and MCHBAR. That should solve Stephane's problem even with the current drivers/pnp/system.c. Bjorn ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. 2014-03-20 20:48 ` Bjorn Helgaas @ 2014-04-16 19:04 ` Borislav Petkov 2014-04-16 20:24 ` Zhang, Rui 2014-04-16 20:31 ` Bjorn Helgaas 0 siblings, 2 replies; 84+ messages in thread From: Borislav Petkov @ 2014-04-16 19:04 UTC (permalink / raw) To: Bjorn Helgaas, Rafael J. Wysocki Cc: Zhang, Rui, Lu, Aaron, lkml, x86, Linux PCI, ACPI Devel Maling List, Yinghai Lu, H. Peter Anvin, Stephane Eranian, Yan, Zheng Z On Thu, Mar 20, 2014 at 02:48:30PM -0600, Bjorn Helgaas wrote: > Right. Even if we had this long-term solution, we'd still have > Stephane's current problem, because the PNP0C02 _CRS is still wrong. > > We do have a drivers/pnp/quirks.c where we could conceivably adjust > the PNP resource if we found the matching PCI device and MCHBAR. That > should solve Stephane's problem even with the current > drivers/pnp/system.c. Guys, this still triggers in -rc1. Do we have a fix or something testable at least? Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- ^ permalink raw reply [flat|nested] 84+ messages in thread
* RE: Info: mapping multiple BARs. Your kernel is fine. 2014-04-16 19:04 ` Borislav Petkov 2014-04-16 20:24 ` Zhang, Rui @ 2014-04-16 20:24 ` Zhang, Rui 1 sibling, 0 replies; 84+ messages in thread From: Zhang, Rui @ 2014-04-16 20:24 UTC (permalink / raw) To: Borislav Petkov, Bjorn Helgaas, Rafael J. Wysocki Cc: Lu, Aaron, lkml, x86, Linux PCI, ACPI Devel Maling List, Yinghai Lu, H. Peter Anvin, Stephane Eranian, Yan, Zheng Z > -----Original Message----- > From: Borislav Petkov [mailto:bp@alien8.de] > Sent: Wednesday, April 16, 2014 12:04 PM > To: Bjorn Helgaas; Rafael J. Wysocki > Cc: Zhang, Rui; Lu, Aaron; lkml; x86@kernel.org; Linux PCI; ACPI Devel > Maling List; Yinghai Lu; H. Peter Anvin; Stephane Eranian; Yan, Zheng Z > Subject: Re: Info: mapping multiple BARs. Your kernel is fine. > Importance: High > > On Thu, Mar 20, 2014 at 02:48:30PM -0600, Bjorn Helgaas wrote: > > Right. Even if we had this long-term solution, we'd still have > > Stephane's current problem, because the PNP0C02 _CRS is still wrong. > > > > We do have a drivers/pnp/quirks.c where we could conceivably adjust > > the PNP resource if we found the matching PCI device and MCHBAR. > That > > should solve Stephane's problem even with the current > > drivers/pnp/system.c. > > Guys, this still triggers in -rc1. Do we have a fix or something > testable at least? > Could you please attach the dmesg output after a fresh boot in -rc1? Thanks, rui > Thanks. > > -- > Regards/Gruss, > Boris. > > Sent from a fat crate under my desk. Formatting is fine. > -- ^ permalink raw reply [flat|nested] 84+ messages in thread
* RE: Info: mapping multiple BARs. Your kernel is fine. @ 2014-04-16 20:24 ` Zhang, Rui 0 siblings, 0 replies; 84+ messages in thread From: Zhang, Rui @ 2014-04-16 20:24 UTC (permalink / raw) To: Borislav Petkov, Bjorn Helgaas, Rafael J. Wysocki Cc: Lu, Aaron, lkml, x86, Linux PCI, ACPI Devel Maling List, Yinghai Lu, H. Peter Anvin, Stephane Eranian, Yan, Zheng Z DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQm9yaXNsYXYgUGV0a292 IFttYWlsdG86YnBAYWxpZW44LmRlXQ0KPiBTZW50OiBXZWRuZXNkYXksIEFwcmlsIDE2LCAyMDE0 IDEyOjA0IFBNDQo+IFRvOiBCam9ybiBIZWxnYWFzOyBSYWZhZWwgSi4gV3lzb2NraQ0KPiBDYzog WmhhbmcsIFJ1aTsgTHUsIEFhcm9uOyBsa21sOyB4ODZAa2VybmVsLm9yZzsgTGludXggUENJOyBB Q1BJIERldmVsDQo+IE1hbGluZyBMaXN0OyBZaW5naGFpIEx1OyBILiBQZXRlciBBbnZpbjsgU3Rl cGhhbmUgRXJhbmlhbjsgWWFuLCBaaGVuZyBaDQo+IFN1YmplY3Q6IFJlOiBJbmZvOiBtYXBwaW5n IG11bHRpcGxlIEJBUnMuIFlvdXIga2VybmVsIGlzIGZpbmUuDQo+IEltcG9ydGFuY2U6IEhpZ2gN Cj4gDQo+IE9uIFRodSwgTWFyIDIwLCAyMDE0IGF0IDAyOjQ4OjMwUE0gLTA2MDAsIEJqb3JuIEhl bGdhYXMgd3JvdGU6DQo+ID4gUmlnaHQuICBFdmVuIGlmIHdlIGhhZCB0aGlzIGxvbmctdGVybSBz b2x1dGlvbiwgd2UnZCBzdGlsbCBoYXZlDQo+ID4gU3RlcGhhbmUncyBjdXJyZW50IHByb2JsZW0s IGJlY2F1c2UgdGhlIFBOUDBDMDIgX0NSUyBpcyBzdGlsbCB3cm9uZy4NCj4gPg0KPiA+IFdlIGRv IGhhdmUgYSBkcml2ZXJzL3BucC9xdWlya3MuYyB3aGVyZSB3ZSBjb3VsZCBjb25jZWl2YWJseSBh ZGp1c3QNCj4gPiB0aGUgUE5QIHJlc291cmNlIGlmIHdlIGZvdW5kIHRoZSBtYXRjaGluZyBQQ0kg ZGV2aWNlIGFuZCBNQ0hCQVIuDQo+IFRoYXQNCj4gPiBzaG91bGQgc29sdmUgU3RlcGhhbmUncyBw cm9ibGVtIGV2ZW4gd2l0aCB0aGUgY3VycmVudA0KPiA+IGRyaXZlcnMvcG5wL3N5c3RlbS5jLg0K PiANCj4gR3V5cywgdGhpcyBzdGlsbCB0cmlnZ2VycyBpbiAtcmMxLiBEbyB3ZSBoYXZlIGEgZml4 IG9yIHNvbWV0aGluZw0KPiB0ZXN0YWJsZSBhdCBsZWFzdD8NCj4gDQpDb3VsZCB5b3UgcGxlYXNl IGF0dGFjaCB0aGUgZG1lc2cgb3V0cHV0IGFmdGVyIGEgZnJlc2ggYm9vdCBpbiAtcmMxPw0KDQpU aGFua3MsDQpydWkNCj4gVGhhbmtzLg0KPiANCj4gLS0NCj4gUmVnYXJkcy9HcnVzcywNCj4gICAg IEJvcmlzLg0KPiANCj4gU2VudCBmcm9tIGEgZmF0IGNyYXRlIHVuZGVyIG15IGRlc2suIEZvcm1h dHRpbmcgaXMgZmluZS4NCj4gLS0NCg== ^ permalink raw reply [flat|nested] 84+ messages in thread
* RE: Info: mapping multiple BARs. Your kernel is fine. @ 2014-04-16 20:24 ` Zhang, Rui 0 siblings, 0 replies; 84+ messages in thread From: Zhang, Rui @ 2014-04-16 20:24 UTC (permalink / raw) To: Borislav Petkov, Bjorn Helgaas, Rafael J. Wysocki Cc: Lu, Aaron, lkml, x86, Linux PCI, ACPI Devel Maling List, Yinghai Lu, H. Peter Anvin, Stephane Eranian, Yan, Zheng Z [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1286 bytes --] > -----Original Message----- > From: Borislav Petkov [mailto:bp@alien8.de] > Sent: Wednesday, April 16, 2014 12:04 PM > To: Bjorn Helgaas; Rafael J. Wysocki > Cc: Zhang, Rui; Lu, Aaron; lkml; x86@kernel.org; Linux PCI; ACPI Devel > Maling List; Yinghai Lu; H. Peter Anvin; Stephane Eranian; Yan, Zheng Z > Subject: Re: Info: mapping multiple BARs. Your kernel is fine. > Importance: High > > On Thu, Mar 20, 2014 at 02:48:30PM -0600, Bjorn Helgaas wrote: > > Right. Even if we had this long-term solution, we'd still have > > Stephane's current problem, because the PNP0C02 _CRS is still wrong. > > > > We do have a drivers/pnp/quirks.c where we could conceivably adjust > > the PNP resource if we found the matching PCI device and MCHBAR. > That > > should solve Stephane's problem even with the current > > drivers/pnp/system.c. > > Guys, this still triggers in -rc1. Do we have a fix or something > testable at least? > Could you please attach the dmesg output after a fresh boot in -rc1? Thanks, rui > Thanks. > > -- > Regards/Gruss, > Boris. > > Sent from a fat crate under my desk. Formatting is fine. > -- ÿôèº{.nÇ+·®+%Ëÿ±éݶ\x17¥wÿº{.nÇ+·¥{±þG«éÿ{ayº\x1dÊÚë,j\a¢f£¢·hïêÿêçz_è®\x03(éÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?¨èÚ&£ø§~á¶iOæ¬z·vØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?I¥ ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. 2014-04-16 19:04 ` Borislav Petkov 2014-04-16 20:24 ` Zhang, Rui @ 2014-04-16 20:31 ` Bjorn Helgaas 2014-04-16 22:31 ` Dave Jones 2014-04-16 23:08 ` Stephane Eranian 1 sibling, 2 replies; 84+ messages in thread From: Bjorn Helgaas @ 2014-04-16 20:31 UTC (permalink / raw) To: Borislav Petkov Cc: Rafael J. Wysocki, Zhang, Rui, Lu, Aaron, lkml, x86, Linux PCI, ACPI Devel Maling List, Yinghai Lu, H. Peter Anvin, Stephane Eranian, Yan, Zheng Z On Wed, Apr 16, 2014 at 09:04:04PM +0200, Borislav Petkov wrote: > On Thu, Mar 20, 2014 at 02:48:30PM -0600, Bjorn Helgaas wrote: > > Right. Even if we had this long-term solution, we'd still have > > Stephane's current problem, because the PNP0C02 _CRS is still wrong. > > > > We do have a drivers/pnp/quirks.c where we could conceivably adjust > > the PNP resource if we found the matching PCI device and MCHBAR. That > > should solve Stephane's problem even with the current > > drivers/pnp/system.c. > > Guys, this still triggers in -rc1. Do we have a fix or something > testable at least? Hi Boris, Can you try the patch below? PNP: Work around Haswell BIOS defect in MCH area reporting From: Bjorn Helgaas <bhelgaas@google.com> Work around a Haswell BIOS defect that causes part of the MCH area to be unreported. MCHBAR is not an architected PCI BAR, so MCH space is usually reported as a PNP0C02 resource. The MCH space was 16KB prior to Haswell, but it is 32KB in Haswell. Some Haswell BIOSes still report a PNP0C02 resource that is only 16KB, which means the rest of the MCH space is consumed but unreported. This can cause resource map sanity check warnings or (theoretically) a device conflict if we assigned the unreported space to another device. The Intel perf event uncore driver tripped over this when it claimed the MCH region: resource map sanity check conflict: 0xfed10000 0xfed15fff 0xfed10000 0xfed13fff pnp 00:01 Info: mapping multiple BARs. Your kernel is fine. To prevent this, if we find a PNP0C02 resource that covers part of the MCH space, extend it to cover the entire space. Link: http://lkml.kernel.org/r/20140224162400.GE16457@pd.tnic Reported-by: Borislav Petkov <bp@alien8.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> --- drivers/pnp/quirks.c | 52 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 52 insertions(+) diff --git a/drivers/pnp/quirks.c b/drivers/pnp/quirks.c index 258fef272ea7..023edf592371 100644 --- a/drivers/pnp/quirks.c +++ b/drivers/pnp/quirks.c @@ -334,6 +334,57 @@ static void quirk_amd_mmconfig_area(struct pnp_dev *dev) } #endif +static void quirk_intel_haswell_mch(struct pnp_dev *dev) +{ + struct pci_dev *host; + u32 addr_lo, addr_hi; + struct pci_bus_region region; + struct resource mch; + struct pnp_resource *pnp_res; + struct resource *res; + + host = pci_get_device(PCI_VENDOR_ID_INTEL, 0x0c00, NULL); + if (!host) + return; + + /* + * MCHBAR is not an architected PCI BAR, so MCH space is usually + * reported as a PNP0C02 resource. The MCH space was 16KB prior to + * Haswell, but it is 32KB in Haswell. Some Haswell BIOSes still + * report a PNP0C02 resource that is only 16KB, which means the + * rest of the MCH space is consumed but unreported. + */ + + /* + * Read MCHBAR for Host Member Mapped Register Range Base + * https://www-ssl.intel.com/content/www/us/en/processors/core/4th-gen-core-family-desktop-vol-2-datasheet + * Sec 3.1.12. + */ + pci_read_config_dword(host, 0x48, &addr_lo); + region.start = addr_lo & ~0x7fff; + pci_read_config_dword(host, 0x4c, &addr_hi); + region.start |= (dma_addr_t) addr_hi << 32; + region.end = region.start + 32*1024 - 1 ; + pcibios_bus_to_resource(host->bus, &mch, ®ion); + + list_for_each_entry(pnp_res, &dev->resources, list) { + res = &pnp_res->res; + if (res->end < mch.start || res->start > mch.end) + continue; /* no overlap */ + if (res->start == mch.start && res->end == mch.end) + continue; /* exact match */ + + dev_info(&dev->dev, FW_BUG + "%pR covers only part of Intel Haswell MCH; extending to %pR\n", + res, &mch); + res->start = mch.start; + res->end = mch.end; + break; + } + + pci_dev_put(host); +} + /* * PnP Quirks * Cards or devices that need some tweaking due to incomplete resource info @@ -364,6 +415,7 @@ static struct pnp_fixup pnp_fixups[] = { #ifdef CONFIG_AMD_NB {"PNP0c01", quirk_amd_mmconfig_area}, #endif + {"PNP0c02", quirk_intel_haswell_mch}, {""} }; ^ permalink raw reply related [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. 2014-04-16 20:31 ` Bjorn Helgaas @ 2014-04-16 22:31 ` Dave Jones 2014-04-16 22:56 ` Bjorn Helgaas 2014-04-16 23:08 ` Stephane Eranian 1 sibling, 1 reply; 84+ messages in thread From: Dave Jones @ 2014-04-16 22:31 UTC (permalink / raw) To: Bjorn Helgaas Cc: Borislav Petkov, Rafael J. Wysocki, Zhang, Rui, Lu, Aaron, lkml, x86, Linux PCI, ACPI Devel Maling List, Yinghai Lu, H. Peter Anvin, Stephane Eranian, Yan, Zheng Z On Wed, Apr 16, 2014 at 02:31:38PM -0600, Bjorn Helgaas wrote: > On Wed, Apr 16, 2014 at 09:04:04PM +0200, Borislav Petkov wrote: > > On Thu, Mar 20, 2014 at 02:48:30PM -0600, Bjorn Helgaas wrote: > > > Right. Even if we had this long-term solution, we'd still have > > > Stephane's current problem, because the PNP0C02 _CRS is still wrong. > > > > > > We do have a drivers/pnp/quirks.c where we could conceivably adjust > > > the PNP resource if we found the matching PCI device and MCHBAR. That > > > should solve Stephane's problem even with the current > > > drivers/pnp/system.c. > > > > Guys, this still triggers in -rc1. Do we have a fix or something > > testable at least? > > Hi Boris, > > Can you try the patch below? I'm seeing the exact same message on my thinkpad t430s. When I try your patch, modesetting no longer works. When it tries to change to the framebuffer I get a black screen and lockup. If I boot with nomodeset it locks up when it gets to X. It all scrolls by too fast to read, but it looks like there's still a backtrace present. Dave ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. 2014-04-16 22:31 ` Dave Jones @ 2014-04-16 22:56 ` Bjorn Helgaas 2014-04-17 0:18 ` Dave Jones 2014-04-17 10:45 ` Borislav Petkov 0 siblings, 2 replies; 84+ messages in thread From: Bjorn Helgaas @ 2014-04-16 22:56 UTC (permalink / raw) To: Dave Jones, Borislav Petkov, Rafael J. Wysocki, Zhang, Rui, Lu, Aaron, lkml, x86, Linux PCI, ACPI Devel Maling List, Yinghai Lu, H. Peter Anvin, Stephane Eranian, Yan, Zheng Z On Wed, Apr 16, 2014 at 06:31:22PM -0400, Dave Jones wrote: > On Wed, Apr 16, 2014 at 02:31:38PM -0600, Bjorn Helgaas wrote: > > On Wed, Apr 16, 2014 at 09:04:04PM +0200, Borislav Petkov wrote: > > > On Thu, Mar 20, 2014 at 02:48:30PM -0600, Bjorn Helgaas wrote: > > > > Right. Even if we had this long-term solution, we'd still have > > > > Stephane's current problem, because the PNP0C02 _CRS is still wrong. > > > > > > > > We do have a drivers/pnp/quirks.c where we could conceivably adjust > > > > the PNP resource if we found the matching PCI device and MCHBAR. That > > > > should solve Stephane's problem even with the current > > > > drivers/pnp/system.c. > > > > > > Guys, this still triggers in -rc1. Do we have a fix or something > > > testable at least? > > > > Hi Boris, > > > > Can you try the patch below? > > I'm seeing the exact same message on my thinkpad t430s. > When I try your patch, modesetting no longer works. When it tries > to change to the framebuffer I get a black screen and lockup. > If I boot with nomodeset it locks up when it gets to X. > It all scrolls by too fast to read, but it looks like there's still > a backtrace present. Ouch, sorry about that. I do see a bug in my patch (fixed below), but I don't see how that could cause what you're seeing. Maybe I could figure out something from this info (this can be from a kernel without my patch): - dmesg log - output of "find /sys/devices/pnp0 -name id -o -name resources | xargs grep ." - output of "sudo lspci -s00:00.0 -xxx" PNP: Work around Haswell BIOS defect in MCH area reporting From: Bjorn Helgaas <bhelgaas@google.com> Work around a Haswell BIOS defect that causes part of the MCH area to be unreported. MCHBAR is not an architected PCI BAR, so MCH space is usually reported as a PNP0C02 resource. The MCH space was 16KB prior to Haswell, but it is 32KB in Haswell. Some Haswell BIOSes still report a PNP0C02 resource that is only 16KB, which means the rest of the MCH space is consumed but unreported. This can cause resource map sanity check warnings or (theoretically) a device conflict if we assigned the unreported space to another device. The Intel perf event uncore driver tripped over this when it claimed the MCH region: resource map sanity check conflict: 0xfed10000 0xfed15fff 0xfed10000 0xfed13fff pnp 00:01 Info: mapping multiple BARs. Your kernel is fine. To prevent this, if we find a PNP0C02 resource that covers part of the MCH space, extend it to cover the entire space. Link: http://lkml.kernel.org/r/20140224162400.GE16457@pd.tnic Reported-by: Borislav Petkov <bp@alien8.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> --- drivers/pnp/quirks.c | 55 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 55 insertions(+) diff --git a/drivers/pnp/quirks.c b/drivers/pnp/quirks.c index 258fef272ea7..8402088d4145 100644 --- a/drivers/pnp/quirks.c +++ b/drivers/pnp/quirks.c @@ -334,6 +334,60 @@ static void quirk_amd_mmconfig_area(struct pnp_dev *dev) } #endif +static void quirk_intel_haswell_mch(struct pnp_dev *dev) +{ + struct pci_dev *host; + u32 addr_lo, addr_hi; + struct pci_bus_region region; + struct resource mch; + struct pnp_resource *pnp_res; + struct resource *res; + + host = pci_get_device(PCI_VENDOR_ID_INTEL, 0x0c00, NULL); + if (!host) + return; + + /* + * MCHBAR is not an architected PCI BAR, so MCH space is usually + * reported as a PNP0C02 resource. The MCH space was 16KB prior to + * Haswell, but it is 32KB in Haswell. Some Haswell BIOSes still + * report a PNP0C02 resource that is only 16KB, which means the + * rest of the MCH space is consumed but unreported. + */ + + /* + * Read MCHBAR for Host Member Mapped Register Range Base + * https://www-ssl.intel.com/content/www/us/en/processors/core/4th-gen-core-family-desktop-vol-2-datasheet + * Sec 3.1.12. + */ + pci_read_config_dword(host, 0x48, &addr_lo); + region.start = addr_lo & ~0x7fff; + pci_read_config_dword(host, 0x4c, &addr_hi); + region.start |= (dma_addr_t) addr_hi << 32; + region.end = region.start + 32*1024 - 1 ; + + memset(&mch, 0, sizeof(mch)); + mch.flags = IORESOURCE_MEM; + pcibios_bus_to_resource(host->bus, &mch, ®ion); + + list_for_each_entry(pnp_res, &dev->resources, list) { + res = &pnp_res->res; + if (res->end < mch.start || res->start > mch.end) + continue; /* no overlap */ + if (res->start == mch.start && res->end == mch.end) + continue; /* exact match */ + + dev_info(&dev->dev, FW_BUG + "%pR covers only part of Intel Haswell MCH; extending to %pR\n", + res, &mch); + res->start = mch.start; + res->end = mch.end; + break; + } + + pci_dev_put(host); +} + /* * PnP Quirks * Cards or devices that need some tweaking due to incomplete resource info @@ -364,6 +418,7 @@ static struct pnp_fixup pnp_fixups[] = { #ifdef CONFIG_AMD_NB {"PNP0c01", quirk_amd_mmconfig_area}, #endif + {"PNP0c02", quirk_intel_haswell_mch}, {""} }; ^ permalink raw reply related [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. 2014-04-16 22:56 ` Bjorn Helgaas @ 2014-04-17 0:18 ` Dave Jones 2014-04-17 10:45 ` Borislav Petkov 1 sibling, 0 replies; 84+ messages in thread From: Dave Jones @ 2014-04-17 0:18 UTC (permalink / raw) To: Bjorn Helgaas Cc: Borislav Petkov, Rafael J. Wysocki, Zhang, Rui, Lu, Aaron, lkml, x86, Linux PCI, ACPI Devel Maling List, Yinghai Lu, H. Peter Anvin, Stephane Eranian, Yan, Zheng Z [-- Attachment #1: Type: text/plain, Size: 903 bytes --] On Wed, Apr 16, 2014 at 04:56:00PM -0600, Bjorn Helgaas wrote: > > I'm seeing the exact same message on my thinkpad t430s. > > When I try your patch, modesetting no longer works. When it tries > > to change to the framebuffer I get a black screen and lockup. > > If I boot with nomodeset it locks up when it gets to X. > > It all scrolls by too fast to read, but it looks like there's still > > a backtrace present. > > Ouch, sorry about that. I do see a bug in my patch (fixed below), but I > don't see how that could cause what you're seeing. updated diff made no difference fwiw. > Maybe I could figure > out something from this info (this can be from a kernel without my patch): > > - dmesg log > - output of "find /sys/devices/pnp0 -name id -o -name resources | xargs grep ." > - output of "sudo lspci -s00:00.0 -xxx" attached from a fedora build of rc1. Dave [-- Attachment #2: pnp.txt --] [-- Type: text/plain, Size: 4027 bytes --] /sys/devices/pnp0/00:00/id:PNP0c01 /sys/devices/pnp0/00:00/resources:state = active /sys/devices/pnp0/00:00/resources:mem 0x0-0x9ffff /sys/devices/pnp0/00:00/resources:mem 0xc0000-0xc3fff /sys/devices/pnp0/00:00/resources:mem 0xc4000-0xc7fff /sys/devices/pnp0/00:00/resources:mem 0xc8000-0xcbfff /sys/devices/pnp0/00:00/resources:mem 0xcc000-0xcffff /sys/devices/pnp0/00:00/resources:mem 0xd0000-0xd3fff /sys/devices/pnp0/00:00/resources:mem 0xd4000-0xd7fff /sys/devices/pnp0/00:00/resources:mem 0xd8000-0xdbfff /sys/devices/pnp0/00:00/resources:mem 0xdc000-0xdffff /sys/devices/pnp0/00:00/resources:mem 0xe0000-0xe3fff /sys/devices/pnp0/00:00/resources:mem 0xe4000-0xe7fff /sys/devices/pnp0/00:00/resources:mem 0xe8000-0xebfff /sys/devices/pnp0/00:00/resources:mem 0xec000-0xeffff /sys/devices/pnp0/00:00/resources:mem 0xf0000-0xfffff /sys/devices/pnp0/00:00/resources:mem 0x100000-0xbf9fffff /sys/devices/pnp0/00:00/resources:mem 0xfec00000-0xfed3ffff /sys/devices/pnp0/00:00/resources:mem 0xfed4c000-0xffffffff /sys/devices/pnp0/00:01/id:PNP0c02 /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 disabled /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:02/id:PNP0103 /sys/devices/pnp0/00:02/resources:state = active /sys/devices/pnp0/00:02/resources:mem 0xfed00000-0xfed003ff /sys/devices/pnp0/00:03/id:PNP0200 /sys/devices/pnp0/00:03/resources:state = active /sys/devices/pnp0/00:03/resources:io 0x0-0xf /sys/devices/pnp0/00:03/resources:io 0x80-0x8f /sys/devices/pnp0/00:03/resources:io 0xc0-0xdf /sys/devices/pnp0/00:03/resources:dma 4 /sys/devices/pnp0/00:04/id:PNP0800 /sys/devices/pnp0/00:04/resources:state = active /sys/devices/pnp0/00:04/resources:io 0x61-0x61 /sys/devices/pnp0/00:05/id:PNP0c04 /sys/devices/pnp0/00:05/resources:state = active /sys/devices/pnp0/00:05/resources:io 0xf0-0xf0 /sys/devices/pnp0/00:05/resources:irq 13 /sys/devices/pnp0/00:06/id:PNP0b00 /sys/devices/pnp0/00:06/resources:state = active /sys/devices/pnp0/00:06/resources:io 0x70-0x71 /sys/devices/pnp0/00:06/resources:irq 8 /sys/devices/pnp0/00:07/id:LEN0071 /sys/devices/pnp0/00:07/id:PNP0303 /sys/devices/pnp0/00:07/resources:state = active /sys/devices/pnp0/00:07/resources:io 0x60-0x60 /sys/devices/pnp0/00:07/resources:io 0x64-0x64 /sys/devices/pnp0/00:07/resources:irq 1 /sys/devices/pnp0/00:08/id:LEN0015 /sys/devices/pnp0/00:08/id:PNP0f13 /sys/devices/pnp0/00:08/resources:state = active /sys/devices/pnp0/00:08/resources:irq 12 /sys/devices/pnp0/00:09/id:SMO1200 /sys/devices/pnp0/00:09/id:PNP0c31 /sys/devices/pnp0/00:09/resources:state = active /sys/devices/pnp0/00:09/resources:mem 0xfed40000-0xfed44fff [-- Attachment #3: pci --] [-- Type: text/plain, Size: 920 bytes --] 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 fb 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 19 00 00 00 07 00 90 bf 01 00 00 bb 60: 05 00 00 f8 00 00 00 00 01 80 d1 fe 00 00 00 00 70: 00 00 00 fe 00 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 00 01 00 00 00 01 00 50 3e 01 00 00 00 a0: 01 00 00 00 01 00 00 00 01 00 60 3e 01 00 00 00 b0: 01 00 a0 bb 01 00 80 bb 01 00 00 bb 01 00 a0 bf 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 82 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 [-- Attachment #4: dmesg --] [-- Type: text/plain, Size: 37382 bytes --] [ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Initializing cgroup subsys cpuacct [ 0.000000] Linux version 3.15.0-0.rc1.git0.1.fc21.x86_64 (mockbuild@bkernel02) (gcc version 4.9.0 20140411 (Red Hat 4.9.0-0.10) (GCC) ) #1 SMP Mon Apr 14 15:42:28 UTC 2014 [ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-3.15.0-0.rc1.git0.1.fc21.x86_64 root=/dev/mapper/luks-88d41cc3-dbf6-42da-be04-55c0b18fc495 ro rd.luks.uuid=luks-a022e7c3-2439-4570-a0a0-f2bc1ed10c93 rd.luks.uuid=luks-88d41cc3-dbf6-42da-be04-55c0b18fc495 biosdevname=0 vconsole.font=latarcyrheb-sun16 rdshell consoleblank=0 console=ttyUSB0,115200 console=tty0 pause_on_oops=30 SYSFONT=default8x9 LANG=en_US.UTF-8 [ 0.000000] e820: BIOS-provided physical RAM map: [ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009d7ff] usable [ 0.000000] BIOS-e820: [mem 0x000000000009d800-0x000000000009ffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved [ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000001fffffff] usable [ 0.000000] BIOS-e820: [mem 0x0000000020000000-0x00000000201fffff] reserved [ 0.000000] BIOS-e820: [mem 0x0000000020200000-0x0000000040003fff] usable [ 0.000000] BIOS-e820: [mem 0x0000000040004000-0x0000000040004fff] reserved [ 0.000000] BIOS-e820: [mem 0x0000000040005000-0x00000000aed2ffff] usable [ 0.000000] BIOS-e820: [mem 0x00000000aed30000-0x00000000bae9efff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000bae9f000-0x00000000baf9efff] ACPI NVS [ 0.000000] BIOS-e820: [mem 0x00000000baf9f000-0x00000000baffefff] ACPI data [ 0.000000] BIOS-e820: [mem 0x00000000bafff000-0x00000000bf9fffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000f8000000-0x00000000fbffffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000fec00000-0x00000000fec00fff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000fed08000-0x00000000fed08fff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000fed10000-0x00000000fed19fff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000ffc00000-0x00000000ffffffff] reserved [ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000013e5fffff] usable [ 0.000000] NX (Execute Disable) protection: active [ 0.000000] SMBIOS 2.7 present. [ 0.000000] DMI: LENOVO 2356JK8/2356JK8, BIOS G7ET94WW (2.54 ) 04/30/2013 [ 0.000000] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved [ 0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable [ 0.000000] e820: last_pfn = 0x13e600 max_arch_pfn = 0x400000000 [ 0.000000] MTRR default type: uncachable [ 0.000000] MTRR fixed ranges enabled: [ 0.000000] 00000-9FFFF write-back [ 0.000000] A0000-BFFFF uncachable [ 0.000000] C0000-FFFFF write-protect [ 0.000000] MTRR variable ranges enabled: [ 0.000000] 0 base 0FFC00000 mask FFFC00000 write-protect [ 0.000000] 1 base 000000000 mask F80000000 write-back [ 0.000000] 2 base 080000000 mask FC0000000 write-back [ 0.000000] 3 base 0BC000000 mask FFC000000 uncachable [ 0.000000] 4 base 0BB000000 mask FFF000000 uncachable [ 0.000000] 5 base 100000000 mask FC0000000 write-back [ 0.000000] 6 base 13F000000 mask FFF000000 uncachable [ 0.000000] 7 base 13E800000 mask FFF800000 uncachable [ 0.000000] 8 base 13E600000 mask FFFE00000 uncachable [ 0.000000] 9 disabled [ 0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 [ 0.000000] e820: last_pfn = 0xaed30 max_arch_pfn = 0x400000000 [ 0.000000] found SMP MP-table at [mem 0x000f0100-0x000f010f] mapped at [ffff8800000f0100] [ 0.000000] Base memory trampoline at [ffff880000097000] 97000 size 24576 [ 0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff] [ 0.000000] [mem 0x00000000-0x000fffff] page 4k [ 0.000000] BRK [0x02033000, 0x02033fff] PGTABLE [ 0.000000] BRK [0x02034000, 0x02034fff] PGTABLE [ 0.000000] BRK [0x02035000, 0x02035fff] PGTABLE [ 0.000000] init_memory_mapping: [mem 0x13e400000-0x13e5fffff] [ 0.000000] [mem 0x13e400000-0x13e5fffff] page 2M [ 0.000000] BRK [0x02036000, 0x02036fff] PGTABLE [ 0.000000] init_memory_mapping: [mem 0x13c000000-0x13e3fffff] [ 0.000000] [mem 0x13c000000-0x13e3fffff] page 2M [ 0.000000] init_memory_mapping: [mem 0x100000000-0x13bffffff] [ 0.000000] [mem 0x100000000-0x13bffffff] page 2M [ 0.000000] init_memory_mapping: [mem 0x00100000-0x1fffffff] [ 0.000000] [mem 0x00100000-0x001fffff] page 4k [ 0.000000] [mem 0x00200000-0x1fffffff] page 2M [ 0.000000] init_memory_mapping: [mem 0x20200000-0x40003fff] [ 0.000000] [mem 0x20200000-0x3fffffff] page 2M [ 0.000000] [mem 0x40000000-0x40003fff] page 4k [ 0.000000] BRK [0x02037000, 0x02037fff] PGTABLE [ 0.000000] BRK [0x02038000, 0x02038fff] PGTABLE [ 0.000000] init_memory_mapping: [mem 0x40005000-0xaed2ffff] [ 0.000000] [mem 0x40005000-0x401fffff] page 4k [ 0.000000] [mem 0x40200000-0xaebfffff] page 2M [ 0.000000] [mem 0xaec00000-0xaed2ffff] page 4k [ 0.000000] RAMDISK: [mem 0x35b6f000-0x36daffff] [ 0.000000] ACPI: RSDP 0x00000000000F0120 000024 (v02 LENOVO) [ 0.000000] ACPI: XSDT 0x00000000BAFFE170 0000BC (v01 LENOVO TP-G7 00002540 PTL 00000002) [ 0.000000] ACPI: FACP 0x00000000BAFE6000 00010C (v05 LENOVO TP-G7 00002540 PTL 00000002) [ 0.000000] ACPI: DSDT 0x00000000BAFE8000 010B02 (v01 LENOVO TP-G7 00002540 INTL 20061109) [ 0.000000] ACPI: FACS 0x00000000BAF5A000 000040 [ 0.000000] ACPI: SLIC 0x00000000BAFFD000 000176 (v01 LENOVO TP-G7 00002540 PTL 00000001) [ 0.000000] ACPI: TCPA 0x00000000BAFFC000 000032 (v02 PTL LENOVO 06040000 LNVO 00000001) [ 0.000000] ACPI: SSDT 0x00000000BAFFB000 000408 (v01 LENOVO TP-SSDT2 00000200 INTL 20061109) [ 0.000000] ACPI: SSDT 0x00000000BAFFA000 000033 (v01 LENOVO TP-SSDT1 00000100 INTL 20061109) [ 0.000000] ACPI: SSDT 0x00000000BAFF9000 000797 (v01 LENOVO SataAhci 00001000 INTL 20061109) [ 0.000000] ACPI: HPET 0x00000000BAFE4000 000038 (v01 LENOVO TP-G7 00002540 PTL 00000002) [ 0.000000] ACPI: APIC 0x00000000BAFE3000 000098 (v01 LENOVO TP-G7 00002540 PTL 00000002) [ 0.000000] ACPI: MCFG 0x00000000BAFE2000 00003C (v01 LENOVO TP-G7 00002540 PTL 00000002) [ 0.000000] ACPI: ECDT 0x00000000BAFE1000 000052 (v01 LENOVO TP-G7 00002540 PTL 00000002) [ 0.000000] ACPI: FPDT 0x00000000BAFE0000 000064 (v01 LENOVO TP-G7 00002540 PTL 00000002) [ 0.000000] ACPI: ASF! 0x00000000BAFE7000 0000A5 (v32 LENOVO TP-G7 00002540 PTL 00000002) [ 0.000000] ACPI: UEFI 0x00000000BAFDF000 00003E (v01 LENOVO TP-G7 00002540 PTL 00000002) [ 0.000000] ACPI: UEFI 0x00000000BAFDE000 000042 (v01 PTL COMBUF 00000001 PTL 00000001) [ 0.000000] ACPI: POAT 0x00000000BAFDD000 000055 (v03 LENOVO TP-G7 00002540 PTL 00000002) [ 0.000000] ACPI: SSDT 0x00000000BAFDC000 000BF3 (v01 PmRef Cpu0Ist 00003000 INTL 20061109) [ 0.000000] ACPI: SSDT 0x00000000BAFDB000 000A83 (v01 PmRef CpuPm 00003000 INTL 20061109) [ 0.000000] ACPI: UEFI 0x00000000BAFDA000 0002A6 (v01 LENOVO TP-G7 00002540 PTL 00000002) [ 0.000000] ACPI: DBG2 0x00000000BAFD9000 0000E9 (v00 LENOVO TP-G7 00002540 PTL 00000002) [ 0.000000] ACPI: Local APIC address 0xfee00000 [ 0.000000] No NUMA configuration found [ 0.000000] Faking a node at [mem 0x0000000000000000-0x000000013e5fffff] [ 0.000000] Initmem setup node 0 [mem 0x00000000-0x13e5fffff] [ 0.000000] NODE_DATA [mem 0x13e5ea000-0x13e5fdfff] [ 0.000000] [ffffea0000000000-ffffea0004ffffff] PMD -> [ffff88013a000000-ffff88013dbfffff] on node 0 [ 0.000000] Zone ranges: [ 0.000000] DMA [mem 0x00001000-0x00ffffff] [ 0.000000] DMA32 [mem 0x01000000-0xffffffff] [ 0.000000] Normal [mem 0x100000000-0x13e5fffff] [ 0.000000] Movable zone start for each node [ 0.000000] Early memory node ranges [ 0.000000] node 0: [mem 0x00001000-0x0009cfff] [ 0.000000] node 0: [mem 0x00100000-0x1fffffff] [ 0.000000] node 0: [mem 0x20200000-0x40003fff] [ 0.000000] node 0: [mem 0x40005000-0xaed2ffff] [ 0.000000] node 0: [mem 0x100000000-0x13e5fffff] [ 0.000000] On node 0 totalpages: 970955 [ 0.000000] DMA zone: 64 pages used for memmap [ 0.000000] DMA zone: 21 pages reserved [ 0.000000] DMA zone: 3996 pages, LIFO batch:0 [ 0.000000] DMA32 zone: 11117 pages used for memmap [ 0.000000] DMA32 zone: 711471 pages, LIFO batch:31 [ 0.000000] Normal zone: 3992 pages used for memmap [ 0.000000] Normal zone: 255488 pages, LIFO batch:31 [ 0.000000] Reserving Intel graphics stolen memory at 0xbba00000-0xbf9fffff [ 0.000000] ACPI: PM-Timer IO Port: 0x408 [ 0.000000] ACPI: Local APIC address 0xfee00000 [ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x00] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x00] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x00] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x00] disabled) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) [ 0.000000] ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0]) [ 0.000000] IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23 [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) [ 0.000000] ACPI: IRQ0 used by override. [ 0.000000] ACPI: IRQ2 used by override. [ 0.000000] ACPI: IRQ9 used by override. [ 0.000000] Using ACPI (MADT) for SMP configuration information [ 0.000000] ACPI: HPET id: 0x8086a301 base: 0xfed00000 [ 0.000000] smpboot: Allowing 8 CPUs, 4 hotplug CPUs [ 0.000000] nr_irqs_gsi: 40 [ 0.000000] PM: Registered nosave memory: [mem 0x0009d000-0x0009dfff] [ 0.000000] PM: Registered nosave memory: [mem 0x0009e000-0x0009ffff] [ 0.000000] PM: Registered nosave memory: [mem 0x000a0000-0x000dffff] [ 0.000000] PM: Registered nosave memory: [mem 0x000e0000-0x000fffff] [ 0.000000] PM: Registered nosave memory: [mem 0x20000000-0x201fffff] [ 0.000000] PM: Registered nosave memory: [mem 0x40004000-0x40004fff] [ 0.000000] PM: Registered nosave memory: [mem 0xaed30000-0xbae9efff] [ 0.000000] PM: Registered nosave memory: [mem 0xbae9f000-0xbaf9efff] [ 0.000000] PM: Registered nosave memory: [mem 0xbaf9f000-0xbaffefff] [ 0.000000] PM: Registered nosave memory: [mem 0xbafff000-0xbf9fffff] [ 0.000000] PM: Registered nosave memory: [mem 0xbfa00000-0xf7ffffff] [ 0.000000] PM: Registered nosave memory: [mem 0xf8000000-0xfbffffff] [ 0.000000] PM: Registered nosave memory: [mem 0xfc000000-0xfebfffff] [ 0.000000] PM: Registered nosave memory: [mem 0xfec00000-0xfec00fff] [ 0.000000] PM: Registered nosave memory: [mem 0xfec01000-0xfed07fff] [ 0.000000] PM: Registered nosave memory: [mem 0xfed08000-0xfed08fff] [ 0.000000] PM: Registered nosave memory: [mem 0xfed09000-0xfed0ffff] [ 0.000000] PM: Registered nosave memory: [mem 0xfed10000-0xfed19fff] [ 0.000000] PM: Registered nosave memory: [mem 0xfed1a000-0xfed1bfff] [ 0.000000] PM: Registered nosave memory: [mem 0xfed1c000-0xfed1ffff] [ 0.000000] PM: Registered nosave memory: [mem 0xfed20000-0xfedfffff] [ 0.000000] PM: Registered nosave memory: [mem 0xfee00000-0xfee00fff] [ 0.000000] PM: Registered nosave memory: [mem 0xfee01000-0xffbfffff] [ 0.000000] PM: Registered nosave memory: [mem 0xffc00000-0xffffffff] [ 0.000000] e820: [mem 0xbfa00000-0xf7ffffff] available for PCI devices [ 0.000000] Booting paravirtualized kernel on bare hardware [ 0.000000] setup_percpu: NR_CPUS:1024 nr_cpumask_bits:8 nr_cpu_ids:8 nr_node_ids:1 [ 0.000000] PERCPU: Embedded 29 pages/cpu @ffff88013e200000 s88128 r8192 d22464 u262144 [ 0.000000] pcpu-alloc: s88128 r8192 d22464 u262144 alloc=1*2097152 [ 0.000000] pcpu-alloc: [0] 0 1 2 3 4 5 6 7 [ 0.000000] Built 1 zonelists in Node order, mobility grouping on. Total pages: 955761 [ 0.000000] Policy zone: Normal [ 0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz-3.15.0-0.rc1.git0.1.fc21.x86_64 root=/dev/mapper/luks-88d41cc3-dbf6-42da-be04-55c0b18fc495 ro rd.luks.uuid=luks-a022e7c3-2439-4570-a0a0-f2bc1ed10c93 rd.luks.uuid=luks-88d41cc3-dbf6-42da-be04-55c0b18fc495 biosdevname=0 vconsole.font=latarcyrheb-sun16 rdshell consoleblank=0 console=ttyUSB0,115200 console=tty0 pause_on_oops=30 SYSFONT=default8x9 LANG=en_US.UTF-8 [ 0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes) [ 0.000000] xsave: enabled xstate_bv 0x7, cntxt size 0x340 [ 0.000000] Memory: 3719672K/3883820K available (7250K kernel code, 1171K rwdata, 3080K rodata, 1440K init, 1652K bss, 164148K reserved) [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=8, Nodes=1 [ 0.000000] Hierarchical RCU implementation. [ 0.000000] RCU restricting CPUs from NR_CPUS=1024 to nr_cpu_ids=8. [ 0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=8 [ 0.000000] NR_IRQS:65792 nr_irqs:744 16 [ 0.000000] Console: colour VGA+ 80x25 [ 0.000000] console [tty0] enabled [ 0.000000] allocated 15728640 bytes of page_cgroup [ 0.000000] please try 'cgroup_disable=memory' option if you don't want memory cgroups [ 0.000000] hpet clockevent registered [ 0.000000] tsc: Fast TSC calibration using PIT [ 0.000000] tsc: Detected 2893.501 MHz processor [ 0.000031] Calibrating delay loop (skipped), value calculated using timer frequency.. 5787.00 BogoMIPS (lpj=2893501) [ 0.000173] pid_max: default: 32768 minimum: 301 [ 0.000252] ACPI: Core revision 20140214 [ 0.009974] ACPI: All ACPI Tables successfully acquired [ 0.011481] Security Framework initialized [ 0.011561] SELinux: Initializing. [ 0.011638] SELinux: Starting in permissive mode [ 0.011911] Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes) [ 0.012895] Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes) [ 0.013358] Mount-cache hash table entries: 8192 (order: 4, 65536 bytes) [ 0.013442] Mountpoint-cache hash table entries: 8192 (order: 4, 65536 bytes) [ 0.013685] Initializing cgroup subsys memory [ 0.013764] Initializing cgroup subsys devices [ 0.013838] Initializing cgroup subsys freezer [ 0.013922] Initializing cgroup subsys net_cls [ 0.013995] Initializing cgroup subsys blkio [ 0.014068] Initializing cgroup subsys perf_event [ 0.014142] Initializing cgroup subsys net_prio [ 0.014215] Initializing cgroup subsys hugetlb [ 0.014308] CPU: Physical Processor ID: 0 [ 0.014384] CPU: Processor Core ID: 0 [ 0.014887] ENERGY_PERF_BIAS: Set to 'normal', was 'performance' ENERGY_PERF_BIAS: View and update with x86_energy_perf_policy(8) [ 0.015304] mce: CPU supports 7 MCE banks [ 0.015387] CPU0: Thermal monitoring enabled (TM1) [ 0.015466] Last level iTLB entries: 4KB 512, 2MB 8, 4MB 8 Last level dTLB entries: 4KB 512, 2MB 32, 4MB 32, 1GB 0 tlb_flushall_shift: 2 [ 0.015687] Freeing SMP alternatives memory: 24K (ffffffff81e8e000 - ffffffff81e94000) [ 0.016746] ftrace: allocating 26542 entries in 104 pages [ 0.028127] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 [ 0.038227] smpboot: CPU0: Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz (fam: 06, model: 3a, stepping: 09) [ 0.038508] TSC deadline timer enabled [ 0.038516] Performance Events: PEBS fmt1+, 16-deep LBR, IvyBridge events, full-width counters, Intel PMU driver. [ 0.038878] ... version: 3 [ 0.038971] ... bit width: 48 [ 0.039063] ... generic registers: 4 [ 0.039156] ... value mask: 0000ffffffffffff [ 0.039250] ... max period: 0000ffffffffffff [ 0.039345] ... fixed-purpose events: 3 [ 0.039438] ... event mask: 000000070000000f [ 0.040584] x86: Booting SMP configuration: [ 0.040682] .... node #0, CPUs: #1 [ 0.054314] NMI watchdog: enabled on all CPUs, permanently consumes one hw-PMU counter. [ 0.054612] #2 #3 [ 0.081854] x86: Booted up 1 node, 4 CPUs [ 0.082041] smpboot: Total of 4 processors activated (23148.00 BogoMIPS) [ 0.085501] devtmpfs: initialized [ 0.087592] PM: Registering ACPI NVS region [mem 0xbae9f000-0xbaf9efff] (1048576 bytes) [ 0.088390] atomic64 test passed for x86-64 platform with CX8 and with SSE [ 0.088492] pinctrl core: initialized pinctrl subsystem [ 0.088623] RTC time: 20:12:16, date: 04/16/14 [ 0.088749] NET: Registered protocol family 16 [ 0.088939] cpuidle: using governor menu [ 0.089092] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it [ 0.089235] ACPI: bus type PCI registered [ 0.089332] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 [ 0.089599] PCI: MMCONFIG for domain 0000 [bus 00-3f] at [mem 0xf8000000-0xfbffffff] (base 0xf8000000) [ 0.089745] PCI: MMCONFIG at [mem 0xf8000000-0xfbffffff] reserved in E820 [ 0.094009] PCI: Using configuration type 1 for base access [ 0.095213] ACPI: Added _OSI(Module Device) [ 0.095310] ACPI: Added _OSI(Processor Device) [ 0.095405] ACPI: Added _OSI(3.0 _SCP Extensions) [ 0.095499] ACPI: Added _OSI(Processor Aggregator Device) [ 0.096762] ACPI : EC: EC description table is found, configuring boot EC [ 0.100379] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored [ 0.112972] ACPI: SSDT 0x00000000BAE3A018 000A01 (v01 PmRef Cpu0Cst 00003001 INTL 20061109) [ 0.113495] ACPI: Dynamic OEM Table Load: [ 0.113675] ACPI: SSDT 0x0000000000000000 000A01 (v01 PmRef Cpu0Cst 00003001 INTL 20061109) [ 0.116584] ACPI: SSDT 0x00000000BAE3BA98 000303 (v01 PmRef ApIst 00003000 INTL 20061109) [ 0.117148] ACPI: Dynamic OEM Table Load: [ 0.117327] ACPI: SSDT 0x0000000000000000 000303 (v01 PmRef ApIst 00003000 INTL 20061109) [ 0.120582] ACPI: SSDT 0x00000000BAE39D98 000119 (v01 PmRef ApCst 00003000 INTL 20061109) [ 0.121102] ACPI: Dynamic OEM Table Load: [ 0.121283] ACPI: SSDT 0x0000000000000000 000119 (v01 PmRef ApCst 00003000 INTL 20061109) [ 0.125008] ACPI: Interpreter enabled [ 0.125107] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S1_] (20140214/hwxface-580) [ 0.125340] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S2_] (20140214/hwxface-580) [ 0.125582] ACPI: (supports S0 S3 S4 S5) [ 0.125679] ACPI: Using IOAPIC for interrupt routing [ 0.125789] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug [ 0.130940] ACPI: Power Resource [PUBS] (on) [ 0.131654] acpi PNP0C0A:01: ACPI dock station (docks/bays count: 1) [ 0.132613] acpi LNXIOBAY:00: ACPI dock station (docks/bays count: 2) [ 0.135020] ACPI: \_PR_.CPU4: failed to get CPU APIC ID. [ 0.135023] ACPI: \_PR_.CPU5: failed to get CPU APIC ID. [ 0.135026] ACPI: \_PR_.CPU6: failed to get CPU APIC ID. [ 0.135028] ACPI: \_PR_.CPU7: failed to get CPU APIC ID. [ 0.135089] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11) [ 0.135671] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 *10 11) [ 0.136246] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 *7 9 10 11) [ 0.136825] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 10 *11) [ 0.137400] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 *11) [ 0.137977] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 *7 9 10 11) [ 0.138551] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 9 *10 11) [ 0.139126] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 *10 11) [ 0.139667] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-3f]) [ 0.139767] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI] [ 0.139993] acpi PNP0A08:00: _OSC: platform does not support [PCIeCapability] [ 0.140131] acpi PNP0A08:00: _OSC: not requesting control; platform does not support [PCIeCapability] [ 0.140277] acpi PNP0A08:00: _OSC: OS requested [PCIeHotplug PME AER PCIeCapability] [ 0.140419] acpi PNP0A08:00: _OSC: platform willing to grant [PCIeHotplug PME AER] [ 0.140560] acpi PNP0A08:00: _OSC failed (AE_SUPPORT); disabling ASPM [ 0.140798] PCI host bridge to bus 0000:00 [ 0.140892] pci_bus 0000:00: root bus resource [bus 00-3f] [ 0.140988] pci_bus 0000:00: root bus resource [io 0x0000-0x0cf7] [ 0.141084] pci_bus 0000:00: root bus resource [io 0x0d00-0xffff] [ 0.141179] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff] [ 0.141276] pci_bus 0000:00: root bus resource [mem 0xbfa00000-0xfebfffff] [ 0.141374] pci_bus 0000:00: root bus resource [mem 0xfed40000-0xfed4bfff] [ 0.141476] pci 0000:00:00.0: [8086:0154] type 00 class 0x060000 [ 0.141541] pci 0000:00:01.0: [8086:0151] type 01 class 0x060400 [ 0.141568] pci 0000:00:01.0: PME# supported from D0 D3hot D3cold [ 0.141622] pci 0000:00:02.0: [8086:0166] type 00 class 0x030000 [ 0.141631] pci 0000:00:02.0: reg 0x10: [mem 0xf1000000-0xf13fffff 64bit] [ 0.141637] pci 0000:00:02.0: reg 0x18: [mem 0xe0000000-0xefffffff 64bit pref] [ 0.141641] pci 0000:00:02.0: reg 0x20: [io 0x6000-0x603f] [ 0.141721] pci 0000:00:14.0: [8086:1e31] type 00 class 0x0c0330 [ 0.141742] pci 0000:00:14.0: reg 0x10: [mem 0xf3520000-0xf352ffff 64bit] [ 0.141812] pci 0000:00:14.0: PME# supported from D3hot D3cold [ 0.141838] pci 0000:00:14.0: System wakeup disabled by ACPI [ 0.141971] pci 0000:00:16.0: [8086:1e3a] type 00 class 0x078000 [ 0.141993] pci 0000:00:16.0: reg 0x10: [mem 0xf3535000-0xf353500f 64bit] [ 0.142066] pci 0000:00:16.0: PME# supported from D0 D3hot D3cold [ 0.142130] pci 0000:00:19.0: [8086:1502] type 00 class 0x020000 [ 0.142147] pci 0000:00:19.0: reg 0x10: [mem 0xf3500000-0xf351ffff] [ 0.142155] pci 0000:00:19.0: reg 0x14: [mem 0xf353b000-0xf353bfff] [ 0.142163] pci 0000:00:19.0: reg 0x18: [io 0x6080-0x609f] [ 0.142223] pci 0000:00:19.0: PME# supported from D0 D3hot D3cold [ 0.142249] pci 0000:00:19.0: System wakeup disabled by ACPI [ 0.142378] pci 0000:00:1a.0: [8086:1e2d] type 00 class 0x0c0320 [ 0.142398] pci 0000:00:1a.0: reg 0x10: [mem 0xf353a000-0xf353a3ff] [ 0.142484] pci 0000:00:1a.0: PME# supported from D0 D3hot D3cold [ 0.142512] pci 0000:00:1a.0: System wakeup disabled by ACPI [ 0.142643] pci 0000:00:1b.0: [8086:1e20] type 00 class 0x040300 [ 0.142657] pci 0000:00:1b.0: reg 0x10: [mem 0xf3530000-0xf3533fff 64bit] [ 0.142728] pci 0000:00:1b.0: PME# supported from D0 D3hot D3cold [ 0.142759] pci 0000:00:1b.0: System wakeup disabled by ACPI [ 0.142894] pci 0000:00:1c.0: [8086:1e10] type 01 class 0x060400 [ 0.143027] pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold [ 0.143101] pci 0000:00:1c.1: [8086:1e12] type 01 class 0x060400 [ 0.143235] pci 0000:00:1c.1: PME# supported from D0 D3hot D3cold [ 0.143305] pci 0000:00:1c.2: [8086:1e14] type 01 class 0x060400 [ 0.143437] pci 0000:00:1c.2: PME# supported from D0 D3hot D3cold [ 0.143476] pci 0000:00:1c.2: System wakeup disabled by ACPI [ 0.143610] pci 0000:00:1d.0: [8086:1e26] type 00 class 0x0c0320 [ 0.143630] pci 0000:00:1d.0: reg 0x10: [mem 0xf3539000-0xf35393ff] [ 0.143716] pci 0000:00:1d.0: PME# supported from D0 D3hot D3cold [ 0.143745] pci 0000:00:1d.0: System wakeup disabled by ACPI [ 0.143879] pci 0000:00:1f.0: [8086:1e55] type 00 class 0x060100 [ 0.144030] pci 0000:00:1f.2: [8086:1e03] type 00 class 0x010601 [ 0.144047] pci 0000:00:1f.2: reg 0x10: [io 0x60a8-0x60af] [ 0.144054] pci 0000:00:1f.2: reg 0x14: [io 0x60b4-0x60b7] [ 0.144062] pci 0000:00:1f.2: reg 0x18: [io 0x60a0-0x60a7] [ 0.144070] pci 0000:00:1f.2: reg 0x1c: [io 0x60b0-0x60b3] [ 0.144077] pci 0000:00:1f.2: reg 0x20: [io 0x6060-0x607f] [ 0.144084] pci 0000:00:1f.2: reg 0x24: [mem 0xf3538000-0xf35387ff] [ 0.144127] pci 0000:00:1f.2: PME# supported from D3hot [ 0.144179] pci 0000:00:1f.3: [8086:1e22] type 00 class 0x0c0500 [ 0.144194] pci 0000:00:1f.3: reg 0x10: [mem 0xf3534000-0xf35340ff 64bit] [ 0.144213] pci 0000:00:1f.3: reg 0x20: [io 0xefa0-0xefbf] [ 0.144318] pci 0000:01:00.0: [10de:1140] type 00 class 0x030200 [ 0.144327] pci 0000:01:00.0: reg 0x10: [mem 0xf0000000-0xf0ffffff] [ 0.144336] pci 0000:01:00.0: reg 0x14: [mem 0xc0000000-0xcfffffff 64bit pref] [ 0.144345] pci 0000:01:00.0: reg 0x1c: [mem 0xd0000000-0xd1ffffff 64bit pref] [ 0.144352] pci 0000:01:00.0: reg 0x24: [io 0x5000-0x507f] [ 0.144359] pci 0000:01:00.0: reg 0x30: [mem 0xfff80000-0xffffffff pref] [ 0.145884] pci 0000:00:01.0: PCI bridge to [bus 01] [ 0.146003] pci 0000:00:01.0: bridge window [io 0x5000-0x5fff] [ 0.146005] pci 0000:00:01.0: bridge window [mem 0xf0000000-0xf0ffffff] [ 0.146008] pci 0000:00:01.0: bridge window [mem 0xc0000000-0xd1ffffff 64bit pref] [ 0.146098] pci 0000:00:1c.0: PCI bridge to [bus 02] [ 0.146196] pci 0000:00:1c.0: bridge window [io 0x4000-0x4fff] [ 0.146200] pci 0000:00:1c.0: bridge window [mem 0xf2d00000-0xf34fffff] [ 0.146209] pci 0000:00:1c.0: bridge window [mem 0xf1400000-0xf1bfffff 64bit pref] [ 0.146435] pci 0000:03:00.0: [8086:4238] type 00 class 0x028000 [ 0.146583] pci 0000:03:00.0: reg 0x10: [mem 0xf2c00000-0xf2c01fff 64bit] [ 0.147354] pci 0000:03:00.0: PME# supported from D0 D3hot D3cold [ 0.149006] pci 0000:00:1c.1: PCI bridge to [bus 03] [ 0.149109] pci 0000:00:1c.1: bridge window [mem 0xf2c00000-0xf2cfffff] [ 0.149211] acpiphp: Slot [1] registered [ 0.149470] pci 0000:04:00.0: [1180:e822] type 00 class 0x088000 [ 0.149489] pci 0000:04:00.0: MMC controller base frequency changed to 50Mhz. [ 0.149772] pci 0000:04:00.0: reg 0x10: [mem 0xf2400000-0xf24000ff] [ 0.149995] pci 0000:04:00.0: supports D1 D2 [ 0.149996] pci 0000:04:00.0: PME# supported from D0 D1 D2 D3hot D3cold [ 0.152073] pci 0000:00:1c.2: PCI bridge to [bus 04-0b] [ 0.152171] pci 0000:00:1c.2: bridge window [io 0x3000-0x3fff] [ 0.152175] pci 0000:00:1c.2: bridge window [mem 0xf2400000-0xf2bfffff] [ 0.152184] pci 0000:00:1c.2: bridge window [mem 0xf1c00000-0xf23fffff 64bit pref] [ 0.152847] ACPI: Enabled 5 GPEs in block 00 to 3F [ 0.153071] ACPI : EC: GPE = 0x11, I/O: command/status = 0x66, data = 0x62 [ 0.153240] vgaarb: device added: PCI:0000:00:02.0,decodes=io+mem,owns=io+mem,locks=none [ 0.153386] vgaarb: loaded [ 0.153478] vgaarb: bridge control possible 0000:00:02.0 [ 0.153622] SCSI subsystem initialized [ 0.153745] libata version 3.00 loaded. [ 0.153764] ACPI: bus type USB registered [ 0.153874] usbcore: registered new interface driver usbfs [ 0.153977] usbcore: registered new interface driver hub [ 0.154107] usbcore: registered new device driver usb [ 0.154251] PCI: Using ACPI for IRQ routing [ 0.156285] PCI: pci_cache_line_size set to 64 bytes [ 0.156772] e820: reserve RAM buffer [mem 0x0009d800-0x0009ffff] [ 0.156773] e820: reserve RAM buffer [mem 0x40004000-0x43ffffff] [ 0.156774] e820: reserve RAM buffer [mem 0xaed30000-0xafffffff] [ 0.156775] e820: reserve RAM buffer [mem 0x13e600000-0x13fffffff] [ 0.156846] NetLabel: Initializing [ 0.156940] NetLabel: domain hash size = 128 [ 0.157033] NetLabel: protocols = UNLABELED CIPSOv4 [ 0.157136] NetLabel: unlabeled traffic allowed by default [ 0.157287] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0, 0, 0, 0, 0, 0 [ 0.157761] hpet0: 8 comparators, 64-bit 14.318180 MHz counter [ 0.159882] Switched to clocksource hpet [ 0.160003] Could not create debugfs 'set_ftrace_filter' entry [ 0.160103] Could not create debugfs 'set_ftrace_notrace' entry [ 0.164865] pnp: PnP ACPI init [ 0.164981] ACPI: bus type PNP registered [ 0.165392] system 00:00: [mem 0x00000000-0x0009ffff] could not be reserved [ 0.165494] system 00:00: [mem 0x000c0000-0x000c3fff] could not be reserved [ 0.165592] system 00:00: [mem 0x000c4000-0x000c7fff] could not be reserved [ 0.165690] system 00:00: [mem 0x000c8000-0x000cbfff] has been reserved [ 0.165787] system 00:00: [mem 0x000cc000-0x000cffff] has been reserved [ 0.165891] system 00:00: [mem 0x000d0000-0x000d3fff] has been reserved [ 0.165988] system 00:00: [mem 0x000d4000-0x000d7fff] has been reserved [ 0.166086] system 00:00: [mem 0x000d8000-0x000dbfff] has been reserved [ 0.166183] system 00:00: [mem 0x000dc000-0x000dffff] has been reserved [ 0.166280] system 00:00: [mem 0x000e0000-0x000e3fff] could not be reserved [ 0.166377] system 00:00: [mem 0x000e4000-0x000e7fff] could not be reserved [ 0.166474] system 00:00: [mem 0x000e8000-0x000ebfff] could not be reserved [ 0.166572] system 00:00: [mem 0x000ec000-0x000effff] could not be reserved [ 0.166669] system 00:00: [mem 0x000f0000-0x000fffff] could not be reserved [ 0.166768] system 00:00: [mem 0x00100000-0xbf9fffff] could not be reserved [ 0.166865] system 00:00: [mem 0xfec00000-0xfed3ffff] could not be reserved [ 0.166968] system 00:00: [mem 0xfed4c000-0xffffffff] could not be reserved [ 0.167067] system 00:00: Plug and Play ACPI device, IDs PNP0c01 (active) [ 0.167135] pnp 00:01: disabling [mem 0xfffff000-0xffffffff] because it overlaps 0000:01:00.0 BAR 6 [mem 0xfff80000-0xffffffff pref] [ 0.167308] system 00:01: [io 0x0400-0x047f] could not be reserved [ 0.167407] system 00:01: [io 0x0500-0x057f] has been reserved [ 0.167503] system 00:01: [io 0x0800-0x080f] has been reserved [ 0.167599] system 00:01: [io 0x15e0-0x15ef] has been reserved [ 0.167696] system 00:01: [io 0x1600-0x167f] has been reserved [ 0.167793] system 00:01: [mem 0xf8000000-0xfbffffff] has been reserved [ 0.167896] system 00:01: [mem 0xfed1c000-0xfed1ffff] has been reserved [ 0.167995] system 00:01: [mem 0xfed10000-0xfed13fff] has been reserved [ 0.168091] system 00:01: [mem 0xfed18000-0xfed18fff] has been reserved [ 0.168189] system 00:01: [mem 0xfed19000-0xfed19fff] has been reserved [ 0.168286] system 00:01: [mem 0xfed45000-0xfed4bfff] has been reserved [ 0.168383] system 00:01: Plug and Play ACPI device, IDs PNP0c02 (active) [ 0.168428] pnp 00:02: Plug and Play ACPI device, IDs PNP0103 (active) [ 0.168434] pnp 00:03: [dma 4] [ 0.168449] pnp 00:03: Plug and Play ACPI device, IDs PNP0200 (active) [ 0.168465] pnp 00:04: Plug and Play ACPI device, IDs PNP0800 (active) [ 0.168494] pnp 00:05: Plug and Play ACPI device, IDs PNP0c04 (active) [ 0.168517] pnp 00:06: Plug and Play ACPI device, IDs PNP0b00 (active) [ 0.168542] pnp 00:07: Plug and Play ACPI device, IDs LEN0071 PNP0303 (active) [ 0.168564] pnp 00:08: Plug and Play ACPI device, IDs LEN0015 PNP0f13 (active) [ 0.168601] pnp 00:09: Plug and Play ACPI device, IDs SMO1200 PNP0c31 (active) [ 0.169023] pnp: PnP ACPI: found 10 devices [ 0.169120] ACPI: bus type PNP unregistered [ 0.175617] pci 0000:01:00.0: can't claim BAR 6 [mem 0xfff80000-0xffffffff pref]: no compatible bridge window [ 0.175807] pci 0000:01:00.0: BAR 6: can't assign mem pref (size 0x80000) [ 0.175909] pci 0000:00:01.0: PCI bridge to [bus 01] [ 0.176004] pci 0000:00:01.0: bridge window [io 0x5000-0x5fff] [ 0.176101] pci 0000:00:01.0: bridge window [mem 0xf0000000-0xf0ffffff] [ 0.176199] pci 0000:00:01.0: bridge window [mem 0xc0000000-0xd1ffffff 64bit pref] [ 0.176342] pci 0000:00:1c.0: PCI bridge to [bus 02] [ 0.177646] pci 0000:00:1c.0: bridge window [io 0x4000-0x4fff] [ 0.177747] pci 0000:00:1c.0: bridge window [mem 0xf2d00000-0xf34fffff] [ 0.177847] pci 0000:00:1c.0: bridge window [mem 0xf1400000-0xf1bfffff 64bit pref] [ 0.177998] pci 0000:00:1c.1: PCI bridge to [bus 03] [ 0.178097] pci 0000:00:1c.1: bridge window [mem 0xf2c00000-0xf2cfffff] [ 0.178205] pci 0000:00:1c.2: PCI bridge to [bus 04-0b] [ 0.178303] pci 0000:00:1c.2: bridge window [io 0x3000-0x3fff] [ 0.178404] pci 0000:00:1c.2: bridge window [mem 0xf2400000-0xf2bfffff] [ 0.178505] pci 0000:00:1c.2: bridge window [mem 0xf1c00000-0xf23fffff 64bit pref] [ 0.178654] pci_bus 0000:00: resource 4 [io 0x0000-0x0cf7] [ 0.178655] pci_bus 0000:00: resource 5 [io 0x0d00-0xffff] [ 0.178656] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff] [ 0.178658] pci_bus 0000:00: resource 7 [mem 0xbfa00000-0xfebfffff] [ 0.178659] pci_bus 0000:00: resource 8 [mem 0xfed40000-0xfed4bfff] [ 0.178660] pci_bus 0000:01: resource 0 [io 0x5000-0x5fff] [ 0.178661] pci_bus 0000:01: resource 1 [mem 0xf0000000-0xf0ffffff] [ 0.178663] pci_bus 0000:01: resource 2 [mem 0xc0000000-0xd1ffffff 64bit pref] [ 0.178664] pci_bus 0000:02: resource 0 [io 0x4000-0x4fff] [ 0.178665] pci_bus 0000:02: resource 1 [mem 0xf2d00000-0xf34fffff] [ 0.178667] pci_bus 0000:02: resource 2 [mem 0xf1400000-0xf1bfffff 64bit pref] [ 0.178668] pci_bus 0000:03: resource 1 [mem 0xf2c00000-0xf2cfffff] [ 0.178669] pci_bus 0000:04: resource 0 [io 0x3000-0x3fff] [ 0.178671] pci_bus 0000:04: resource 1 [mem 0xf2400000-0xf2bfffff] [ 0.178672] pci_bus 0000:04: resource 2 [mem 0xf1c00000-0xf23fffff 64bit pref] [ 0.178693] NET: Registered protocol family 2 [ 0.178928] TCP established hash table entries: 32768 (order: 6, 262144 bytes) [ 0.179141] TCP bind hash table entries: 32768 (order: 7, 524288 bytes) [ 0.179328] TCP: Hash tables configured (established 32768 bind 32768) [ 0.179442] TCP: reno registered [ 0.179545] UDP hash table entries: 2048 (order: 4, 65536 bytes) [ 0.179659] UDP-Lite hash table entries: 2048 (order: 4, 65536 bytes) [ 0.179803] NET: Registered protocol family 1 [ 0.179914] pci 0000:00:02.0: Boot video device [ 0.180445] PCI: CLS 64 bytes, default 64 [ 0.180480] Unpacking initramfs... [ 0.419917] Freeing initrd memory: 18692K (ffff880035b6f000 - ffff880036db0000) [ 0.420092] PCI-DMA: Using software bounce buffering for IO (SWIOTLB) [ 0.420193] software IO TLB [mem 0xaad30000-0xaed30000] (64MB) mapped at [ffff8800aad30000-ffff8800aed2ffff] [ 0.420565] resource map sanity check conflict: 0xfed10000 0xfed15fff 0xfed10000 0xfed13fff pnp 00:01 [ 0.420713] ------------[ cut here ]------------ [ 0.420810] WARNING: CPU: 0 PID: 1 at arch/x86/mm/ioremap.c:171 __ioremap_caller+0x2dd/0x380() [ 0.420962] Info: mapping multiple BARs. Your kernel is fine. [ 0.421012] Modules linked in: [ 0.421235] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.15.0-0.rc1.git0.1.fc21.x86_64 #1 [ 0.421377] Hardware name: LENOVO 2356JK8/2356JK8, BIOS G7ET94WW (2.54 ) 04/30/2013 [ 0.421518] 0000000000000000 00000000294ea4b4 ffff8801385f9b08 ffffffff8170077e [ 0.421829] ffff8801385f9b50 ffff8801385f9b40 ffffffff81089f6d ffffc90000670000 [ 0.422142] ffff8800a874e200 ffffc90000670000 ffffc90000670000 0000000000006000 [ 0.422450] Call Trace: [ 0.422545] [<ffffffff8170077e>] dump_stack+0x45/0x56 [ 0.422642] [<ffffffff81089f6d>] warn_slowpath_common+0x7d/0xa0 [ 0.422738] [<ffffffff81089fec>] warn_slowpath_fmt+0x5c/0x80 [ 0.422834] [<ffffffff810911d8>] ? iomem_map_sanity_check+0xc8/0xd0 [ 0.422932] [<ffffffff8105786d>] __ioremap_caller+0x2dd/0x380 [ 0.423042] [<ffffffff81057927>] ioremap_nocache+0x17/0x20 [ 0.423138] [<ffffffff81033d0c>] snb_uncore_imc_init_box+0x7c/0xc0 [ 0.423235] [<ffffffff81036da5>] uncore_pci_probe+0xd5/0x1b0 [ 0.423334] [<ffffffff8139c915>] local_pci_probe+0x45/0xa0 [ 0.423430] [<ffffffff8139dca9>] pci_device_probe+0xf9/0x150 [ 0.423527] [<ffffffff8146d39c>] driver_probe_device+0x9c/0x3d0 [ 0.423625] [<ffffffff8146d79b>] __driver_attach+0x8b/0x90 [ 0.423722] [<ffffffff8146d710>] ? __device_attach+0x40/0x40 [ 0.423818] [<ffffffff8146b0c3>] bus_for_each_dev+0x73/0xc0 [ 0.423915] [<ffffffff8146cdee>] driver_attach+0x1e/0x20 [ 0.424038] [<ffffffff8146c990>] bus_add_driver+0x180/0x250 [ 0.424137] [<ffffffff81d4990d>] ? uncore_types_init+0x1a7/0x1a7 [ 0.424234] [<ffffffff8146de44>] driver_register+0x64/0xf0 [ 0.424330] [<ffffffff81d4990d>] ? uncore_types_init+0x1a7/0x1a7 [ 0.424427] [<ffffffff8139c1cc>] __pci_register_driver+0x4c/0x50 [ 0.424524] [<ffffffff81d49a81>] intel_uncore_init+0x174/0x416 [ 0.424622] [<ffffffff81d4990d>] ? uncore_types_init+0x1a7/0x1a7 [ 0.424719] [<ffffffff81002162>] do_one_initcall+0xf2/0x1b0 [ 0.424816] [<ffffffff810abd1d>] ? parse_args+0x21d/0x4d0 [ 0.424913] [<ffffffff81d3d087>] kernel_init_freeable+0x1b8/0x254 [ 0.425018] [<ffffffff816f48e0>] ? rest_init+0x80/0x80 [ 0.425114] [<ffffffff816f48ee>] kernel_init+0xe/0xf0 [ 0.425211] [<ffffffff8171043c>] ret_from_fork+0x7c/0xb0 [ 0.425306] [<ffffffff816f48e0>] ? rest_init+0x80/0x80 [ 0.425405] ---[ end trace 6765dd4a297528d0 ]--- ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. 2014-04-16 22:56 ` Bjorn Helgaas 2014-04-17 0:18 ` Dave Jones @ 2014-04-17 10:45 ` Borislav Petkov 2014-04-17 18:26 ` Bjorn Helgaas 1 sibling, 1 reply; 84+ messages in thread From: Borislav Petkov @ 2014-04-17 10:45 UTC (permalink / raw) To: Bjorn Helgaas Cc: Dave Jones, Rafael J. Wysocki, Zhang, Rui, Lu, Aaron, lkml, x86, Linux PCI, ACPI Devel Maling List, Yinghai Lu, H. Peter Anvin, Stephane Eranian, Yan, Zheng Z Hi Bjorn, thanks for the patch, a couple of notes below: On Wed, Apr 16, 2014 at 04:56:00PM -0600, Bjorn Helgaas wrote: > PNP: Work around Haswell BIOS defect in MCH area reporting > > From: Bjorn Helgaas <bhelgaas@google.com> > > Work around a Haswell BIOS defect that causes part of the MCH area to be > unreported. Yep, what Stephane said, this is not HSW only. > MCHBAR is not an architected PCI BAR, so MCH space is usually reported as a > PNP0C02 resource. The MCH space was 16KB prior to Haswell, but it is 32KB > in Haswell. Some Haswell BIOSes still report a PNP0C02 resource that is > only 16KB, which means the rest of the MCH space is consumed but > unreported. > > This can cause resource map sanity check warnings or (theoretically) a > device conflict if we assigned the unreported space to another device. > > The Intel perf event uncore driver tripped over this when it claimed the > MCH region: > > resource map sanity check conflict: 0xfed10000 0xfed15fff 0xfed10000 0xfed13fff pnp 00:01 > Info: mapping multiple BARs. Your kernel is fine. > > To prevent this, if we find a PNP0C02 resource that covers part of the MCH > space, extend it to cover the entire space. > > Link: http://lkml.kernel.org/r/20140224162400.GE16457@pd.tnic > Reported-by: Borislav Petkov <bp@alien8.de> > Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> > --- > drivers/pnp/quirks.c | 55 ++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 55 insertions(+) > > diff --git a/drivers/pnp/quirks.c b/drivers/pnp/quirks.c > index 258fef272ea7..8402088d4145 100644 > --- a/drivers/pnp/quirks.c > +++ b/drivers/pnp/quirks.c > @@ -334,6 +334,60 @@ static void quirk_amd_mmconfig_area(struct pnp_dev *dev) > } > #endif > > +static void quirk_intel_haswell_mch(struct pnp_dev *dev) > +{ > + struct pci_dev *host; > + u32 addr_lo, addr_hi; > + struct pci_bus_region region; > + struct resource mch; > + struct pnp_resource *pnp_res; > + struct resource *res; > + > + host = pci_get_device(PCI_VENDOR_ID_INTEL, 0x0c00, NULL); And because it is not HSW only, this PCI device ID doesn't match on my IVB system. On mine the hostbridge is 00:00.0 Host bridge: Intel Corporation 3rd Gen Core processor DRAM Controller (rev 09) Subsystem: Lenovo Device 21fa Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx- Latency: 0 Capabilities: <access denied> Kernel driver in use: ivb_uncore 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 and from looking at Dave's, it is the same one, so PCI device ID is 0x154. With that changed to host = pci_get_device(PCI_VENDOR_ID_INTEL, 0x0154, NULL); and a bit of debugging code, it says now: [ 0.235739] quirk_intel_haswell_mch: entry [ 0.235800] quirk_intel_haswell_mch: got host: 0x0 [ 0.235860] quirk_intel_haswell_mch: mch: [mem 0xfed10000-0xfed17fff] [ 0.235930] quirk_intel_haswell_mch: res: [mem 0xfed10000-0xfed13fff] [ 0.235990] pnp 00:01: [Firmware Bug]: [mem 0xfed10000-0xfed13fff] covers only part of Intel Haswell MCH; extending to [mem 0xfed10000-0xfed17fff] So you probably want to have a list of hostbridge pci ids in the quirk or so. Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. 2014-04-17 10:45 ` Borislav Petkov @ 2014-04-17 18:26 ` Bjorn Helgaas 2014-04-17 19:48 ` Borislav Petkov 2014-04-17 19:52 ` Dave Jones 0 siblings, 2 replies; 84+ messages in thread From: Bjorn Helgaas @ 2014-04-17 18:26 UTC (permalink / raw) To: Borislav Petkov Cc: Dave Jones, Rafael J. Wysocki, Zhang, Rui, Lu, Aaron, lkml, x86, Linux PCI, ACPI Devel Maling List, Yinghai Lu, H. Peter Anvin, Stephane Eranian, Yan, Zheng Z Thanks a lot for testing this out and debugging my issues. Here's a new version that looks for both device IDs I know about. I'm still nervous about the modeset problem Dave is seeing. Since the original patch wouldn't find an 8086:0c00 device on Dave's system, it should have done nothing. But since it caused a modesetting problem, there's something else doing on that I don't understand. Bjorn PNP: Work around BIOS defects in Intel MCH area reporting From: Bjorn Helgaas <bhelgaas@google.com> Work around BIOSes that don't report the entire Intel MCH area. MCHBAR is not an architected PCI BAR, so MCH space is usually reported as a PNP0C02 resource. The MCH space was once 16KB, but is 32KB in newer parts. Some BIOSes still report a PNP0C02 resource that is only 16KB, which means the rest of the MCH space is consumed but unreported. This can cause resource map sanity check warnings or (theoretically) a device conflict if we assigned the unreported space to another device. The Intel perf event uncore driver tripped over this when it claimed the MCH region: resource map sanity check conflict: 0xfed10000 0xfed15fff 0xfed10000 0xfed13fff pnp 00:01 Info: mapping multiple BARs. Your kernel is fine. To prevent this, if we find a PNP0C02 resource that covers part of the MCH space, extend it to cover the entire space. Link: http://lkml.kernel.org/r/20140224162400.GE16457@pd.tnic Reported-by: Borislav Petkov <bp@alien8.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> --- drivers/pnp/quirks.c | 74 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 74 insertions(+) diff --git a/drivers/pnp/quirks.c b/drivers/pnp/quirks.c index 258fef272ea7..403bd5c42ed1 100644 --- a/drivers/pnp/quirks.c +++ b/drivers/pnp/quirks.c @@ -334,6 +334,79 @@ static void quirk_amd_mmconfig_area(struct pnp_dev *dev) } #endif +/* Device IDs of parts that have 32KB MCH space */ +static const unsigned int mch_quirk_devices[] = { + 0x0154, /* Ivy Bridge */ + 0x0c00, /* Haswell */ +}; + +static struct pci_dev *get_intel_host(void) +{ + int i; + struct pci_dev *host; + + for (i = 0; i < ARRAY_SIZE(mch_quirk_devices); i++) { + host = pci_get_device(PCI_VENDOR_ID_INTEL, mch_quirk_devices[i], + NULL); + if (host) + return host; + } + return NULL; +} + +static void quirk_intel_mch(struct pnp_dev *dev) +{ + struct pci_dev *host; + u32 addr_lo, addr_hi; + struct pci_bus_region region; + struct resource mch; + struct pnp_resource *pnp_res; + struct resource *res; + + host = get_intel_host(); + if (!host) + return; + + /* + * MCHBAR is not an architected PCI BAR, so MCH space is usually + * reported as a PNP0C02 resource. The MCH space was originally + * 16KB, but is 32KB in newer parts. Some BIOSes still report a + * PNP0C02 resource that is only 16KB, which means the rest of the + * MCH space is consumed but unreported. + */ + + /* + * Read MCHBAR for Host Member Mapped Register Range Base + * https://www-ssl.intel.com/content/www/us/en/processors/core/4th-gen-core-family-desktop-vol-2-datasheet + * Sec 3.1.12. + */ + pci_read_config_dword(host, 0x48, &addr_lo); + region.start = addr_lo & ~0x7fff; + pci_read_config_dword(host, 0x4c, &addr_hi); + region.start |= (dma_addr_t) addr_hi << 32; + region.end = region.start + 32*1024 - 1 ; + + memset(&mch, 0, sizeof(mch)); + mch.flags = IORESOURCE_MEM; + pcibios_bus_to_resource(host->bus, &mch, ®ion); + + list_for_each_entry(pnp_res, &dev->resources, list) { + res = &pnp_res->res; + if (res->end < mch.start || res->start > mch.end) + continue; /* no overlap */ + if (res->start == mch.start && res->end == mch.end) + continue; /* exact match */ + + dev_info(&dev->dev, FW_BUG "PNP resource %pR covers only part of %s Intel MCH; extending to %pR\n", + res, pci_name(host), &mch); + res->start = mch.start; + res->end = mch.end; + break; + } + + pci_dev_put(host); +} + /* * PnP Quirks * Cards or devices that need some tweaking due to incomplete resource info @@ -364,6 +437,7 @@ static struct pnp_fixup pnp_fixups[] = { #ifdef CONFIG_AMD_NB {"PNP0c01", quirk_amd_mmconfig_area}, #endif + {"PNP0c02", quirk_intel_mch}, {""} }; ^ permalink raw reply related [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. 2014-04-17 18:26 ` Bjorn Helgaas @ 2014-04-17 19:48 ` Borislav Petkov 2014-04-17 20:10 ` Bjorn Helgaas 2014-04-17 19:52 ` Dave Jones 1 sibling, 1 reply; 84+ messages in thread From: Borislav Petkov @ 2014-04-17 19:48 UTC (permalink / raw) To: Bjorn Helgaas Cc: Dave Jones, Rafael J. Wysocki, Zhang, Rui, Lu, Aaron, lkml, x86, Linux PCI, ACPI Devel Maling List, Yinghai Lu, H. Peter Anvin, Stephane Eranian, Yan, Zheng Z On Thu, Apr 17, 2014 at 12:26:37PM -0600, Bjorn Helgaas wrote: > Thanks a lot for testing this out and debugging my issues. > > Here's a new version that looks for both device IDs I know about. > > I'm still nervous about the modeset problem Dave is seeing. Since the > original patch wouldn't find an 8086:0c00 device on Dave's system, it > should have done nothing. But since it caused a modesetting problem, > there's something else doing on that I don't understand. Yeah, this is strange, to put it mildly. This quirk wouldnt've done anything besides the iteration over the pci devices with pci_get_device. Which wouldn't do anything (refcount increment or so) if it didn't find the device, right? Bah, today is the day of the strange bugs. :-\ > PNP: Work around BIOS defects in Intel MCH area reporting > > From: Bjorn Helgaas <bhelgaas@google.com> > > Work around BIOSes that don't report the entire Intel MCH area. > > MCHBAR is not an architected PCI BAR, so MCH space is usually reported as a > PNP0C02 resource. The MCH space was once 16KB, but is 32KB in newer parts. > Some BIOSes still report a PNP0C02 resource that is only 16KB, which means > the rest of the MCH space is consumed but unreported. > > This can cause resource map sanity check warnings or (theoretically) a > device conflict if we assigned the unreported space to another device. > > The Intel perf event uncore driver tripped over this when it claimed the > MCH region: > > resource map sanity check conflict: 0xfed10000 0xfed15fff 0xfed10000 0xfed13fff pnp 00:01 > Info: mapping multiple BARs. Your kernel is fine. > > To prevent this, if we find a PNP0C02 resource that covers part of the MCH > space, extend it to cover the entire space. > > Link: http://lkml.kernel.org/r/20140224162400.GE16457@pd.tnic > Reported-by: Borislav Petkov <bp@alien8.de> Yep, this one works fine: [ 0.403855] pnp 00:01: [Firmware Bug]: PNP resource [mem 0xfed10000-0xfed13fff] covers only part of 0000:00:00.0 Intel MCH; extending to [mem 0xfed10000-0xfed17fff] Acked-by: Borislav Petkov <bp@suse.de> Tested-by: Borislav Petkov <bp@suse.de> Just a minor nitpick below. > Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> > --- > drivers/pnp/quirks.c | 74 ++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 74 insertions(+) > > diff --git a/drivers/pnp/quirks.c b/drivers/pnp/quirks.c > index 258fef272ea7..403bd5c42ed1 100644 > --- a/drivers/pnp/quirks.c > +++ b/drivers/pnp/quirks.c > @@ -334,6 +334,79 @@ static void quirk_amd_mmconfig_area(struct pnp_dev *dev) > } > #endif > > +/* Device IDs of parts that have 32KB MCH space */ > +static const unsigned int mch_quirk_devices[] = { > + 0x0154, /* Ivy Bridge */ > + 0x0c00, /* Haswell */ > +}; > + > +static struct pci_dev *get_intel_host(void) > +{ > + int i; > + struct pci_dev *host; > + > + for (i = 0; i < ARRAY_SIZE(mch_quirk_devices); i++) { > + host = pci_get_device(PCI_VENDOR_ID_INTEL, mch_quirk_devices[i], > + NULL); > + if (host) > + return host; > + } > + return NULL; > +} > + > +static void quirk_intel_mch(struct pnp_dev *dev) > +{ > + struct pci_dev *host; > + u32 addr_lo, addr_hi; > + struct pci_bus_region region; > + struct resource mch; > + struct pnp_resource *pnp_res; > + struct resource *res; > + > + host = get_intel_host(); > + if (!host) > + return; > + > + /* > + * MCHBAR is not an architected PCI BAR, so MCH space is usually > + * reported as a PNP0C02 resource. The MCH space was originally > + * 16KB, but is 32KB in newer parts. Some BIOSes still report a > + * PNP0C02 resource that is only 16KB, which means the rest of the > + * MCH space is consumed but unreported. > + */ > + > + /* > + * Read MCHBAR for Host Member Mapped Register Range Base > + * https://www-ssl.intel.com/content/www/us/en/processors/core/4th-gen-core-family-desktop-vol-2-datasheet > + * Sec 3.1.12. > + */ > + pci_read_config_dword(host, 0x48, &addr_lo); > + region.start = addr_lo & ~0x7fff; > + pci_read_config_dword(host, 0x4c, &addr_hi); > + region.start |= (dma_addr_t) addr_hi << 32; > + region.end = region.start + 32*1024 - 1 ; checkpatch complains about a trailing space before the semicolon. > + > + memset(&mch, 0, sizeof(mch)); > + mch.flags = IORESOURCE_MEM; > + pcibios_bus_to_resource(host->bus, &mch, ®ion); > + > + list_for_each_entry(pnp_res, &dev->resources, list) { > + res = &pnp_res->res; > + if (res->end < mch.start || res->start > mch.end) > + continue; /* no overlap */ > + if (res->start == mch.start && res->end == mch.end) > + continue; /* exact match */ > + > + dev_info(&dev->dev, FW_BUG "PNP resource %pR covers only part of %s Intel MCH; extending to %pR\n", > + res, pci_name(host), &mch); > + res->start = mch.start; > + res->end = mch.end; > + break; > + } > + > + pci_dev_put(host); > +} > + > /* > * PnP Quirks > * Cards or devices that need some tweaking due to incomplete resource info > @@ -364,6 +437,7 @@ static struct pnp_fixup pnp_fixups[] = { > #ifdef CONFIG_AMD_NB > {"PNP0c01", quirk_amd_mmconfig_area}, > #endif > + {"PNP0c02", quirk_intel_mch}, > {""} > }; -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. 2014-04-17 19:48 ` Borislav Petkov @ 2014-04-17 20:10 ` Bjorn Helgaas 0 siblings, 0 replies; 84+ messages in thread From: Bjorn Helgaas @ 2014-04-17 20:10 UTC (permalink / raw) To: Borislav Petkov Cc: Dave Jones, Rafael J. Wysocki, Zhang, Rui, Lu, Aaron, lkml, x86, Linux PCI, ACPI Devel Maling List, Yinghai Lu, H. Peter Anvin, Stephane Eranian, Yan, Zheng Z On Thu, Apr 17, 2014 at 1:48 PM, Borislav Petkov <bp@alien8.de> wrote: > On Thu, Apr 17, 2014 at 12:26:37PM -0600, Bjorn Helgaas wrote: >> Thanks a lot for testing this out and debugging my issues. >> >> Here's a new version that looks for both device IDs I know about. >> >> I'm still nervous about the modeset problem Dave is seeing. Since the >> original patch wouldn't find an 8086:0c00 device on Dave's system, it >> should have done nothing. But since it caused a modesetting problem, >> there's something else doing on that I don't understand. > > Yeah, this is strange, to put it mildly. This quirk wouldnt've done > anything besides the iteration over the pci devices with pci_get_device. > Which wouldn't do anything (refcount increment or so) if it didn't find > the device, right? Right. > Bah, today is the day of the strange bugs. :-\ > >> PNP: Work around BIOS defects in Intel MCH area reporting >> >> From: Bjorn Helgaas <bhelgaas@google.com> >> >> Work around BIOSes that don't report the entire Intel MCH area. >> >> MCHBAR is not an architected PCI BAR, so MCH space is usually reported as a >> PNP0C02 resource. The MCH space was once 16KB, but is 32KB in newer parts. >> Some BIOSes still report a PNP0C02 resource that is only 16KB, which means >> the rest of the MCH space is consumed but unreported. >> >> This can cause resource map sanity check warnings or (theoretically) a >> device conflict if we assigned the unreported space to another device. >> >> The Intel perf event uncore driver tripped over this when it claimed the >> MCH region: >> >> resource map sanity check conflict: 0xfed10000 0xfed15fff 0xfed10000 0xfed13fff pnp 00:01 >> Info: mapping multiple BARs. Your kernel is fine. >> >> To prevent this, if we find a PNP0C02 resource that covers part of the MCH >> space, extend it to cover the entire space. >> >> Link: http://lkml.kernel.org/r/20140224162400.GE16457@pd.tnic >> Reported-by: Borislav Petkov <bp@alien8.de> > > Yep, this one works fine: > > [ 0.403855] pnp 00:01: [Firmware Bug]: PNP resource [mem 0xfed10000-0xfed13fff] covers only part of 0000:00:00.0 Intel MCH; extending to [mem 0xfed10000-0xfed17fff] > > Acked-by: Borislav Petkov <bp@suse.de> > Tested-by: Borislav Petkov <bp@suse.de> >> + region.end = region.start + 32*1024 - 1 ; > checkpatch complains about a trailing space before the semicolon. Thanks! I hate typos like that. I'll fix this, add your tested-by and ack, and send to Rafael. Bjorn ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. 2014-04-17 18:26 ` Bjorn Helgaas 2014-04-17 19:48 ` Borislav Petkov @ 2014-04-17 19:52 ` Dave Jones 2014-04-17 20:01 ` Borislav Petkov 1 sibling, 1 reply; 84+ messages in thread From: Dave Jones @ 2014-04-17 19:52 UTC (permalink / raw) To: Bjorn Helgaas Cc: Borislav Petkov, Rafael J. Wysocki, Zhang, Rui, Lu, Aaron, lkml, x86, Linux PCI, ACPI Devel Maling List, Yinghai Lu, H. Peter Anvin, Stephane Eranian, Yan, Zheng Z, daniel.vetter On Thu, Apr 17, 2014 at 12:26:37PM -0600, Bjorn Helgaas wrote: > Thanks a lot for testing this out and debugging my issues. > > Here's a new version that looks for both device IDs I know about. I can confirm this patch does fix the backtrace. I disabled lockdep, and now I can get to X each boot, but I still see a black screen rather than a console between modesetting becoming active, and X starting. (The lockdep thing turned out to be a known XFS false positive, but for some reason it actually caused X to lock up) > I'm still nervous about the modeset problem Dave is seeing. Since the > original patch wouldn't find an 8086:0c00 device on Dave's system, it > should have done nothing. But since it caused a modesetting problem, > there's something else doing on that I don't understand. I don't know if it's relevant, but this laptop (and I suspect many other thinkpads which seem affected) have dual gfx, both show up on the bus, even if though the nvidia isn't in use.. 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) (prog-if 00 [VGA controller]) Subsystem: Lenovo Device 2200 Flags: bus master, fast devsel, latency 0, IRQ 44 Memory at f1000000 (64-bit, non-prefetchable) [size=4M] Memory at e0000000 (64-bit, prefetchable) [size=256M] I/O ports at 6000 [size=64] Expansion ROM at <unassigned> [disabled] Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Capabilities: [d0] Power Management version 2 Capabilities: [a4] PCI Advanced Features Kernel driver in use: i915 01:00.0 3D controller: NVIDIA Corporation GF117M [GeForce 610M/710M/820M / GT 620M/625M/630M/720M] (rev a1) Subsystem: Lenovo NVS 5200M Flags: bus master, fast devsel, latency 0, IRQ 11 Memory at f0000000 (32-bit, non-prefetchable) [size=16M] Memory at c0000000 (64-bit, prefetchable) [size=256M] Memory at d0000000 (64-bit, prefetchable) [size=32M] I/O ports at 5000 [size=128] Expansion ROM at <ignored> [disabled] Capabilities: [60] Power Management version 3 Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+ Capabilities: [78] Express Endpoint, MSI 00 Capabilities: [b4] Vendor Specific Information: Len=14 <?> Capabilities: [100] Virtual Channel Capabilities: [128] Power Budgeting <?> Capabilities: [600] Vendor Specific Information: ID=0001 Rev=1 Len=024 <?> Just as X starts up, I see this in dmesg.. [ 42.879049] [drm:cpt_serr_int_handler] *ERROR* PCH transcoder A FIFO underrun Dave ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. 2014-04-17 19:52 ` Dave Jones @ 2014-04-17 20:01 ` Borislav Petkov 2014-04-17 20:03 ` Dave Jones 0 siblings, 1 reply; 84+ messages in thread From: Borislav Petkov @ 2014-04-17 20:01 UTC (permalink / raw) To: Dave Jones Cc: Bjorn Helgaas, Rafael J. Wysocki, Zhang, Rui, Lu, Aaron, lkml, x86, Linux PCI, ACPI Devel Maling List, Yinghai Lu, H. Peter Anvin, Stephane Eranian, Yan, Zheng Z, daniel.vetter On Thu, Apr 17, 2014 at 03:52:40PM -0400, Dave Jones wrote: > Just as X starts up, I see this in dmesg.. > > [ 42.879049] [drm:cpt_serr_int_handler] *ERROR* PCH transcoder A FIFO underrun FWIW, I have that too. It should be something i915-related: [ 0.617673] [drm] Memory usable by graphics device = 2048M [ 0.694445] i915 0000:00:02.0: irq 42 for MSI/MSI-X [ 0.694549] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 0.694631] [drm] Driver supports precise vblank timestamp query. [ 0.695313] vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem [ 0.788300] [drm] GMBUS [i915 gmbus dpb] timed out, falling back to bit banging on pin 5 [ 0.799829] fbcon: inteldrmfb (fb0) is primary device [ 1.176845] [drm:cpt_serr_int_handler] *ERROR* PCH transcoder A FIFO underrun -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. 2014-04-17 20:01 ` Borislav Petkov @ 2014-04-17 20:03 ` Dave Jones 2014-04-17 20:53 ` Dave Jones 0 siblings, 1 reply; 84+ messages in thread From: Dave Jones @ 2014-04-17 20:03 UTC (permalink / raw) To: Borislav Petkov Cc: Bjorn Helgaas, Rafael J. Wysocki, Zhang, Rui, Lu, Aaron, lkml, x86, Linux PCI, ACPI Devel Maling List, Yinghai Lu, H. Peter Anvin, Stephane Eranian, Yan, Zheng Z, daniel.vetter On Thu, Apr 17, 2014 at 10:01:27PM +0200, Borislav Petkov wrote: > On Thu, Apr 17, 2014 at 03:52:40PM -0400, Dave Jones wrote: > > Just as X starts up, I see this in dmesg.. > > > > [ 42.879049] [drm:cpt_serr_int_handler] *ERROR* PCH transcoder A FIFO underrun > > FWIW, I have that too. It should be something i915-related: > > [ 0.617673] [drm] Memory usable by graphics device = 2048M > [ 0.694445] i915 0000:00:02.0: irq 42 for MSI/MSI-X > [ 0.694549] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > [ 0.694631] [drm] Driver supports precise vblank timestamp query. > [ 0.695313] vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem > [ 0.788300] [drm] GMBUS [i915 gmbus dpb] timed out, falling back to bit banging on pin 5 > [ 0.799829] fbcon: inteldrmfb (fb0) is primary device > [ 1.176845] [drm:cpt_serr_int_handler] *ERROR* PCH transcoder A FIFO underrun Can you send me your .config off-list ? I wonder if this is something config specific that's causing me to see this, and you not, given we've apparently got similar machines. Dave ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. 2014-04-17 20:03 ` Dave Jones @ 2014-04-17 20:53 ` Dave Jones 2014-04-17 21:01 ` Borislav Petkov 0 siblings, 1 reply; 84+ messages in thread From: Dave Jones @ 2014-04-17 20:53 UTC (permalink / raw) To: Borislav Petkov, Bjorn Helgaas, Rafael J. Wysocki, Zhang, Rui, Lu, Aaron, lkml, x86, Linux PCI, ACPI Devel Maling List, Yinghai Lu, H. Peter Anvin, Stephane Eranian, Yan, Zheng Z, daniel.vetter On Thu, Apr 17, 2014 at 04:03:52PM -0400, Dave Jones wrote: > On Thu, Apr 17, 2014 at 10:01:27PM +0200, Borislav Petkov wrote: > > On Thu, Apr 17, 2014 at 03:52:40PM -0400, Dave Jones wrote: > > > Just as X starts up, I see this in dmesg.. > > > > > > [ 42.879049] [drm:cpt_serr_int_handler] *ERROR* PCH transcoder A FIFO underrun > > > > FWIW, I have that too. It should be something i915-related: > > > > [ 0.617673] [drm] Memory usable by graphics device = 2048M > > [ 0.694445] i915 0000:00:02.0: irq 42 for MSI/MSI-X > > [ 0.694549] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > > [ 0.694631] [drm] Driver supports precise vblank timestamp query. > > [ 0.695313] vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem > > [ 0.788300] [drm] GMBUS [i915 gmbus dpb] timed out, falling back to bit banging on pin 5 > > [ 0.799829] fbcon: inteldrmfb (fb0) is primary device > > [ 1.176845] [drm:cpt_serr_int_handler] *ERROR* PCH transcoder A FIFO underrun > > Can you send me your .config off-list ? > I wonder if this is something config specific that's causing me to see > this, and you not, given we've apparently got similar machines. ok, with your config I get back to a console after the modesetting switch, but then it hangs in USB init. Hrmm. Dave ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. 2014-04-17 20:53 ` Dave Jones @ 2014-04-17 21:01 ` Borislav Petkov [not found] ` <20140417213027.GA22412@redhat.com> 0 siblings, 1 reply; 84+ messages in thread From: Borislav Petkov @ 2014-04-17 21:01 UTC (permalink / raw) To: Dave Jones Cc: Bjorn Helgaas, Rafael J. Wysocki, Zhang, Rui, Lu, Aaron, lkml, x86, Linux PCI, ACPI Devel Maling List, Yinghai Lu, H. Peter Anvin, Stephane Eranian, Yan, Zheng Z, daniel.vetter On Thu, Apr 17, 2014 at 04:53:55PM -0400, Dave Jones wrote: > ok, with your config I get back to a console after the modesetting > switch, but then it hangs in USB init. Maybe because of our machines are not that similar there? Can you take my config but paste the usb part of yours and see whether it boots fine then? It could be yours and mine have different USB hw... -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- ^ permalink raw reply [flat|nested] 84+ messages in thread
[parent not found: <20140417213027.GA22412@redhat.com>]
* Re: Info: mapping multiple BARs. Your kernel is fine. [not found] ` <20140417213027.GA22412@redhat.com> @ 2014-04-18 10:38 ` Borislav Petkov 0 siblings, 0 replies; 84+ messages in thread From: Borislav Petkov @ 2014-04-18 10:38 UTC (permalink / raw) To: Dave Jones Cc: Bjorn Helgaas, Rafael J. Wysocki, Zhang, Rui, Lu, Aaron, lkml, x86, Linux PCI, ACPI Devel Maling List, Yinghai Lu, H. Peter Anvin, Stephane Eranian, Yan, Zheng Z, daniel.vetter On Thu, Apr 17, 2014 at 05:30:27PM -0400, Dave Jones wrote: > I think it's just implicated because that's the next thing that seems > to init after the modeswitch. The config differences are small, just > things like =m instead of =y or vice-versa. > > I'm about to head into a long weekend, so I'll get back to this on > Monday, but for now I'm out of ideas. This is for when you get back: :-) Can you debug that hang a bit more, like enable some sensible options under "Kernel Hacking" or somesuch, boot with initcall_debug, add more printks at key places? If the machine would tell us why exactly it hangs, we might have an idea, like corruption, transaction stall, whatever... -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. 2014-04-16 20:31 ` Bjorn Helgaas 2014-04-16 22:31 ` Dave Jones @ 2014-04-16 23:08 ` Stephane Eranian 2014-04-16 23:11 ` Bjorn Helgaas 1 sibling, 1 reply; 84+ messages in thread From: Stephane Eranian @ 2014-04-16 23:08 UTC (permalink / raw) To: Bjorn Helgaas Cc: Borislav Petkov, Rafael J. Wysocki, Zhang, Rui, Lu, Aaron, lkml, x86, Linux PCI, ACPI Devel Maling List, Yinghai Lu, H. Peter Anvin, Yan, Zheng Z On Wed, Apr 16, 2014 at 1:31 PM, Bjorn Helgaas <bhelgaas@google.com> wrote: > On Wed, Apr 16, 2014 at 09:04:04PM +0200, Borislav Petkov wrote: >> On Thu, Mar 20, 2014 at 02:48:30PM -0600, Bjorn Helgaas wrote: >> > Right. Even if we had this long-term solution, we'd still have >> > Stephane's current problem, because the PNP0C02 _CRS is still wrong. >> > >> > We do have a drivers/pnp/quirks.c where we could conceivably adjust >> > the PNP resource if we found the matching PCI device and MCHBAR. That >> > should solve Stephane's problem even with the current >> > drivers/pnp/system.c. >> >> Guys, this still triggers in -rc1. Do we have a fix or something >> testable at least? > > Hi Boris, > > Can you try the patch below? > > > > PNP: Work around Haswell BIOS defect in MCH area reporting > > From: Bjorn Helgaas <bhelgaas@google.com> > > Work around a Haswell BIOS defect that causes part of the MCH area to be > unreported. > > MCHBAR is not an architected PCI BAR, so MCH space is usually reported as a > PNP0C02 resource. The MCH space was 16KB prior to Haswell, but it is 32KB > in Haswell. Some Haswell BIOSes still report a PNP0C02 resource that is > only 16KB, which means the rest of the MCH space is consumed but > unreported. > Why are you saying this is Haswell vs. others. I see the problem on my IvyBridge laptop, like Boris. > This can cause resource map sanity check warnings or (theoretically) a > device conflict if we assigned the unreported space to another device. > > The Intel perf event uncore driver tripped over this when it claimed the > MCH region: > > resource map sanity check conflict: 0xfed10000 0xfed15fff 0xfed10000 0xfed13fff pnp 00:01 > Info: mapping multiple BARs. Your kernel is fine. > > To prevent this, if we find a PNP0C02 resource that covers part of the MCH > space, extend it to cover the entire space. > > Link: http://lkml.kernel.org/r/20140224162400.GE16457@pd.tnic > Reported-by: Borislav Petkov <bp@alien8.de> > Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> > --- > drivers/pnp/quirks.c | 52 ++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 52 insertions(+) > > diff --git a/drivers/pnp/quirks.c b/drivers/pnp/quirks.c > index 258fef272ea7..023edf592371 100644 > --- a/drivers/pnp/quirks.c > +++ b/drivers/pnp/quirks.c > @@ -334,6 +334,57 @@ static void quirk_amd_mmconfig_area(struct pnp_dev *dev) > } > #endif > > +static void quirk_intel_haswell_mch(struct pnp_dev *dev) > +{ > + struct pci_dev *host; > + u32 addr_lo, addr_hi; > + struct pci_bus_region region; > + struct resource mch; > + struct pnp_resource *pnp_res; > + struct resource *res; > + > + host = pci_get_device(PCI_VENDOR_ID_INTEL, 0x0c00, NULL); > + if (!host) > + return; > + > + /* > + * MCHBAR is not an architected PCI BAR, so MCH space is usually > + * reported as a PNP0C02 resource. The MCH space was 16KB prior to > + * Haswell, but it is 32KB in Haswell. Some Haswell BIOSes still > + * report a PNP0C02 resource that is only 16KB, which means the > + * rest of the MCH space is consumed but unreported. > + */ > + > + /* > + * Read MCHBAR for Host Member Mapped Register Range Base > + * https://www-ssl.intel.com/content/www/us/en/processors/core/4th-gen-core-family-desktop-vol-2-datasheet > + * Sec 3.1.12. > + */ > + pci_read_config_dword(host, 0x48, &addr_lo); > + region.start = addr_lo & ~0x7fff; > + pci_read_config_dword(host, 0x4c, &addr_hi); > + region.start |= (dma_addr_t) addr_hi << 32; > + region.end = region.start + 32*1024 - 1 ; > + pcibios_bus_to_resource(host->bus, &mch, ®ion); > + > + list_for_each_entry(pnp_res, &dev->resources, list) { > + res = &pnp_res->res; > + if (res->end < mch.start || res->start > mch.end) > + continue; /* no overlap */ > + if (res->start == mch.start && res->end == mch.end) > + continue; /* exact match */ > + > + dev_info(&dev->dev, FW_BUG > + "%pR covers only part of Intel Haswell MCH; extending to %pR\n", > + res, &mch); > + res->start = mch.start; > + res->end = mch.end; > + break; > + } > + > + pci_dev_put(host); > +} > + > /* > * PnP Quirks > * Cards or devices that need some tweaking due to incomplete resource info > @@ -364,6 +415,7 @@ static struct pnp_fixup pnp_fixups[] = { > #ifdef CONFIG_AMD_NB > {"PNP0c01", quirk_amd_mmconfig_area}, > #endif > + {"PNP0c02", quirk_intel_haswell_mch}, > {""} > }; > ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: Info: mapping multiple BARs. Your kernel is fine. 2014-04-16 23:08 ` Stephane Eranian @ 2014-04-16 23:11 ` Bjorn Helgaas 0 siblings, 0 replies; 84+ messages in thread From: Bjorn Helgaas @ 2014-04-16 23:11 UTC (permalink / raw) To: Stephane Eranian Cc: Borislav Petkov, Rafael J. Wysocki, Zhang, Rui, Lu, Aaron, lkml, x86, Linux PCI, ACPI Devel Maling List, Yinghai Lu, H. Peter Anvin, Yan, Zheng Z On Wed, Apr 16, 2014 at 5:08 PM, Stephane Eranian <eranian@google.com> wrote: > On Wed, Apr 16, 2014 at 1:31 PM, Bjorn Helgaas <bhelgaas@google.com> wrote: >> On Wed, Apr 16, 2014 at 09:04:04PM +0200, Borislav Petkov wrote: >>> On Thu, Mar 20, 2014 at 02:48:30PM -0600, Bjorn Helgaas wrote: >>> > Right. Even if we had this long-term solution, we'd still have >>> > Stephane's current problem, because the PNP0C02 _CRS is still wrong. >>> > >>> > We do have a drivers/pnp/quirks.c where we could conceivably adjust >>> > the PNP resource if we found the matching PCI device and MCHBAR. That >>> > should solve Stephane's problem even with the current >>> > drivers/pnp/system.c. >>> >>> Guys, this still triggers in -rc1. Do we have a fix or something >>> testable at least? >> >> Hi Boris, >> >> Can you try the patch below? >> >> >> >> PNP: Work around Haswell BIOS defect in MCH area reporting >> >> From: Bjorn Helgaas <bhelgaas@google.com> >> >> Work around a Haswell BIOS defect that causes part of the MCH area to be >> unreported. >> >> MCHBAR is not an architected PCI BAR, so MCH space is usually reported as a >> PNP0C02 resource. The MCH space was 16KB prior to Haswell, but it is 32KB >> in Haswell. Some Haswell BIOSes still report a PNP0C02 resource that is >> only 16KB, which means the rest of the MCH space is consumed but >> unreported. >> > Why are you saying this is Haswell vs. others. I see the problem on my > IvyBridge laptop, like Boris. Ah, good question. Somewhere I got pointed to the Haswell docs, which say 32KB. I don't know what other parts have 32KB MCH spaces. If we could figure out a list of device IDs with 32KB spaces, we could add that to the quirk. But I don't know how to come up with a complete list. Bjorn ^ permalink raw reply [flat|nested] 84+ messages in thread
end of thread, other threads:[~2014-04-18 10:38 UTC | newest] Thread overview: 84+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-02-24 16:24 Info: mapping multiple BARs. Your kernel is fine Borislav Petkov 2014-02-24 16:24 ` Borislav Petkov 2014-02-24 20:19 ` Borislav Petkov 2014-02-24 20:19 ` Borislav Petkov 2014-02-25 15:48 ` H. Peter Anvin 2014-02-25 16:14 ` Stephane Eranian 2014-02-25 16:30 ` Borislav Petkov 2014-02-25 16:30 ` Borislav Petkov 2014-02-25 16:33 ` Stephane Eranian 2014-02-25 17:39 ` Borislav Petkov 2014-02-25 17:39 ` Borislav Petkov 2014-02-25 18:54 ` Stephane Eranian 2014-02-25 22:10 ` Borislav Petkov 2014-02-25 22:10 ` Borislav Petkov 2014-02-26 6:56 ` Stephane Eranian 2014-02-26 9:29 ` Borislav Petkov 2014-02-26 9:29 ` Borislav Petkov 2014-02-26 9:47 ` Stephane Eranian 2014-02-26 9:59 ` Borislav Petkov 2014-02-26 9:59 ` Borislav Petkov 2014-02-27 10:12 ` Stephane Eranian 2014-02-27 10:27 ` Borislav Petkov 2014-02-27 10:27 ` Borislav Petkov 2014-02-27 22:12 ` Rafael J. Wysocki 2014-02-27 22:12 ` Rafael J. Wysocki 2014-02-27 22:21 ` Borislav Petkov 2014-02-27 22:21 ` Borislav Petkov 2014-03-05 21:03 ` Stephane Eranian 2014-03-05 21:03 ` Stephane Eranian 2014-02-27 10:30 ` Peter Zijlstra 2014-02-27 10:30 ` Peter Zijlstra 2014-02-27 10:32 ` Stephane Eranian 2014-02-27 11:08 ` Peter Zijlstra 2014-02-27 11:08 ` Peter Zijlstra 2014-02-27 12:20 ` Stephane Eranian 2014-02-26 13:57 ` Rafael J. Wysocki 2014-02-26 13:57 ` Rafael J. Wysocki 2014-02-26 13:50 ` Peter Zijlstra 2014-02-26 13:50 ` Peter Zijlstra 2014-02-26 13:52 ` Borislav Petkov 2014-02-26 13:52 ` Borislav Petkov 2014-03-15 14:15 ` Rafael J. Wysocki 2014-03-16 11:55 ` Borislav Petkov 2014-03-16 13:08 ` Stephane Eranian 2014-03-17 0:09 ` Rafael J. Wysocki 2014-03-17 0:23 ` Rafael J. Wysocki 2014-03-20 2:24 ` Aaron Lu 2014-03-20 2:29 ` Stephane Eranian 2014-03-20 3:03 ` Zhang, Rui 2014-03-20 3:03 ` Zhang, Rui 2014-03-20 3:03 ` Zhang, Rui 2014-03-20 3:34 ` Stephane Eranian 2014-03-20 7:53 ` Zhang, Rui 2014-03-20 7:53 ` Zhang, Rui 2014-03-20 7:53 ` Zhang, Rui 2014-03-20 8:16 ` Yan, Zheng 2014-03-20 13:43 ` Zhang Rui 2014-03-20 16:03 ` Stephane Eranian 2014-03-20 13:35 ` Zhang Rui 2014-03-20 13:35 ` Zhang Rui 2014-03-20 12:29 ` Rafael J. Wysocki 2014-03-20 16:45 ` Bjorn Helgaas 2014-03-20 20:55 ` Rafael J. Wysocki 2014-03-20 20:48 ` Bjorn Helgaas 2014-04-16 19:04 ` Borislav Petkov 2014-04-16 20:24 ` Zhang, Rui 2014-04-16 20:24 ` Zhang, Rui 2014-04-16 20:24 ` Zhang, Rui 2014-04-16 20:31 ` Bjorn Helgaas 2014-04-16 22:31 ` Dave Jones 2014-04-16 22:56 ` Bjorn Helgaas 2014-04-17 0:18 ` Dave Jones 2014-04-17 10:45 ` Borislav Petkov 2014-04-17 18:26 ` Bjorn Helgaas 2014-04-17 19:48 ` Borislav Petkov 2014-04-17 20:10 ` Bjorn Helgaas 2014-04-17 19:52 ` Dave Jones 2014-04-17 20:01 ` Borislav Petkov 2014-04-17 20:03 ` Dave Jones 2014-04-17 20:53 ` Dave Jones 2014-04-17 21:01 ` Borislav Petkov [not found] ` <20140417213027.GA22412@redhat.com> 2014-04-18 10:38 ` Borislav Petkov 2014-04-16 23:08 ` Stephane Eranian 2014-04-16 23:11 ` Bjorn Helgaas
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.