linux-stable.git/drivers/edac, branch linux-4.5.y

EDAC: i7core, sb_edac: Don't return NOTIFY_BAD from mce_decoder callback

2016-05-04T21:49:07+00:00

commit c4fc1956fa31003bfbe4f597e359d751568e2954 upstream.

Both of these drivers can return NOTIFY_BAD, but this terminates
processing other callbacks that were registered later on the chain.
Since the driver did nothing to log the error it seems wrong to prevent
other interested parties from seeing it. E.g. neither of them had even
bothered to check the type of the error to see if it was a memory error
before the return NOTIFY_BAD.

Signed-off-by: Tony Luck 
Acked-by: Aristeu Rozanski 
Acked-by: Mauro Carvalho Chehab 
Cc: linux-edac 
Link: http://lkml.kernel.org/r/72937355dd92318d2630979666063f8a2853495b.1461864507.git.tony.luck@intel.com
Signed-off-by: Borislav Petkov 
Signed-off-by: Greg Kroah-Hartman

x86 EDAC, sb_edac.c: Take account of channel hashing when needed

2016-05-04T21:49:01+00:00

commit ea5dfb5fae81939f777ca569d8cfb599252da2e8 upstream.

Haswell and Broadwell can be configured to hash the channel
interleave function using bits [27:12] of the physical address.

On those processor models we must check to see if hashing is
enabled (bit21 of the HASWELL_HASYSDEFEATURE2 register) and
act accordingly.

Based on a patch by patrickg 

Tested-by: Patrick Geary 
Signed-off-by: Tony Luck 
Acked-by: Mauro Carvalho Chehab 
Cc: Aristeu Rozanski 
Cc: Borislav Petkov 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-edac@vger.kernel.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

x86 EDAC, sb_edac.c: Repair damage introduced when "fixing" channel address

2016-05-04T21:49:01+00:00

commit ff15e95c82768d589957dbb17d7eb7dba7904659 upstream.

In commit:

  eb1af3b71f9d ("Fix computation of channel address")

I switched the "sck_way" variable from holding the log2 value read
from the h/w to instead be the actual number. Unfortunately it
is needed in log2 form when used to shift the address.

Tested-by: Patrick Geary 
Signed-off-by: Tony Luck 
Acked-by: Mauro Carvalho Chehab 
Cc: Aristeu Rozanski 
Cc: Borislav Petkov 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-edac@vger.kernel.org
Fixes: eb1af3b71f9d ("Fix computation of channel address")
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

EDAC, amd64_edac: Shift wrapping issue in f1x_get_norm_dct_addr()

2016-04-12T14:33:15+00:00

commit 6f3508f61c814ee852c199988a62bd954c50dfc1 upstream.

dct_sel_base_off is declared as a u64 but we're only using the lower 32
bits because of a shift wrapping bug. This can possibly truncate the
upper 16 bits of DctSelBaseOffset[47:26], causing us to misdecode the CS
row.

Fixes: c8e518d5673d ('amd64_edac: Sanitize f10_get_base_addr_offset')
Signed-off-by: Dan Carpenter 
Cc: Aravind Gopalakrishnan 
Cc: linux-edac 
Link: http://lkml.kernel.org/r/20160120095451.GB19898@mwanda
Signed-off-by: Borislav Petkov 
Signed-off-by: Greg Kroah-Hartman

EDAC/sb_edac: Fix computation of channel address

2016-04-12T14:33:15+00:00

commit eb1af3b71f9d83e45f2fd2fd649356e98e1c582c upstream.

Large memory Haswell-EX systems with multiple DIMMs per channel were
sometimes reporting the wrong DIMM.

Found three problems:

 1) Debug printouts for socket and channel interleave were not interpreting
    the register fields correctly. The socket interleave field is a 2^X
    value (0=1, 1=2, 2=4, 3=8). The channel interleave is X+1 (0=1, 1=2,
    2=3. 3=4).

 2) Actual use of the socket interleave value didn't interpret as 2^X

 3) Conversion of address to channel address was complicated, and wrong.

Signed-off-by: Tony Luck 
Acked-by: Aristeu Rozanski 
Cc: Borislav Petkov 
Cc: Linus Torvalds 
Cc: Mauro Carvalho Chehab 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-edac@vger.kernel.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

EDAC, sb_edac: Fix logic when computing DIMM sizes on Xeon Phi

2016-03-07T18:07:40+00:00

Correct a typo introduced by

  d0cdf9003140 ("EDAC, sb_edac: Add Knights Landing (Xeon Phi gen 2) support")

As a result under some configurations DIMMs were not correctly
recognized. Problem affects only Xeon Phi architecture.

Signed-off-by: Hubert Chrzaniuk 
Acked-by: Aristeu Rozanski 
Cc: Mauro Carvalho Chehab 
Cc: linux-edac 
Cc: lukasz.anaczkowski@intel.com
Link: http://lkml.kernel.org/r/1457361045-26221-1-git-send-email-hubert.chrzaniuk@intel.com
Signed-off-by: Borislav Petkov

EDAC, i5100: Use to_delayed_work()

2016-01-01T17:31:34+00:00

Use to_delayed_work() instead of open-coding it.

Signed-off-by: Geliang Tang 
Cc: linux-edac 
Link: http://lkml.kernel.org/r/58c0e319c7263a10b692100c657c06c42814aecf.1451659910.git.geliangtang@163.com
Signed-off-by: Borislav Petkov

EDAC, sb_edac: Set fixed DIMM width on Xeon Knights Landing

2015-12-11T15:58:32+00:00

Knights Landing does not come with register that could be used to fetch
DIMM width. However the value is fixed for this architecture so it can
be hardcoded.

Signed-off-by: Hubert Chrzaniuk 
Cc: Doug Thompson 
Cc: Mauro Carvalho Chehab 
Cc: linux-edac 
Cc: lukasz.anaczkowski@intel.com
Link: http://lkml.kernel.org/r/1449840082-18673-1-git-send-email-hubert.chrzaniuk@intel.com
Signed-off-by: Borislav Petkov

EDAC: Rework workqueue handling

2015-12-11T15:56:43+00:00

Hide the EDAC workqueue pointer in a separate compilation unit and add
accessors for the workqueue manipulations needed.

Remove edac_pci_reset_delay_period() which wasn't used by anything. It
seems it got added without a user with

  91b99041c1d5 ("drivers/edac: updated PCI monitoring")

Signed-off-by: Borislav Petkov

EDAC: Make edac_device workqueue setup/teardown functions static

2015-12-11T15:56:42+00:00

They're not used anywhere else.

Signed-off-by: Borislav Petkov