diff options
author | Mauro Carvalho Chehab <mchehab@redhat.com> | 2012-10-24 08:30:01 -0400 |
---|---|---|
committer | Mauro Carvalho Chehab <mchehab@redhat.com> | 2012-10-25 05:17:18 -0400 |
commit | 24bef66e74d647aebd34e0bef7693512b7912029 (patch) | |
tree | ba8c0018022349ba3c9ca2f6deb414df96cc288d /drivers | |
parent | 479696840239e0cc43efb3c917bdcad2174d2215 (diff) |
edac: Fix the dimm filling for csrows-based layouts
The driver is currently filling data in a wrong way, on drivers
for csrows-based memory controller, when the first layer is a
csrow.
This is not easily to notice, as, in general, memories are
filed in dual, interleaved, symetric mode, as very few memory
controllers support asymetric modes.
While digging into a bug for i82795_edac driver, the asymetric
mode there is now working, allowing us to fill the machine with
4x1GB ranks at channel 0, and 2x512GB at channel 1:
Channel 0 ranks:
EDAC DEBUG: i82975x_init_csrows: DIMM A0: from page 0x00000000 to 0x0003ffff (size: 0x00040000 pages)
EDAC DEBUG: i82975x_init_csrows: DIMM A1: from page 0x00040000 to 0x0007ffff (size: 0x00040000 pages)
EDAC DEBUG: i82975x_init_csrows: DIMM A2: from page 0x00080000 to 0x000bffff (size: 0x00040000 pages)
EDAC DEBUG: i82975x_init_csrows: DIMM A3: from page 0x000c0000 to 0x000fffff (size: 0x00040000 pages)
Channel 1 ranks:
EDAC DEBUG: i82975x_init_csrows: DIMM B0: from page 0x00100000 to 0x0011ffff (size: 0x00020000 pages)
EDAC DEBUG: i82975x_init_csrows: DIMM B1: from page 0x00120000 to 0x0013ffff (size: 0x00020000 pages)
Instead of properly showing the memories as such, before this patch, it
shows the memory layout as:
+-----------------------------------+
| mc0 |
| csrow0 | csrow1 | csrow2 |
----------+-----------------------------------+
channel1: | 1024 MB | 1024 MB | 512 MB |
channel0: | 1024 MB | 1024 MB | 512 MB |
----------+-----------------------------------+
as if both channels were symetric, grouping the DIMMs on a wrong
layout.
After this patch, the memory is correctly represented.
So, for csrows at layers[0], it shows:
+-----------------------------------------------+
| mc0 |
| csrow0 | csrow1 | csrow2 | csrow3 |
----------+-----------------------------------------------+
channel1: | 512 MB | 512 MB | 0 MB | 0 MB |
channel0: | 1024 MB | 1024 MB | 1024 MB | 1024 MB |
----------+-----------------------------------------------+
For csrows at layers[1], it shows:
+-----------------------+
| mc0 |
| channel0 | channel1 |
--------+-----------------------+
csrow3: | 1024 MB | 0 MB |
csrow2: | 1024 MB | 0 MB |
--------+-----------------------+
csrow1: | 1024 MB | 512 MB |
csrow0: | 1024 MB | 512 MB |
--------+-----------------------+
So, no matter of what comes first, the information between
channel and csrow will be properly represented.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Diffstat (limited to 'drivers')
-rw-r--r-- | drivers/edac/edac_mc.c | 14 |
1 files changed, 11 insertions, 3 deletions
diff --git a/drivers/edac/edac_mc.c b/drivers/edac/edac_mc.c index d5dc9da7f99f..81eb9fd3f717 100644 --- a/drivers/edac/edac_mc.c +++ b/drivers/edac/edac_mc.c | |||
@@ -416,10 +416,18 @@ struct mem_ctl_info *edac_mc_alloc(unsigned mc_num, | |||
416 | dimm->cschannel = chn; | 416 | dimm->cschannel = chn; |
417 | 417 | ||
418 | /* Increment csrow location */ | 418 | /* Increment csrow location */ |
419 | row++; | 419 | if (layers[0].is_virt_csrow) { |
420 | if (row == tot_csrows) { | ||
421 | row = 0; | ||
422 | chn++; | 420 | chn++; |
421 | if (chn == tot_channels) { | ||
422 | chn = 0; | ||
423 | row++; | ||
424 | } | ||
425 | } else { | ||
426 | row++; | ||
427 | if (row == tot_csrows) { | ||
428 | row = 0; | ||
429 | chn++; | ||
430 | } | ||
423 | } | 431 | } |
424 | 432 | ||
425 | /* Increment dimm location */ | 433 | /* Increment dimm location */ |