Re: [PATCH 0/3] Add new ie31200_edac driver

2014-04-07 Thread Borislav Petkov
On Fri, Apr 04, 2014 at 09:13:45PM +, Jason Baron wrote:
> Hi,
> 
> Add support for memory errors for the Intel E3-1200 processors.
> 
> While testing the driver, I found that doing a readq() on the
> memory mapped memory controller hub registers caused a hard lockup
> on my x86_64 system. It turns out that a read across a DW boundary
> is a no no here.
> 
> "
> Software must not access B0/D0/F0 32-bit memory-mapped registers with
> requests that cross a DW boundary.
> "
> 
> (http://www.intel.com/content/www/us/en/processors/xeon/xeon-e3-1200-family-vol-2-datasheet.html
>  p. 16)
> 
> Thus, I've added a generic lo_hi_[read|write]_q API, to deal with
> this issue.
> 
> I think longer term the right thing is maybe to simply add these
> definitions to include/asm-generic/io.h, as I didn't see any
> in tree users of 'io-64-nonatomic-hi-lo.h', and simply remove
> io-64-nonatomic-hi-lo.h and io-64-nonatomic-lo-hi.h. But I didn't want to
> tie that cleanup to this edac driver submission.

Makes sense to me. There are a couple of drivers which include
io-64-nonatomic-lo-hi.h though.

As part of the cleanup, it might be even clearer to do the lo_hi_* calls
directly instead of the readq/writeq defines as a means of documenting
that this particular code cannot stomach doubleword-crossing accesses.

x86 guys, opinions? Especially patch 1/3, should I pick it up or you
want?

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: [PATCH 0/3] Add new ie31200_edac driver

2014-04-07 Thread Borislav Petkov
On Fri, Apr 04, 2014 at 09:13:45PM +, Jason Baron wrote:
 Hi,
 
 Add support for memory errors for the Intel E3-1200 processors.
 
 While testing the driver, I found that doing a readq() on the
 memory mapped memory controller hub registers caused a hard lockup
 on my x86_64 system. It turns out that a read across a DW boundary
 is a no no here.
 
 
 Software must not access B0/D0/F0 32-bit memory-mapped registers with
 requests that cross a DW boundary.
 
 
 (http://www.intel.com/content/www/us/en/processors/xeon/xeon-e3-1200-family-vol-2-datasheet.html
  p. 16)
 
 Thus, I've added a generic lo_hi_[read|write]_q API, to deal with
 this issue.
 
 I think longer term the right thing is maybe to simply add these
 definitions to include/asm-generic/io.h, as I didn't see any
 in tree users of 'io-64-nonatomic-hi-lo.h', and simply remove
 io-64-nonatomic-hi-lo.h and io-64-nonatomic-lo-hi.h. But I didn't want to
 tie that cleanup to this edac driver submission.

Makes sense to me. There are a couple of drivers which include
io-64-nonatomic-lo-hi.h though.

As part of the cleanup, it might be even clearer to do the lo_hi_* calls
directly instead of the readq/writeq defines as a means of documenting
that this particular code cannot stomach doubleword-crossing accesses.

x86 guys, opinions? Especially patch 1/3, should I pick it up or you
want?

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/


[PATCH 0/3] Add new ie31200_edac driver

2014-04-04 Thread Jason Baron
Hi,

Add support for memory errors for the Intel E3-1200 processors.

While testing the driver, I found that doing a readq() on the
memory mapped memory controller hub registers caused a hard lockup
on my x86_64 system. It turns out that a read across a DW boundary
is a no no here.

"
Software must not access B0/D0/F0 32-bit memory-mapped registers with
requests that cross a DW boundary.
"

(http://www.intel.com/content/www/us/en/processors/xeon/xeon-e3-1200-family-vol-2-datasheet.html
 p. 16)

Thus, I've added a generic lo_hi_[read|write]_q API, to deal with
this issue.

I think longer term the right thing is maybe to simply add these
definitions to include/asm-generic/io.h, as I didn't see any
in tree users of 'io-64-nonatomic-hi-lo.h', and simply remove
io-64-nonatomic-hi-lo.h and io-64-nonatomic-lo-hi.h. But I didn't want to
tie that cleanup to this edac driver submission.

Thanks,

-Jason


Jason Baron (3):
  readq/writeq: Add explicit lo_hi_[read|write]_q and hi_lo_[read|write]_q
  x38_edac: make use of lo_hi_readq()
  ie31200_edac: Add driver

 drivers/edac/Kconfig|   7 +
 drivers/edac/Makefile   |   1 +
 drivers/edac/ie31200_edac.c | 540 
 drivers/edac/x38_edac.c |  15 +-
 include/asm-generic/io-64-nonatomic-hi-lo.h |  14 +-
 include/asm-generic/io-64-nonatomic-lo-hi.h |  14 +-
 6 files changed, 572 insertions(+), 19 deletions(-)
 create mode 100644 drivers/edac/ie31200_edac.c

-- 
1.8.2.rc2

--
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/


[PATCH 0/3] Add new ie31200_edac driver

2014-04-04 Thread Jason Baron
Hi,

Add support for memory errors for the Intel E3-1200 processors.

While testing the driver, I found that doing a readq() on the
memory mapped memory controller hub registers caused a hard lockup
on my x86_64 system. It turns out that a read across a DW boundary
is a no no here.


Software must not access B0/D0/F0 32-bit memory-mapped registers with
requests that cross a DW boundary.


(http://www.intel.com/content/www/us/en/processors/xeon/xeon-e3-1200-family-vol-2-datasheet.html
 p. 16)

Thus, I've added a generic lo_hi_[read|write]_q API, to deal with
this issue.

I think longer term the right thing is maybe to simply add these
definitions to include/asm-generic/io.h, as I didn't see any
in tree users of 'io-64-nonatomic-hi-lo.h', and simply remove
io-64-nonatomic-hi-lo.h and io-64-nonatomic-lo-hi.h. But I didn't want to
tie that cleanup to this edac driver submission.

Thanks,

-Jason


Jason Baron (3):
  readq/writeq: Add explicit lo_hi_[read|write]_q and hi_lo_[read|write]_q
  x38_edac: make use of lo_hi_readq()
  ie31200_edac: Add driver

 drivers/edac/Kconfig|   7 +
 drivers/edac/Makefile   |   1 +
 drivers/edac/ie31200_edac.c | 540 
 drivers/edac/x38_edac.c |  15 +-
 include/asm-generic/io-64-nonatomic-hi-lo.h |  14 +-
 include/asm-generic/io-64-nonatomic-lo-hi.h |  14 +-
 6 files changed, 572 insertions(+), 19 deletions(-)
 create mode 100644 drivers/edac/ie31200_edac.c

-- 
1.8.2.rc2

--
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/