All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab@redhat.com>
To: Borislav Petkov <bp@amd64.org>
Cc: "Luck, Tony" <tony.luck@intel.com>, Ingo Molnar <mingo@elte.hu>,
	EDAC devel <linux-edac@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/3] mce: Add a msg string to the MCE tracepoint
Date: Thu, 01 Mar 2012 10:19:39 -0300	[thread overview]
Message-ID: <4F4F776B.90609@redhat.com> (raw)
In-Reply-To: <20120301112949.GA32410@aftab>

Em 01-03-2012 08:29, Borislav Petkov escreveu:
> On Wed, Feb 29, 2012 at 05:33:51PM +0000, Luck, Tony wrote:
>>> IOW, we want to assume that cores 0, 1, 2 ... k-1 are on node 0; k, k+1
>>> ... 2k-1 belong to node 1, etc., where k is the number of cores on a
>>> socket and thus we have a regular core enumeration on the box.
>>
>> Sounds dubious:
>>
>> Booting Node   0, Processors  #1 #2 #3 #4 #5 #6 #7 Ok.
>> Booting Node   1, Processors  #8 #9 #10 #11 #12 #13 #14 #15 Ok.
>> Booting Node   0, Processors  #16 #17 #18 #19 #20 #21 #22 #23 Ok.
>> Booting Node   1, Processors  #24 #25 #26 #27 #28 #29 #30 #31
>> Brought up 32 CPUs
>>
>> Now those are logical cpu numbers, and we brought up the first HT
>> thread on each core first, and then came around for a 2nd pass
>> bringing up the other HT thread.  This order is determined by
>> how the BIOS lists the cpus (and in this case it seems to be
>> doing so according to recommendations) - so here our core numbers
>> will match what you said. But the BIOS could do something
>> strange and list logical cpus alternating between sockets. In
>> which case cores 0, 2, 4, 6 ... would be on node 0, and cores
>> 1, 3, 5, 7, ... on node 1.
> 
> Ok, the example above actually confirms my fear that you won't be always
> able to map back to a physical socket from the CPU number. So, we'll
> need the ->socketid field which is the physical processor ID we get from
> CPUID leafs.
> 
> Then, mapping back the socketid to the silkscreen labels on the boards
> should be easy because on the boxes I have here, they go like this: P0,
> P1, ..., where P0 is the socket containing the BSP, P1 is the second
> socket etc. I'm guessing this is similar on Intel boards...?

The mapping from socket id to silkscreen label is motherboard-dependent.
I did some tests with a few different machines:

[root@dell-pe1950-05 ~]# dmidecode | grep -i "Processor Information" -A10
Processor Information
	Socket Designation: CPU1
	Type: Central Processor
	Family: Xeon
	Manufacturer: Intel
	ID: F6 06 00 00 FF FB EB BF
	Signature: Type 0, Family 6, Model 15, Stepping 6
	Flags:
		FPU (Floating-point unit on-chip)
		VME (Virtual mode extension)
		DE (Debugging extension)
--
Processor Information
	Socket Designation: CPU2
	Type: Central Processor
	Family: Xeon
	Manufacturer: Intel
	ID: F6 06 00 00 FF FB EB BF
	Signature: Type 0, Family 6, Model 15, Stepping 6
	Flags:
		FPU (Floating-point unit on-chip)
		VME (Virtual mode extension)
		DE (Debugging extension)

[root@hp-dl580g5-01 ~]# dmidecode | grep -i "Processor Information" -A10
Processor Information
	Socket Designation: Proc 1
	Type: Central Processor
	Family: Xeon MP
	Manufacturer: Intel
	ID: FB 06 00 00 FF FB EB BF
	Signature: Type 0, Family 6, Model 15, Stepping 11
	Flags:
		FPU (Floating-point unit on-chip)
		VME (Virtual mode extension)
		DE (Debugging extension)
--
Processor Information
	Socket Designation: Proc 2
	Type: Central Processor
	Family: Xeon MP
	Manufacturer: Intel
	ID: FB 06 00 00 FF FB EB BF
	Signature: Type 0, Family 6, Model 15, Stepping 11
	Flags:
		FPU (Floating-point unit on-chip)
		VME (Virtual mode extension)
		DE (Debugging extension)
--
Processor Information
	Socket Designation: Proc 3
	Type: Central Processor
	Family: Xeon MP
	Manufacturer: Intel
	ID: FB 06 00 00 FF FB EB BF
	Signature: Type 0, Family 6, Model 15, Stepping 11
	Flags:
		FPU (Floating-point unit on-chip)
		VME (Virtual mode extension)
		DE (Debugging extension)
--
Processor Information
	Socket Designation: Proc 4
	Type: Central Processor
	Family: Xeon MP
	Manufacturer: Intel
	ID: FB 06 00 00 FF FB EB BF
	Signature: Type 0, Family 6, Model 15, Stepping 11
	Flags:
		FPU (Floating-point unit on-chip)
		VME (Virtual mode extension)
		DE (Debugging extension)

