subject:"Re\: \[GIT PULL\] EDAC fixes for 3.8"

Re: [GIT PULL] EDAC fixes for 3.8

2013-03-12 Thread Mauro Carvalho Chehab

Em Tue, 12 Mar 2013 12:56:32 +0100
Borislav Petkov  escreveu:

> On Tue, Mar 12, 2013 at 08:34:48AM -0300, Mauro Carvalho Chehab wrote:
> > Looks ok on my eyes. I'll test it here on both systems, with both this
> > patch and the second one:
> > 
> > http://git.infradead.org/users/mchehab/edac.git/commitdiff/56ba4c93d909ef9dfab4f1101a8c3bf75bc4cdab
> > 
> > It should take some time to finish compilation.
> 
> No hurry, I'd need to finish testing them and if all is fine, will send
> them upstream next week, the latest.

Ok. Anyway, x86_64 compilation finished. Just re-did the tests on both
machines:

Here are the tests with the modified version of the patch applied, on the
machine equipped with quad-rank RAMs:

/sys/devices/system/edac/mc/mc0/size_mb:8192
/sys/devices/system/edac/mc/mc0/csrow2/size_mb:2048
/sys/devices/system/edac/mc/mc0/csrow3/size_mb:2048
/sys/devices/system/edac/mc/mc0/csrow6/size_mb:2048
/sys/devices/system/edac/mc/mc0/csrow7/size_mb:2048

/sys/devices/system/edac/mc/mc1/size_mb:8192
/sys/devices/system/edac/mc/mc1/csrow2/size_mb:2048
/sys/devices/system/edac/mc/mc1/csrow3/size_mb:2048
/sys/devices/system/edac/mc/mc1/csrow6/size_mb:2048
/sys/devices/system/edac/mc/mc1/csrow7/size_mb:2048

/sys/devices/system/edac/mc/mc0/rank4/size:1024
/sys/devices/system/edac/mc/mc0/rank5/size:1024
/sys/devices/system/edac/mc/mc0/rank6/size:1024
/sys/devices/system/edac/mc/mc0/rank7/size:1024
/sys/devices/system/edac/mc/mc0/rank12/size:1024
/sys/devices/system/edac/mc/mc0/rank13/size:1024
/sys/devices/system/edac/mc/mc0/rank14/size:1024
/sys/devices/system/edac/mc/mc0/rank15/size:1024
/sys/devices/system/edac/mc/mc1/rank4/size:1024
/sys/devices/system/edac/mc/mc1/rank5/size:1024
/sys/devices/system/edac/mc/mc1/rank6/size:1024
/sys/devices/system/edac/mc/mc1/rank7/size:1024
/sys/devices/system/edac/mc/mc1/rank12/size:1024
/sys/devices/system/edac/mc/mc1/rank13/size:1024
/sys/devices/system/edac/mc/mc1/rank14/size:1024
/sys/devices/system/edac/mc/mc1/rank15/size:1024

[0.00] Linux version 3.8.2-209.fc18.x86_64.debug 
(mockbu...@buildvm-04.phx2.fedoraproject.org) (gcc version 4.7.2 20121109 (Red 
Hat 4.7.2-8) (GCC) ) #1 SMP Tue Mar 12 11:37:54 UTC 2013

[   33.321105] EDAC MC: Ver: 3.0.0
[   33.325269] EDAC DEBUG: edac_mc_sysfs_init: device mc created
[   33.630374] AMD64 EDAC driver v3.4.0
[   33.634117] EDAC amd64: DRAM ECC enabled.
[   33.638170] EDAC DEBUG: amd64_nb_mce_bank_enabled_on_node: core: 0, MCG_CTL: 
0x3f, NB MSR is enabled
[   33.638174] EDAC DEBUG: amd64_nb_mce_bank_enabled_on_node: core: 2, MCG_CTL: 
0x3f, NB MSR is enabled
[   33.638177] EDAC DEBUG: amd64_nb_mce_bank_enabled_on_node: core: 3, MCG_CTL: 
0x3f, NB MSR is enabled
[   33.638180] EDAC DEBUG: amd64_nb_mce_bank_enabled_on_node: core: 4, MCG_CTL: 
0x3f, NB MSR is enabled
[   33.638183] EDAC DEBUG: amd64_nb_mce_bank_enabled_on_node: core: 5, MCG_CTL: 
0x3f, NB MSR is enabled
[   33.638186] EDAC DEBUG: amd64_nb_mce_bank_enabled_on_node: core: 6, MCG_CTL: 
0x3f, NB MSR is enabled
[   33.638203] EDAC amd64: F10h detected (node 0).
[   33.642795] EDAC DEBUG: reserve_mc_sibling_devs: F1: :00:18.1
[   33.642797] EDAC DEBUG: reserve_mc_sibling_devs: F2: :00:18.2
[   33.642800] EDAC DEBUG: reserve_mc_sibling_devs: F3: :00:18.3
[   33.642804] EDAC DEBUG: read_mc_regs:   TOP_MEM:  0xe000
[   33.642807] EDAC DEBUG: read_mc_regs:   TOP_MEM2: 0x00042000
[   33.642813] EDAC DEBUG: read_dram_ctl_register: F2x110 (DCTSelLow): 
0x05e4, High range addrs at: 0x0
[   33.642816] EDAC DEBUG: read_dram_ctl_register:   DCTs operate in unganged 
mode
[   33.642818] EDAC DEBUG: read_dram_ctl_register:   Address range split per 
DCT: no
[   33.642821] EDAC DEBUG: read_dram_ctl_register:   data interleave for ECC: 
enabled, DRAM cleared since last warm reset: yes
[   33.642824] EDAC DEBUG: read_dram_ctl_register:   channel interleave: 
enabled, interleave bits selector: 0x3
[   33.642835] EDAC DEBUG: read_mc_regs:   DRAM range[0], base: 
0x; limit: 0x00021fff
[   33.642839] EDAC DEBUG: read_mc_regs:IntlvEn=Disabled; Range access: RW 
IntlvSel=0 DstNode=0
[   33.642845] EDAC DEBUG: read_mc_regs:   DRAM range[1], base: 
0x00022000; limit: 0x00041fff
[   33.642849] EDAC DEBUG: read_mc_regs:IntlvEn=Disabled; Range access: RW 
IntlvSel=0 DstNode=1
[   33.642860] EDAC DEBUG: read_dct_base_mask:   DCSB0[0]=0x reg: F2x40
[   33.642863] EDAC DEBUG: read_dct_base_mask:   DCSB1[0]=0x reg: F2x140
[   33.642867] EDAC DEBUG: read_dct_base_mask:   DCSB0[1]=0x reg: F2x44
[   33.642871] EDAC DEBUG: read_dct_base_mask:   DCSB1[1]=0x reg: F2x144
[   33.642874] EDAC DEBUG: read_dct_base_mask:   DCSB0[2]=0x0001 reg: F2x48
[   33.642877] EDAC DEBUG: read_dct_base_mask:   DCSB1[2]=0x0001 reg: F2x148
[   33.642880] EDAC DEBUG: read_dct_base_mask:   DCSB0[3]=0x0101 reg: F2x4c
[   33.642883] EDAC DEBUG: read_dct_base_mask:   DCSB1[3]=0x0101 reg:

Re: [GIT PULL] EDAC fixes for 3.8

2013-03-12 Thread Borislav Petkov

On Tue, Mar 12, 2013 at 08:34:48AM -0300, Mauro Carvalho Chehab wrote:
> Looks ok on my eyes. I'll test it here on both systems, with both this
> patch and the second one:
> 
> http://git.infradead.org/users/mchehab/edac.git/commitdiff/56ba4c93d909ef9dfab4f1101a8c3bf75bc4cdab
> 
> It should take some time to finish compilation.

No hurry, I'd need to finish testing them and if all is fine, will send
them upstream next week, the latest.

Thanks.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] EDAC fixes for 3.8

2013-03-12 Thread Mauro Carvalho Chehab

Em Tue, 12 Mar 2013 10:16:30 +0100
Borislav Petkov  escreveu:

> Btw,
> 
> the first one I changed to not divide by the channel_count, see below.
> Now I'll go and run them to check everything's fine.

Looks ok on my eyes. I'll test it here on both systems, with both this
patch and the second one:

http://git.infradead.org/users/mchehab/edac.git/commitdiff/56ba4c93d909ef9dfab4f1101a8c3bf75bc4cdab

It should take some time to finish compilation.

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

Re: [GIT PULL] EDAC fixes for 3.8

2013-03-12 Thread Mauro Carvalho Chehab

Em Mon, 11 Mar 2013 21:43:03 +0100
Borislav Petkov  escreveu:

> On Mon, Mar 11, 2013 at 05:08:37PM -0300, Mauro Carvalho Chehab wrote:
> > While this machine is reserved for my usage, do you need a different
> > test on it?
> 
> Yes please. Can you send dmesg and sysfs entries before applying your
> patches?
> 
> Thanks.
> 

Sorry to take a longer time. I had some troubles with the KVM remote access
on that machine.

Those are the logs before the patch:

[   25.948433] EDAC MC: Ver: 3.0.0
[   25.955808] EDAC DEBUG: edac_mc_sysfs_init: device mc created
[   25.981798] AMD64 EDAC driver v3.4.0
[   25.998314] EDAC amd64: DRAM ECC enabled.
[   26.002384] EDAC DEBUG: amd64_nb_mce_bank_enabled_on_node: core: 0, MCG_CTL: 
0x1f, NB MSR is enabled
[   26.002387] EDAC DEBUG: amd64_nb_mce_bank_enabled_on_node: core: 1, MCG_CTL: 
0x1f, NB MSR is enabled
[   26.002410] EDAC amd64: K8 revF or later detected (node 0).
[   26.008122] EDAC DEBUG: reserve_mc_sibling_devs: F1: :00:18.1
[   26.008125] EDAC DEBUG: reserve_mc_sibling_devs: F2: :00:18.2
[   26.008127] EDAC DEBUG: reserve_mc_sibling_devs: F3: :00:18.3
[   26.008130] EDAC DEBUG: read_mc_regs:   TOP_MEM:  0x8000
[   26.008132] EDAC DEBUG: read_mc_regs:   TOP_MEM2 disabled
[   26.008139] EDAC DEBUG: read_mc_regs:   DRAM range[0], base: 
0x; limit: 0x7fff
[   26.008142] EDAC DEBUG: read_mc_regs:IntlvEn=Disabled; Range access: RW 
IntlvSel=0 DstNode=0
[   26.008161] EDAC DEBUG: read_dct_base_mask:   DCSB0[0]=0x0001 reg: F2x40
[   26.008164] EDAC DEBUG: read_dct_base_mask:   DCSB0[1]=0x reg: F2x44
[   26.008168] EDAC DEBUG: read_dct_base_mask:   DCSB0[2]=0x0101 reg: F2x48
[   26.008171] EDAC DEBUG: read_dct_base_mask:   DCSB0[3]=0x reg: F2x4c
[   26.008175] EDAC DEBUG: read_dct_base_mask:   DCSB0[4]=0x reg: F2x50
[   26.008178] EDAC DEBUG: read_dct_base_mask:   DCSB0[5]=0x reg: F2x54
[   26.008182] EDAC DEBUG: read_dct_base_mask:   DCSB0[6]=0x reg: F2x58
[   26.008185] EDAC DEBUG: read_dct_base_mask:   DCSB0[7]=0x reg: F2x5c
[   26.008189] EDAC DEBUG: read_dct_base_mask: DCSM0[0]=0x00783ee0 reg: 
F2x60
[   26.008193] EDAC DEBUG: read_dct_base_mask: DCSM0[1]=0x00783ee0 reg: 
F2x64
[   26.008196] EDAC DEBUG: read_dct_base_mask: DCSM0[2]=0x reg: 
F2x68
[   26.008200] EDAC DEBUG: read_dct_base_mask: DCSM0[3]=0x reg: 
F2x6c
[   26.008208] EDAC DEBUG: dump_misc_regs: F3xE8 (NB Cap): 0x1719
[   26.008210] EDAC DEBUG: dump_misc_regs:   NB two channel DRAM capable: yes
[   26.008212] EDAC DEBUG: dump_misc_regs:   ECC capable: yes, ChipKill ECC 
capable: yes
[   26.008215] EDAC DEBUG: amd64_dump_dramcfg_low: F2x090 (DRAM Cfg Low): 
0x00090c10
[   26.008217] EDAC DEBUG: amd64_dump_dramcfg_low:   DIMM type: unbuffered; all 
DIMMs support ECC: yes
[   26.008220] EDAC DEBUG: amd64_dump_dramcfg_low:   PAR/ERR parity: disabled
[   26.008222] EDAC DEBUG: amd64_dump_dramcfg_low:   x4 logical DIMMs present: 
L0: no L1: no L2: no L3: no
[   26.008224] EDAC DEBUG: dump_misc_regs: F3xB0 (Online Spare): 0x
[   26.008227] EDAC DEBUG: dump_misc_regs: F1xF0 (DRAM Hole Address): 
0x, base: 0x, offset: 0x
[   26.008229] EDAC DEBUG: dump_misc_regs:   DramHoleValid: no
[   26.008232] EDAC DEBUG: amd64_debug_display_dimm_sizes: F2x080 (DRAM Bank 
Address Mapping): 0x0022
[   26.008234] EDAC MC: DCT0 chip selects:
[   26.008236] EDAC amd64: MC: 0:  1024MB 1: 0MB
[   26.012951] EDAC amd64: MC: 2:  1024MB 3: 0MB
[   26.017659] EDAC amd64: MC: 4: 0MB 5: 0MB
[   26.022370] EDAC amd64: MC: 6: 0MB 7: 0MB
[   26.027080] EDAC DEBUG: edac_mc_alloc: allocating 2112 bytes for mci data 
(16 ranks, 16 csrows/channels)
[   26.035885] EDAC DEBUG: init_csrows: node 0, 
NBCFG=0x0ad00044[ChipKillEccCap: 1|DramEccEn: 1]
[   26.035888] EDAC DEBUG: init_csrows: MC node: 0, csrow: 0
[   26.035891] EDAC DEBUG: amd64_csrow_nr_pages: csrow: 0, channel: 0, DBAM 
idx: 2
[   26.035893] EDAC DEBUG: amd64_csrow_nr_pages: nr_pages/channel: 262144
[   26.035895] EDAC amd64: CS0: Unbuffered DDR2 RAM
[   26.040538] EDAC DEBUG: init_csrows: Total csrow0 pages: 262144
[   26.040540] EDAC DEBUG: init_csrows: MC node: 0, csrow: 2
[   26.040543] EDAC DEBUG: amd64_csrow_nr_pages: csrow: 2, channel: 0, DBAM 
idx: 2
[   26.040545] EDAC DEBUG: amd64_csrow_nr_pages: nr_pages/channel: 262144
[   26.040546] EDAC amd64: CS2: Unbuffered DDR2 RAM
[   26.045254] EDAC DEBUG: init_csrows: Total csrow2 pages: 262144
[   26.045257] EDAC DEBUG: edac_mc_add_mc: 
[   26.045452] EDAC DEBUG: edac_create_sysfs_mci_device: creating bus mc0
[   26.046249] EDAC DEBUG: edac_create_sysfs_mci_device: creating device mc0
[   26.047042] EDAC DEBUG: edac_create_sysfs_mci_device: creating dimm0, 
located at csrow 0 channel 0 
[   26.047662] EDAC DEBUG: edac_create_dimm_object: creating rank/dimm device 
rank0
[   26.047665] EDAC DEBUG:

Re: [GIT PULL] EDAC fixes for 3.8

2013-03-12 Thread Mauro Carvalho Chehab

Em Tue, 12 Mar 2013 09:58:55 +0100
Borislav Petkov  escreveu:

