linux-kernel - Re: [EDAC PATCH v13 6/7] edac.h: Prepare to handle with generic layers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4F995ACA.2010701@redhat.com>
Date:	Thu, 26 Apr 2012 11:25:14 -0300
From:	Mauro Carvalho Chehab <mchehab@...hat.com>
To:	Borislav Petkov <bp@...64.org>
CC:	Tony Luck <tony.luck@...el.com>,
	Linux Edac Mailing List <linux-edac@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Doug Thompson <norsk5@...oo.com>
Subject: Re: [EDAC PATCH v13 6/7] edac.h: Prepare to handle with generic layers

Em 26-04-2012 11:11, Borislav Petkov escreveu:
> On Wed, Apr 25, 2012 at 02:47:39PM -0300, Mauro Carvalho Chehab wrote:
>>> Now let's look at your output from earlier:
>>>
>>>> $ ./edac-ctl --layout
>>>>        +-----------------------------------+
>>>>        |                mc0                |
>>>>        | channel0  | channel1  | channel2  |
>>>> -------+-----------------------------------+
>>>> slot2: |     0 MB  |     0 MB  |     0 MB  |
>>>> slot1: |  1024 MB  |     0 MB  |     0 MB  |
>>>> slot0: |  1024 MB  |  1024 MB  |  1024 MB  |
>>>> -------+-----------------------------------+
>>>>
>>>> Those are the logs that dump the Memory Controller registers:
>>>>
>>>> [  115.818947] EDAC DEBUG: get_dimm_config: Ch0 phy rd0, wr0 (0x063f4031): 2 ranks, UDIMMs
>>>
>>> it says here 2 ranks
>>
>> The above output is for the Nehalem machine, with 4 dimms, all single ranked.
>>
>>>> [  115.818950] EDAC DEBUG: get_dimm_config:   dimm 0 1024 Mb offset: 0, bank: 8, rank: 1, row: 0x4000, col: 0x400
>>>> [  115.818955] EDAC DEBUG: get_dimm_config:   dimm 1 1024 Mb offset: 4, bank: 8, rank: 1, row: 0x4000, col: 0x400
>>>> [  115.818982] EDAC DEBUG: get_dimm_config: Ch1 phy rd1, wr1 (0x063f4031): 2 ranks, UDIMMs
>>>
>>> and here 2 too although there's only one single-ranked DIMM here. So
>>> which is it?
>>
>> The # of ranks there is the total amount of ranks at the channel.
> 
> The total amount of ranks what? The channel supports, are present on the
> channel, the number of physical slots?
> 
> I'm just saying it is puzzling because your output says "2 ranks" whent
> there are 2 single-ranked DIMMs connected to ch0 and also "2 ranks" when
> there's only one DIMM connected to ch1.

Ah, ok, now I understood what you meant: yeah, channel 1 and 2 also says
that there are two ranks.

I'll double check what's happening there.

> 
> [..]
> 
>> In the case of the EDAC driver, we're relying at the per-DIMM
>> information, that is reported via the MCE misc register. Also, there
>> are per-DIMM error counters out there. So, while it could, in thesis,
>> be possible to use the per-RANK registers and do the error decoding
>> without MCA, this can have troubles, in practice, as some BIOSes
>> can also be accessing the same registers, which would cause race
>> conditions between BIOS and Linux.
> 
> BIOS accessing those registers while OS is running, what is that SMM?
> APEI?

I was thinking in preventing against races with SMM when I was writing 
the code for using the MCA registers instead of accessing the registers 
directly.

> 
> [..]
> 
>>>>>> At Sandy Bridge-EP (E. g. Intel E5 CPUs), we have one machine fully equipped
>>>>>> with dual rank memories. The number of ranks there is just a DIMM property.
>>>>>>
>>>>>> # ./edac-ctl --layout
>>>>>>        +-----------------------------------------------------------------------------------------------+
>>>>>>        |                      mc0                      |                      mc1                      |
>>>>>>        | channel0  | channel1  | channel2  | channel3  | channel0  | channel1  | channel2  | channel3  |
>>>>>> -------+-----------------------------------------------------------------------------------------------+
>>>>>> slot2: |     0 MB  |     0 MB  |     0 MB  |     0 MB  |     0 MB  |     0 MB  |     0 MB  |     0 MB  |
>>>>>> slot1: |  4096 MB  |  4096 MB  |  4096 MB  |  4096 MB  |  4096 MB  |  4096 MB  |  4096 MB  |  4096 MB  |
>>>>>> slot0: |  4096 MB  |  4096 MB  |  4096 MB  |  4096 MB  |  4096 MB  |  4096 MB  |  4096 MB  |  4096 MB  |
>>>>>> -------+-----------------------------------------------------------------------------------------------+
>>>>>>
>>>>>> (this machine doesn't have physical DIMM sockets for slot#2)
>>>
>>> This looks like a 4-channel memory controller with 3 physical slots per
>>> channel.
>>
>> Yes, except that this specific motherboard has only 16 physical slots. In
>> thesis, it is possible to have a motherboard with 24 physical slots.
> 
> Ok, this probably means the memory controller supports 3 slots per
> channel but the mobo designer laid out only 2 per channel.

Yes.

Regards,
Mauro.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/