linux-toradex.git/drivers/edac/sb_edac.c, branch v3.18.18

sb_edac: Fix typo computing number of banks

2015-04-17T00:13:15+00:00

[ Upstream commit fec53af531dd040e41fe358abe00b33747af2688 ]

Code will always think there are 16 banks because of a typo

Reported-by: Misha
Signed-off-by: Tony Luck 
Acked-by: Aristeu Rozanski 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Sasha Levin

sb_edac: Fix discovery of top-of-low-memory for Haswell

2015-04-17T00:13:15+00:00

[ Upstream commit f7cf2a22a2896d3b3595b71d7936b6d7a3316b00 ]

Haswell moved the TOLM/TOHM registers to a different device and offset.
The sb_edac driver accounted for the change of device, but not for the
new offset.  There was also a typo in the constant to fill in the low
26 bits (was 0x1ffffff, should be 0x3ffffff).

This resulted in a bogus value for the top of low memory:

  EDAC DEBUG: get_memory_layout: TOLM: 0.032 GB (0x0000000001ffffff)

which would result in EDAC refusing to translate addresses for
errors above the bogus value and below 4GB:

   sbridge MC3: HANDLING MCE MEMORY ERROR
   sbridge MC3: CPU 0: Machine Check Event: 0 Bank 7: 8c00004000010090
   sbridge MC3: TSC 0
   sbridge MC3: ADDR 2000000
   sbridge MC3: MISC 523eac86
   sbridge MC3: PROCESSOR 0:306f3 TIME 1414600951 SOCKET 0 APIC 0
   MC3: 1 CE Error at TOLM area, on addr 0x02000000 on any memory ( page:0x0 offset:0x0 grain:32 syndrome:0x0)

With the fix we see the correct TOLM value:

   DEBUG: get_memory_layout: TOLM: 2.048 GB (0x000000007fffffff)

and we decode address 2000000 correctly:

   sbridge MC3: HANDLING MCE MEMORY ERROR
   sbridge MC3: CPU 0: Machine Check Event: 0 Bank 7: 8c00004000010090
   sbridge MC3: TSC 0
   sbridge MC3: ADDR 2000000
   sbridge MC3: MISC 523e1086
   sbridge MC3: PROCESSOR 0:306f3 TIME 1414601319 SOCKET 0 APIC 0
   DEBUG: get_memory_error_data: SAD interleave package: 0 = CPU socket 0, HA 0, shiftup: 0
   DEBUG: get_memory_error_data: TAD#0: address 0x0000000002000000 < 0x000000007fffffff, socket interleave 1, channel interleave 4 (offset 0x00000000), index 0, base ch: 0, ch mask: 0x01
   DEBUG: get_memory_error_data: RIR#0, limit: 4.095 GB (0x00000000ffffffff), way: 1
   DEBUG: get_memory_error_data: RIR#0: channel address 0x00200000 < 0xffffffff, RIR interleave 0, index 0
   DEBUG: sbridge_mce_output_error:  area:DRAM err_code:0001:0090 socket:0 channel_mask:1 rank:0
   MC3: 1 CE memory read error on CPU_SrcID#0_Channel#0_DIMM#0 (channel:0 slot:0 page:0x2000 offset:0x0 grain:32 syndrome:0x0 -  area:DRAM err_code:0001:0090 socket:0 channel_mask:1 rank:0)

Signed-off-by: Tony Luck 
Acked-by: Aristeu Rozanski 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Sasha Levin

sb_edac: Fix detection on SNB machines

2015-03-06T22:53:05+00:00

commit 11249e73992981e31fd50e7231da24fad68e3320 upstream.

d0585cd815fa ("sb_edac: Claim a different PCI device") changed the
probing of sb_edac to look for PCI device 0x3ca0:

3f:0e.0 System peripheral: Intel Corporation Xeon E5/Core i7 Processor Home Agent (rev 07)
00: 86 80 a0 3c 00 00 00 00 07 00 80 08 00 00 80 00
...

but we're matching for 0x3ca8, i.e. PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_TA
in sbridge_probe() therefore the probing fails.

Changing it to probe for 0x3ca0 (PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_HA0),
.i.e., the 14.0 device, fixes the issue and driver loads successfully
again:

[ 2449.013120] EDAC DEBUG: sbridge_init:
[ 2449.017029] EDAC sbridge: Seeking for: PCI ID 8086:3ca0
[ 2449.022368] EDAC DEBUG: sbridge_get_onedevice: Detected 8086:3ca0
[ 2449.028498] EDAC sbridge: Seeking for: PCI ID 8086:3ca0
[ 2449.033768] EDAC sbridge: Seeking for: PCI ID 8086:3ca8
[ 2449.039028] EDAC DEBUG: sbridge_get_onedevice: Detected 8086:3ca8
[ 2449.045155] EDAC sbridge: Seeking for: PCI ID 8086:3ca8
...