> On Mon, Mar 11, 2013 at 09:28:48AM -0300, Mauro Carvalho Chehab wrote:
> > @@ -740,7 +740,6 @@ struct mem_ctl_info {
> > u32 fake_inject_ue;
> > u16 fake_inject_count;
> >  #endif
> > -   __u8 csbased : 1,   /* csrow-based memory controller */
> >  __resv  : 7;
> 
> I don't know how you tested this one, but it doesn't even build. I fixed
> it up though, while applying.

Funny enough, it compiled on one machine. I noticed this issue when
compiling the Fedora kernel and just dropped the __resv field, that it is
not used anywhere. So, on the Fedora 18 Kernel I pointed, I just dropped both
lines.

Regards,
Mauro

> 
> In file included from arch/x86/kernel/nmi.c:23:0:
> include/linux/edac.h:743:7: error: expected specifier-qualifier-list before 
> ‘__resv’
> In file included from arch/x86/kernel/traps.c:44:0:
> include/linux/edac.h:743:7: error: expected specifier-qualifier-list before 
> ‘__resv’
> make[2]: *** [arch/x86/kernel/nmi.o] Error 1
> make[2]: *** Waiting for unfinished jobs
> make[2]: *** [arch/x86/kernel/traps.o] Error 1
> make[1]: *** [arch/x86/kernel] Error 2
> make[1]: *** Waiting for unfinished jobs
> make: *** [arch/x86] Error 2
> make: *** Waiting for unfinished jobs
> In file included from drivers/edac/edac_stub.c:16:0:
> include/linux/edac.h:743:7: error: expected specifier-qualifier-list before 
> ‘__resv’
> make[2]: *** [drivers/edac/edac_stub.o] Error 1
> make[2]: *** Waiting for unfinished jobs
> In file included from drivers/edac/amd64_edac.h:72:0,
>  from drivers/edac/amd64_edac.c:1:
> include/linux/edac.h:743:7: error: expected specifier-qualifier-list before 
> ‘__resv’
> In file included from drivers/edac/amd64_edac.h:72:0,
>  from drivers/edac/amd64_edac_inj.c:1:
> include/linux/edac.h:743:7: error: expected specifier-qualifier-list before 
> ‘__resv’
> make[2]: *** [drivers/edac/amd64_edac_inj.o] Error 1
> make[2]: *** [drivers/edac/amd64_edac.o] Error 1
> make[1]: *** [drivers/edac] Error 2
> make[1]: *** Waiting for unfinished jobs
> make: *** [drivers] Error 2
> 


-- 

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

Re: [GIT PULL] EDAC fixes for 3.8

2013-03-12 Thread Borislav Petkov

Btw,

the first one I changed to not divide by the channel_count, see below.
Now I'll go and run them to check everything's fine.

Thanks.

>From ef11e0b3e22d19f06474ced9365c69a0353f793a Mon Sep 17 00:00:00 2001
From: Mauro Carvalho Chehab 
Date: Mon, 11 Mar 2013 09:07:46 -0300
Subject: [PATCH 1/2] amd64_edac: Correct dimm sizes

We were filling the csrow size with a wrong value. 16a528ee3975 ("EDAC:
Fix csrow size reported in sysfs") tried to address the issue. It fixed
the report with the old API but not with the new one. Correct it for the
new API too.

Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Borislav Petkov 
---
 drivers/edac/amd64_edac.c| 14 +-
 drivers/edac/edac_mc_sysfs.c | 13 +++--
 include/linux/edac.h |  1 -
 3 files changed, 12 insertions(+), 16 deletions(-)

diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
index 910b0116c128..532de775a184 100644
--- a/drivers/edac/amd64_edac.c
+++ b/drivers/edac/amd64_edac.c
@@ -2048,12 +2048,18 @@ static int init_csrows(struct mem_ctl_info *mci)
edac_dbg(1, "MC node: %d, csrow: %d\n",
pvt->mc_node_id, i);
 
-   if (row_dct0)
+   if (row_dct0) {
nr_pages = amd64_csrow_nr_pages(pvt, 0, i);
+   csrow->channels[0]->dimm->nr_pages = nr_pages;
+   }
 
/* K8 has only one DCT */
-   if (boot_cpu_data.x86 != 0xf && row_dct1)
-   nr_pages += amd64_csrow_nr_pages(pvt, 1, i);
+   if (boot_cpu_data.x86 != 0xf && row_dct1) {
+   int row_dct1_pages = amd64_csrow_nr_pages(pvt, 1, i);
+
+   csrow->channels[1]->dimm->nr_pages = row_dct1_pages;
+   nr_pages += row_dct1_pages;
+   }
 
mtype = amd64_determine_memory_type(pvt, i);
 
@@ -2072,9 +2078,7 @@ static int init_csrows(struct mem_ctl_info *mci)
dimm = csrow->channels[j]->dimm;
dimm->mtype = mtype;
dimm->edac_mode = edac_mode;
-   dimm->nr_pages = nr_pages;
}
-   csrow->nr_pages = nr_pages;
}
 
