Acked-by: Doug Thompson <[email protected]>
On 12/11/2012 03:31 AM, Mauro Carvalho Chehab wrote: > Em Mon, 10 Dec 2012 21:09:26 -0500 (EST) > CAI Qian <[email protected]> escreveu: > >> Doug, Mauro, this upstream patch looks applicable to the stable releases. >> Please ACK it if you agree, so that Greg can commit it there. > ACK for 3.6.x. > >> From Mauro Carvalho Chehab <[email protected]> >> Upstream-ID: 24bef66e74d647aebd34e0bef7693512b7912029 >> Stable-trees: 3.6.x >> >> 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 <[email protected]> >> Signed-off-by: CAI Qian <[email protected]> >> >> diff --git a/drivers/edac/edac_mc.c b/drivers/edac/edac_mc.c >> index d5dc9da..81eb9fd 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, >> dimm->cschannel = chn; >> >> /* Increment csrow location */ >> - row++; >> - if (row == tot_csrows) { >> - row = 0; >> + if (layers[0].is_virt_csrow) { >> chn++; >> + if (chn == tot_channels) { >> + chn = 0; >> + row++; >> + } >> + } else { >> + row++; >> + if (row == tot_csrows) { >> + row = 0; >> + chn++; >> + } >> } >> >> /* Increment dimm location */ > -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