Add a debug printk while at it to be able to catch the failure in the
future and dump driver version on successful load.

Fixes: d0585cd815fa ("sb_edac: Claim a different PCI device")
Acked-by: Aristeu Rozanski 
Cc: Tony Luck 
Acked-by: Andy Lutomirski 
Acked-by: Mauro Carvalho Chehab 
Signed-off-by: Borislav Petkov 
Signed-off-by: Greg Kroah-Hartman

sb_edac: Claim a different PCI device

2014-10-08T20:04:16+00:00

sb_edac controls a large number of different PCI functions.  Rather
than registering as a normal PCI driver for all of them, it
registers for just one so that it gets probed and, at probe time, it
looks for all the others.

Coincidentally, the device it registers for also contains the SMBUS
registers, so the PCI core will refuse to probe both sb_edac and a
future iMC SMBUS driver.  The drivers don't actually conflict, so
just change sb_edac's device table to probe a different device.

An alternative fix would be to merge the two drivers, but sb_edac
will also refuse to load on non-ECC systems, whereas i2c_imc would
still be useful without ECC.

The only user-visible change should be that sb_edac appears to bind
a different device.

Signed-off-by: Andy Lutomirski 
Cc: Rui Wang 
Acked-by: Aristeu Rozanski 
Signed-off-by: Mauro Carvalho Chehab

Move Intel SNB device ids from sb_edac to pci_ids.h

2014-10-08T20:04:16+00:00

The i2c_imc driver will use two of them, and moving only part of
the list seems messier.

Signed-off-by: Andy Lutomirski 
Acked-by: Bjorn Helgaas 
Acked-by: Aristeu Rozanski 
Signed-off-by: Mauro Carvalho Chehab

sb_edac: avoid INTERNAL ERROR message in EDAC with unspecified channel

2014-10-08T20:04:16+00:00

Intel IA32 SDM Table 15-14 defines channel 0xf as 'not specified', but
EDAC doesn't know about this and returns and INTERNAL ERROR when the
channel is greater than NUM_CHANNELS:

kernel: [ 1538.886456] CPU 0: Machine Check Exception: 0 Bank 1: 940000000000009f
kernel: [ 1538.886669] TSC 2bc68b22e7e812 ADDR 46dae7000 MISC 0 PROCESSOR 0:306e4 TIME 1390414572 SOCKET 0 APIC 0
kernel: [ 1538.971948] EDAC MC1: INTERNAL ERROR: channel value is out of range (15 >= 4)
kernel: [ 1538.972203] EDAC MC1: 0 CE memory read error on unknown memory (slot:0 page:0x46dae7 offset:0x0 grain:0 syndrome:0x0 -  area:DRAM err_code:0000:009f socket:1 channel_mask:1 rank:0)

This commit changes sb_edac to forward a channel of -1 to EDAC if the
channel is not specified.  edac_mc_handle_error() sets the channel to -1
internally after the error message anyway, so this commit should have no
effect other than avoiding the INTERNAL ERROR message when the channel
is not specified.

Signed-off-by: Seth Jennings 
Signed-off-by: Mauro Carvalho Chehab

sb_edac: add support for Haswell based systems

2014-06-26T18:47:01+00:00

Haswell memory controllers are very similar to Ivy Bridge and Sandy Bridge
ones. This patch adds support to Haswell based systems.

[m.chehab@samsung.com: Fix CodingStyle issues]
Cc: Tony Luck 
Signed-off-by: Aristeu Rozanski 
Signed-off-by: Mauro Carvalho Chehab

sb_edac: Fix mix tab/spaces alignments

2014-06-26T18:47:00+00:00

We should not have spaces before ^I on alignments.

Signed-off-by: Mauro Carvalho Chehab

sb_edac: remove bogus assumption on mc ordering

2014-06-26T18:46:51+00:00

When a MC is handled, the correct sbridge_dev is searched based on the node,
checking again later with the assumption the first memory controller found is
the first socket's memory controller is a bogus assumption. Get rid of it.

Cc: Tony Luck 
Signed-off-by: Aristeu Rozanski 
Signed-off-by: Mauro Carvalho Chehab

sb_edac: make minimal use of channel_mask

2014-06-26T18:46:46+00:00

channel_mask will be used in the future to determine which group of memory
modules is causing the errors since when mirroring, lockstep and close page
are enabled you can't. While that doesn't happen, use the channel_mask to
determine the channel instead of relying on the MC event/exception.

Cc: Tony Luck 
Signed-off-by: Aristeu Rozanski 
Signed-off-by: Mauro Carvalho Chehab