return empty;
diff --git a/drivers/edac/edac_mc_sysfs.c b/drivers/edac/edac_mc_sysfs.c
index 4f4b6137d74e..5463ed3abfec 100644
--- a/drivers/edac/edac_mc_sysfs.c
+++ b/drivers/edac/edac_mc_sysfs.c
@@ -180,9 +180,6 @@ static ssize_t csrow_size_show(struct device *dev,
int i;
u32 nr_pages = 0;
 
-   if (csrow->mci->csbased)
-   return sprintf(data, "%u\n", PAGES_TO_MiB(csrow->nr_pages));
-
for (i = 0; i < csrow->nr_channels; i++)
nr_pages += csrow->channels[i]->dimm->nr_pages;
return sprintf(data, "%u\n", PAGES_TO_MiB(nr_pages));
@@ -778,14 +775,10 @@ static ssize_t mci_size_mb_show(struct device *dev,
for (csrow_idx = 0; csrow_idx < mci->nr_csrows; csrow_idx++) {
struct csrow_info *csrow = mci->csrows[csrow_idx];
 
-   if (csrow->mci->csbased) {
-   total_pages += csrow->nr_pages;
-   } else {
-   for (j = 0; j < csrow->nr_channels; j++) {
-   struct dimm_info *dimm = 
csrow->channels[j]->dimm;
+   for (j = 0; j < csrow->nr_channels; j++) {
+   struct dimm_info *dimm = csrow->channels[j]->dimm;
 
-   total_pages += dimm->nr_pages;
-   }
+   total_pages += dimm->nr_pages;
}
}
 
diff --git a/include/linux/edac.h b/include/linux/edac.h
index 4fd4999ccb5b..ab1ea98e767c 100644
--- a/include/linux/edac.h
+++ b/include/linux/edac.h
@@ -561,7 +561,6 @@ struct csrow_info {
 
u32 ue_count;   /* Uncorrectable Errors for this csrow */
u32 ce_count;   /* Correctable Errors for this csrow */
-   u32 nr_pages;   /* combined pages count of all channels */
 
struct mem_ctl_info *mci;   /* the parent */
 
-- 
1.8.1.3.535.ga923c31


-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] EDAC fixes for 3.8

2013-03-12 Thread Borislav Petkov

On Mon, Mar 11, 2013 at 09:28:48AM -0300, Mauro Carvalho Chehab wrote:
> @@ -740,7 +740,6 @@ struct mem_ctl_info {
>   u32 fake_inject_ue;
>   u16 fake_inject_count;
>  #endif
> - __u8 csbased : 1,   /* csrow-based memory controller */
>__resv  : 7;

I don't know how you tested this one, but it doesn't even build. I fixed
it up though, while applying.

In file included from arch/x86/kernel/nmi.c:23:0:
include/linux/edac.h:743:7: error: expected specifier-qualifier-list before 
‘__resv’
In file included from arch/x86/kernel/traps.c:44:0:
include/linux/edac.h:743:7: error: expected specifier-qualifier-list before 
‘__resv’
make[2]: *** [arch/x86/kernel/nmi.o] Error 1
make[2]: *** Waiting for unfinished jobs
make[2]: *** [arch/x86/kernel/traps.o] Error 1
make[1]: *** [arch/x86/kernel] Error 2
make[1]: *** Waiting for unfinished jobs
make: *** [arch/x86] Error 2
make: *** Waiting for unfinished jobs
In file included from drivers/edac/edac_stub.c:16:0:
include/linux/edac.h:743:7: error: expected specifier-qualifier-list before 
‘__resv’
make[2]: *** [drivers/edac/edac_stub.o] Error 1
make[2]: *** Waiting for unfinished jobs
In file included from drivers/edac/amd64_edac.h:72:0,
 from drivers/edac/amd64_edac.c:1:
include/linux/edac.h:743:7: error: expected specifier-qualifier-list before 
‘__resv’
In file included from drivers/edac/amd64_edac.h:72:0,
 from drivers/edac/amd64_edac_inj.c:1:
include/linux/edac.h:743:7: error: expected specifier-qualifier-list before 
‘__resv’
make[2]: *** [drivers/edac/amd64_edac_inj.o] Error 1
make[2]: *** [drivers/edac/amd64_edac.o] Error 1
make[1]: *** [drivers/edac] Error 2
make[1]: *** Waiting for unfinished jobs
make: *** [drivers] Error 2

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] EDAC fixes for 3.8

2013-03-12 Thread Borislav Petkov

On Mon, Mar 11, 2013 at 09:28:48AM -0300, Mauro Carvalho Chehab wrote:
 @@ -740,7 +740,6 @@ struct mem_ctl_info {
   u32 fake_inject_ue;
   u16 fake_inject_count;
  #endif
 - __u8 csbased : 1,   /* csrow-based memory controller */
__resv  : 7;

I don't know how you tested this one, but it doesn't even build. I fixed
it up though, while applying.

In file included from arch/x86/kernel/nmi.c:23:0:
include/linux/edac.h:743:7: error: expected specifier-qualifier-list before 
‘__resv’
In file included from arch/x86/kernel/traps.c:44:0:
include/linux/edac.h:743:7: error: expected specifier-qualifier-list before 
‘__resv’
make[2]: *** [arch/x86/kernel/nmi.o] Error 1
make[2]: *** Waiting for unfinished jobs
make[2]: *** [arch/x86/kernel/traps.o] Error 1
make[1]: *** [arch/x86/kernel] Error 2
make[1]: *** Waiting for unfinished jobs
make: *** [arch/x86] Error 2
make: *** Waiting for unfinished jobs
In file included from drivers/edac/edac_stub.c:16:0:
include/linux/edac.h:743:7: error: expected specifier-qualifier-list before 
‘__resv’
make[2]: *** [drivers/edac/edac_stub.o] Error 1
make[2]: *** Waiting for unfinished jobs
In file included from drivers/edac/amd64_edac.h:72:0,
 from drivers/edac/amd64_edac.c:1:
include/linux/edac.h:743:7: error: expected specifier-qualifier-list before 
‘__resv’
In file included from drivers/edac/amd64_edac.h:72:0,
 from drivers/edac/amd64_edac_inj.c:1:
include/linux/edac.h:743:7: error: expected specifier-qualifier-list before 
‘__resv’
make[2]: *** [drivers/edac/amd64_edac_inj.o] Error 1
make[2]: *** [drivers/edac/amd64_edac.o] Error 1
make[1]: *** [drivers/edac] Error 2
make[1]: *** Waiting for unfinished jobs
make: *** [drivers] Error 2

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] EDAC fixes for 3.8

2013-03-12 Thread Borislav Petkov

Btw,

the first one I changed to not divide by the channel_count, see below.
Now I'll go and run them to check everything's fine.

Thanks.

From ef11e0b3e22d19f06474ced9365c69a0353f793a Mon Sep 17 00:00:00 2001
From: Mauro Carvalho Chehab mche...@redhat.com
Date: Mon, 11 Mar 2013 09:07:46 -0300
Subject: [PATCH 1/2] amd64_edac: Correct dimm sizes

We were filling the csrow size with a wrong value. 16a528ee3975 (EDAC:
Fix csrow size reported in sysfs) tried to address the issue. It fixed
the report with the old API but not with the new one. Correct it for the
new API too.

Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
Signed-off-by: Borislav Petkov b...@suse.de
---
 drivers/edac/amd64_edac.c| 14 +-
 drivers/edac/edac_mc_sysfs.c | 13 +++--
 include/linux/edac.h |  1 -
 3 files changed, 12 insertions(+), 16 deletions(-)

diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
index 910b0116c128..532de775a184 100644
--- a/drivers/edac/amd64_edac.c
+++ b/drivers/edac/amd64_edac.c
@@ -2048,12 +2048,18 @@ static int init_csrows(struct mem_ctl_info *mci)
edac_dbg(1, MC node: %d, csrow: %d\n,
pvt-mc_node_id, i);
 
-   if (row_dct0)
+   if (row_dct0) {
nr_pages = amd64_csrow_nr_pages(pvt, 0, i);
+   csrow-channels[0]-dimm-nr_pages = nr_pages;
+   }
 
/* K8 has only one DCT */
-   if (boot_cpu_data.x86 != 0xf  row_dct1)
-   nr_pages += amd64_csrow_nr_pages(pvt, 1, i);
+   if (boot_cpu_data.x86 != 0xf  row_dct1) {
+   int row_dct1_pages = amd64_csrow_nr_pages(pvt, 1, i);
+
+   csrow-channels[1]-dimm-nr_pages = row_dct1_pages;
+   nr_pages += row_dct1_pages;
+   }
 
mtype = amd64_determine_memory_type(pvt, i);
 
@@ -2072,9 +2078,7 @@ static int init_csrows(struct mem_ctl_info *mci)
dimm = csrow-channels[j]-dimm;
dimm-mtype = mtype;
dimm-edac_mode = edac_mode;
-   dimm-nr_pages = nr_pages;
}
-   csrow-nr_pages = nr_pages;
}
 
return empty;
diff --git a/drivers/edac/edac_mc_sysfs.c b/drivers/edac/edac_mc_sysfs.c
index 4f4b6137d74e..5463ed3abfec 100644
--- a/drivers/edac/edac_mc_sysfs.c
+++ b/drivers/edac/edac_mc_sysfs.c
@@ -180,9 +180,6 @@ static ssize_t csrow_size_show(struct device *dev,
int i;
u32 nr_pages = 0;
 
-   if (csrow-mci-csbased)
-   return sprintf(data, %u\n, PAGES_TO_MiB(csrow-nr_pages));
-
for (i = 0; i  csrow-nr_channels; i++)
nr_pages += csrow-channels[i]-dimm-nr_pages;
return sprintf(data, %u\n, PAGES_TO_MiB(nr_pages));
@@ -778,14 +775,10 @@ static ssize_t mci_size_mb_show(struct device *dev,
for (csrow_idx = 0; csrow_idx  mci-nr_csrows; csrow_idx++) {
struct csrow_info *csrow = mci-csrows[csrow_idx];
 
-   if (csrow-mci-csbased) {
-   total_pages += csrow-nr_pages;
-   } else {
-   for (j = 0; j  csrow-nr_channels; j++) {
-   struct dimm_info *dimm = 
csrow-channels[j]-dimm;
+   for (j = 0; j  csrow-nr_channels; j++) {
+   struct dimm_info *dimm = csrow-channels[j]-dimm;
 
-   total_pages += dimm-nr_pages;
-   }
+   total_pages += dimm-nr_pages;
}
}
 
diff --git a/include/linux/edac.h b/include/linux/edac.h
index 4fd4999ccb5b..ab1ea98e767c 100644
--- a/include/linux/edac.h
+++ b/include/linux/edac.h
@@ -561,7 +561,6 @@ struct csrow_info {
 
u32 ue_count;   /* Uncorrectable Errors for this csrow */
u32 ce_count;   /* Correctable Errors for this csrow */
-   u32 nr_pages;   /* combined pages count of all channels */
 
struct mem_ctl_info *mci;   /* the parent */
 
-- 
1.8.1.3.535.ga923c31


-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] EDAC fixes for 3.8

2013-03-12 Thread Mauro Carvalho Chehab

Em Tue, 12 Mar 2013 09:58:55 +0100
Borislav Petkov b...@alien8.de escreveu:

 On Mon, Mar 11, 2013 at 09:28:48AM -0300, Mauro Carvalho Chehab wrote:
  @@ -740,7 +740,6 @@ struct mem_ctl_info {
  u32 fake_inject_ue;
  u16 fake_inject_count;
   #endif
  -   __u8 csbased : 1,   /* csrow-based memory controller */
   __resv  : 7;
 
 I don't know how you tested this one, but it doesn't even build. I fixed
 it up though, while applying.

Funny enough, it compiled on one machine. I noticed this issue when
compiling the Fedora kernel and just dropped the __resv field, that it is
not used anywhere. So, on the Fedora 18 Kernel I pointed, I just dropped both
lines.

Regards,
Mauro

 
 In file included from arch/x86/kernel/nmi.c:23:0:
 include/linux/edac.h:743:7: error: expected specifier-qualifier-list before 
 ‘__resv’
 In file included from arch/x86/kernel/traps.c:44:0:
 include/linux/edac.h:743:7: error: expected specifier-qualifier-list before 
 ‘__resv’
 make[2]: *** [arch/x86/kernel/nmi.o] Error 1
 make[2]: *** Waiting for unfinished jobs
 make[2]: *** [arch/x86/kernel/traps.o] Error 1
 make[1]: *** [arch/x86/kernel] Error 2
 make[1]: *** Waiting for unfinished jobs
 make: *** [arch/x86] Error 2
 make: *** Waiting for unfinished jobs
 In file included from drivers/edac/edac_stub.c:16:0:
 include/linux/edac.h:743:7: error: expected specifier-qualifier-list before 
 ‘__resv’
 make[2]: *** [drivers/edac/edac_stub.o] Error 1
 make[2]: *** Waiting for unfinished jobs
 In file included from drivers/edac/amd64_edac.h:72:0,
  from drivers/edac/amd64_edac.c:1:
 include/linux/edac.h:743:7: error: expected specifier-qualifier-list before 
 ‘__resv’
 In file included from drivers/edac/amd64_edac.h:72:0,
  from drivers/edac/amd64_edac_inj.c:1:
 include/linux/edac.h:743:7: error: expected specifier-qualifier-list before 
 ‘__resv’
 make[2]: *** [drivers/edac/amd64_edac_inj.o] Error 1
 make[2]: *** [drivers/edac/amd64_edac.o] Error 1
 make[1]: *** [drivers/edac] Error 2
 make[1]: *** Waiting for unfinished jobs
 make: *** [drivers] Error 2
 


-- 

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

Re: [GIT PULL] EDAC fixes for 3.8

2013-03-12 Thread Mauro Carvalho Chehab

Em Mon, 11 Mar 2013 21:43:03 +0100
Borislav Petkov b...@alien8.de escreveu:

 On Mon, Mar 11, 2013 at 05:08:37PM -0300, Mauro Carvalho Chehab wrote:
  While this machine is reserved for my usage, do you need a different
  test on it?
 
 Yes please. Can you send dmesg and sysfs entries before applying your
 patches?
 
 Thanks.
 

Sorry to take a longer time. I had some troubles with the KVM remote access
on that machine.

Those are the logs before the patch:

[   25.948433] EDAC MC: Ver: 3.0.0
[   25.955808] EDAC DEBUG: edac_mc_sysfs_init: device mc created
[   25.981798] AMD64 EDAC driver v3.4.0
[   25.998314] EDAC amd64: DRAM ECC enabled.
[   26.002384] EDAC DEBUG: amd64_nb_mce_bank_enabled_on_node: core: 0, MCG_CTL: 
0x1f, NB MSR is enabled
[   26.002387] EDAC DEBUG: amd64_nb_mce_bank_enabled_on_node: core: 1, MCG_CTL: 
0x1f, NB MSR is enabled
[   26.002410] EDAC amd64: K8 revF or later detected (node 0).
[   26.008122] EDAC DEBUG: reserve_mc_sibling_devs: F1: :00:18.1
[   26.008125] EDAC DEBUG: reserve_mc_sibling_devs: F2: :00:18.2
[   26.008127] EDAC DEBUG: reserve_mc_sibling_devs: F3: :00:18.3
[   26.008130] EDAC DEBUG: read_mc_regs:   TOP_MEM:  0x8000
[   26.008132] EDAC DEBUG: read_mc_regs:   TOP_MEM2 disabled
[   26.008139] EDAC DEBUG: read_mc_regs:   DRAM range[0], base: 
0x; limit: 0x7fff
[   26.008142] EDAC DEBUG: read_mc_regs:IntlvEn=Disabled; Range access: RW 
IntlvSel=0 DstNode=0
[   26.008161] EDAC DEBUG: read_dct_base_mask:   DCSB0[0]=0x0001 reg: F2x40
[   26.008164] EDAC DEBUG: read_dct_base_mask:   DCSB0[1]=0x reg: F2x44
[   26.008168] EDAC DEBUG: read_dct_base_mask:   DCSB0[2]=0x0101 reg: F2x48
[   26.008171] EDAC DEBUG: read_dct_base_mask:   DCSB0[3]=0x reg: F2x4c
[   26.008175] EDAC DEBUG: read_dct_base_mask:   DCSB0[4]=0x reg: F2x50
[   26.008178] EDAC DEBUG: read_dct_base_mask:   DCSB0[5]=0x reg: F2x54
[   26.008182] EDAC DEBUG: read_dct_base_mask:   DCSB0[6]=0x reg: F2x58
[   26.008185] EDAC DEBUG: read_dct_base_mask:   DCSB0[7]=0x reg: F2x5c
[   26.008189] EDAC DEBUG: read_dct_base_mask: DCSM0[0]=0x00783ee0 reg: 
F2x60
[   26.008193] EDAC DEBUG: read_dct_base_mask: DCSM0[1]=0x00783ee0 reg: 
F2x64
[   26.008196] EDAC DEBUG: read_dct_base_mask: DCSM0[2]=0x reg: 
F2x68
[   26.008200] EDAC DEBUG: read_dct_base_mask: DCSM0[3]=0x reg: 
F2x6c
[   26.008208] EDAC DEBUG: dump_misc_regs: F3xE8 (NB Cap): 0x1719
[   26.008210] EDAC DEBUG: dump_misc_regs:   NB two channel DRAM capable: yes
[   26.008212] EDAC DEBUG: dump_misc_regs:   ECC capable: yes, ChipKill ECC 
capable: yes
[   26.008215] EDAC DEBUG: amd64_dump_dramcfg_low: F2x090 (DRAM Cfg Low): 
0x00090c10
[   26.008217] EDAC DEBUG: amd64_dump_dramcfg_low:   DIMM type: unbuffered; all 
DIMMs support ECC: yes
[   26.008220] EDAC DEBUG: amd64_dump_dramcfg_low:   PAR/ERR parity: disabled
[   26.008222] EDAC DEBUG: amd64_dump_dramcfg_low:   x4 logical DIMMs present: 
L0: no L1: no L2: no L3: no
[   26.008224] EDAC DEBUG: dump_misc_regs: F3xB0 (Online Spare): 0x
[   26.008227] EDAC DEBUG: dump_misc_regs: F1xF0 (DRAM Hole Address): 
0x, base: 0x, offset: 0x
[   26.008229] EDAC DEBUG: dump_misc_regs:   DramHoleValid: no
[   26.008232] EDAC DEBUG: amd64_debug_display_dimm_sizes: F2x080 (DRAM Bank 
Address Mapping): 0x0022
[   26.008234] EDAC MC: DCT0 chip selects:
[   26.008236] EDAC amd64: MC: 0:  1024MB 1: 0MB
[   26.012951] EDAC amd64: MC: 2:  1024MB 3: 0MB
[   26.017659] EDAC amd64: MC: 4: 0MB 5: 0MB
[   26.022370] EDAC amd64: MC: 6: 0MB 7: 0MB
[   26.027080] EDAC DEBUG: edac_mc_alloc: allocating 2112 bytes for mci data 
(16 ranks, 16 csrows/channels)
[   26.035885] EDAC DEBUG: init_csrows: node 0, 
NBCFG=0x0ad00044[ChipKillEccCap: 1|DramEccEn: 1]
[   26.035888] EDAC DEBUG: init_csrows: MC node: 0, csrow: 0
[   26.035891] EDAC DEBUG: amd64_csrow_nr_pages: csrow: 0, channel: 0, DBAM 
idx: 2
[   26.035893] EDAC DEBUG: amd64_csrow_nr_pages: nr_pages/channel: 262144
[   26.035895] EDAC amd64: CS0: Unbuffered DDR2 RAM
[   26.040538] EDAC DEBUG: init_csrows: Total csrow0 pages: 262144
[   26.040540] EDAC DEBUG: init_csrows: MC node: 0, csrow: 2
[   26.040543] EDAC DEBUG: amd64_csrow_nr_pages: csrow: 2, channel: 0, DBAM 
idx: 2
[   26.040545] EDAC DEBUG: amd64_csrow_nr_pages: nr_pages/channel: 262144
[   26.040546] EDAC amd64: CS2: Unbuffered DDR2 RAM
[   26.045254] EDAC DEBUG: init_csrows: Total csrow2 pages: 262144
[   26.045257] EDAC DEBUG: edac_mc_add_mc: 
[   26.045452] EDAC DEBUG: edac_create_sysfs_mci_device: creating bus mc0
[   26.046249] EDAC DEBUG: edac_create_sysfs_mci_device: creating device mc0
[   26.047042] EDAC DEBUG: edac_create_sysfs_mci_device: creating dimm0, 
located at csrow 0 channel 0 
[   26.047662] EDAC DEBUG: edac_create_dimm_object: creating rank/dimm device 
rank0
[   26.047665] EDAC DEBUG:

Re: [GIT PULL] EDAC fixes for 3.8

2013-03-12 Thread Mauro Carvalho Chehab

Em Tue, 12 Mar 2013 10:16:30 +0100
Borislav Petkov b...@alien8.de escreveu:

 Btw,
 
 the first one I changed to not divide by the channel_count, see below.
 Now I'll go and run them to check everything's fine.

Looks ok on my eyes. I'll test it here on both systems, with both this
patch and the second one:

http://git.infradead.org/users/mchehab/edac.git/commitdiff/56ba4c93d909ef9dfab4f1101a8c3bf75bc4cdab

It should take some time to finish compilation.

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

Re: [GIT PULL] EDAC fixes for 3.8

2013-03-12 Thread Borislav Petkov

On Tue, Mar 12, 2013 at 08:34:48AM -0300, Mauro Carvalho Chehab wrote:
 Looks ok on my eyes. I'll test it here on both systems, with both this
 patch and the second one:
 
 http://git.infradead.org/users/mchehab/edac.git/commitdiff/56ba4c93d909ef9dfab4f1101a8c3bf75bc4cdab
 
 It should take some time to finish compilation.

No hurry, I'd need to finish testing them and if all is fine, will send
them upstream next week, the latest.

Thanks.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] EDAC fixes for 3.8

2013-03-12 Thread Mauro Carvalho Chehab

Em Tue, 12 Mar 2013 12:56:32 +0100
Borislav Petkov b...@alien8.de escreveu:

 On Tue, Mar 12, 2013 at 08:34:48AM -0300, Mauro Carvalho Chehab wrote:
  Looks ok on my eyes. I'll test it here on both systems, with both this
  patch and the second one:
  
  http://git.infradead.org/users/mchehab/edac.git/commitdiff/56ba4c93d909ef9dfab4f1101a8c3bf75bc4cdab
  
  It should take some time to finish compilation.
 
 No hurry, I'd need to finish testing them and if all is fine, will send
 them upstream next week, the latest.

Ok. Anyway, x86_64 compilation finished. Just re-did the tests on both
machines:

Here are the tests with the modified version of the patch applied, on the
machine equipped with quad-rank RAMs:

/sys/devices/system/edac/mc/mc0/size_mb:8192
/sys/devices/system/edac/mc/mc0/csrow2/size_mb:2048
/sys/devices/system/edac/mc/mc0/csrow3/size_mb:2048
/sys/devices/system/edac/mc/mc0/csrow6/size_mb:2048
/sys/devices/system/edac/mc/mc0/csrow7/size_mb:2048

/sys/devices/system/edac/mc/mc1/size_mb:8192
/sys/devices/system/edac/mc/mc1/csrow2/size_mb:2048
/sys/devices/system/edac/mc/mc1/csrow3/size_mb:2048
/sys/devices/system/edac/mc/mc1/csrow6/size_mb:2048
/sys/devices/system/edac/mc/mc1/csrow7/size_mb:2048

/sys/devices/system/edac/mc/mc0/rank4/size:1024
/sys/devices/system/edac/mc/mc0/rank5/size:1024
/sys/devices/system/edac/mc/mc0/rank6/size:1024
/sys/devices/system/edac/mc/mc0/rank7/size:1024
/sys/devices/system/edac/mc/mc0/rank12/size:1024
/sys/devices/system/edac/mc/mc0/rank13/size:1024
/sys/devices/system/edac/mc/mc0/rank14/size:1024
/sys/devices/system/edac/mc/mc0/rank15/size:1024
/sys/devices/system/edac/mc/mc1/rank4/size:1024
/sys/devices/system/edac/mc/mc1/rank5/size:1024
/sys/devices/system/edac/mc/mc1/rank6/size:1024
/sys/devices/system/edac/mc/mc1/rank7/size:1024
/sys/devices/system/edac/mc/mc1/rank12/size:1024
/sys/devices/system/edac/mc/mc1/rank13/size:1024
/sys/devices/system/edac/mc/mc1/rank14/size:1024
/sys/devices/system/edac/mc/mc1/rank15/size:1024

[0.00] Linux version 3.8.2-209.fc18.x86_64.debug 
(mockbu...@buildvm-04.phx2.fedoraproject.org) (gcc version 4.7.2 20121109 (Red 
Hat 4.7.2-8) (GCC) ) #1 SMP Tue Mar 12 11:37:54 UTC 2013

[   33.321105] EDAC MC: Ver: 3.0.0
[   33.325269] EDAC DEBUG: edac_mc_sysfs_init: device mc created
[   33.630374] AMD64 EDAC driver v3.4.0
[   33.634117] EDAC amd64: DRAM ECC enabled.
[   33.638170] EDAC DEBUG: amd64_nb_mce_bank_enabled_on_node: core: 0, MCG_CTL: 
0x3f, NB MSR is enabled
[   33.638174] EDAC DEBUG: amd64_nb_mce_bank_enabled_on_node: core: 2, MCG_CTL: 
0x3f, NB MSR is enabled
[   33.638177] EDAC DEBUG: amd64_nb_mce_bank_enabled_on_node: core: 3, MCG_CTL: 
0x3f, NB MSR is enabled
[   33.638180] EDAC DEBUG: amd64_nb_mce_bank_enabled_on_node: core: 4, MCG_CTL: 
0x3f, NB MSR is enabled
[   33.638183] EDAC DEBUG: amd64_nb_mce_bank_enabled_on_node: core: 5, MCG_CTL: 
0x3f, NB MSR is enabled
[   33.638186] EDAC DEBUG: amd64_nb_mce_bank_enabled_on_node: core: 6, MCG_CTL: 
0x3f, NB MSR is enabled
[   33.638203] EDAC amd64: F10h detected (node 0).
[   33.642795] EDAC DEBUG: reserve_mc_sibling_devs: F1: :00:18.1
[   33.642797] EDAC DEBUG: reserve_mc_sibling_devs: F2: :00:18.2
[   33.642800] EDAC DEBUG: reserve_mc_sibling_devs: F3: :00:18.3
[   33.642804] EDAC DEBUG: read_mc_regs:   TOP_MEM:  0xe000
[   33.642807] EDAC DEBUG: read_mc_regs:   TOP_MEM2: 0x00042000
[   33.642813] EDAC DEBUG: read_dram_ctl_register: F2x110 (DCTSelLow): 
0x05e4, High range addrs at: 0x0
[   33.642816] EDAC DEBUG: read_dram_ctl_register:   DCTs operate in unganged 
mode
[   33.642818] EDAC DEBUG: read_dram_ctl_register:   Address range split per 
DCT: no
[   33.642821] EDAC DEBUG: read_dram_ctl_register:   data interleave for ECC: 
enabled, DRAM cleared since last warm reset: yes
[   33.642824] EDAC DEBUG: read_dram_ctl_register:   channel interleave: 
enabled, interleave bits selector: 0x3
[   33.642835] EDAC DEBUG: read_mc_regs:   DRAM range[0], base: 
0x; limit: 0x00021fff
[   33.642839] EDAC DEBUG: read_mc_regs:IntlvEn=Disabled; Range access: RW 
IntlvSel=0 DstNode=0
[   33.642845] EDAC DEBUG: read_mc_regs:   DRAM range[1], base: 
0x00022000; limit: 0x00041fff
[   33.642849] EDAC DEBUG: read_mc_regs:IntlvEn=Disabled; Range access: RW 
IntlvSel=0 DstNode=1
[   33.642860] EDAC DEBUG: read_dct_base_mask:   DCSB0[0]=0x reg: F2x40
[   33.642863] EDAC DEBUG: read_dct_base_mask:   DCSB1[0]=0x reg: F2x140
[   33.642867] EDAC DEBUG: read_dct_base_mask:   DCSB0[1]=0x reg: F2x44
[   33.642871] EDAC DEBUG: read_dct_base_mask:   DCSB1[1]=0x reg: F2x144
[   33.642874] EDAC DEBUG: read_dct_base_mask:   DCSB0[2]=0x0001 reg: F2x48
[   33.642877] EDAC DEBUG: read_dct_base_mask:   DCSB1[2]=0x0001 reg: F2x148
[   33.642880] EDAC DEBUG: read_dct_base_mask:   DCSB0[3]=0x0101 reg: F2x4c
[   33.642883] EDAC DEBUG: read_dct_base_mask:   DCSB1[3]=0x0101 reg:

Re: [GIT PULL] EDAC fixes for 3.8

2013-03-11 Thread Borislav Petkov

On Mon, Mar 11, 2013 at 05:08:37PM -0300, Mauro Carvalho Chehab wrote:
> While this machine is reserved for my usage, do you need a different
> test on it?

Yes please. Can you send dmesg and sysfs entries before applying your
patches?

Thanks.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] EDAC fixes for 3.8

2013-03-11 Thread Mauro Carvalho Chehab

Hi Boris,

Em Mon, 11 Mar 2013 15:31:38 +0100
Borislav Petkov  escreveu:

> On Mon, Mar 11, 2013 at 11:12:15AM -0300, Mauro Carvalho Chehab wrote:
> > Ok, I'll test it on a K8 box at RH.
> >
> > The bug seems to be on K8 rev F, right? Is there a different PCI ID on
> > those machines? That would help me to quickly find such machine on at
> > RH labs.
> 
> K8 revF should be a good choice, yes. Anything with model >= 40 in
> /proc/cpuinfo.

Tests done and it looks alright.

I've applied this Fedora18 Kernel with the patches applied on it:

http://koji.fedoraproject.org/koji/taskinfo?taskID=5107290

The machine I took is an HP xw4550, using a dual-core CPU, with those
CPU info:

vendor_id   : AuthenticAMD
cpu family  : 15
model   : 67
model name  : Dual-Core AMD Opteron(tm) Processor 1214 HE
stepping: 3
microcode   : 0x6d

The EDAC dmesg is:

[   26.763384] EDAC MC: Ver: 3.0.0
[   26.769214] EDAC DEBUG: edac_mc_sysfs_init: device mc created
[   26.803556] AMD64 EDAC driver v3.4.0
[   26.807289] EDAC amd64: DRAM ECC enabled.
[   26.811379] EDAC DEBUG: amd64_nb_mce_bank_enabled_on_node: core: 0, MCG_CTL: 
0x1f, NB MSR is enabled
[   26.811382] EDAC DEBUG: amd64_nb_mce_bank_enabled_on_node: core: 1, MCG_CTL: 
0x1f, NB MSR is enabled
[   26.811393] EDAC amd64: K8 revF or later detected (node 0).
[   26.816973] EDAC DEBUG: reserve_mc_sibling_devs: F1: :00:18.1
[   26.816975] EDAC DEBUG: reserve_mc_sibling_devs: F2: :00:18.2
[   26.816977] EDAC DEBUG: reserve_mc_sibling_devs: F3: :00:18.3
[   26.816980] EDAC DEBUG: read_mc_regs:   TOP_MEM:  0x8000
[   26.816982] EDAC DEBUG: read_mc_regs:   TOP_MEM2 disabled
[   26.816986] EDAC DEBUG: read_mc_regs:   DRAM range[0], base: 
0x; limit: 0x7fff
[   26.816989] EDAC DEBUG: read_mc_regs:IntlvEn=Disabled; Range access: RW 
IntlvSel=0 DstNode=0
[   26.816998] EDAC DEBUG: read_dct_base_mask:   DCSB0[0]=0x0001 reg: F2x40
[   26.817001] EDAC DEBUG: read_dct_base_mask:   DCSB0[1]=0x reg: F2x44
[   26.817019] EDAC DEBUG: read_dct_base_mask:   DCSB0[2]=0x0101 reg: F2x48
[   26.817022] EDAC DEBUG: read_dct_base_mask:   DCSB0[3]=0x reg: F2x4c
[   26.817026] EDAC DEBUG: read_dct_base_mask:   DCSB0[4]=0x reg: F2x50
[   26.817030] EDAC DEBUG: read_dct_base_mask:   DCSB0[5]=0x reg: F2x54
[   26.817035] EDAC DEBUG: read_dct_base_mask:   DCSB0[6]=0x reg: F2x58
[   26.817038] EDAC DEBUG: read_dct_base_mask:   DCSB0[7]=0x reg: F2x5c
[   26.817041] EDAC DEBUG: read_dct_base_mask: DCSM0[0]=0x00783ee0 reg: 
F2x60
[   26.817044] EDAC DEBUG: read_dct_base_mask: DCSM0[1]=0x00783ee0 reg: 
F2x64
[   26.817046] EDAC DEBUG: read_dct_base_mask: DCSM0[2]=0x reg: 
F2x68
[   26.817049] EDAC DEBUG: read_dct_base_mask: DCSM0[3]=0x reg: 
F2x6c
[   26.817055] EDAC DEBUG: dump_misc_regs: F3xE8 (NB Cap): 0x1719
[   26.817057] EDAC DEBUG: dump_misc_regs:   NB two channel DRAM capable: yes
[   26.817059] EDAC DEBUG: dump_misc_regs:   ECC capable: yes, ChipKill ECC 
capable: yes
[   26.817061] EDAC DEBUG: amd64_dump_dramcfg_low: F2x090 (DRAM Cfg Low): 
0x00090c10
[   26.817064] EDAC DEBUG: amd64_dump_dramcfg_low:   DIMM type: unbuffered; all 
DIMMs support ECC: yes
[   26.817066] EDAC DEBUG: amd64_dump_dramcfg_low:   PAR/ERR parity: disabled
[   26.817068] EDAC DEBUG: amd64_dump_dramcfg_low:   x4 logical DIMMs present: 
L0: no L1: no L2: no L3: no
[   26.817071] EDAC DEBUG: dump_misc_regs: F3xB0 (Online Spare): 0x
[   26.817073] EDAC DEBUG: dump_misc_regs: F1xF0 (DRAM Hole Address): 
0x, base: 0x, offset: 0x
[   26.817075] EDAC DEBUG: dump_misc_regs:   DramHoleValid: no
[   26.817078] EDAC DEBUG: amd64_debug_display_dimm_sizes: F2x080 (DRAM Bank 
Address Mapping): 0x0022
[   26.817080] EDAC MC: DCT0 chip selects:
[   26.817083] EDAC amd64: MC: 0:  1024MB 1: 0MB
[   26.821788] EDAC amd64: MC: 2:  1024MB 3: 0MB
[   26.826489] EDAC amd64: MC: 4: 0MB 5: 0MB
[   26.831187] EDAC amd64: MC: 6: 0MB 7: 0MB
[   26.835887] EDAC DEBUG: edac_mc_alloc: allocating 2112 bytes for mci data 
(16 ranks, 16 csrows/channels)
[   26.836348] EDAC DEBUG: init_csrows: node 0, 
NBCFG=0x0ad00044[ChipKillEccCap: 1|DramEccEn: 1]
[   26.836351] EDAC DEBUG: init_csrows: MC node: 0, csrow: 0
[   26.836353] EDAC DEBUG: amd64_csrow_nr_pages: csrow: 0, channel: 0, DBAM 
idx: 2
[   26.836356] EDAC DEBUG: amd64_csrow_nr_pages: nr_pages/channel: 262144
[   26.836358] EDAC amd64: CS0: Unbuffered DDR2 RAM
[   26.840973] EDAC DEBUG: init_csrows: Total csrow0 pages: 262144
[   26.840976] EDAC DEBUG: init_csrows: MC node: 0, csrow: 2
[   26.840981] EDAC DEBUG: amd64_csrow_nr_pages: csrow: 2, channel: 0, DBAM 
idx: 2
[   26.840982] EDAC DEBUG: amd64_csrow_nr_pages: nr_pages/channel: 262144
[   26.840984] EDAC amd64: CS2: Unbuffered DDR2 RAM
[   26.845600] EDAC DEBUG: init_csrows: Total csrow2 pages: 262144
[

Re: [GIT PULL] EDAC fixes for 3.8

2013-03-11 Thread Borislav Petkov

On Mon, Mar 11, 2013 at 11:12:15AM -0300, Mauro Carvalho Chehab wrote:
> Ok, I'll test it on a K8 box at RH.
>
> The bug seems to be on K8 rev F, right? Is there a different PCI ID on
> those machines? That would help me to quickly find such machine on at
> RH labs.

K8 revF should be a good choice, yes. Anything with model >= 40 in
/proc/cpuinfo.

Thanks.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] EDAC fixes for 3.8

2013-03-11 Thread Mauro Carvalho Chehab

Em Mon, 11 Mar 2013 14:48:14 +0100
Borislav Petkov  escreveu:

> On Mon, Mar 11, 2013 at 09:28:48AM -0300, Mauro Carvalho Chehab wrote:
> > With this patch, mci->csbased field got unused. So, it makes sense to
> > also remove it. The enclosed patch does that.
> 
> AFAIR, this whole fixing was done for K8 as reported by Josh Hunt from
> Akamai: http://marc.info/?l=linux-edac=134740440610678 (the whole
> thread contains the discussion).
> 
> So, before we go and change anything in amd64_edac, we need to test
> those on a K8 box. Now, I need ot find one but it would be good if you
> could find one too at RH and test the patches on it before we continue
> with this.

Ok, I'll test it on a K8 box at RH. 

The bug seems to be on K8 rev F, right? Is there a different PCI ID on those
machines? That would help me to quickly find such machine on at RH labs.

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

Re: [GIT PULL] EDAC fixes for 3.8

2013-03-11 Thread Borislav Petkov

On Mon, Mar 11, 2013 at 09:28:48AM -0300, Mauro Carvalho Chehab wrote:
> With this patch, mci->csbased field got unused. So, it makes sense to
> also remove it. The enclosed patch does that.

AFAIR, this whole fixing was done for K8 as reported by Josh Hunt from
Akamai: http://marc.info/?l=linux-edac=134740440610678 (the whole
thread contains the discussion).

So, before we go and change anything in amd64_edac, we need to test
those on a K8 box. Now, I need ot find one but it would be good if you
could find one too at RH and test the patches on it before we continue
with this.

Thanks.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] EDAC fixes for 3.8

