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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20120424162743.GU11559@aftab.osrc.amd.com>
Date:	Tue, 24 Apr 2012 18:27:43 +0200
From:	Borislav Petkov <bp@...64.org>
To:	Mauro Carvalho Chehab <mchehab@...hat.com>,
	Tony Luck <tony.luck@...el.com>
Cc:	Borislav Petkov <bp@...64.org>,
	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

On Tue, Apr 24, 2012 at 11:24:03AM -0300, Mauro Carvalho Chehab wrote:
> Yes (well, except that Nehalem has also a concept of "virtual channel", so
> calling it "virtual" can mislead into a different view).

No, it cannot. It is a very simple question: Am I looking at virtual
slots/channels or not, when I'm looking at edac-ctl output?

[..]

> > I hope you can understand my confusion now:
> > 
> > On the one hand, there are the physical slots where the DIMMs are
> > sticked into.
> > 
> > OTOH, there are the slots==ranks which the memory controllers use to
> > talk to the DIMMs.
> 
> This only applies to amd64 and other csrows-based memory controllers.
> 
> A memory controller like the one at Nehalem abstracts csrows (I suspect
> that they have internally something functionally similar to a FB-DIMM
> AMB internally). They do memory interleaving between the memory channels
> in order to produce a cachesize bigger than 64 bits, but they don't

You mean cacheline here.

> actually care about how many ranks are there on each DIMM.

This cannot be right - you need the chip select to talk to a rank.
This is basic DDR functionality.

I can imagine that they're doing some tricks like channel/chip
select/memory controller interleaving.

In the end of the day, it is smallest row that gives you 64 bits of
data.

@Tony: hey Tony, can you point us to an Intel document explaining how
Sandy Bridge or NH or one of the new ones does the memory addressing wrt
ranks, channels etc? Thanks.

[..]

> No. As far as I can tell, they can have 9 quad-ranked DIMMs (the machines
> I've looked so far are all equipped with single rank memories, so I don't 
> have a real scenario with 2R or 4R for Nehalem yet).
> 
> 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)

Ok, I can count 8 2R DIMMs here and each rank or slot in your
nomenclature is 4G. slot#2 has to be something virtual since each rank
occupies one slot, i.e. slot0 and slot1 on a channel.

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551
--
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/