dmidecode | grep -i "Processor Information" -A10
Processor Information
	Socket Designation: CPU 1
	Type: Central Processor
	Family: Pentium M
	Manufacturer: Intel            
	ID: A4 06 01 00 FF FB EB BF
	Signature: Type 0, Family 6, Model 26, Stepping 4
	Flags:
		FPU (Floating-point unit on-chip)
		VME (Virtual mode extension)
		DE (Debugging extension)
--
Processor Information
	Socket Designation: CPU 2
	Type: Central Processor
	Family: Pentium M
	Manufacturer: Intel            
	ID: A4 06 01 00 FF FB EB BF
	Signature: Type 0, Family 6, Model 26, Stepping 4
	Flags:
		FPU (Floating-point unit on-chip)
		VME (Virtual mode extension)
		DE (Debugging extension)

[root@hp-bl260cg5-01 ~]# dmidecode | grep "Processor Information" -A10
Processor Information
	Socket Designation: Proc 1
	Type: Central Processor
	Family: Xeon
	Manufacturer: Intel
	ID: 76 06 01 00 FF FB EB BF
	Signature: Type 0, Family 6, Model 23, Stepping 6
	Flags:
		FPU (Floating-point unit on-chip)
		VME (Virtual mode extension)
		DE (Debugging extension)
--
Processor Information
	Socket Designation: Proc 2
	Type: Central Processor
	Family: Xeon
	Manufacturer: Intel
	ID: 00 00 00 00 00 00 00 00
	Signature: Type 0, Family 0, Model 0, Stepping 0
	Flags: None
	Version: Not Specified
	Voltage: 1.1 V
	External Clock: 200 MHz

On all the above, the socket label starts on 1, but I bet we'll find cases
where it start from 0.


Regards,
Mauro

  reply	other threads:[~2012-03-01 13:20 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-28 16:11 [RFC PATCH 0/3] RAS: Use MCE tracepoint for decoded MCEs Borislav Petkov
2012-02-28 16:11 ` [PATCH 1/3] mce: Add a msg string to the MCE tracepoint Borislav Petkov
2012-02-29  1:14   ` Hidetoshi Seto
2012-02-29 10:10     ` Borislav Petkov
2012-02-29 12:04       ` Mauro Carvalho Chehab
2012-02-29 12:19         ` Borislav Petkov
2012-02-29 13:05           ` Mauro Carvalho Chehab
2012-02-29 13:37             ` Borislav Petkov
2012-02-29 17:11               ` Luck, Tony
2012-02-29 17:19                 ` Borislav Petkov
2012-03-01  2:23               ` Hidetoshi Seto
2012-03-01 11:40                 ` Borislav Petkov
2012-03-01 18:28                   ` Luck, Tony
2012-03-02  4:02                     ` Hidetoshi Seto
2012-03-02 13:17                       ` Mauro Carvalho Chehab
2012-03-02 20:05                       ` Luck, Tony
2012-02-29 17:20         ` Luck, Tony
2012-02-29 18:00           ` Mauro Carvalho Chehab
2012-02-29 18:11             ` Luck, Tony
2012-02-29 12:52   ` Mauro Carvalho Chehab
2012-02-29 13:45     ` Borislav Petkov
2012-02-29 14:04       ` Mauro Carvalho Chehab
2012-02-29 14:40         ` Borislav Petkov
2012-02-29 16:58           ` Luck, Tony
2012-02-29 17:16             ` Borislav Petkov
2012-02-29 17:33               ` Luck, Tony
2012-03-01 11:29                 ` Borislav Petkov
2012-03-01 13:19                   ` Mauro Carvalho Chehab [this message]
2012-03-01 18:15                     ` Luck, Tony
2012-03-01 18:45                       ` Borislav Petkov
2012-03-01 18:58                         ` Luck, Tony
2012-03-01 19:54                           ` Mauro Carvalho Chehab
2012-02-29 17:45               ` Mauro Carvalho Chehab
2012-02-29 17:17           ` Mauro Carvalho Chehab
2012-02-28 16:11 ` [PATCH 2/3] x86, RAS: Add a decoded msg buffer Borislav Petkov
2012-02-28 22:43   ` Luck, Tony
2012-02-29 10:11     ` Borislav Petkov
2012-03-02  9:55       ` Borislav Petkov
2012-02-28 16:11 ` [PATCH 3/3] EDAC: Convert AMD EDAC pieces to use RAS printk buffer Borislav Petkov
  -- strict thread matches above, loose matches on Subject: below --
2012-03-06 13:31 [RFC -v3 PATCH 0/3] RAS: Use MCE tracepoint for decoded MCEs Borislav Petkov
2012-03-06 13:31 ` [PATCH 1/3] mce: Add a msg string to the MCE tracepoint Borislav Petkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F4F776B.90609@redhat.com \
    --to=mchehab@redhat.com \
    --cc=bp@amd64.org \
    --cc=linux-edac@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=tony.luck@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.