2013-03-11 Thread Mauro Carvalho Chehab

Em Mon, 11 Mar 2013 09:07:46 -0300
Mauro Carvalho Chehab  escreveu:

> Em Sat, 9 Mar 2013 16:46:35 +0100
> Borislav Petkov  escreveu:
> 
> > On Thu, Mar 07, 2013 at 11:02:13AM -0300, Mauro Carvalho Chehab wrote:
> > > Sure. See below:
> > > 

...

> > So, actually to satisfy the new api, you'll probably need to stick down
> > this information above, i.e. the chip selects *per* DCT which equals
> > also the ranks.
> > 
> 
> Yes. Basically, we should revert this patchset:
>   commit 16a528ee3975c860dc93fbfc718fe9aa25ed92bc
>   Author: Borislav Petkov 
>   Date:   Thu Sep 13 18:53:58 2012 +0200
> 
> And fill dimm->nr_pages with:
> 
>   dimm->nr_pages = nr_pages / pvt->channel_count;
> 
> This way, both new API and the old API will reflect the right size.
> 
> The patch below does that.

...

> [PATCH] Fix dimm size on amd64_edac
> 
...
> --- a/drivers/edac/edac_mc_sysfs.c
> +++ b/drivers/edac/edac_mc_sysfs.c
> @@ -180,9 +180,6 @@ static ssize_t csrow_size_show(struct device *dev,
>   int i;
>   u32 nr_pages = 0;
>  
> - if (csrow->mci->csbased)
> - return sprintf(data, "%u\n", PAGES_TO_MiB(csrow->nr_pages));
> -

With this patch, mci->csbased field got unused. So, it makes sense to
also remove it. The enclosed patch does that.

Regards,
Mauro

-

[PATCH] edac: merge mci.mem_is_per_rank with mci.csbased

Both mci.mem_is_per_rank and mci.csbased have the same meaning:
the memory controller is csrows based. Merge both fields into one.

There's no need for the driver to actually fill it, as the core
detectsi it by checking if one of the layes has the csrows type
as part of the memory hierarchy:

if (layers[i].type == EDAC_MC_LAYER_CHIP_SELECT)
per_rank = true;
...
mci->csbased = per_rank;

Signed-off-by: Mauro Carvalho Chehab 

diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
index 074657d..06e633a 100644
--- a/drivers/edac/amd64_edac.c
+++ b/drivers/edac/amd64_edac.c
@@ -2418,7 +2418,6 @@ static int amd64_init_one_instance(struct pci_dev *F2)
 
mci->pvt_info = pvt;
mci->pdev = >F2->dev;
-   mci->csbased = 1;
 
setup_mci_misc_attrs(mci, fam_type);
 
diff --git a/drivers/edac/edac_mc.c b/drivers/edac/edac_mc.c
index cdb81aa..27e86d9 100644
--- a/drivers/edac/edac_mc.c
+++ b/drivers/edac/edac_mc.c
@@ -86,7 +86,7 @@ static void edac_mc_dump_dimm(struct dimm_info *dimm, int 
number)
edac_dimm_info_location(dimm, location, sizeof(location));
 
edac_dbg(4, "%s%i: %smapped as virtual row %d, chan %d\n",
-dimm->mci->mem_is_per_rank ? "rank" : "dimm",
+dimm->mci->csbased ? "rank" : "dimm",
 number, location, dimm->csrow, dimm->cschannel);
edac_dbg(4, "  dimm = %p\n", dimm);
edac_dbg(4, "  dimm->label = '%s'\n", dimm->label);
@@ -341,7 +341,7 @@ struct mem_ctl_info *edac_mc_alloc(unsigned mc_num,
memcpy(mci->layers, layers, sizeof(*layer) * n_layers);
mci->nr_csrows = tot_csrows;
mci->num_cschannel = tot_channels;
-   mci->mem_is_per_rank = per_rank;
+   mci->csbased = per_rank;
 
/*
 * Alocate and fill the csrow/channels structs
@@ -1235,7 +1235,7 @@ void edac_mc_handle_error(const enum hw_event_mc_err_type 
type,
 * incrementing the compat API counters
 */
edac_dbg(4, "%s csrows map: (%d,%d)\n",
-mci->mem_is_per_rank ? "rank" : "dimm",
+mci->csbased ? "rank" : "dimm",
 dimm->csrow, dimm->cschannel);
if (row == -1)
row = dimm->csrow;
diff --git a/drivers/edac/edac_mc_sysfs.c b/drivers/edac/edac_mc_sysfs.c
index 5463ed3..6ab4a50 100644
--- a/drivers/edac/edac_mc_sysfs.c
+++ b/drivers/edac/edac_mc_sysfs.c
@@ -609,7 +609,7 @@ static int edac_create_dimm_object(struct mem_ctl_info *mci,
device_initialize(>dev);
 
dimm->dev.parent = >dev;
-   if (mci->mem_is_per_rank)
+   if (mci->csbased)
dev_set_name(>dev, "rank%d", index);
else
dev_set_name(>dev, "dimm%d", index);
diff --git a/include/linux/edac.h b/include/linux/edac.h
index ab1ea98..7f5d8d6 100644
--- a/include/linux/edac.h
+++ b/include/linux/edac.h
@@ -675,11 +675,11 @@ struct mem_ctl_info {
 * sees memory sticks ("dimms"), and the ones that sees memory ranks.
 * All old memory controllers enumerate memories per rank, but most
 * of the recent drivers enumerate memories per DIMM, instead.
-* When the memory controller is per rank, mem_is_per_rank is true.
+* When the memory controller is per rank, csbased is true.
 */
unsigned n_layers;
struct edac_mc_layer *layers;
-   bool mem_is_per_rank;
+   bool csbased;
 
/*
 * DIMM info. Will eventually remove

Re: [GIT PULL] EDAC fixes for 3.8

2013-03-11 Thread Mauro Carvalho Chehab

Em Sat, 9 Mar 2013 16:46:35 +0100
Borislav Petkov  escreveu:

> On Thu, Mar 07, 2013 at 11:02:13AM -0300, Mauro Carvalho Chehab wrote:
> > Sure. See below:
> > 
> > [   19.062902] EDAC MC: Ver: 3.0.0
> > [   19.088757] EDAC DEBUG: edac_mc_sysfs_init: device mc created
> > [   19.284745] AMD64 EDAC driver v3.4.0
> > [   19.299082] EDAC amd64: DRAM ECC enabled.
> > [   19.315960] EDAC DEBUG: amd64_nb_mce_bank_enabled_on_node: core: 0, 
> > MCG_CTL: 0x3f, NB MSR is enabled
> 
>   ^^^
> Whoops, where did core 1 go? Strange.
> 
> > [   19.321115] EDAC DEBUG: amd64_nb_mce_bank_enabled_on_node: core: 2, 
> > MCG_CTL: 0x3f, NB MSR is enabled
> > [   19.321118] EDAC DEBUG: amd64_nb_mce_bank_enabled_on_node: core: 3, 
> > MCG_CTL: 0x3f, NB MSR is enabled
> > [   19.321120] EDAC DEBUG: amd64_nb_mce_bank_enabled_on_node: core: 4, 
> > MCG_CTL: 0x3f, NB MSR is enabled
> > [   19.321123] EDAC DEBUG: amd64_nb_mce_bank_enabled_on_node: core: 5, 
> > MCG_CTL: 0x3f, NB MSR is enabled
> > [   19.321125] EDAC DEBUG: amd64_nb_mce_bank_enabled_on_node: core: 6, 
> > MCG_CTL: 0x3f, NB MSR is enabled
> > [   19.321140] EDAC amd64: F10h detected (node 0).
> > [   19.327072] EDAC DEBUG: reserve_mc_sibling_devs: F1: :00:18.1
> > [   19.327074] EDAC DEBUG: reserve_mc_sibling_devs: F2: :00:18.2
> > [   19.327076] EDAC DEBUG: reserve_mc_sibling_devs: F3: :00:18.3
> > [   19.327078] EDAC DEBUG: read_mc_regs:   TOP_MEM:  0xe000
> > [   19.327081] EDAC DEBUG: read_mc_regs:   TOP_MEM2: 0x00042000
> 
> Looks about right - 16G.
> 
> > [   19.327087] EDAC DEBUG: read_dram_ctl_register: F2x110 (DCTSelLow): 
> > 0x05e4, High range addrs at: 0x0
> > [   19.327089] EDAC DEBUG: read_dram_ctl_register:   DCTs operate in 
> > unganged mode
> > [   19.327091] EDAC DEBUG: read_dram_ctl_register:   Address range split 
> > per DCT: no
> > [   19.327093] EDAC DEBUG: read_dram_ctl_register:   data interleave for 
> > ECC: enabled, DRAM cleared since last warm reset: yes
> > [   19.327095] EDAC DEBUG: read_dram_ctl_register:   channel interleave: 
> > enabled, interleave bits selector: 0x3
> > [   19.327099] EDAC DEBUG: read_mc_regs:   DRAM range[0], base: 
> > 0x; limit: 0x00021fff
> > [   19.327101] EDAC DEBUG: read_mc_regs:IntlvEn=Disabled; Range access: 
> > RW IntlvSel=0 DstNode=0
> > [   19.327104] EDAC DEBUG: read_mc_regs:   DRAM range[1], base: 
> > 0x00022000; limit: 0x00041fff
> > [   19.327107] EDAC DEBUG: read_mc_regs:IntlvEn=Disabled; Range access: 
> > RW IntlvSel=0 DstNode=1
> > [   19.327114] EDAC DEBUG: read_dct_base_mask:   DCSB0[0]=0x reg: 
> > F2x40
> > [   19.327117] EDAC DEBUG: read_dct_base_mask:   DCSB1[0]=0x reg: 
> > F2x140
> > [   19.327119] EDAC DEBUG: read_dct_base_mask:   DCSB0[1]=0x reg: 
> > F2x44
> > [   19.327121] EDAC DEBUG: read_dct_base_mask:   DCSB1[1]=0x reg: 
> > F2x144
> > [   19.327123] EDAC DEBUG: read_dct_base_mask:   DCSB0[2]=0x0001 reg: 
> > F2x48
> > [   19.327125] EDAC DEBUG: read_dct_base_mask:   DCSB1[2]=0x0001 reg: 
> > F2x148
> > [   19.327129] EDAC DEBUG: read_dct_base_mask:   DCSB0[3]=0x0101 reg: 
> > F2x4c
> > [   19.327131] EDAC DEBUG: read_dct_base_mask:   DCSB1[3]=0x0101 reg: 
> > F2x14c
> > [   19.327134] EDAC DEBUG: read_dct_base_mask:   DCSB0[4]=0x reg: 
> > F2x50
> > [   19.327136] EDAC DEBUG: read_dct_base_mask:   DCSB1[4]=0x reg: 
> > F2x150
> > [   19.327138] EDAC DEBUG: read_dct_base_mask:   DCSB0[5]=0x reg: 
> > F2x54
> > [   19.327140] EDAC DEBUG: read_dct_base_mask:   DCSB1[5]=0x reg: 
> > F2x154
> > [   19.327142] EDAC DEBUG: read_dct_base_mask:   DCSB0[6]=0x0201 reg: 
> > F2x58
> > [   19.327144] EDAC DEBUG: read_dct_base_mask:   DCSB1[6]=0x0201 reg: 
> > F2x158
> > [   19.327146] EDAC DEBUG: read_dct_base_mask:   DCSB0[7]=0x0301 reg: 
> > F2x5c
> > [   19.327148] EDAC DEBUG: read_dct_base_mask:   DCSB1[7]=0x0301 reg: 
> > F2x15c
> > [   19.327150] EDAC DEBUG: read_dct_base_mask: DCSM0[0]=0x reg: 
> > F2x60
> > [   19.327152] EDAC DEBUG: read_dct_base_mask: DCSM1[0]=0x reg: 
> > F2x160
> > [   19.327155] EDAC DEBUG: read_dct_base_mask: DCSM0[1]=0x00f83ce0 reg: 
> > F2x64
> > [   19.327157] EDAC DEBUG: read_dct_base_mask: DCSM1[1]=0x00f83ce0 reg: 
> > F2x164
> > [   19.327159] EDAC DEBUG: read_dct_base_mask: DCSM0[2]=0x reg: 
> > F2x68
> > [   19.327161] EDAC DEBUG: read_dct_base_mask: DCSM1[2]=0x reg: 
> > F2x168
> > [   19.327163] EDAC DEBUG: read_dct_base_mask: DCSM0[3]=0x00f83ce0 reg: 
> > F2x6c
> > [   19.327165] EDAC DEBUG: read_dct_base_mask: DCSM1[3]=0x00f83ce0 reg: 
> > F2x16c
> > [   19.327169] EDAC DEBUG: dump_misc_regs: F3xE8 (NB Cap): 0x0200df5f
> > [   19.327170] EDAC DEBUG: dump_misc_regs:   NB two channel DRAM capable: 
> > yes
> > [   19.327172] EDAC DEBUG:

Re: [GIT PULL] EDAC fixes for 3.8

2013-03-11 Thread Mauro Carvalho Chehab

Em Sat, 9 Mar 2013 16:46:35 +0100
Borislav Petkov b...@alien8.de escreveu:

 On Thu, Mar 07, 2013 at 11:02:13AM -0300, Mauro Carvalho Chehab wrote:
  Sure. See below:
  
  [   19.062902] EDAC MC: Ver: 3.0.0
  [   19.088757] EDAC DEBUG: edac_mc_sysfs_init: device mc created
  [   19.284745] AMD64 EDAC driver v3.4.0
  [   19.299082] EDAC amd64: DRAM ECC enabled.
  [   19.315960] EDAC DEBUG: amd64_nb_mce_bank_enabled_on_node: core: 0, 
  MCG_CTL: 0x3f, NB MSR is enabled
 
   ^^^
 Whoops, where did core 1 go? Strange.
 
  [   19.321115] EDAC DEBUG: amd64_nb_mce_bank_enabled_on_node: core: 2, 
  MCG_CTL: 0x3f, NB MSR is enabled
  [   19.321118] EDAC DEBUG: amd64_nb_mce_bank_enabled_on_node: core: 3, 
  MCG_CTL: 0x3f, NB MSR is enabled
  [   19.321120] EDAC DEBUG: amd64_nb_mce_bank_enabled_on_node: core: 4, 
  MCG_CTL: 0x3f, NB MSR is enabled
  [   19.321123] EDAC DEBUG: amd64_nb_mce_bank_enabled_on_node: core: 5, 
  MCG_CTL: 0x3f, NB MSR is enabled
  [   19.321125] EDAC DEBUG: amd64_nb_mce_bank_enabled_on_node: core: 6, 
  MCG_CTL: 0x3f, NB MSR is enabled
  [   19.321140] EDAC amd64: F10h detected (node 0).
  [   19.327072] EDAC DEBUG: reserve_mc_sibling_devs: F1: :00:18.1
  [   19.327074] EDAC DEBUG: reserve_mc_sibling_devs: F2: :00:18.2
  [   19.327076] EDAC DEBUG: reserve_mc_sibling_devs: F3: :00:18.3
  [   19.327078] EDAC DEBUG: read_mc_regs:   TOP_MEM:  0xe000
  [   19.327081] EDAC DEBUG: read_mc_regs:   TOP_MEM2: 0x00042000
 
 Looks about right - 16G.
 
  [   19.327087] EDAC DEBUG: read_dram_ctl_register: F2x110 (DCTSelLow): 
  0x05e4, High range addrs at: 0x0
  [   19.327089] EDAC DEBUG: read_dram_ctl_register:   DCTs operate in 
  unganged mode
  [   19.327091] EDAC DEBUG: read_dram_ctl_register:   Address range split 
  per DCT: no
  [   19.327093] EDAC DEBUG: read_dram_ctl_register:   data interleave for 
  ECC: enabled, DRAM cleared since last warm reset: yes
  [   19.327095] EDAC DEBUG: read_dram_ctl_register:   channel interleave: 
  enabled, interleave bits selector: 0x3
  [   19.327099] EDAC DEBUG: read_mc_regs:   DRAM range[0], base: 
  0x; limit: 0x00021fff
  [   19.327101] EDAC DEBUG: read_mc_regs:IntlvEn=Disabled; Range access: 
  RW IntlvSel=0 DstNode=0
  [   19.327104] EDAC DEBUG: read_mc_regs:   DRAM range[1], base: 
  0x00022000; limit: 0x00041fff
  [   19.327107] EDAC DEBUG: read_mc_regs:IntlvEn=Disabled; Range access: 
  RW IntlvSel=0 DstNode=1
  [   19.327114] EDAC DEBUG: read_dct_base_mask:   DCSB0[0]=0x reg: 
  F2x40
  [   19.327117] EDAC DEBUG: read_dct_base_mask:   DCSB1[0]=0x reg: 
  F2x140
  [   19.327119] EDAC DEBUG: read_dct_base_mask:   DCSB0[1]=0x reg: 
  F2x44
  [   19.327121] EDAC DEBUG: read_dct_base_mask:   DCSB1[1]=0x reg: 
  F2x144
  [   19.327123] EDAC DEBUG: read_dct_base_mask:   DCSB0[2]=0x0001 reg: 
  F2x48
  [   19.327125] EDAC DEBUG: read_dct_base_mask:   DCSB1[2]=0x0001 reg: 
  F2x148
  [   19.327129] EDAC DEBUG: read_dct_base_mask:   DCSB0[3]=0x0101 reg: 
  F2x4c
  [   19.327131] EDAC DEBUG: read_dct_base_mask:   DCSB1[3]=0x0101 reg: 
  F2x14c
  [   19.327134] EDAC DEBUG: read_dct_base_mask:   DCSB0[4]=0x reg: 
  F2x50
  [   19.327136] EDAC DEBUG: read_dct_base_mask:   DCSB1[4]=0x reg: 
  F2x150
  [   19.327138] EDAC DEBUG: read_dct_base_mask:   DCSB0[5]=0x reg: 
  F2x54
  [   19.327140] EDAC DEBUG: read_dct_base_mask:   DCSB1[5]=0x reg: 
  F2x154
  [   19.327142] EDAC DEBUG: read_dct_base_mask:   DCSB0[6]=0x0201 reg: 
  F2x58
  [   19.327144] EDAC DEBUG: read_dct_base_mask:   DCSB1[6]=0x0201 reg: 
  F2x158
  [   19.327146] EDAC DEBUG: read_dct_base_mask:   DCSB0[7]=0x0301 reg: 
  F2x5c
  [   19.327148] EDAC DEBUG: read_dct_base_mask:   DCSB1[7]=0x0301 reg: 
  F2x15c
  [   19.327150] EDAC DEBUG: read_dct_base_mask: DCSM0[0]=0x reg: 
  F2x60
  [   19.327152] EDAC DEBUG: read_dct_base_mask: DCSM1[0]=0x reg: 
  F2x160
  [   19.327155] EDAC DEBUG: read_dct_base_mask: DCSM0[1]=0x00f83ce0 reg: 
  F2x64
  [   19.327157] EDAC DEBUG: read_dct_base_mask: DCSM1[1]=0x00f83ce0 reg: 
  F2x164
  [   19.327159] EDAC DEBUG: read_dct_base_mask: DCSM0[2]=0x reg: 
  F2x68
  [   19.327161] EDAC DEBUG: read_dct_base_mask: DCSM1[2]=0x reg: 
  F2x168
  [   19.327163] EDAC DEBUG: read_dct_base_mask: DCSM0[3]=0x00f83ce0 reg: 
  F2x6c
  [   19.327165] EDAC DEBUG: read_dct_base_mask: DCSM1[3]=0x00f83ce0 reg: 
  F2x16c
  [   19.327169] EDAC DEBUG: dump_misc_regs: F3xE8 (NB Cap): 0x0200df5f
  [   19.327170] EDAC DEBUG: dump_misc_regs:   NB two channel DRAM capable: 
  yes
  [   19.327172] EDAC DEBUG: dump_misc_regs:   ECC capable: yes, ChipKill ECC 
  capable: yes
  [   19.327175] EDAC DEBUG: amd64_dump_dramcfg_low: F2x090 (DRAM Cfg Low): 
  0x00080100
  [   19.327179] EDAC DEBUG:

Re: [GIT PULL] EDAC fixes for 3.8

2013-03-11 Thread Mauro Carvalho Chehab

Em Mon, 11 Mar 2013 09:07:46 -0300
Mauro Carvalho Chehab mche...@redhat.com escreveu:

 Em Sat, 9 Mar 2013 16:46:35 +0100
 Borislav Petkov b...@alien8.de escreveu:
 
  On Thu, Mar 07, 2013 at 11:02:13AM -0300, Mauro Carvalho Chehab wrote:
   Sure. See below:
   

...

  So, actually to satisfy the new api, you'll probably need to stick down
  this information above, i.e. the chip selects *per* DCT which equals
  also the ranks.
  
 
 Yes. Basically, we should revert this patchset:
   commit 16a528ee3975c860dc93fbfc718fe9aa25ed92bc
   Author: Borislav Petkov borislav.pet...@amd.com
   Date:   Thu Sep 13 18:53:58 2012 +0200
 
 And fill dimm-nr_pages with:
 
   dimm-nr_pages = nr_pages / pvt-channel_count;
 
 This way, both new API and the old API will reflect the right size.
 
 The patch below does that.

...

 [PATCH] Fix dimm size on amd64_edac
 
...
 --- a/drivers/edac/edac_mc_sysfs.c
 +++ b/drivers/edac/edac_mc_sysfs.c
 @@ -180,9 +180,6 @@ static ssize_t csrow_size_show(struct device *dev,
   int i;
   u32 nr_pages = 0;
  
 - if (csrow-mci-csbased)
 - return sprintf(data, %u\n, PAGES_TO_MiB(csrow-nr_pages));
 -

With this patch, mci-csbased field got unused. So, it makes sense to
also remove it. The enclosed patch does that.

Regards,
Mauro

-

[PATCH] edac: merge mci.mem_is_per_rank with mci.csbased

Both mci.mem_is_per_rank and mci.csbased have the same meaning:
the memory controller is csrows based. Merge both fields into one.

There's no need for the driver to actually fill it, as the core
detectsi it by checking if one of the layes has the csrows type
as part of the memory hierarchy:

if (layers[i].type == EDAC_MC_LAYER_CHIP_SELECT)
per_rank = true;
...
mci-csbased = per_rank;

Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com

diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
index 074657d..06e633a 100644
--- a/drivers/edac/amd64_edac.c
+++ b/drivers/edac/amd64_edac.c
@@ -2418,7 +2418,6 @@ static int amd64_init_one_instance(struct pci_dev *F2)
 
mci-pvt_info = pvt;
mci-pdev = pvt-F2-dev;
-   mci-csbased = 1;
 
setup_mci_misc_attrs(mci, fam_type);
 
diff --git a/drivers/edac/edac_mc.c b/drivers/edac/edac_mc.c
index cdb81aa..27e86d9 100644
--- a/drivers/edac/edac_mc.c
+++ b/drivers/edac/edac_mc.c
@@ -86,7 +86,7 @@ static void edac_mc_dump_dimm(struct dimm_info *dimm, int 
number)
edac_dimm_info_location(dimm, location, sizeof(location));
 
edac_dbg(4, %s%i: %smapped as virtual row %d, chan %d\n,
-dimm-mci-mem_is_per_rank ? rank : dimm,
+dimm-mci-csbased ? rank : dimm,
 number, location, dimm-csrow, dimm-cschannel);
edac_dbg(4,   dimm = %p\n, dimm);
edac_dbg(4,   dimm-label = '%s'\n, dimm-label);
@@ -341,7 +341,7 @@ struct mem_ctl_info *edac_mc_alloc(unsigned mc_num,
memcpy(mci-layers, layers, sizeof(*layer) * n_layers);
mci-nr_csrows = tot_csrows;
mci-num_cschannel = tot_channels;
-   mci-mem_is_per_rank = per_rank;
+   mci-csbased = per_rank;
 
/*
 * Alocate and fill the csrow/channels structs
@@ -1235,7 +1235,7 @@ void edac_mc_handle_error(const enum hw_event_mc_err_type 
type,
 * incrementing the compat API counters
 */
edac_dbg(4, %s csrows map: (%d,%d)\n,
-mci-mem_is_per_rank ? rank : dimm,
+mci-csbased ? rank : dimm,
 dimm-csrow, dimm-cschannel);
if (row == -1)
row = dimm-csrow;
diff --git a/drivers/edac/edac_mc_sysfs.c b/drivers/edac/edac_mc_sysfs.c
index 5463ed3..6ab4a50 100644
--- a/drivers/edac/edac_mc_sysfs.c
+++ b/drivers/edac/edac_mc_sysfs.c
@@ -609,7 +609,7 @@ static int edac_create_dimm_object(struct mem_ctl_info *mci,
device_initialize(dimm-dev);
 
dimm-dev.parent = mci-dev;
-   if (mci-mem_is_per_rank)
+   if (mci-csbased)
dev_set_name(dimm-dev, rank%d, index);
else
dev_set_name(dimm-dev, dimm%d, index);
diff --git a/include/linux/edac.h b/include/linux/edac.h
index ab1ea98..7f5d8d6 100644
--- a/include/linux/edac.h
+++ b/include/linux/edac.h
@@ -675,11 +675,11 @@ struct mem_ctl_info {
 * sees memory sticks (dimms), and the ones that sees memory ranks.
 * All old memory controllers enumerate memories per rank, but most
 * of the recent drivers enumerate memories per DIMM, instead.
-* When the memory controller is per rank, mem_is_per_rank is true.
+* When the memory controller is per rank, csbased is true.
 */
unsigned n_layers;
struct edac_mc_layer *layers;
-   bool mem_is_per_rank;
+   bool csbased;
 
/*
 * DIMM info. Will eventually remove the entire

Re: [GIT PULL] EDAC fixes for 3.8

2013-03-11 Thread Borislav Petkov

On Mon, Mar 11, 2013 at 09:28:48AM -0300, Mauro Carvalho Chehab wrote:
 With this patch, mci-csbased field got unused. So, it makes sense to
 also remove it. The enclosed patch does that.

AFAIR, this whole fixing was done for K8 as reported by Josh Hunt from
Akamai: http://marc.info/?l=linux-edacm=134740440610678 (the whole
thread contains the discussion).

So, before we go and change anything in amd64_edac, we need to test
those on a K8 box. Now, I need ot find one but it would be good if you
could find one too at RH and test the patches on it before we continue
with this.

Thanks.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] EDAC fixes for 3.8

2013-03-11 Thread Mauro Carvalho Chehab

Em Mon, 11 Mar 2013 14:48:14 +0100
Borislav Petkov b...@alien8.de escreveu:

 On Mon, Mar 11, 2013 at 09:28:48AM -0300, Mauro Carvalho Chehab wrote:
  With this patch, mci-csbased field got unused. So, it makes sense to
  also remove it. The enclosed patch does that.
 
 AFAIR, this whole fixing was done for K8 as reported by Josh Hunt from
 Akamai: http://marc.info/?l=linux-edacm=134740440610678 (the whole
 thread contains the discussion).
 
 So, before we go and change anything in amd64_edac, we need to test
 those on a K8 box. Now, I need ot find one but it would be good if you
 could find one too at RH and test the patches on it before we continue
 with this.

Ok, I'll test it on a K8 box at RH. 

The bug seems to be on K8 rev F, right? Is there a different PCI ID on those
machines? That would help me to quickly find such machine on at RH labs.

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

Re: [GIT PULL] EDAC fixes for 3.8

2013-03-11 Thread Borislav Petkov

On Mon, Mar 11, 2013 at 11:12:15AM -0300, Mauro Carvalho Chehab wrote:
 Ok, I'll test it on a K8 box at RH.

 The bug seems to be on K8 rev F, right? Is there a different PCI ID on
 those machines? That would help me to quickly find such machine on at
 RH labs.

K8 revF should be a good choice, yes. Anything with model = 40 in
/proc/cpuinfo.

Thanks.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] EDAC fixes for 3.8

2013-03-11 Thread Mauro Carvalho Chehab

Hi Boris,

Em Mon, 11 Mar 2013 15:31:38 +0100
Borislav Petkov b...@alien8.de escreveu:

 On Mon, Mar 11, 2013 at 11:12:15AM -0300, Mauro Carvalho Chehab wrote:
  Ok, I'll test it on a K8 box at RH.
 
  The bug seems to be on K8 rev F, right? Is there a different PCI ID on
  those machines? That would help me to quickly find such machine on at
  RH labs.
 
 K8 revF should be a good choice, yes. Anything with model = 40 in
 /proc/cpuinfo.

Tests done and it looks alright.

I've applied this Fedora18 Kernel with the patches applied on it:

http://koji.fedoraproject.org/koji/taskinfo?taskID=5107290

The machine I took is an HP xw4550, using a dual-core CPU, with those
CPU info:

vendor_id   : AuthenticAMD
cpu family  : 15
model   : 67
model name  : Dual-Core AMD Opteron(tm) Processor 1214 HE
stepping: 3
microcode   : 0x6d

The EDAC dmesg is:

[   26.763384] EDAC MC: Ver: 3.0.0
[   26.769214] EDAC DEBUG: edac_mc_sysfs_init: device mc created
[   26.803556] AMD64 EDAC driver v3.4.0
[   26.807289] EDAC amd64: DRAM ECC enabled.
[   26.811379] EDAC DEBUG: amd64_nb_mce_bank_enabled_on_node: core: 0, MCG_CTL: 
0x1f, NB MSR is enabled
[   26.811382] EDAC DEBUG: amd64_nb_mce_bank_enabled_on_node: core: 1, MCG_CTL: 
0x1f, NB MSR is enabled
[   26.811393] EDAC amd64: K8 revF or later detected (node 0).
[   26.816973] EDAC DEBUG: reserve_mc_sibling_devs: F1: :00:18.1
[   26.816975] EDAC DEBUG: reserve_mc_sibling_devs: F2: :00:18.2
[   26.816977] EDAC DEBUG: reserve_mc_sibling_devs: F3: :00:18.3
[   26.816980] EDAC DEBUG: read_mc_regs:   TOP_MEM:  0x8000
[   26.816982] EDAC DEBUG: read_mc_regs:   TOP_MEM2 disabled
[   26.816986] EDAC DEBUG: read_mc_regs:   DRAM range[0], base: 
0x; limit: 0x7fff
[   26.816989] EDAC DEBUG: read_mc_regs:IntlvEn=Disabled; Range access: RW 
IntlvSel=0 DstNode=0
[   26.816998] EDAC DEBUG: read_dct_base_mask:   DCSB0[0]=0x0001 reg: F2x40
[   26.817001] EDAC DEBUG: read_dct_base_mask:   DCSB0[1]=0x reg: F2x44
[   26.817019] EDAC DEBUG: read_dct_base_mask:   DCSB0[2]=0x0101 reg: F2x48
[   26.817022] EDAC DEBUG: read_dct_base_mask:   DCSB0[3]=0x reg: F2x4c
[   26.817026] EDAC DEBUG: read_dct_base_mask:   DCSB0[4]=0x reg: F2x50
[   26.817030] EDAC DEBUG: read_dct_base_mask:   DCSB0[5]=0x reg: F2x54
[   26.817035] EDAC DEBUG: read_dct_base_mask:   DCSB0[6]=0x reg: F2x58
[   26.817038] EDAC DEBUG: read_dct_base_mask:   DCSB0[7]=0x reg: F2x5c
[   26.817041] EDAC DEBUG: read_dct_base_mask: DCSM0[0]=0x00783ee0 reg: 
F2x60
[   26.817044] EDAC DEBUG: read_dct_base_mask: DCSM0[1]=0x00783ee0 reg: 
F2x64
[   26.817046] EDAC DEBUG: read_dct_base_mask: DCSM0[2]=0x reg: 
F2x68
[   26.817049] EDAC DEBUG: read_dct_base_mask: DCSM0[3]=0x reg: 
F2x6c
[   26.817055] EDAC DEBUG: dump_misc_regs: F3xE8 (NB Cap): 0x1719
[   26.817057] EDAC DEBUG: dump_misc_regs:   NB two channel DRAM capable: yes
[   26.817059] EDAC DEBUG: dump_misc_regs:   ECC capable: yes, ChipKill ECC 
capable: yes
[   26.817061] EDAC DEBUG: amd64_dump_dramcfg_low: F2x090 (DRAM Cfg Low): 
0x00090c10
[   26.817064] EDAC DEBUG: amd64_dump_dramcfg_low:   DIMM type: unbuffered; all 
DIMMs support ECC: yes
[   26.817066] EDAC DEBUG: amd64_dump_dramcfg_low:   PAR/ERR parity: disabled
[   26.817068] EDAC DEBUG: amd64_dump_dramcfg_low:   x4 logical DIMMs present: 
L0: no L1: no L2: no L3: no
[   26.817071] EDAC DEBUG: dump_misc_regs: F3xB0 (Online Spare): 0x
[   26.817073] EDAC DEBUG: dump_misc_regs: F1xF0 (DRAM Hole Address): 
0x, base: 0x, offset: 0x
[   26.817075] EDAC DEBUG: dump_misc_regs:   DramHoleValid: no
[   26.817078] EDAC DEBUG: amd64_debug_display_dimm_sizes: F2x080 (DRAM Bank 
Address Mapping): 0x0022
[   26.817080] EDAC MC: DCT0 chip selects:
[   26.817083] EDAC amd64: MC: 0:  1024MB 1: 0MB
[   26.821788] EDAC amd64: MC: 2:  1024MB 3: 0MB
[   26.826489] EDAC amd64: MC: 4: 0MB 5: 0MB
[   26.831187] EDAC amd64: MC: 6: 0MB 7: 0MB
[   26.835887] EDAC DEBUG: edac_mc_alloc: allocating 2112 bytes for mci data 
(16 ranks, 16 csrows/channels)
[   26.836348] EDAC DEBUG: init_csrows: node 0, 
NBCFG=0x0ad00044[ChipKillEccCap: 1|DramEccEn: 1]
[   26.836351] EDAC DEBUG: init_csrows: MC node: 0, csrow: 0
[   26.836353] EDAC DEBUG: amd64_csrow_nr_pages: csrow: 0, channel: 0, DBAM 
idx: 2
[   26.836356] EDAC DEBUG: amd64_csrow_nr_pages: nr_pages/channel: 262144
[   26.836358] EDAC amd64: CS0: Unbuffered DDR2 RAM
[   26.840973] EDAC DEBUG: init_csrows: Total csrow0 pages: 262144
[   26.840976] EDAC DEBUG: init_csrows: MC node: 0, csrow: 2
[   26.840981] EDAC DEBUG: amd64_csrow_nr_pages: csrow: 2, channel: 0, DBAM 
idx: 2
[   26.840982] EDAC DEBUG: amd64_csrow_nr_pages: nr_pages/channel: 262144
[   26.840984] EDAC amd64: CS2: Unbuffered DDR2 RAM
[   26.845600] EDAC DEBUG: init_csrows: Total csrow2 pages: 262144
[

Re: [GIT PULL] EDAC fixes for 3.8

2013-03-11 Thread Borislav Petkov

On Mon, Mar 11, 2013 at 05:08:37PM -0300, Mauro Carvalho Chehab wrote:
 While this machine is reserved for my usage, do you need a different
 test on it?

Yes please. Can you send dmesg and sysfs entries before applying your
patches?

Thanks.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] EDAC fixes for 3.8

2013-03-09 Thread Borislav Petkov

On Thu, Mar 07, 2013 at 11:02:13AM -0300, Mauro Carvalho Chehab wrote:
> Sure. See below:
> 
> [   19.062902] EDAC MC: Ver: 3.0.0
> [   19.088757] EDAC DEBUG: edac_mc_sysfs_init: device mc created
> [   19.284745] AMD64 EDAC driver v3.4.0
> [   19.299082] EDAC amd64: DRAM ECC enabled.
> [   19.315960] EDAC DEBUG: amd64_nb_mce_bank_enabled_on_node: core: 0, 
> MCG_CTL: 0x3f, NB MSR is enabled

^^^
Whoops, where did core 1 go? Strange.

> [   19.321115] EDAC DEBUG: amd64_nb_mce_bank_enabled_on_node: core: 2, 
> MCG_CTL: 0x3f, NB MSR is enabled
> [   19.321118] EDAC DEBUG: amd64_nb_mce_bank_enabled_on_node: core: 3, 
> MCG_CTL: 0x3f, NB MSR is enabled
> [   19.321120] EDAC DEBUG: amd64_nb_mce_bank_enabled_on_node: core: 4, 
> MCG_CTL: 0x3f, NB MSR is enabled
> [   19.321123] EDAC DEBUG: amd64_nb_mce_bank_enabled_on_node: core: 5, 
> MCG_CTL: 0x3f, NB MSR is enabled
> [   19.321125] EDAC DEBUG: amd64_nb_mce_bank_enabled_on_node: core: 6, 
> MCG_CTL: 0x3f, NB MSR is enabled
> [   19.321140] EDAC amd64: F10h detected (node 0).
> [   19.327072] EDAC DEBUG: reserve_mc_sibling_devs: F1: :00:18.1
> [   19.327074] EDAC DEBUG: reserve_mc_sibling_devs: F2: :00:18.2
> [   19.327076] EDAC DEBUG: reserve_mc_sibling_devs: F3: :00:18.3
> [   19.327078] EDAC DEBUG: read_mc_regs:   TOP_MEM:  0xe000
> [   19.327081] EDAC DEBUG: read_mc_regs:   TOP_MEM2: 0x00042000

Looks about right - 16G.

> [   19.327087] EDAC DEBUG: read_dram_ctl_register: F2x110 (DCTSelLow): 
> 0x05e4, High range addrs at: 0x0
> [   19.327089] EDAC DEBUG: read_dram_ctl_register:   DCTs operate in unganged 
> mode
> [   19.327091] EDAC DEBUG: read_dram_ctl_register:   Address range split per 
> DCT: no
> [   19.327093] EDAC DEBUG: read_dram_ctl_register:   data interleave for ECC: 
> enabled, DRAM cleared since last warm reset: yes
> [   19.327095] EDAC DEBUG: read_dram_ctl_register:   channel interleave: 
> enabled, interleave bits selector: 0x3
> [   19.327099] EDAC DEBUG: read_mc_regs:   DRAM range[0], base: 
> 0x; limit: 0x00021fff
> [   19.327101] EDAC DEBUG: read_mc_regs:IntlvEn=Disabled; Range access: 
> RW IntlvSel=0 DstNode=0
> [   19.327104] EDAC DEBUG: read_mc_regs:   DRAM range[1], base: 
> 0x00022000; limit: 0x00041fff
> [   19.327107] EDAC DEBUG: read_mc_regs:IntlvEn=Disabled; Range access: 
> RW IntlvSel=0 DstNode=1
> [   19.327114] EDAC DEBUG: read_dct_base_mask:   DCSB0[0]=0x reg: 
> F2x40
> [   19.327117] EDAC DEBUG: read_dct_base_mask:   DCSB1[0]=0x reg: 
> F2x140
> [   19.327119] EDAC DEBUG: read_dct_base_mask:   DCSB0[1]=0x reg: 
> F2x44
> [   19.327121] EDAC DEBUG: read_dct_base_mask:   DCSB1[1]=0x reg: 
> F2x144
> [   19.327123] EDAC DEBUG: read_dct_base_mask:   DCSB0[2]=0x0001 reg: 
> F2x48
> [   19.327125] EDAC DEBUG: read_dct_base_mask:   DCSB1[2]=0x0001 reg: 
> F2x148
> [   19.327129] EDAC DEBUG: read_dct_base_mask:   DCSB0[3]=0x0101 reg: 
> F2x4c
> [   19.327131] EDAC DEBUG: read_dct_base_mask:   DCSB1[3]=0x0101 reg: 
> F2x14c
> [   19.327134] EDAC DEBUG: read_dct_base_mask:   DCSB0[4]=0x reg: 
> F2x50
> [   19.327136] EDAC DEBUG: read_dct_base_mask:   DCSB1[4]=0x reg: 
> F2x150
> [   19.327138] EDAC DEBUG: read_dct_base_mask:   DCSB0[5]=0x reg: 
> F2x54
> [   19.327140] EDAC DEBUG: read_dct_base_mask:   DCSB1[5]=0x reg: 
> F2x154
> [   19.327142] EDAC DEBUG: read_dct_base_mask:   DCSB0[6]=0x0201 reg: 
> F2x58
> [   19.327144] EDAC DEBUG: read_dct_base_mask:   DCSB1[6]=0x0201 reg: 
> F2x158
> [   19.327146] EDAC DEBUG: read_dct_base_mask:   DCSB0[7]=0x0301 reg: 
> F2x5c
> [   19.327148] EDAC DEBUG: read_dct_base_mask:   DCSB1[7]=0x0301 reg: 
> F2x15c
> [   19.327150] EDAC DEBUG: read_dct_base_mask: DCSM0[0]=0x reg: 
> F2x60
> [   19.327152] EDAC DEBUG: read_dct_base_mask: DCSM1[0]=0x reg: 
> F2x160
> [   19.327155] EDAC DEBUG: read_dct_base_mask: DCSM0[1]=0x00f83ce0 reg: 
> F2x64
> [   19.327157] EDAC DEBUG: read_dct_base_mask: DCSM1[1]=0x00f83ce0 reg: 
> F2x164
> [   19.327159] EDAC DEBUG: read_dct_base_mask: DCSM0[2]=0x reg: 
> F2x68
> [   19.327161] EDAC DEBUG: read_dct_base_mask: DCSM1[2]=0x reg: 
> F2x168
> [   19.327163] EDAC DEBUG: read_dct_base_mask: DCSM0[3]=0x00f83ce0 reg: 
> F2x6c
> [   19.327165] EDAC DEBUG: read_dct_base_mask: DCSM1[3]=0x00f83ce0 reg: 
> F2x16c
> [   19.327169] EDAC DEBUG: dump_misc_regs: F3xE8 (NB Cap): 0x0200df5f
> [   19.327170] EDAC DEBUG: dump_misc_regs:   NB two channel DRAM capable: yes
> [   19.327172] EDAC DEBUG: dump_misc_regs:   ECC capable: yes, ChipKill ECC 
> capable: yes
> [   19.327175] EDAC DEBUG: amd64_dump_dramcfg_low: F2x090 (DRAM Cfg Low): 
> 0x00080100
> [   19.327179] EDAC DEBUG: amd64_dump_dramcfg_low:   DIMM type: buffered; all 
> DIMMs support ECC: yes
> [

Re: [GIT PULL] EDAC fixes for 3.8

2013-03-09 Thread Borislav Petkov

On Thu, Mar 07, 2013 at 11:02:13AM -0300, Mauro Carvalho Chehab wrote:
 Sure. See below:
 
 [   19.062902] EDAC MC: Ver: 3.0.0
 [   19.088757] EDAC DEBUG: edac_mc_sysfs_init: device mc created
 [   19.284745] AMD64 EDAC driver v3.4.0
 [   19.299082] EDAC amd64: DRAM ECC enabled.
 [   19.315960] EDAC DEBUG: amd64_nb_mce_bank_enabled_on_node: core: 0, 
 MCG_CTL: 0x3f, NB MSR is enabled

^^^
Whoops, where did core 1 go? Strange.

 [   19.321115] EDAC DEBUG: amd64_nb_mce_bank_enabled_on_node: core: 2, 
 MCG_CTL: 0x3f, NB MSR is enabled
 [   19.321118] EDAC DEBUG: amd64_nb_mce_bank_enabled_on_node: core: 3, 
 MCG_CTL: 0x3f, NB MSR is enabled
 [   19.321120] EDAC DEBUG: amd64_nb_mce_bank_enabled_on_node: core: 4, 
 MCG_CTL: 0x3f, NB MSR is enabled
 [   19.321123] EDAC DEBUG: amd64_nb_mce_bank_enabled_on_node: core: 5, 
 MCG_CTL: 0x3f, NB MSR is enabled
 [   19.321125] EDAC DEBUG: amd64_nb_mce_bank_enabled_on_node: core: 6, 
 MCG_CTL: 0x3f, NB MSR is enabled
 [   19.321140] EDAC amd64: F10h detected (node 0).
 [   19.327072] EDAC DEBUG: reserve_mc_sibling_devs: F1: :00:18.1
 [   19.327074] EDAC DEBUG: reserve_mc_sibling_devs: F2: :00:18.2
 [   19.327076] EDAC DEBUG: reserve_mc_sibling_devs: F3: :00:18.3
 [   19.327078] EDAC DEBUG: read_mc_regs:   TOP_MEM:  0xe000
 [   19.327081] EDAC DEBUG: read_mc_regs:   TOP_MEM2: 0x00042000

Looks about right - 16G.

 [   19.327087] EDAC DEBUG: read_dram_ctl_register: F2x110 (DCTSelLow): 
 0x05e4, High range addrs at: 0x0
 [   19.327089] EDAC DEBUG: read_dram_ctl_register:   DCTs operate in unganged 
 mode
 [   19.327091] EDAC DEBUG: read_dram_ctl_register:   Address range split per 
 DCT: no
 [   19.327093] EDAC DEBUG: read_dram_ctl_register:   data interleave for ECC: 
 enabled, DRAM cleared since last warm reset: yes
 [   19.327095] EDAC DEBUG: read_dram_ctl_register:   channel interleave: 
 enabled, interleave bits selector: 0x3
 [   19.327099] EDAC DEBUG: read_mc_regs:   DRAM range[0], base: 
 0x; limit: 0x00021fff
 [   19.327101] EDAC DEBUG: read_mc_regs:IntlvEn=Disabled; Range access: 
 RW IntlvSel=0 DstNode=0
 [   19.327104] EDAC DEBUG: read_mc_regs:   DRAM range[1], base: 
 0x00022000; limit: 0x00041fff
 [   19.327107] EDAC DEBUG: read_mc_regs:IntlvEn=Disabled; Range access: 
 RW IntlvSel=0 DstNode=1
 [   19.327114] EDAC DEBUG: read_dct_base_mask:   DCSB0[0]=0x reg: 
 F2x40
 [   19.327117] EDAC DEBUG: read_dct_base_mask:   DCSB1[0]=0x reg: 
 F2x140
 [   19.327119] EDAC DEBUG: read_dct_base_mask:   DCSB0[1]=0x reg: 
 F2x44
 [   19.327121] EDAC DEBUG: read_dct_base_mask:   DCSB1[1]=0x reg: 
 F2x144
 [   19.327123] EDAC DEBUG: read_dct_base_mask:   DCSB0[2]=0x0001 reg: 
 F2x48
 [   19.327125] EDAC DEBUG: read_dct_base_mask:   DCSB1[2]=0x0001 reg: 
 F2x148
 [   19.327129] EDAC DEBUG: read_dct_base_mask:   DCSB0[3]=0x0101 reg: 
 F2x4c
 [   19.327131] EDAC DEBUG: read_dct_base_mask:   DCSB1[3]=0x0101 reg: 
 F2x14c
 [   19.327134] EDAC DEBUG: read_dct_base_mask:   DCSB0[4]=0x reg: 
 F2x50
 [   19.327136] EDAC DEBUG: read_dct_base_mask:   DCSB1[4]=0x reg: 
 F2x150
 [   19.327138] EDAC DEBUG: read_dct_base_mask:   DCSB0[5]=0x reg: 
 F2x54
 [   19.327140] EDAC DEBUG: read_dct_base_mask:   DCSB1[5]=0x reg: 
 F2x154
 [   19.327142] EDAC DEBUG: read_dct_base_mask:   DCSB0[6]=0x0201 reg: 
 F2x58
 [   19.327144] EDAC DEBUG: read_dct_base_mask:   DCSB1[6]=0x0201 reg: 
 F2x158
 [   19.327146] EDAC DEBUG: read_dct_base_mask:   DCSB0[7]=0x0301 reg: 
 F2x5c
 [   19.327148] EDAC DEBUG: read_dct_base_mask:   DCSB1[7]=0x0301 reg: 
 F2x15c
 [   19.327150] EDAC DEBUG: read_dct_base_mask: DCSM0[0]=0x reg: 
 F2x60
 [   19.327152] EDAC DEBUG: read_dct_base_mask: DCSM1[0]=0x reg: 
 F2x160
 [   19.327155] EDAC DEBUG: read_dct_base_mask: DCSM0[1]=0x00f83ce0 reg: 
 F2x64
 [   19.327157] EDAC DEBUG: read_dct_base_mask: DCSM1[1]=0x00f83ce0 reg: 
 F2x164
 [   19.327159] EDAC DEBUG: read_dct_base_mask: DCSM0[2]=0x reg: 
 F2x68
 [   19.327161] EDAC DEBUG: read_dct_base_mask: DCSM1[2]=0x reg: 
 F2x168
 [   19.327163] EDAC DEBUG: read_dct_base_mask: DCSM0[3]=0x00f83ce0 reg: 
 F2x6c
 [   19.327165] EDAC DEBUG: read_dct_base_mask: DCSM1[3]=0x00f83ce0 reg: 
 F2x16c
 [   19.327169] EDAC DEBUG: dump_misc_regs: F3xE8 (NB Cap): 0x0200df5f
 [   19.327170] EDAC DEBUG: dump_misc_regs:   NB two channel DRAM capable: yes
 [   19.327172] EDAC DEBUG: dump_misc_regs:   ECC capable: yes, ChipKill ECC 
 capable: yes
 [   19.327175] EDAC DEBUG: amd64_dump_dramcfg_low: F2x090 (DRAM Cfg Low): 
 0x00080100
 [   19.327179] EDAC DEBUG: amd64_dump_dramcfg_low:   DIMM type: buffered; all 
 DIMMs support ECC: yes
 [   19.327181] EDAC DEBUG: amd64_dump_dramcfg_low:   PAR/ERR parity: enabled
 [   19.327183] EDAC DEBUG:

Re: [GIT PULL] EDAC fixes for 3.8

2013-03-07 Thread Mauro Carvalho Chehab

Em Thu, 7 Mar 2013 14:06:35 +0100
Borislav Petkov  escreveu:

> On Thu, Mar 07, 2013 at 09:57:03AM -0300, Mauro Carvalho Chehab wrote:
> > After running my edac testbanch on an AMD64 machine, populated
> > with 4 DIMMS, each being a 4GB QUAD-rank DIMMs, the EDAC driver
> > reported 4 different memory configurations ;)
> 
> Can you please enable CONFIG_EDAC_DEBUG and send me dmesg?

Sure. See below:

[   19.062902] EDAC MC: Ver: 3.0.0
[   19.088757] EDAC DEBUG: edac_mc_sysfs_init: device mc created
[   19.284745] AMD64 EDAC driver v3.4.0
[   19.299082] EDAC amd64: DRAM ECC enabled.
[   19.315960] EDAC DEBUG: amd64_nb_mce_bank_enabled_on_node: core: 0, MCG_CTL: 
0x3f, NB MSR is enabled
[   19.321115] EDAC DEBUG: amd64_nb_mce_bank_enabled_on_node: core: 2, MCG_CTL: 
0x3f, NB MSR is enabled
[   19.321118] EDAC DEBUG: amd64_nb_mce_bank_enabled_on_node: core: 3, MCG_CTL: 
0x3f, NB MSR is enabled
[   19.321120] EDAC DEBUG: amd64_nb_mce_bank_enabled_on_node: core: 4, MCG_CTL: 
0x3f, NB MSR is enabled
[   19.321123] EDAC DEBUG: amd64_nb_mce_bank_enabled_on_node: core: 5, MCG_CTL: 
0x3f, NB MSR is enabled
[   19.321125] EDAC DEBUG: amd64_nb_mce_bank_enabled_on_node: core: 6, MCG_CTL: 
0x3f, NB MSR is enabled
[   19.321140] EDAC amd64: F10h detected (node 0).
[   19.327072] EDAC DEBUG: reserve_mc_sibling_devs: F1: :00:18.1
[   19.327074] EDAC DEBUG: reserve_mc_sibling_devs: F2: :00:18.2
[   19.327076] EDAC DEBUG: reserve_mc_sibling_devs: F3: :00:18.3
[   19.327078] EDAC DEBUG: read_mc_regs:   TOP_MEM:  0xe000
[   19.327081] EDAC DEBUG: read_mc_regs:   TOP_MEM2: 0x00042000
[   19.327087] EDAC DEBUG: read_dram_ctl_register: F2x110 (DCTSelLow): 
0x05e4, High range addrs at: 0x0
[   19.327089] EDAC DEBUG: read_dram_ctl_register:   DCTs operate in unganged 
mode
[   19.327091] EDAC DEBUG: read_dram_ctl_register:   Address range split per 
DCT: no
[   19.327093] EDAC DEBUG: read_dram_ctl_register:   data interleave for ECC: 
enabled, DRAM cleared since last warm reset: yes
[   19.327095] EDAC DEBUG: read_dram_ctl_register:   channel interleave: 
enabled, interleave bits selector: 0x3
[   19.327099] EDAC DEBUG: read_mc_regs:   DRAM range[0], base: 
0x; limit: 0x00021fff
[   19.327101] EDAC DEBUG: read_mc_regs:IntlvEn=Disabled; Range access: RW 
IntlvSel=0 DstNode=0
[   19.327104] EDAC DEBUG: read_mc_regs:   DRAM range[1], base: 
0x00022000; limit: 0x00041fff
[   19.327107] EDAC DEBUG: read_mc_regs:IntlvEn=Disabled; Range access: RW 
IntlvSel=0 DstNode=1
[   19.327114] EDAC DEBUG: read_dct_base_mask:   DCSB0[0]=0x reg: F2x40
[   19.327117] EDAC DEBUG: read_dct_base_mask:   DCSB1[0]=0x reg: F2x140
[   19.327119] EDAC DEBUG: read_dct_base_mask:   DCSB0[1]=0x reg: F2x44
[   19.327121] EDAC DEBUG: read_dct_base_mask:   DCSB1[1]=0x reg: F2x144
[   19.327123] EDAC DEBUG: read_dct_base_mask:   DCSB0[2]=0x0001 reg: F2x48
[   19.327125] EDAC DEBUG: read_dct_base_mask:   DCSB1[2]=0x0001 reg: F2x148
[   19.327129] EDAC DEBUG: read_dct_base_mask:   DCSB0[3]=0x0101 reg: F2x4c
[   19.327131] EDAC DEBUG: read_dct_base_mask:   DCSB1[3]=0x0101 reg: F2x14c
[   19.327134] EDAC DEBUG: read_dct_base_mask:   DCSB0[4]=0x reg: F2x50
[   19.327136] EDAC DEBUG: read_dct_base_mask:   DCSB1[4]=0x reg: F2x150
[   19.327138] EDAC DEBUG: read_dct_base_mask:   DCSB0[5]=0x reg: F2x54
[   19.327140] EDAC DEBUG: read_dct_base_mask:   DCSB1[5]=0x reg: F2x154
[   19.327142] EDAC DEBUG: read_dct_base_mask:   DCSB0[6]=0x0201 reg: F2x58
[   19.327144] EDAC DEBUG: read_dct_base_mask:   DCSB1[6]=0x0201 reg: F2x158
[   19.327146] EDAC DEBUG: read_dct_base_mask:   DCSB0[7]=0x0301 reg: F2x5c
[   19.327148] EDAC DEBUG: read_dct_base_mask:   DCSB1[7]=0x0301 reg: F2x15c
[   19.327150] EDAC DEBUG: read_dct_base_mask: DCSM0[0]=0x reg: 
F2x60
[   19.327152] EDAC DEBUG: read_dct_base_mask: DCSM1[0]=0x reg: 
F2x160
[   19.327155] EDAC DEBUG: read_dct_base_mask: DCSM0[1]=0x00f83ce0 reg: 
F2x64
[   19.327157] EDAC DEBUG: read_dct_base_mask: DCSM1[1]=0x00f83ce0 reg: 
F2x164
[   19.327159] EDAC DEBUG: read_dct_base_mask: DCSM0[2]=0x reg: 
F2x68
[   19.327161] EDAC DEBUG: read_dct_base_mask: DCSM1[2]=0x reg: 
F2x168
[   19.327163] EDAC DEBUG: read_dct_base_mask: DCSM0[3]=0x00f83ce0 reg: 
F2x6c
[   19.327165] EDAC DEBUG: read_dct_base_mask: DCSM1[3]=0x00f83ce0 reg: 
F2x16c
[   19.327169] EDAC DEBUG: dump_misc_regs: F3xE8 (NB Cap): 0x0200df5f
[   19.327170] EDAC DEBUG: dump_misc_regs:   NB two channel DRAM capable: yes
[   19.327172] EDAC DEBUG: dump_misc_regs:   ECC capable: yes, ChipKill ECC 
capable: yes
[   19.327175] EDAC DEBUG: amd64_dump_dramcfg_low: F2x090 (DRAM Cfg Low): 
0x00080100
[   19.327179] EDAC DEBUG: amd64_dump_dramcfg_low:   DIMM type: buffered; all 
DIMMs support ECC: yes
[   19.327181] EDAC DEBUG: amd64_dump_dramcfg_low:

Re: [GIT PULL] EDAC fixes for 3.8

2013-03-07 Thread Borislav Petkov

On Thu, Mar 07, 2013 at 09:57:03AM -0300, Mauro Carvalho Chehab wrote:
> After running my edac testbanch on an AMD64 machine, populated
> with 4 DIMMS, each being a 4GB QUAD-rank DIMMs, the EDAC driver
> reported 4 different memory configurations ;)

Can you please enable CONFIG_EDAC_DEBUG and send me dmesg?

Thanks.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] EDAC fixes for 3.8

2013-03-07 Thread Borislav Petkov

On Thu, Mar 07, 2013 at 09:57:03AM -0300, Mauro Carvalho Chehab wrote:
 After running my edac testbanch on an AMD64 machine, populated
 with 4 DIMMS, each being a 4GB QUAD-rank DIMMs, the EDAC driver
 reported 4 different memory configurations ;)

Can you please enable CONFIG_EDAC_DEBUG and send me dmesg?

Thanks.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] EDAC fixes for 3.8

2013-03-07 Thread Mauro Carvalho Chehab

Em Thu, 7 Mar 2013 14:06:35 +0100
Borislav Petkov b...@alien8.de escreveu:

 On Thu, Mar 07, 2013 at 09:57:03AM -0300, Mauro Carvalho Chehab wrote:
  After running my edac testbanch on an AMD64 machine, populated
  with 4 DIMMS, each being a 4GB QUAD-rank DIMMs, the EDAC driver
  reported 4 different memory configurations ;)
 
 Can you please enable CONFIG_EDAC_DEBUG and send me dmesg?

Sure. See below:

[   19.062902] EDAC MC: Ver: 3.0.0
[   19.088757] EDAC DEBUG: edac_mc_sysfs_init: device mc created
[   19.284745] AMD64 EDAC driver v3.4.0
[   19.299082] EDAC amd64: DRAM ECC enabled.
[   19.315960] EDAC DEBUG: amd64_nb_mce_bank_enabled_on_node: core: 0, MCG_CTL: 
0x3f, NB MSR is enabled
[   19.321115] EDAC DEBUG: amd64_nb_mce_bank_enabled_on_node: core: 2, MCG_CTL: 
0x3f, NB MSR is enabled
[   19.321118] EDAC DEBUG: amd64_nb_mce_bank_enabled_on_node: core: 3, MCG_CTL: 
0x3f, NB MSR is enabled
[   19.321120] EDAC DEBUG: amd64_nb_mce_bank_enabled_on_node: core: 4, MCG_CTL: 
0x3f, NB MSR is enabled
[   19.321123] EDAC DEBUG: amd64_nb_mce_bank_enabled_on_node: core: 5, MCG_CTL: 
0x3f, NB MSR is enabled
[   19.321125] EDAC DEBUG: amd64_nb_mce_bank_enabled_on_node: core: 6, MCG_CTL: 
0x3f, NB MSR is enabled
[   19.321140] EDAC amd64: F10h detected (node 0).
[   19.327072] EDAC DEBUG: reserve_mc_sibling_devs: F1: :00:18.1
[   19.327074] EDAC DEBUG: reserve_mc_sibling_devs: F2: :00:18.2
[   19.327076] EDAC DEBUG: reserve_mc_sibling_devs: F3: :00:18.3
[   19.327078] EDAC DEBUG: read_mc_regs:   TOP_MEM:  0xe000
[   19.327081] EDAC DEBUG: read_mc_regs:   TOP_MEM2: 0x00042000
[   19.327087] EDAC DEBUG: read_dram_ctl_register: F2x110 (DCTSelLow): 
0x05e4, High range addrs at: 0x0
[   19.327089] EDAC DEBUG: read_dram_ctl_register:   DCTs operate in unganged 
mode
[   19.327091] EDAC DEBUG: read_dram_ctl_register:   Address range split per 
DCT: no
[   19.327093] EDAC DEBUG: read_dram_ctl_register:   data interleave for ECC: 
enabled, DRAM cleared since last warm reset: yes
[   19.327095] EDAC DEBUG: read_dram_ctl_register:   channel interleave: 
enabled, interleave bits selector: 0x3
[   19.327099] EDAC DEBUG: read_mc_regs:   DRAM range[0], base: 
0x; limit: 0x00021fff
[   19.327101] EDAC DEBUG: read_mc_regs:IntlvEn=Disabled; Range access: RW 
IntlvSel=0 DstNode=0
[   19.327104] EDAC DEBUG: read_mc_regs:   DRAM range[1], base: 
0x00022000; limit: 0x00041fff
[   19.327107] EDAC DEBUG: read_mc_regs:IntlvEn=Disabled; Range access: RW 
IntlvSel=0 DstNode=1
[   19.327114] EDAC DEBUG: read_dct_base_mask:   DCSB0[0]=0x reg: F2x40
[   19.327117] EDAC DEBUG: read_dct_base_mask:   DCSB1[0]=0x reg: F2x140
[   19.327119] EDAC DEBUG: read_dct_base_mask:   DCSB0[1]=0x reg: F2x44
[   19.327121] EDAC DEBUG: read_dct_base_mask:   DCSB1[1]=0x reg: F2x144
[   19.327123] EDAC DEBUG: read_dct_base_mask:   DCSB0[2]=0x0001 reg: F2x48
[   19.327125] EDAC DEBUG: read_dct_base_mask:   DCSB1[2]=0x0001 reg: F2x148
[   19.327129] EDAC DEBUG: read_dct_base_mask:   DCSB0[3]=0x0101 reg: F2x4c
[   19.327131] EDAC DEBUG: read_dct_base_mask:   DCSB1[3]=0x0101 reg: F2x14c
[   19.327134] EDAC DEBUG: read_dct_base_mask:   DCSB0[4]=0x reg: F2x50
[   19.327136] EDAC DEBUG: read_dct_base_mask:   DCSB1[4]=0x reg: F2x150
[   19.327138] EDAC DEBUG: read_dct_base_mask:   DCSB0[5]=0x reg: F2x54
[   19.327140] EDAC DEBUG: read_dct_base_mask:   DCSB1[5]=0x reg: F2x154
[   19.327142] EDAC DEBUG: read_dct_base_mask:   DCSB0[6]=0x0201 reg: F2x58
[   19.327144] EDAC DEBUG: read_dct_base_mask:   DCSB1[6]=0x0201 reg: F2x158
[   19.327146] EDAC DEBUG: read_dct_base_mask:   DCSB0[7]=0x0301 reg: F2x5c
[   19.327148] EDAC DEBUG: read_dct_base_mask:   DCSB1[7]=0x0301 reg: F2x15c
[   19.327150] EDAC DEBUG: read_dct_base_mask: DCSM0[0]=0x reg: 
F2x60
[   19.327152] EDAC DEBUG: read_dct_base_mask: DCSM1[0]=0x reg: 
F2x160
[   19.327155] EDAC DEBUG: read_dct_base_mask: DCSM0[1]=0x00f83ce0 reg: 
F2x64
[   19.327157] EDAC DEBUG: read_dct_base_mask: DCSM1[1]=0x00f83ce0 reg: 
F2x164
[   19.327159] EDAC DEBUG: read_dct_base_mask: DCSM0[2]=0x reg: 
F2x68
[   19.327161] EDAC DEBUG: read_dct_base_mask: DCSM1[2]=0x reg: 
F2x168
[   19.327163] EDAC DEBUG: read_dct_base_mask: DCSM0[3]=0x00f83ce0 reg: 
F2x6c
[   19.327165] EDAC DEBUG: read_dct_base_mask: DCSM1[3]=0x00f83ce0 reg: 
F2x16c
[   19.327169] EDAC DEBUG: dump_misc_regs: F3xE8 (NB Cap): 0x0200df5f
[   19.327170] EDAC DEBUG: dump_misc_regs:   NB two channel DRAM capable: yes
[   19.327172] EDAC DEBUG: dump_misc_regs:   ECC capable: yes, ChipKill ECC 
capable: yes
[   19.327175] EDAC DEBUG: amd64_dump_dramcfg_low: F2x090 (DRAM Cfg Low): 
0x00080100
[   19.327179] EDAC DEBUG: amd64_dump_dramcfg_low:   DIMM type: buffered; all 
DIMMs support ECC: yes
[   19.327181] EDAC DEBUG:

Re: [GIT PULL] EDAC fixes for 3.8

Re: [GIT PULL] EDAC fixes for 3.8

Re: [GIT PULL] EDAC fixes for 3.8

Re: [GIT PULL] EDAC fixes for 3.8

Re: [GIT PULL] EDAC fixes for 3.8

Re: [GIT PULL] EDAC fixes for 3.8

Re: [GIT PULL] EDAC fixes for 3.8

Re: [GIT PULL] EDAC fixes for 3.8

Re: [GIT PULL] EDAC fixes for 3.8

Re: [GIT PULL] EDAC fixes for 3.8

Re: [GIT PULL] EDAC fixes for 3.8

Re: [GIT PULL] EDAC fixes for 3.8

Re: [GIT PULL] EDAC fixes for 3.8

Re: [GIT PULL] EDAC fixes for 3.8

Re: [GIT PULL] EDAC fixes for 3.8

Re: [GIT PULL] EDAC fixes for 3.8

Re: [GIT PULL] EDAC fixes for 3.8

Re: [GIT PULL] EDAC fixes for 3.8

Re: [GIT PULL] EDAC fixes for 3.8

Re: [GIT PULL] EDAC fixes for 3.8

Re: [GIT PULL] EDAC fixes for 3.8

Re: [GIT PULL] EDAC fixes for 3.8

Re: [GIT PULL] EDAC fixes for 3.8

Re: [GIT PULL] EDAC fixes for 3.8

Re: [GIT PULL] EDAC fixes for 3.8

Re: [GIT PULL] EDAC fixes for 3.8

Re: [GIT PULL] EDAC fixes for 3.8

Re: [GIT PULL] EDAC fixes for 3.8

Re: [GIT PULL] EDAC fixes for 3.8

Re: [GIT PULL] EDAC fixes for 3.8

Re: [GIT PULL] EDAC fixes for 3.8

Re: [GIT PULL] EDAC fixes for 3.8

Re: [GIT PULL] EDAC fixes for 3.8

Re: [GIT PULL] EDAC fixes for 3.8

34 matches

Site Navigation

Mail list logo

Footer information