1. 02 10月, 2009 1 次提交
    • I
      x86: EDAC: MCE: Fix MCE decoding callback logic · f436f8bb
      Ingo Molnar 提交于
      Make decoding of MCEs happen only on AMD hardware by registering a
      non-default callback only on CPU families which support it.
      
      While looking at the interaction of decode_mce() with the other MCE
      code i also noticed a few other things and made the following
      cleanups/fixes:
      
       - Fixed the mce_decode() weak alias - a weak alias is really not
         good here, it should be a proper callback. A weak alias will be
         overriden if a piece of code is built into the kernel - not
         good, obviously.
      
       - The patch initializes the callback on AMD family 10h and 11h.
      
       - Added the more correct fallback printk of:
      
      	No support for human readable MCE decoding on this CPU type.
      	Transcribe the message and run it through 'mcelog --ascii' to decode.
      
         On CPUs that dont have a decoder.
      
       - Made the surrounding code more readable.
      
      Note that the callback allows us to have a default fallback -
      without having to check the CPU versions during the printout
      itself. When an EDAC module registers itself, it can install the
      decode-print function.
      
      (there's no unregister needed as this is core code.)
      
      version -v2 by Borislav Petkov:
      
       - add K8 to the set of supported CPUs
      
       - always build in edac_mce_amd since we use an early_initcall now
      
       - fix checkpatch warnings
      Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Andi Kleen <andi@firstfloor.org>
      LKML-Reference: <20091001141432.GA11410@aftab>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      f436f8bb
  2. 24 9月, 2009 1 次提交
  3. 15 9月, 2009 1 次提交
    • B
      EDAC: move MCE error descriptions to EDAC core · b70ef010
      Borislav Petkov 提交于
      This is in preparation of adding AMD-specific MCE decoding functionality
      to the EDAC core. The error decoding macros originate from the AMD64
      EDAC driver albeit in a simplified and cleaned up version here.
      
      While at it, add macros to generate the error description strings and
      use them in the error type decoders directly which removes a bunch of
      code and makes the decoding functions much more readable. Also, fix
      strings and shorten macro names.
      
      Remove superfluous htlink_msgs.
      Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>
      b70ef010
  4. 19 6月, 2009 1 次提交
  5. 10 6月, 2009 1 次提交
    • D
      amd64_edac: add module registration routines · 7d6034d3
      Doug Thompson 提交于
      Also, link into Kbuild by adding Kconfig and Makefile entries.
      
      Borislav:
      - Kconfig/Makefile splitting
      - use zero-sized arrays for the sysfs attrs if not enabled
      - rename sysfs attrs to more conform values
      - shorten CONFIG_ names
      - make multiple structure members assignment vertically aligned
      - fix/cleanup comments
      - fix function return value patterns
      - fix err labels
      - fix a memleak bug caught by Ingo
      - remove the NUMA dependency and use num_k8_northbrides for initializing
        a driver instance per NB.
      - do not copy the pvt contents into the mci struct in
        amd64_init_2nd_stage() and save it in the mci->pvt_info void ptr
        instead.
      - cleanup debug calls
      - simplify amd64_setup_pci_device()
      Reviewed-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      Signed-off-by: NDoug Thompson <dougthompson@xmission.com>
      Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>
      7d6034d3
  6. 29 5月, 2009 1 次提交
  7. 03 4月, 2009 1 次提交
    • G
      edac: new ppc4xx driver module · dba7a77c
      Grant Erickson 提交于
      This adds support for an EDAC memory controller adaptation driver for the
      "ibm,sdram-4xx-ddr2" ECC controller realized in the AMCC PowerPC 405EX[r].
      
      At present, this driver has been developed and tested against the
      controller realization in the AMCC PPC405EX[r] on the AMCC Kilauea and
      Haleakala boards (256 MiB w/o ECC memory soldered onto the board) and a
      proprietary board based on those designs (128 MiB ECC memory, also
      soldered onto the board).
      
      In the future, dynamic feature detection and handling needs to be added
      for the other realizations of this controller found in the 440SP, 440SPe,
      460EX, 460GT and 460SX.
      
      Eventually, this driver will likely be evolved and adapted to the above
      variant realizations of this controller as well as broken apart to handle
      the other known ECC-capable controllers prevalent in other PPC4xx
      processors:
      
        - IBM SDRAM (405GP, 405CR and 405EP) "ibm,sdram-4xx"
        - IBM DDR1 (440GP, 440GX, 440EP and 440GR) "ibm,sdram-4xx-ddr"
        - Denali DDR1/DDR2 (440EPX and 440GRX) "denali,sdram-4xx-ddr2"
      
      [akpm@linux-foundation.org: coding-style fixes]
      Signed-off-by: NGrant Erickson <gerickson@nuovations.com>
      Signed-off-by: NDoug Thompson <dougthompson@xmission.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      dba7a77c
  8. 07 1月, 2009 1 次提交
  9. 31 10月, 2008 1 次提交
  10. 26 7月, 2008 1 次提交
    • A
      edac: i5100 new intel chipset driver · 8f421c59
      Arthur Jones 提交于
      Preliminary support for the Intel 5100 MCH.  CE and UE errors are reported
      along with the current DIMM label information and other memory parameters.
      
      Reasons why this is preliminary:
      
      1) This chip has 2 independent memory controllers which, for best
         perforance, use interleaved accesses to the DDR2 memory.  This
         architecture does not map very well to the current edac data structures
         which depend on symmetric channel access to the interleaved data.
         Without core changes, the best I could do for now is to map both memory
         controllers to different csrows (first all ranks of controller 0, then
         all ranks of controller 1).  Someone much more familiar with the edac
         core than I will probably need to come up with a more general data
         structure to handle the interleaving and de-interleaving of the two
         memory controllers.
      
      2) I have not yet tackled the de-interleaving of the rank/controller
         address space into the physical address space of the CPU.  There is
         nothing fundamentally missing, it is just ending up to be a lot of
         code, and I'd rather keep it separate for now, esp since it doesn't
         work yet...
      
      3) The code depends on a particular i5100 chip select to DIMM mainboard
         chip select mapping.  This mapping seems obvious to me in order to
         support dual and single ranked memory, but it is not unique and DIMM
         labels could be wrong on other mainboards.  There is no way to query
         this mapping that I know of.
      
      4) The code requires that the i5100 is in 32GB mode.  Only 4 ranks per
         controller, 2 ranks per DIMM are supported.  I do not have hardware
         (nor do I expect to have hardware anytime soon) for the 48GB (6 ranks
         per controller) mode.
      
      5) The serial presence detect code should be broken out into a "real"
         i2c driver so that decode-dimms.pl can work.
      Signed-off-by: NArthur Jones <ajones@riverbed.com>
      Signed-off-by: NDoug Thompson <dougthompson@xmission.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8f421c59
  11. 08 2月, 2008 3 次提交
  12. 20 7月, 2007 9 次提交
  13. 19 1月, 2006 1 次提交