From: Mauro Carvalho Chehab <mchehab@redhat.com>
To: Borislav Petkov <bp@amd64.org>
Cc: Tony Luck <tony.luck@intel.com>,
Linux Edac Mailing List <linux-edac@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Doug Thompson <norsk5@yahoo.com>
Subject: Re: [EDAC PATCH v13 6/7] edac.h: Prepare to handle with generic layers
Date: Tue, 24 Apr 2012 14:24:59 -0300 [thread overview]
Message-ID: <4F96E1EB.1030407@redhat.com> (raw)
In-Reply-To: <20120424162743.GU11559@aftab.osrc.amd.com>
Em 24-04-2012 13:27, Borislav Petkov escreveu:
> 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?
It is showing physical slots/channels 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.
Yes. Sorry for the typo.
>> 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.
Yes, but this seems to be hidden on some lower level layer on their hardware.
The rank information is only an information inside their per-DIMM registers.
> I can imagine that they're doing some tricks like channel/chip
> select/memory controller interleaving.
They can do all several different types of interleaving, using from 1
(no interleaving) to 4 channels. The interleave is done by address range,
not by csrow.
This is a dump of what sb_edac reads from Sandy Bridge EP registers:
[52803.640136] EDAC DEBUG: get_dimm_config: mc#1: Node ID: 1, source ID: 1
[52803.640141] EDAC DEBUG: get_dimm_config: Memory mirror is disabled
[52803.640154] EDAC DEBUG: get_dimm_config: Lockstep is disabled
[52803.640156] EDAC DEBUG: get_dimm_config: address map is on open page mode
[52803.640157] EDAC DEBUG: get_dimm_config: Memory is unregistered
[52803.640159] EDAC DEBUG: get_dimm_config: Channel #0 MTR0 = 500c
[52803.640162] EDAC DEBUG: get_dimm_config: mc#1: channel 0, dimm 0, 4096 Mb (1048576 pages) bank: 8, rank: 2, row: 0x8000, col: 0x400
[52803.640165] EDAC DEBUG: get_dimm_config: Channel #0 MTR1 = 500c
[52803.640168] EDAC DEBUG: get_dimm_config: mc#1: channel 0, dimm 1, 4096 Mb (1048576 pages) bank: 8, rank: 2, row: 0x8000, col: 0x400
[52803.640171] EDAC DEBUG: get_dimm_config: Channel #0 MTR2 = 0
[52803.640174] EDAC DEBUG: get_dimm_config: Channel #1 MTR0 = 500c
[52803.640176] EDAC DEBUG: get_dimm_config: mc#1: channel 1, dimm 0, 4096 Mb (1048576 pages) bank: 8, rank: 2, row: 0x8000, col: 0x400
[52803.640180] EDAC DEBUG: get_dimm_config: Channel #1 MTR1 = 500c
[52803.640182] EDAC DEBUG: get_dimm_config: mc#1: channel 1, dimm 1, 4096 Mb (1048576 pages) bank: 8, rank: 2, row: 0x8000, col: 0x400
[52803.640185] EDAC DEBUG: get_dimm_config: Channel #1 MTR2 = 0
[52803.640188] EDAC DEBUG: get_dimm_config: Channel #2 MTR0 = 500c
[52803.640190] EDAC DEBUG: get_dimm_config: mc#1: channel 2, dimm 0, 4096 Mb (1048576 pages) bank: 8, rank: 2, row: 0x8000, col: 0x400
[52803.640193] EDAC DEBUG: get_dimm_config: Channel #2 MTR1 = 500c
[52803.640195] EDAC DEBUG: get_dimm_config: mc#1: channel 2, dimm 1, 4096 Mb (1048576 pages) bank: 8, rank: 2, row: 0x8000, col: 0x400
[52803.640199] EDAC DEBUG: get_dimm_config: Channel #2 MTR2 = 0
[52803.640201] EDAC DEBUG: get_dimm_config: Channel #3 MTR0 = 500c
[52803.640203] EDAC DEBUG: get_dimm_config: mc#1: channel 3, dimm 0, 4096 Mb (1048576 pages) bank: 8, rank: 2, row: 0x8000, col: 0x400
[52803.640218] EDAC DEBUG: get_dimm_config: Channel #3 MTR1 = 500c
[52803.640220] EDAC DEBUG: get_dimm_config: mc#1: channel 3, dimm 1, 4096 Mb (1048576 pages) bank: 8, rank: 2, row: 0x8000, col: 0x400
[52803.640223] EDAC DEBUG: get_dimm_config: Channel #3 MTR2 = 0
[52803.640226] EDAC DEBUG: get_memory_layout: TOLM: 3.136 GB (0x00000000c3ffffff)
[52803.640228] EDAC DEBUG: get_memory_layout: TOHM: 66.624 GB (0x0000001043ffffff)
[52803.640231] EDAC DEBUG: get_memory_layout: SAD#0 DRAM up to 33.792 GB (0x0000000840000000) Interleave: 8:6 reg=0x000083c3
[52803.640234] EDAC DEBUG: get_memory_layout: SAD#0, interleave #0: 0
[52803.640237] EDAC DEBUG: get_memory_layout: SAD#1 DRAM up to 66.560 GB (0x0000001040000000) Interleave: 8:6 reg=0x000103c3
[52803.640239] EDAC DEBUG: get_memory_layout: SAD#1, interleave #0: 1
[52803.640245] EDAC DEBUG: get_memory_layout: TAD#0: up to 66.560 GB (0x0000001040000000), socket interleave 0, memory interleave 3, TGT: 0, 1, 2, 3, reg=0x0040f3e4
[52803.640249] EDAC DEBUG: get_memory_layout: TAD CH#0, offset #0: 33.792 GB (0x0000000840000000), reg=0x00008400
[52803.640252] EDAC DEBUG: get_memory_layout: TAD CH#1, offset #0: 33.792 GB (0x0000000840000000), reg=0x00008400
[52803.640255] EDAC DEBUG: get_memory_layout: TAD CH#2, offset #0: 33.792 GB (0x0000000840000000), reg=0x00008400
[52803.640258] EDAC DEBUG: get_memory_layout: TAD CH#3, offset #0: 33.792 GB (0x0000000840000000), reg=0x00008400
[52803.640261] EDAC DEBUG: get_memory_layout: CH#0 RIR#0, limit: 8.191 GB (0x00000001fff00000), way: 4, reg=0xa000001e
[52803.640264] EDAC DEBUG: get_memory_layout: CH#0 RIR#0 INTL#0, offset 0.000 GB (0x0000000000000000), tgt: 0, reg=0x00000000
[52803.640278] EDAC DEBUG: get_memory_layout: CH#0 RIR#0 INTL#1, offset 0.000 GB (0x0000000000000000), tgt: 4, reg=0x00040000
[52803.640281] EDAC DEBUG: get_memory_layout: CH#0 RIR#0 INTL#2, offset 0.000 GB (0x0000000000000000), tgt: 1, reg=0x00010000
[52803.640283] EDAC DEBUG: get_memory_layout: CH#0 RIR#0 INTL#3, offset 0.000 GB (0x0000000000000000), tgt: 5, reg=0x00050000
[52803.640287] EDAC DEBUG: get_memory_layout: CH#1 RIR#0, limit: 8.191 GB (0x00000001fff00000), way: 4, reg=0xa000001e
[52803.640290] EDAC DEBUG: get_memory_layout: CH#1 RIR#0 INTL#0, offset 0.000 GB (0x0000000000000000), tgt: 0, reg=0x00000000
[52803.640293] EDAC DEBUG: get_memory_layout: CH#1 RIR#0 INTL#1, offset 0.000 GB (0x0000000000000000), tgt: 4, reg=0x00040000
[52803.640296] EDAC DEBUG: get_memory_layout: CH#1 RIR#0 INTL#2, offset 0.000 GB (0x0000000000000000), tgt: 1, reg=0x00010000
[52803.640299] EDAC DEBUG: get_memory_layout: CH#1 RIR#0 INTL#3, offset 0.000 GB (0x0000000000000000), tgt: 5, reg=0x00050000
[52803.640303] EDAC DEBUG: get_memory_layout: CH#2 RIR#0, limit: 8.191 GB (0x00000001fff00000), way: 4, reg=0xa000001e
[52803.640306] EDAC DEBUG: get_memory_layout: CH#2 RIR#0 INTL#0, offset 0.000 GB (0x0000000000000000), tgt: 0, reg=0x00000000
[52803.640309] EDAC DEBUG: get_memory_layout: CH#2 RIR#0 INTL#1, offset 0.000 GB (0x0000000000000000), tgt: 4, reg=0x00040000
[52803.640312] EDAC DEBUG: get_memory_layout: CH#2 RIR#0 INTL#2, offset 0.000 GB (0x0000000000000000), tgt: 1, reg=0x00010000
[52803.640315] EDAC DEBUG: get_memory_layout: CH#2 RIR#0 INTL#3, offset 0.000 GB (0x0000000000000000), tgt: 5, reg=0x00050000
[52803.640319] EDAC DEBUG: get_memory_layout: CH#3 RIR#0, limit: 8.191 GB (0x00000001fff00000), way: 4, reg=0xa000001e
[52803.640322] EDAC DEBUG: get_memory_layout: CH#3 RIR#0 INTL#0, offset 0.000 GB (0x0000000000000000), tgt: 0, reg=0x00000000
[52803.640324] EDAC DEBUG: get_memory_layout: CH#3 RIR#0 INTL#1, offset 0.000 GB (0x0000000000000000), tgt: 4, reg=0x00040000
[52803.640327] EDAC DEBUG: get_memory_layout: CH#3 RIR#0 INTL#2, offset 0.000 GB (0x0000000000000000), tgt: 1, reg=0x00010000
[52803.640330] EDAC DEBUG: get_memory_layout: CH#3 RIR#0 INTL#3, offset 0.000 GB (0x0000000000000000), tgt: 5, reg=0x00050000
In this case, all 4 channels are used for interleave:
[52803.640245] EDAC DEBUG: get_memory_layout: TAD#0: up to 66.560 GB (0x0000001040000000), socket interleave 0, memory interleave 3, TGT: 0, 1, 2, 3, reg=0x0040f3e4
It doesn't do DIMM socket interleave (socket interleave 0). It does channel interleave
among channels 0 to 3 (TGT: 0, 1, 2, 3).
It also does an interleave at the physical memory address on bits 6 to 8:
[52803.640231] EDAC DEBUG: get_memory_layout: SAD#0 DRAM up to 33.792 GB (0x0000000840000000) Interleave: 8:6 reg=0x000083c3
This memory controller have thousands (literally) of different BIOS setups
that change how interleaves can happen on it. The above is the default
setup.
They're based on DIMM socket, MCU channel and physical address ranges.
> In the end of the day, it is smallest row that gives you 64 bits of
> data.
Yes, but the memory controller views memories per DIMM socket, and
> @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.
For Nehalem, see i7core_edac comments that I added at the beginning of the
driver:
* Based on the following public Intel datasheets:
* Intel Core i7 Processor Extreme Edition and Intel Core i7 Processor
* Datasheet, Volume 2:
* http://download.intel.com/design/processor/datashts/320835.pdf
* Intel Xeon Processor 5500 Series Datasheet Volume 2
* http://www.intel.com/Assets/PDF/datasheet/321322.pdf
* also available at:
* http://www.arrownac.com/manufacturers/intel/s/nehalem/5500-datasheet-v2.pdf
>
> [..]
>
>> 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.
No. This machine has 64 GB of RAM, and it was physically filled with 16 DIMMs,
each with 4GB. Each of the above represents one DIMM (and not a rank).
Btw, the above logs are for this machine.
# free
total used free shared buffers cached
Mem: 65933268 1166384 64766884 0 60572 363712
-/+ buffers/cache: 742100 65191168
Swap: 68157436 18680 68138756
The DMI decode info also clearly states that:
# dmidecode|grep -e "Memory Device$" -e Size -e "Bank Locat" -e "Serial Number" |grep -v Range
...
Memory Device
Size: 4096 MB
Bank Locator: NODE 0 CHANNEL 0 DIMM 0
Serial Number: 82766209
Memory Device
Size: 4096 MB
Bank Locator: NODE 0 CHANNEL 0 DIMM 1
Serial Number: 827661D3
Memory Device
Size: 4096 MB
Bank Locator: NODE 0 CHANNEL 1 DIMM 0
Serial Number: 82766197
Memory Device
Size: 4096 MB
Bank Locator: NODE 0 CHANNEL 1 DIMM 1
Serial Number: 82766204
Memory Device
Size: 4096 MB
Bank Locator: NODE 0 CHANNEL 2 DIMM 0
Serial Number: 827661D7
Memory Device
Size: 4096 MB
Bank Locator: NODE 0 CHANNEL 2 DIMM 1
Serial Number: 82766200
Memory Device
Size: 4096 MB
Bank Locator: NODE 0 CHANNEL 3 DIMM 0
Serial Number: 827661F9
Memory Device
Size: 4096 MB
Bank Locator: NODE 0 CHANNEL 3 DIMM 1
Serial Number: 827661B3
Memory Device
Size: 4096 MB
Bank Locator: NODE 1 CHANNEL 0 DIMM 0
Serial Number: 47473B79
Memory Device
Size: 4096 MB
Bank Locator: NODE 1 CHANNEL 0 DIMM 1
Serial Number: 440FF77F
Memory Device
Size: 4096 MB
Bank Locator: NODE 1 CHANNEL 1 DIMM 0
Serial Number: 47473B5A
Memory Device
Size: 4096 MB
Bank Locator: NODE 1 CHANNEL 1 DIMM 1
Serial Number: 47473B71
Memory Device
Size: 4096 MB
Bank Locator: NODE 1 CHANNEL 2 DIMM 0
Serial Number: 47473B62
Memory Device
Size: 4096 MB
Bank Locator: NODE 1 CHANNEL 2 DIMM 1
Serial Number: 440FF7FC
Memory Device
Size: 4096 MB
Bank Locator: NODE 1 CHANNEL 3 DIMM 0
Serial Number: 440FF7C1
Memory Device
Size: 4096 MB
Bank Locator: NODE 1 CHANNEL 3 DIMM 1
Serial Number: 440FF7F4
As I said, for this memory controller, and for Nehalem, the memories are
mapped per DIMM socket (and not per rank).
Mauro.
next prev parent reply other threads:[~2012-04-24 17:25 UTC|newest]
Thread overview: 161+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-29 16:45 [PATCH 00/13] Convert EDAC internal strutures to support all types of Memory Controllers Mauro Carvalho Chehab
2012-03-29 16:45 ` [PATCH 01/13] edac: Create a dimm struct and move the labels into it Mauro Carvalho Chehab
2012-03-30 10:50 ` Borislav Petkov
2012-03-30 13:26 ` Mauro Carvalho Chehab
2012-03-30 15:38 ` Borislav Petkov
2012-04-16 8:41 ` Mauro Carvalho Chehab
2012-04-16 11:02 ` Borislav Petkov
2012-04-16 11:44 ` Mauro Carvalho Chehab
2012-04-16 13:21 ` Borislav Petkov
2012-03-29 16:45 ` [PATCH 02/13] edac: move dimm properties to struct memset_info Mauro Carvalho Chehab
2012-03-30 13:10 ` Borislav Petkov
2012-03-30 13:22 ` Mauro Carvalho Chehab
2012-03-30 17:03 ` Borislav Petkov
2012-04-16 8:56 ` Mauro Carvalho Chehab
2012-04-16 13:31 ` Borislav Petkov
2012-03-29 16:45 ` [PATCH 03/13] edac: Don't initialize csrow's first_page & friends when not needed Mauro Carvalho Chehab
2012-04-02 12:33 ` Borislav Petkov
2012-03-29 16:45 ` [PATCH 04/13] edac: move nr_pages to dimm struct Mauro Carvalho Chehab
2012-04-02 13:18 ` Borislav Petkov
2012-03-29 16:45 ` [PATCH 05/13] edac: Fix core support for MC's that see DIMMS instead of ranks Mauro Carvalho Chehab
2012-03-29 16:45 ` [PATCH 06/13] edac: Initialize the dimm label with the known information Mauro Carvalho Chehab
2012-03-29 16:45 ` [PATCH 07/13] edac: Cleanup the logs for i7core and sb edac drivers Mauro Carvalho Chehab
2012-03-29 16:45 ` [PATCH 08/13] i5400_edac: improve debug messages to better represent the filled memory Mauro Carvalho Chehab
2012-03-29 16:45 ` [PATCH 09/13] events/hw_event: Create a Hardware Events Report Mecanism (HERM) Mauro Carvalho Chehab
2012-03-29 16:45 ` [PATCH 10/13] i5000_edac: Fix the logic that retrieves memory information Mauro Carvalho Chehab
2012-03-29 16:45 ` [PATCH 11/13] e752x_edac: provide more info about how DIMMS/ranks are mapped Mauro Carvalho Chehab
2012-03-29 16:45 ` [PATCH 12/13] edac: Rename the parent dev to pdev Mauro Carvalho Chehab
2012-03-29 16:45 ` [PATCH 13/13] edac: use Documentation-nano format for some data structs Mauro Carvalho Chehab
2012-03-29 20:46 ` [PATCH 00/13] Convert EDAC internal strutures to support all types of Memory Controllers Aristeu Rozanski Filho
2012-04-02 13:59 ` Borislav Petkov
2012-04-16 12:58 ` Mauro Carvalho Chehab
2012-04-16 14:06 ` Borislav Petkov
2012-04-16 20:12 ` [EDAC PATCH v13 0/7] Convert EDAC core to work with non-csrow-based memory controllers Mauro Carvalho Chehab
2012-04-16 20:12 ` [EDAC PATCH v13 1/7] edac: Create a dimm struct and move the labels into it Mauro Carvalho Chehab
2012-04-26 14:26 ` Borislav Petkov
2012-04-16 20:12 ` [EDAC PATCH v13 3/7] edac: Don't initialize csrow's first_page & friends when not needed Mauro Carvalho Chehab
2012-04-16 20:12 ` [EDAC PATCH v13 4/7] edac: move nr_pages to dimm struct Mauro Carvalho Chehab
2012-04-17 18:48 ` Borislav Petkov
2012-04-17 19:28 ` Mauro Carvalho Chehab
2012-04-17 21:40 ` Borislav Petkov
2012-04-18 12:58 ` Mauro Carvalho Chehab
2012-04-18 17:53 ` [PATCH] " Mauro Carvalho Chehab
2012-04-16 20:12 ` [EDAC PATCH v13 5/7] edac: rewrite edac_align_ptr() Mauro Carvalho Chehab
2012-04-18 14:06 ` Borislav Petkov
2012-04-18 15:25 ` Borislav Petkov
2012-04-18 18:15 ` Mauro Carvalho Chehab
2012-04-18 18:19 ` [PATCH] " Mauro Carvalho Chehab
2012-04-23 14:05 ` Borislav Petkov
2012-04-23 15:19 ` Mauro Carvalho Chehab
2012-04-23 15:26 ` Mauro Carvalho Chehab
2012-04-16 20:12 ` [EDAC PATCH v13 6/7] edac.h: Prepare to handle with generic layers Mauro Carvalho Chehab
2012-04-23 17:49 ` Borislav Petkov
2012-04-23 18:30 ` Mauro Carvalho Chehab
2012-04-23 18:56 ` Mauro Carvalho Chehab
2012-04-23 19:19 ` [PATCH] edac.h: Add generic layers for describing a memory location Mauro Carvalho Chehab
2012-04-23 20:07 ` Mauro Carvalho Chehab
2012-04-24 10:46 ` Borislav Petkov
2012-04-24 10:40 ` [EDAC PATCH v13 6/7] edac.h: Prepare to handle with generic layers Borislav Petkov
2012-04-24 11:46 ` Mauro Carvalho Chehab
2012-04-24 12:42 ` Mauro Carvalho Chehab
2012-04-24 12:49 ` [PATCH] edac.h: Add generic layers for describing a memory location Mauro Carvalho Chehab
2012-04-24 13:09 ` Borislav Petkov
2012-04-24 13:22 ` Mauro Carvalho Chehab
2012-04-24 13:38 ` Borislav Petkov
2012-04-24 16:39 ` Mauro Carvalho Chehab
2012-04-24 16:49 ` Borislav Petkov
2012-04-24 17:38 ` Mauro Carvalho Chehab
[not found] ` <1335291342-14922-1-git-send-email-mchehab@redhat.com>
2012-04-24 18:15 ` [PATCH EDACv16 2/2] amd64_edac: convert driver to use the new edac ABI Mauro Carvalho Chehab
2012-04-27 10:42 ` Mauro Carvalho Chehab
2012-04-27 13:33 ` [PATCH EDACv16 1/2] edac: Change internal representation to work with layers Borislav Petkov
2012-04-27 14:11 ` Joe Perches
2012-04-27 15:12 ` Borislav Petkov
2012-04-27 16:07 ` Mauro Carvalho Chehab
2012-04-28 8:52 ` Borislav Petkov
2012-04-28 20:38 ` Joe Perches
2012-04-29 14:25 ` Mauro Carvalho Chehab
2012-04-29 15:11 ` Mauro Carvalho Chehab
2012-04-29 16:03 ` Joe Perches
2012-04-29 17:18 ` Mauro Carvalho Chehab
2012-04-29 16:20 ` Mauro Carvalho Chehab
2012-04-29 16:43 ` Joe Perches
2012-04-29 17:39 ` Mauro Carvalho Chehab
2012-04-30 7:47 ` Borislav Petkov
2012-04-30 11:09 ` Mauro Carvalho Chehab
2012-04-30 11:15 ` Borislav Petkov
2012-04-30 11:46 ` Mauro Carvalho Chehab
2012-04-27 15:36 ` Mauro Carvalho Chehab
2012-04-28 9:05 ` Borislav Petkov
2012-04-29 13:49 ` Mauro Carvalho Chehab
2012-04-30 8:15 ` Borislav Petkov
2012-04-30 10:58 ` Mauro Carvalho Chehab
2012-04-30 11:11 ` Borislav Petkov
2012-04-30 11:45 ` Mauro Carvalho Chehab
2012-04-30 12:38 ` Borislav Petkov
2012-04-30 13:00 ` Mauro Carvalho Chehab
2012-04-30 13:53 ` Mauro Carvalho Chehab
2012-04-30 15:02 ` [PATCH v2] edac_mc: Cleanup per-dimm_info debug messages Mauro Carvalho Chehab
2012-04-30 15:10 ` Mauro Carvalho Chehab
2012-04-30 15:20 ` Borislav Petkov
2012-04-30 15:33 ` Mauro Carvalho Chehab
2012-04-30 16:16 ` Joe Perches
2012-04-30 16:47 ` Mauro Carvalho Chehab
2012-04-30 16:44 ` [PATCHv3] " Mauro Carvalho Chehab
2012-04-30 11:37 ` [PATCH EDACv16 1/2] edac: Change internal representation to work with layers Mauro Carvalho Chehab
2012-04-27 17:52 ` Mauro Carvalho Chehab
2012-04-28 9:16 ` Borislav Petkov
2012-04-28 17:07 ` Joe Perches
2012-04-29 14:02 ` Mauro Carvalho Chehab
2012-04-29 14:16 ` Mauro Carvalho Chehab
2012-04-30 7:59 ` Borislav Petkov
2012-04-30 11:23 ` Mauro Carvalho Chehab
2012-04-30 12:51 ` Borislav Petkov
2012-04-24 12:55 ` [EDAC PATCH v13 6/7] edac.h: Prepare to handle with generic layers Borislav Petkov
2012-04-24 13:11 ` Mauro Carvalho Chehab
2012-04-24 13:32 ` Borislav Petkov
2012-04-24 14:24 ` Mauro Carvalho Chehab
2012-04-24 16:27 ` Borislav Petkov
2012-04-24 17:24 ` Mauro Carvalho Chehab [this message]
2012-04-25 17:19 ` Borislav Petkov
2012-04-25 17:47 ` Mauro Carvalho Chehab
2012-04-25 18:32 ` Luck, Tony
2012-04-25 18:44 ` Mauro Carvalho Chehab
2012-04-26 14:11 ` Borislav Petkov
2012-04-26 14:25 ` Mauro Carvalho Chehab
2012-04-26 14:59 ` Mauro Carvalho Chehab
2012-04-25 17:55 ` Luck, Tony
2012-04-24 17:31 ` Luck, Tony
2012-04-16 20:21 ` [EDAC_ABI PATCH v13 00/26] Use the new EDAC kernel ABI on drivers Mauro Carvalho Chehab
2012-04-16 20:21 ` [EDAC_ABI PATCH v13 01/26] amd64_edac: convert driver to use the new edac ABI Mauro Carvalho Chehab
2012-05-07 14:31 ` Borislav Petkov
2012-05-07 16:12 ` Mauro Carvalho Chehab
2012-05-07 16:17 ` Borislav Petkov
2012-05-07 16:59 ` Mauro Carvalho Chehab
2012-05-07 19:49 ` Borislav Petkov
2012-05-07 16:24 ` Mauro Carvalho Chehab
2012-04-16 20:21 ` [EDAC_ABI PATCH v13 02/26] amd76x_edac: " Mauro Carvalho Chehab
2012-04-16 20:21 ` [EDAC_ABI PATCH v13 03/26] cell_edac: " Mauro Carvalho Chehab
2012-04-16 20:21 ` [EDAC_ABI PATCH v13 04/26] cpc925_edac: " Mauro Carvalho Chehab
2012-04-16 20:21 ` [EDAC_ABI PATCH v13 05/26] e752x_edac: " Mauro Carvalho Chehab
2012-04-16 20:21 ` [EDAC_ABI PATCH v13 06/26] e7xxx_edac: " Mauro Carvalho Chehab
2012-04-16 20:21 ` [EDAC_ABI PATCH v13 07/26] i3000_edac: " Mauro Carvalho Chehab
2012-04-16 20:21 ` [EDAC_ABI PATCH v13 08/26] i3200_edac: " Mauro Carvalho Chehab
2012-04-16 20:21 ` [EDAC_ABI PATCH v13 09/26] i5000_edac: " Mauro Carvalho Chehab
2012-04-16 20:21 ` [EDAC_ABI PATCH v13 10/26] i5100_edac: " Mauro Carvalho Chehab
2012-04-16 20:21 ` [EDAC_ABI PATCH v13 11/26] i5400_edac: " Mauro Carvalho Chehab
2012-04-16 20:21 ` [EDAC_ABI PATCH v13 12/26] i7300_edac: " Mauro Carvalho Chehab
2012-04-16 20:21 ` [EDAC_ABI PATCH v13 13/26] i7core_edac: " Mauro Carvalho Chehab
2012-04-16 20:21 ` [EDAC_ABI PATCH v13 14/26] i82443bxgx_edac: " Mauro Carvalho Chehab
2012-04-16 20:21 ` [EDAC_ABI PATCH v13 15/26] i82860_edac: " Mauro Carvalho Chehab
2012-04-16 20:21 ` [EDAC_ABI PATCH v13 16/26] i82875p_edac: " Mauro Carvalho Chehab
2012-04-16 20:21 ` [EDAC_ABI PATCH v13 17/26] i82975x_edac: " Mauro Carvalho Chehab
2012-04-16 20:21 ` [EDAC_ABI PATCH v13 18/26] mpc85xx_edac: " Mauro Carvalho Chehab
2012-04-16 20:21 ` [EDAC_ABI PATCH v13 19/26] mv64x60_edac: " Mauro Carvalho Chehab
2012-04-16 20:21 ` [EDAC_ABI PATCH v13 20/26] pasemi_edac: " Mauro Carvalho Chehab
2012-04-16 20:21 ` [EDAC_ABI PATCH v13 21/26] ppc4xx_edac: " Mauro Carvalho Chehab
2012-04-16 20:21 ` [EDAC_ABI PATCH v13 22/26] r82600_edac: " Mauro Carvalho Chehab
2012-04-16 20:21 ` [EDAC_ABI PATCH v13 23/26] sb_edac: " Mauro Carvalho Chehab
2012-04-16 20:21 ` [EDAC_ABI PATCH v13 24/26] tile_edac: " Mauro Carvalho Chehab
2012-04-26 19:47 ` Chris Metcalf
2012-04-16 20:21 ` [EDAC_ABI PATCH v13 25/26] x38_edac: " Mauro Carvalho Chehab
2012-04-16 20:21 ` [EDAC_ABI PATCH v13 26/26] edac: Remove the legacy EDAC ABI Mauro Carvalho Chehab
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=4F96E1EB.1030407@redhat.com \
--to=mchehab@redhat.com \
--cc=bp@amd64.org \
--cc=linux-edac@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=norsk5@yahoo.com \
--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 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).