* perf/x86/intel/uncore
@ 2019-01-25 18:54 Song Liu
2019-01-25 20:08 ` perf/x86/intel/uncore Liang, Kan
0 siblings, 1 reply; 7+ messages in thread
From: Song Liu @ 2019-01-25 18:54 UTC (permalink / raw)
To: lkml; +Cc: kan.liang
Hi,
We are debugging an issue that skx_pci_uncores cannot be registered on
8-socket system with Xeon Platinum 8176 CPUs. After poking around for a
while, I found it is caused by snbep_pci2phy_map_init() couldn't find
a unbox_dev:
ubox_dev = pci_get_device(PCI_VENDOR_ID_INTEL, devid, ubox_dev);
unbox_dev == NULL
...
The same kernel (Linus' master) works fine on some single socket SKX
systems.
I am not sure what to check next. And I am not sure whether this is
specific to this system (HPE Superdome Flex).
One thing I noticed is that the PCI configuration space shows
subsystem vendor ID of 0x1590 instead of 0x8086:
0000:00:08.0 System peripheral: Intel Corporation Sky Lake-E Ubox Registers (rev 04)
00: 86 80 14 20 00 00 10 00 04 00 80 08 00 00 80 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 90 15 14 20 << subsystem vendor
30: 00 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00
But I don't think that is the problem as the code search with PCI_ANY_ID.
Any suggestions on what might be broken? And what to try next?
Thanks in advance!
Song
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: perf/x86/intel/uncore
2019-01-25 18:54 perf/x86/intel/uncore Song Liu
@ 2019-01-25 20:08 ` Liang, Kan
2019-01-25 20:16 ` perf/x86/intel/uncore Song Liu
0 siblings, 1 reply; 7+ messages in thread
From: Liang, Kan @ 2019-01-25 20:08 UTC (permalink / raw)
To: Song Liu, lkml
On 1/25/2019 1:54 PM, Song Liu wrote:
> Hi,
>
> We are debugging an issue that skx_pci_uncores cannot be registered on
> 8-socket system with Xeon Platinum 8176 CPUs. After poking around for a
> while, I found it is caused by snbep_pci2phy_map_init() couldn't find
> a unbox_dev:
>
> ubox_dev = pci_get_device(PCI_VENDOR_ID_INTEL, devid, ubox_dev);
> unbox_dev == NULL
> ...
>
> The same kernel (Linus' master) works fine on some single socket SKX
> systems.
>
> I am not sure what to check next. And I am not sure whether this is
> specific to this system (HPE Superdome Flex).
Could you please share the offset 0xC0 and 0xD4 of the PCI configuration
space for each device which PCI ID is 0x2014?
snbep_pci2phy_map_init() tries to build a mapping from BUS# to Socket ID.
CPUNODEID (0xc0) discloses the Node ID of current BUS.
GIDNIDMAP (0xd4) discloses the mapping between Socket ID and Node ID.
Here is an example from a 4 socket SKX.
BUS CPUNODEID(bit2:0) GIDNIDMAP
0x0 0x0 0x688
0x40 0x1 0x688
0x80 0x2 0x688
0xC0 0x3 0x688
>
> One thing I noticed is that the PCI configuration space shows
> subsystem vendor ID of 0x1590 instead of 0x8086:
>
> 0000:00:08.0 System peripheral: Intel Corporation Sky Lake-E Ubox Registers (rev 04)
> 00: 86 80 14 20 00 00 10 00 04 00 80 08 00 00 80 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 90 15 14 20 << subsystem vendor
>
> 30: 00 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00
>
> But I don't think that is the problem as the code search with PCI_ANY_ID.
>
It looks for the device with PCI ID 0x2014.
Thanks,
Kan
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: perf/x86/intel/uncore
2019-01-25 20:08 ` perf/x86/intel/uncore Liang, Kan
@ 2019-01-25 20:16 ` Song Liu
2019-01-25 21:35 ` perf/x86/intel/uncore Liang, Kan
0 siblings, 1 reply; 7+ messages in thread
From: Song Liu @ 2019-01-25 20:16 UTC (permalink / raw)
To: Liang, Kan; +Cc: lkml
Thanks Kan!
> On Jan 25, 2019, at 12:08 PM, Liang, Kan <kan.liang@linux.intel.com> wrote:
>
>
>
> On 1/25/2019 1:54 PM, Song Liu wrote:
>> Hi,
>> We are debugging an issue that skx_pci_uncores cannot be registered on
>> 8-socket system with Xeon Platinum 8176 CPUs. After poking around for a
>> while, I found it is caused by snbep_pci2phy_map_init() couldn't find
>> a unbox_dev:
>> ubox_dev = pci_get_device(PCI_VENDOR_ID_INTEL, devid, ubox_dev);
>> unbox_dev == NULL
>> ...
>> The same kernel (Linus' master) works fine on some single socket SKX
>> systems.
>> I am not sure what to check next. And I am not sure whether this is
>> specific to this system (HPE Superdome Flex).
>
> Could you please share the offset 0xC0 and 0xD4 of the PCI configuration space for each device which PCI ID is 0x2014?
>
> snbep_pci2phy_map_init() tries to build a mapping from BUS# to Socket ID.
> CPUNODEID (0xc0) discloses the Node ID of current BUS.
> GIDNIDMAP (0xd4) discloses the mapping between Socket ID and Node ID.
>
> Here is an example from a 4 socket SKX.
> BUS CPUNODEID(bit2:0) GIDNIDMAP
> 0x0 0x0 0x688
> 0x40 0x1 0x688
> 0x80 0x2 0x688
> 0xC0 0x3 0x688
>
Here is the data I get:
# lspci -xxx | grep "86 80 14 20" -A 15 -B 1 | grep -e "86 80 14 20" -e c0: -e d0: -e Intel
0000:00:08.0 System peripheral: Intel Corporation Sky Lake-E Ubox Registers (rev 04)
00: 86 80 14 20 00 00 10 00 04 00 80 08 00 00 80 00
c0: 00 a0 00 00 2f 00 00 80 01 00 02 00 2f 2f 2f 20
d0: 02 00 00 00 88 d6 b6 00 01 00 00 00 00 00 00 00
0001:00:08.0 System peripheral: Intel Corporation Sky Lake-E Ubox Registers (rev 04)
00: 86 80 14 20 00 00 10 00 04 00 80 08 00 00 80 00
c0: 01 80 00 00 1f 00 00 80 01 00 02 00 1f 1f 1f 10
d0: 02 00 00 00 88 46 92 00 01 00 00 00 00 00 00 00
0002:00:08.0 System peripheral: Intel Corporation Sky Lake-E Ubox Registers (rev 04)
00: 86 80 14 20 00 00 10 00 04 00 80 08 00 00 80 00
c0: 02 e0 00 00 8f 00 00 80 01 00 02 00 8f 8f 8f 80
d0: 02 00 00 00 88 f6 ff 00 01 00 00 00 00 00 00 00
0003:00:08.0 System peripheral: Intel Corporation Sky Lake-E Ubox Registers (rev 04)
00: 86 80 14 20 00 00 10 00 04 00 80 08 00 00 80 00
c0: 03 c0 00 00 4f 00 00 80 01 00 02 00 4f 4f 4f 40
d0: 02 00 00 00 88 66 db 00 01 00 00 00 00 00 00 00
0004:00:08.0 System peripheral: Intel Corporation Sky Lake-E Ubox Registers (rev 04)
00: 86 80 14 20 00 00 10 00 04 00 80 08 00 00 80 00
c0: a0 b4 00 00 2f 00 00 80 01 00 02 00 2f 2f 2f 20
d0: 02 00 00 00 6d 8b 68 00 01 00 00 00 00 00 00 00
0005:00:08.0 System peripheral: Intel Corporation Sky Lake-E Ubox Registers (rev 04)
00: 86 80 14 20 00 00 10 00 04 00 80 08 00 00 80 00
c0: 81 90 00 00 1f 00 00 80 01 00 02 00 1f 1f 1f 10
d0: 02 00 00 00 24 89 68 00 01 00 00 00 00 00 00 00
0006:00:08.0 System peripheral: Intel Corporation Sky Lake-E Ubox Registers (rev 04)
00: 86 80 14 20 00 00 10 00 04 00 80 08 00 00 80 00
c0: e2 fc 00 00 8f 00 00 80 01 00 02 00 8f 8f 8f 80
d0: 02 00 00 00 ff 8f 68 00 01 00 00 00 00 00 00 00
0007:00:08.0 System peripheral: Intel Corporation Sky Lake-E Ubox Registers (rev 04)
00: 86 80 14 20 00 00 10 00 04 00 80 08 00 00 80 00
c0: c3 d8 00 00 4f 00 00 80 01 00 02 00 4f 4f 4f 40
d0: 02 00 00 00 b6 8d 68 00 01 00 00 00 00 00 00 00
Song
>
>> One thing I noticed is that the PCI configuration space shows
>> subsystem vendor ID of 0x1590 instead of 0x8086:
>> 0000:00:08.0 System peripheral: Intel Corporation Sky Lake-E Ubox Registers (rev 04)
>> 00: 86 80 14 20 00 00 10 00 04 00 80 08 00 00 80 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 90 15 14 20 << subsystem vendor
>> 30: 00 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00
>> But I don't think that is the problem as the code search with PCI_ANY_ID.
>>
>
> It looks for the device with PCI ID 0x2014.
>
>
> Thanks,
> Kan
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: perf/x86/intel/uncore
2019-01-25 20:16 ` perf/x86/intel/uncore Song Liu
@ 2019-01-25 21:35 ` Liang, Kan
2019-01-25 22:24 ` perf/x86/intel/uncore Song Liu
0 siblings, 1 reply; 7+ messages in thread
From: Liang, Kan @ 2019-01-25 21:35 UTC (permalink / raw)
To: Song Liu; +Cc: lkml
On 1/25/2019 3:16 PM, Song Liu wrote:
> Thanks Kan!
>
>> On Jan 25, 2019, at 12:08 PM, Liang, Kan <kan.liang@linux.intel.com> wrote:
>>
>>
>>
>> On 1/25/2019 1:54 PM, Song Liu wrote:
>>> Hi,
>>> We are debugging an issue that skx_pci_uncores cannot be registered on
>>> 8-socket system with Xeon Platinum 8176 CPUs. After poking around for a
>>> while, I found it is caused by snbep_pci2phy_map_init() couldn't find
>>> a unbox_dev:
>>> ubox_dev = pci_get_device(PCI_VENDOR_ID_INTEL, devid, ubox_dev);
>>> unbox_dev == NULL
>>> ...
>>> The same kernel (Linus' master) works fine on some single socket SKX
>>> systems.
>>> I am not sure what to check next. And I am not sure whether this is
>>> specific to this system (HPE Superdome Flex).
>>
>> Could you please share the offset 0xC0 and 0xD4 of the PCI configuration space for each device which PCI ID is 0x2014?
>>
>> snbep_pci2phy_map_init() tries to build a mapping from BUS# to Socket ID.
>> CPUNODEID (0xc0) discloses the Node ID of current BUS.
>> GIDNIDMAP (0xd4) discloses the mapping between Socket ID and Node ID.
>>
>> Here is an example from a 4 socket SKX.
>> BUS CPUNODEID(bit2:0) GIDNIDMAP
>> 0x0 0x0 0x688
>> 0x40 0x1 0x688
>> 0x80 0x2 0x688
>> 0xC0 0x3 0x688
>>
>
> Here is the data I get:
>
> # lspci -xxx | grep "86 80 14 20" -A 15 -B 1 | grep -e "86 80 14 20" -e c0: -e d0: -e Intel
> 0000:00:08.0 System peripheral: Intel Corporation Sky Lake-E Ubox Registers (rev 04)
> 00: 86 80 14 20 00 00 10 00 04 00 80 08 00 00 80 00
> c0: 00 a0 00 00 2f 00 00 80 01 00 02 00 2f 2f 2f 20
> d0: 02 00 00 00 88 d6 b6 00 01 00 00 00 00 00 00 00
>
> 0001:00:08.0 System peripheral: Intel Corporation Sky Lake-E Ubox Registers (rev 04)
> 00: 86 80 14 20 00 00 10 00 04 00 80 08 00 00 80 00
> c0: 01 80 00 00 1f 00 00 80 01 00 02 00 1f 1f 1f 10
> d0: 02 00 00 00 88 46 92 00 01 00 00 00 00 00 00 00
>
> 0002:00:08.0 System peripheral: Intel Corporation Sky Lake-E Ubox Registers (rev 04)
> 00: 86 80 14 20 00 00 10 00 04 00 80 08 00 00 80 00
> c0: 02 e0 00 00 8f 00 00 80 01 00 02 00 8f 8f 8f 80
> d0: 02 00 00 00 88 f6 ff 00 01 00 00 00 00 00 00 00
>
> 0003:00:08.0 System peripheral: Intel Corporation Sky Lake-E Ubox Registers (rev 04)
> 00: 86 80 14 20 00 00 10 00 04 00 80 08 00 00 80 00
> c0: 03 c0 00 00 4f 00 00 80 01 00 02 00 4f 4f 4f 40
> d0: 02 00 00 00 88 66 db 00 01 00 00 00 00 00 00 00
>
> 0004:00:08.0 System peripheral: Intel Corporation Sky Lake-E Ubox Registers (rev 04)
> 00: 86 80 14 20 00 00 10 00 04 00 80 08 00 00 80 00
> c0: a0 b4 00 00 2f 00 00 80 01 00 02 00 2f 2f 2f 20
The local node ID should be bit2:0. We didn't mask it in our codes.
Does the patch as below work?
diff --git a/arch/x86/events/intel/uncore_snbep.c
b/arch/x86/events/intel/uncore_snbep.c
index c07bee3..15a8e3c 100644
--- a/arch/x86/events/intel/uncore_snbep.c
+++ b/arch/x86/events/intel/uncore_snbep.c
@@ -1222,6 +1222,8 @@ static struct pci_driver snbep_uncore_pci_driver = {
.id_table = snbep_uncore_pci_ids,
};
+#define NODE_ID_MASK 0x7
+
/*
* build pci bus to socket mapping
*/
@@ -1243,7 +1245,7 @@ static int snbep_pci2phy_map_init(int devid, int
nodeid_loc, int idmap_loc, bool
err = pci_read_config_dword(ubox_dev, nodeid_loc, &config);
if (err)
break;
- nodeid = config;
+ nodeid = config & NODE_ID_MASK;
/* get the Node ID mapping */
err = pci_read_config_dword(ubox_dev, idmap_loc, &config);
if (err)
Thanks,
Kan
> d0: 02 00 00 00 6d 8b 68 00 01 00 00 00 00 00 00 00
>
> 0005:00:08.0 System peripheral: Intel Corporation Sky Lake-E Ubox Registers (rev 04)
> 00: 86 80 14 20 00 00 10 00 04 00 80 08 00 00 80 00
> c0: 81 90 00 00 1f 00 00 80 01 00 02 00 1f 1f 1f 10
> d0: 02 00 00 00 24 89 68 00 01 00 00 00 00 00 00 00
>
> 0006:00:08.0 System peripheral: Intel Corporation Sky Lake-E Ubox Registers (rev 04)
> 00: 86 80 14 20 00 00 10 00 04 00 80 08 00 00 80 00
> c0: e2 fc 00 00 8f 00 00 80 01 00 02 00 8f 8f 8f 80
> d0: 02 00 00 00 ff 8f 68 00 01 00 00 00 00 00 00 00
>
> 0007:00:08.0 System peripheral: Intel Corporation Sky Lake-E Ubox Registers (rev 04)
> 00: 86 80 14 20 00 00 10 00 04 00 80 08 00 00 80 00
> c0: c3 d8 00 00 4f 00 00 80 01 00 02 00 4f 4f 4f 40
> d0: 02 00 00 00 b6 8d 68 00 01 00 00 00 00 00 00 00
>
> Song
>>
>>> One thing I noticed is that the PCI configuration space shows
>>> subsystem vendor ID of 0x1590 instead of 0x8086:
>>> 0000:00:08.0 System peripheral: Intel Corporation Sky Lake-E Ubox Registers (rev 04)
>>> 00: 86 80 14 20 00 00 10 00 04 00 80 08 00 00 80 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 90 15 14 20 << subsystem vendor
>>> 30: 00 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00
>>> But I don't think that is the problem as the code search with PCI_ANY_ID.
>>>
>>
>> It looks for the device with PCI ID 0x2014.
>>
>>
>> Thanks,
>> Kan
>
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: perf/x86/intel/uncore
2019-01-25 21:35 ` perf/x86/intel/uncore Liang, Kan
@ 2019-01-25 22:24 ` Song Liu
2019-01-25 22:42 ` perf/x86/intel/uncore Liang, Kan
0 siblings, 1 reply; 7+ messages in thread
From: Song Liu @ 2019-01-25 22:24 UTC (permalink / raw)
To: Liang, Kan; +Cc: lkml
> On Jan 25, 2019, at 1:35 PM, Liang, Kan <kan.liang@linux.intel.com> wrote:
>
>
>
> On 1/25/2019 3:16 PM, Song Liu wrote:
>> Thanks Kan!
>>> On Jan 25, 2019, at 12:08 PM, Liang, Kan <kan.liang@linux.intel.com> wrote:
>>>
>>>
>>>
>>> On 1/25/2019 1:54 PM, Song Liu wrote:
>>>> Hi,
>>>> We are debugging an issue that skx_pci_uncores cannot be registered on
>>>> 8-socket system with Xeon Platinum 8176 CPUs. After poking around for a
>>>> while, I found it is caused by snbep_pci2phy_map_init() couldn't find
>>>> a unbox_dev:
>>>> ubox_dev = pci_get_device(PCI_VENDOR_ID_INTEL, devid, ubox_dev);
>>>> unbox_dev == NULL
>>>> ...
>>>> The same kernel (Linus' master) works fine on some single socket SKX
>>>> systems.
>>>> I am not sure what to check next. And I am not sure whether this is
>>>> specific to this system (HPE Superdome Flex).
>>>
>>> Could you please share the offset 0xC0 and 0xD4 of the PCI configuration space for each device which PCI ID is 0x2014?
>>>
>>> snbep_pci2phy_map_init() tries to build a mapping from BUS# to Socket ID.
>>> CPUNODEID (0xc0) discloses the Node ID of current BUS.
>>> GIDNIDMAP (0xd4) discloses the mapping between Socket ID and Node ID.
>>>
>>> Here is an example from a 4 socket SKX.
>>> BUS CPUNODEID(bit2:0) GIDNIDMAP
>>> 0x0 0x0 0x688
>>> 0x40 0x1 0x688
>>> 0x80 0x2 0x688
>>> 0xC0 0x3 0x688
>>>
>> Here is the data I get:
>> # lspci -xxx | grep "86 80 14 20" -A 15 -B 1 | grep -e "86 80 14 20" -e c0: -e d0: -e Intel
>> 0000:00:08.0 System peripheral: Intel Corporation Sky Lake-E Ubox Registers (rev 04)
>> 00: 86 80 14 20 00 00 10 00 04 00 80 08 00 00 80 00
>> c0: 00 a0 00 00 2f 00 00 80 01 00 02 00 2f 2f 2f 20
>> d0: 02 00 00 00 88 d6 b6 00 01 00 00 00 00 00 00 00
>> 0001:00:08.0 System peripheral: Intel Corporation Sky Lake-E Ubox Registers (rev 04)
>> 00: 86 80 14 20 00 00 10 00 04 00 80 08 00 00 80 00
>> c0: 01 80 00 00 1f 00 00 80 01 00 02 00 1f 1f 1f 10
>> d0: 02 00 00 00 88 46 92 00 01 00 00 00 00 00 00 00
>> 0002:00:08.0 System peripheral: Intel Corporation Sky Lake-E Ubox Registers (rev 04)
>> 00: 86 80 14 20 00 00 10 00 04 00 80 08 00 00 80 00
>> c0: 02 e0 00 00 8f 00 00 80 01 00 02 00 8f 8f 8f 80
>> d0: 02 00 00 00 88 f6 ff 00 01 00 00 00 00 00 00 00
>> 0003:00:08.0 System peripheral: Intel Corporation Sky Lake-E Ubox Registers (rev 04)
>> 00: 86 80 14 20 00 00 10 00 04 00 80 08 00 00 80 00
>> c0: 03 c0 00 00 4f 00 00 80 01 00 02 00 4f 4f 4f 40
>> d0: 02 00 00 00 88 66 db 00 01 00 00 00 00 00 00 00
>> 0004:00:08.0 System peripheral: Intel Corporation Sky Lake-E Ubox Registers (rev 04)
>> 00: 86 80 14 20 00 00 10 00 04 00 80 08 00 00 80 00
>> c0: a0 b4 00 00 2f 00 00 80 01 00 02 00 2f 2f 2f 20
>
> The local node ID should be bit2:0. We didn't mask it in our codes.
> Does the patch as below work?
>
> diff --git a/arch/x86/events/intel/uncore_snbep.c b/arch/x86/events/intel/uncore_snbep.c
> index c07bee3..15a8e3c 100644
> --- a/arch/x86/events/intel/uncore_snbep.c
> +++ b/arch/x86/events/intel/uncore_snbep.c
> @@ -1222,6 +1222,8 @@ static struct pci_driver snbep_uncore_pci_driver = {
> .id_table = snbep_uncore_pci_ids,
> };
>
> +#define NODE_ID_MASK 0x7
> +
> /*
> * build pci bus to socket mapping
> */
> @@ -1243,7 +1245,7 @@ static int snbep_pci2phy_map_init(int devid, int nodeid_loc, int idmap_loc, bool
> err = pci_read_config_dword(ubox_dev, nodeid_loc, &config);
> if (err)
> break;
> - nodeid = config;
> + nodeid = config & NODE_ID_MASK;
> /* get the Node ID mapping */
> err = pci_read_config_dword(ubox_dev, idmap_loc, &config);
> if (err)
>
>
> Thanks,
> Kan
Yes, this patch works! Now I can see uncore_imc_0 etc. Thanks Kan!
I also noticed that uncore_pci_probe() returns at
if (atomic_inc_return(&pmu->activeboxes) > 1)
return 0;
for bus 1-7. So we only probed bus 0 (socket 0). Is this expected behavior?
Thanks again!
Song
>> d0: 02 00 00 00 6d 8b 68 00 01 00 00 00 00 00 00 00
>> 0005:00:08.0 System peripheral: Intel Corporation Sky Lake-E Ubox Registers (rev 04)
>> 00: 86 80 14 20 00 00 10 00 04 00 80 08 00 00 80 00
>> c0: 81 90 00 00 1f 00 00 80 01 00 02 00 1f 1f 1f 10
>> d0: 02 00 00 00 24 89 68 00 01 00 00 00 00 00 00 00
>> 0006:00:08.0 System peripheral: Intel Corporation Sky Lake-E Ubox Registers (rev 04)
>> 00: 86 80 14 20 00 00 10 00 04 00 80 08 00 00 80 00
>> c0: e2 fc 00 00 8f 00 00 80 01 00 02 00 8f 8f 8f 80
>> d0: 02 00 00 00 ff 8f 68 00 01 00 00 00 00 00 00 00
>> 0007:00:08.0 System peripheral: Intel Corporation Sky Lake-E Ubox Registers (rev 04)
>> 00: 86 80 14 20 00 00 10 00 04 00 80 08 00 00 80 00
>> c0: c3 d8 00 00 4f 00 00 80 01 00 02 00 4f 4f 4f 40
>> d0: 02 00 00 00 b6 8d 68 00 01 00 00 00 00 00 00 00
>> Song
>>>
>>>> One thing I noticed is that the PCI configuration space shows
>>>> subsystem vendor ID of 0x1590 instead of 0x8086:
>>>> 0000:00:08.0 System peripheral: Intel Corporation Sky Lake-E Ubox Registers (rev 04)
>>>> 00: 86 80 14 20 00 00 10 00 04 00 80 08 00 00 80 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 90 15 14 20 << subsystem vendor
>>>> 30: 00 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00
>>>> But I don't think that is the problem as the code search with PCI_ANY_ID.
>>>>
>>>
>>> It looks for the device with PCI ID 0x2014.
>>>
>>>
>>> Thanks,
>>> Kan
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: perf/x86/intel/uncore
2019-01-25 22:24 ` perf/x86/intel/uncore Song Liu
@ 2019-01-25 22:42 ` Liang, Kan
2019-01-25 22:45 ` perf/x86/intel/uncore Song Liu
0 siblings, 1 reply; 7+ messages in thread
From: Liang, Kan @ 2019-01-25 22:42 UTC (permalink / raw)
To: Song Liu; +Cc: lkml
On 1/25/2019 5:24 PM, Song Liu wrote:
> I also noticed that uncore_pci_probe() returns at
>
> if (atomic_inc_return(&pmu->activeboxes) > 1)
> return 0;
>
> for bus 1-7. So we only probed bus 0 (socket 0). Is this expected behavior?
We probed all, but only need to register PMU once.
It can be distinguished by cpumask. E.g. you may want to check
"/sys/devices/uncore_imc_0/cpumask".
Thanks,
Kan
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: perf/x86/intel/uncore
2019-01-25 22:42 ` perf/x86/intel/uncore Liang, Kan
@ 2019-01-25 22:45 ` Song Liu
0 siblings, 0 replies; 7+ messages in thread
From: Song Liu @ 2019-01-25 22:45 UTC (permalink / raw)
To: Liang, Kan; +Cc: lkml
> On Jan 25, 2019, at 2:42 PM, Liang, Kan <kan.liang@linux.intel.com> wrote:
>
>
>
> On 1/25/2019 5:24 PM, Song Liu wrote:
>> I also noticed that uncore_pci_probe() returns at
>> if (atomic_inc_return(&pmu->activeboxes) > 1)
>> return 0;
>> for bus 1-7. So we only probed bus 0 (socket 0). Is this expected behavior?
>
> We probed all, but only need to register PMU once.
> It can be distinguished by cpumask. E.g. you may want to check "/sys/devices/uncore_imc_0/cpumask".
>
>
> Thanks,
> Kan
I see. That works:
[root@rtptest10787.snc1 /sys/bus/event_source/devices/uncore_imc_0]# cat cpumask
0,28,56,84,112,140,168,196
I think this solves all the problems.
Thanks again!
Song
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2019-01-25 22:46 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-01-25 18:54 perf/x86/intel/uncore Song Liu
2019-01-25 20:08 ` perf/x86/intel/uncore Liang, Kan
2019-01-25 20:16 ` perf/x86/intel/uncore Song Liu
2019-01-25 21:35 ` perf/x86/intel/uncore Liang, Kan
2019-01-25 22:24 ` perf/x86/intel/uncore Song Liu
2019-01-25 22:42 ` perf/x86/intel/uncore Liang, Kan
2019-01-25 22:45 ` perf/x86/intel/uncore Song Liu
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).