1. 28 May, 2012 34 commits
    • Mauro Carvalho Chehab's avatar
      edac: Initialize the dimm label with the known information · 5926ff50
      Mauro Carvalho Chehab authored
      While userspace doesn't fill the dimm labels, add there the dimm location,
      as described by the used memory model. This could eventually match what
      is described at the dmidecode, making easier for people to identify the
      memory.
      
      For example, on an Intel motherboard where the DMI table is reliable,
      the first memory stick is described as:
      
      Memory Device
      	Array Handle: 0x0029
      	Error Information Handle: Not Provided
      	Total Width: 64 bits
      	Data Width: 64 bits
      	Size: 2048 MB
      	Form Factor: DIMM
      	Set: 1
      	Locator: A1_DIMM0
      	Bank Locator: A1_Node0_Channel0_Dimm0
      	Type: <OUT OF SPEC>
      	Type Detail: Synchronous
      	Speed: 800 MHz
      	Manufacturer: A1_Manufacturer0
      	Serial Number: A1_SerNum0
      	Asset Tag: A1_AssetTagNum0
      	Part Number: A1_PartNum0
      
      The memory named as "A1_DIMM0" is physically located at the first
      memory controller (node 0), at channel 0, dimm slot 0.
      
      After this patch, the memory label will be filled with:
      	/sys/devices/system/edac/mc/csrow0/ch0_dimm_label:mc#0channel#0slot#0
      
      And (after the new EDAC API patches) as:
      	/sys/devices/system/edac/mc/mc0/dimm0/dimm_label:mc#0channel#0slot#0
      
      So, even if the memory label is not initialized on userspace, an useful
      information with the error location is filled there, expecially since
      several systems/motherboards are provided with enough info to map from
      channel/slot (or branch/channel/slot) into the DIMM label. So, letting the
      EDAC core fill it by default is a good thing.
      
      It should noticed that, as the label filling happens at the
      edac_mc_alloc(), drivers can override it to better describe the memories
      (and some actually do it).
      
      Cc: Aristeu Rozanski <arozansk@redhat.com>
      Cc: Doug Thompson <norsk5@yahoo.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      5926ff50
    • Mauro Carvalho Chehab's avatar
      edac: Remove the legacy EDAC ABI · ca0907b9
      Mauro Carvalho Chehab authored
      Now that all drivers got converted to use the new ABI, we can
      drop the old one.
      Acked-by: default avatarChris Metcalf <cmetcalf@tilera.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      ca0907b9
    • Mauro Carvalho Chehab's avatar
      x38_edac: convert driver to use the new edac ABI · e2acc357
      Mauro Carvalho Chehab authored
      The legacy edac ABI is going to be removed. Port the driver to use
      and benefit from the new API functionality.
      
      Cc: Borislav Petkov <borislav.petkov@amd.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      e2acc357
    • Mauro Carvalho Chehab's avatar
      tile_edac: convert driver to use the new edac ABI · 40467db7
      Mauro Carvalho Chehab authored
      The legacy edac ABI is going to be removed. Port the driver to use
      and benefit from the new API functionality.
      Acked-by: default avatarChris Metcalf <cmetcalf@tilera.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      40467db7
    • Mauro Carvalho Chehab's avatar
      sb_edac: convert driver to use the new edac ABI · c36e3e77
      Mauro Carvalho Chehab authored
      The legacy edac ABI is going to be removed. Port the driver to use
      and benefit from the new API functionality.
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      c36e3e77
    • Mauro Carvalho Chehab's avatar
      r82600_edac: convert driver to use the new edac ABI · 63b5d1d9
      Mauro Carvalho Chehab authored
      The legacy edac ABI is going to be removed. Port the driver to use
      and benefit from the new API functionality.
      
      Cc: Tim Small <tim@buttersideup.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      63b5d1d9
    • Mauro Carvalho Chehab's avatar
      ppc4xx_edac: convert driver to use the new edac ABI · 94d93374
      Mauro Carvalho Chehab authored
      The legacy edac ABI is going to be removed. Port the driver to use
      and benefit from the new API functionality.
      
      Cc: Josh Boyer <jwboyer@gmail.com>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Borislav Petkov <borislav.petkov@amd.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      94d93374
    • Mauro Carvalho Chehab's avatar
      pasemi_edac: convert driver to use the new edac ABI · f34575ac
      Mauro Carvalho Chehab authored
      The legacy edac ABI is going to be removed. Port the driver to use
      and benefit from the new API functionality.
      
      Cc: Olof Johansson <olof@lixom.net>
      Cc: Egor Martovetsky <egor@pasemi.com>
      Cc: linuxppc-dev@lists.ozlabs.org
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      f34575ac
    • Mauro Carvalho Chehab's avatar
      mv64x60_edac: convert driver to use the new edac ABI · a583ac6c
      Mauro Carvalho Chehab authored
      The legacy edac ABI is going to be removed. Port the driver to use
      and benefit from the new API functionality.
      
      Cc: Borislav Petkov <borislav.petkov@amd.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      a583ac6c
    • Mauro Carvalho Chehab's avatar
      mpc85xx_edac: convert driver to use the new edac ABI · ad4d6e23
      Mauro Carvalho Chehab authored
      The legacy edac ABI is going to be removed. Port the driver to use
      and benefit from the new API functionality.
      
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Shaohui Xie <Shaohui.Xie@freescale.com>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      ad4d6e23
    • Mauro Carvalho Chehab's avatar
      i82975x_edac: convert driver to use the new edac ABI · 70521358
      Mauro Carvalho Chehab authored
      The legacy edac ABI is going to be removed. Port the driver to use
      and benefit from the new API functionality.
      
      Cc: Ranganathan Desikan <ravi@jetztechnologies.com>
      Cc: "Arvind R." <arvino55@gmail.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      70521358
    • Mauro Carvalho Chehab's avatar
      i82875p_edac: convert driver to use the new edac ABI · 0a8a9ac9
      Mauro Carvalho Chehab authored
      The legacy edac ABI is going to be removed. Port the driver to use
      and benefit from the new API functionality.
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      0a8a9ac9
    • Mauro Carvalho Chehab's avatar
      i82860_edac: convert driver to use the new edac ABI · 84c3a684
      Mauro Carvalho Chehab authored
      The legacy edac ABI is going to be removed. Port the driver to use
      and benefit from the new API functionality.
      
      Cc: Michal Marek <mmarek@suse.cz>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      84c3a684
    • Mauro Carvalho Chehab's avatar
      i82443bxgx_edac: convert driver to use the new edac ABI · 40f562b1
      Mauro Carvalho Chehab authored
      The legacy edac ABI is going to be removed. Port the driver to use
      and benefit from the new API functionality.
      
      Cc: Tim Small <tim@buttersideup.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      40f562b1
    • Mauro Carvalho Chehab's avatar
      i7core_edac: convert driver to use the new edac ABI · 0975c16f
      Mauro Carvalho Chehab authored
      The legacy edac ABI is going to be removed. Port the driver to use
      and benefit from the new API functionality.
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      0975c16f
    • Mauro Carvalho Chehab's avatar
      i7300_edac: convert driver to use the new edac ABI · 70e2a837
      Mauro Carvalho Chehab authored
      The legacy edac ABI is going to be removed. Port the driver to use
      and benefit from the new API functionality.
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      70e2a837
    • Mauro Carvalho Chehab's avatar
      i5400_edac: convert driver to use the new edac ABI · 296da591
      Mauro Carvalho Chehab authored
      The legacy edac ABI is going to be removed. Port the driver to use
      and benefit from the new API functionality.
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      296da591
    • Mauro Carvalho Chehab's avatar
      i5100_edac: convert driver to use the new edac ABI · d1afaa0a
      Mauro Carvalho Chehab authored
      The legacy edac ABI is going to be removed. Port the driver to use
      and benefit from the new API functionality.
      
      Cc: "Niklas Söderlund" <niklas.soderlund@ericsson.com>
      Cc: Borislav Petkov <borislav.petkov@amd.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      d1afaa0a
    • Mauro Carvalho Chehab's avatar
      i5000_edac: convert driver to use the new edac ABI · 702df640
      Mauro Carvalho Chehab authored
      The legacy edac ABI is going to be removed. Port the driver to use
      and benefit from the new API functionality.
      
      Cc: Doug Thompson <norsk5@yahoo.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      702df640
    • Mauro Carvalho Chehab's avatar
      i3200_edac: convert driver to use the new edac ABI · 95b93287
      Mauro Carvalho Chehab authored
      The legacy edac ABI is going to be removed. Port the driver to use
      and benefit from the new API functionality.
      
      Cc: Hitoshi Mitake <h.mitake@gmail.com>
      Cc: Borislav Petkov <borislav.petkov@amd.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      95b93287
    • Mauro Carvalho Chehab's avatar
      i3000_edac: convert driver to use the new edac ABI · 884906f1
      Mauro Carvalho Chehab authored
      The legacy edac ABI is going to be removed. Port the driver to use
      and benefit from the new API functionality.
      
      Cc: Jason Uhlenkott <juhlenko@akamai.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      884906f1
    • Mauro Carvalho Chehab's avatar
      e7xxx_edac: convert driver to use the new edac ABI · 30ac4406
      Mauro Carvalho Chehab authored
      The legacy edac ABI is going to be removed. Port the driver to use
      and benefit from the new API functionality.
      
      Cc: Doug Thompson <norsk5@yahoo.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      30ac4406
    • Mauro Carvalho Chehab's avatar
      e752x_edac: convert driver to use the new edac ABI · ce11ce17
      Mauro Carvalho Chehab authored
      The legacy edac ABI is going to be removed. Port the driver to use
      and benefit from the new API functionality.
      
      Cc: Mark Gross <mark.gross@intel.com>
      Cc: Doug Thompson <norsk5@yahoo.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      ce11ce17
    • Mauro Carvalho Chehab's avatar
      cpc925_edac: convert driver to use the new edac ABI · df62b1e6
      Mauro Carvalho Chehab authored
      The legacy edac ABI is going to be removed. Port the driver to use
      and benefit from the new API functionality.
      
      Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Michal Marek <mmarek@suse.cz>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      df62b1e6
    • Mauro Carvalho Chehab's avatar
      cell_edac: convert driver to use the new edac ABI · 6458fc08
      Mauro Carvalho Chehab authored
      The legacy edac ABI is going to be removed. Port the driver to use
      and benefit from the new API functionality.
      
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Joe Perches <joe@perches.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      6458fc08
    • Mauro Carvalho Chehab's avatar
      amd76x_edac: convert driver to use the new edac ABI · d8c34af4
      Mauro Carvalho Chehab authored
      The legacy edac ABI is going to be removed. Port the driver to use
      and benefit from the new API functionality.
      
      Cc: Michal Marek <mmarek@suse.cz>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      d8c34af4
    • Mauro Carvalho Chehab's avatar
      amd64_edac: convert driver to use the new edac ABI · ab5a503c
      Mauro Carvalho Chehab authored
      The legacy edac ABI is going to be removed. Port the driver to use
      and benefit from the new API functionality.
      
      Cc: Doug Thompson <norsk5@yahoo.com>
      Cc: Borislav Petkov <borislav.petkov@amd.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      ab5a503c
    • Mauro Carvalho Chehab's avatar
      edac: Change internal representation to work with layers · 4275be63
      Mauro Carvalho Chehab authored
      Change the EDAC internal representation to work with non-csrow
      based memory controllers.
      
      There are lots of those memory controllers nowadays, and more
      are coming. So, the EDAC internal representation needs to be
      changed, in order to work with those memory controllers, while
      preserving backward compatibility with the old ones.
      
      The edac core was written with the idea that memory controllers
      are able to directly access csrows.
      
      This is not true for FB-DIMM and RAMBUS memory controllers.
      
      Also, some recent advanced memory controllers don't present a per-csrows
      view. Instead, they view memories as DIMMs, instead of ranks.
      
      So, change the allocation and error report routines to allow
      them to work with all types of architectures.
      
      This will allow the removal of several hacks with FB-DIMM and RAMBUS
      memory controllers.
      
      Also, several tests were done on different platforms using different
      x86 drivers.
      
      TODO: a multi-rank DIMMs are currently represented by multiple DIMM
      entries in struct dimm_info. That means that changing a label for one
      rank won't change the same label for the other ranks at the same DIMM.
      This bug is present since the beginning of the EDAC, so it is not a big
      deal. However, on several drivers, it is possible to fix this issue, but
      it should be a per-driver fix, as the csrow => DIMM arrangement may not
      be equal for all. So, don't try to fix it here yet.
      
      I tried to make this patch as short as possible, preceding it with
      several other patches that simplified the logic here. Yet, as the
      internal API changes, all drivers need changes. The changes are
      generally bigger in the drivers for FB-DIMMs.
      
      Cc: Aristeu Rozanski <arozansk@redhat.com>
      Cc: Doug Thompson <norsk5@yahoo.com>
      Cc: Borislav Petkov <borislav.petkov@amd.com>
      Cc: Mark Gross <mark.gross@intel.com>
      Cc: Jason Uhlenkott <juhlenko@akamai.com>
      Cc: Tim Small <tim@buttersideup.com>
      Cc: Ranganathan Desikan <ravi@jetztechnologies.com>
      Cc: "Arvind R." <arvino55@gmail.com>
      Cc: Olof Johansson <olof@lixom.net>
      Cc: Egor Martovetsky <egor@pasemi.com>
      Cc: Chris Metcalf <cmetcalf@tilera.com>
      Cc: Michal Marek <mmarek@suse.cz>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Joe Perches <joe@perches.com>
      Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Hitoshi Mitake <h.mitake@gmail.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: "Niklas Söderlund" <niklas.soderlund@ericsson.com>
      Cc: Shaohui Xie <Shaohui.Xie@freescale.com>
      Cc: Josh Boyer <jwboyer@gmail.com>
      Cc: linuxppc-dev@lists.ozlabs.org
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      4275be63
    • Mauro Carvalho Chehab's avatar
      edac.h: Add generic layers for describing a memory location · 982216a4
      Mauro Carvalho Chehab authored
      The edac core were written with the idea that memory controllers
      are able to directly access csrows, and that the channels are
      used inside a csrows select.
      
      This is not true for FB-DIMM and RAMBUS memory controllers.
      
      Also, some recent advanced memory controllers don't present a per-csrows
      view. Instead, they view memories as DIMMs, instead of ranks, accessed
      via csrow/channel.
      
      So, changes are needed in order to allow the EDAC core to
      work with all types of architectures.
      
      In preparation for handling non-csrows based memory controllers,
      add some memory structs and a macro:
      
      enum hw_event_mc_err_type: describes the type of error
      			   (corrected, uncorrected, fatal)
      
      To be used by the new edac_mc_handle_error function;
      
      enum edac_mc_layer: describes the type of a given memory
      architecture layer (branch, channel, slot, csrow).
      
      struct edac_mc_layer: describes the properties of a memory
      		      layer (type, size, and if the layer
      		      will be used on a virtual csrow.
      
      EDAC_DIMM_PTR() - as the number of layers can vary from 1 to 3,
      this macro converts from an address with up to 3 layers into
      a linear address.
      Reviewed-by: default avatarBorislav Petkov <bp@amd64.org>
      Cc: Doug Thompson <norsk5@yahoo.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      982216a4
    • Mauro Carvalho Chehab's avatar
      edac: rewrite edac_align_ptr() · 93e4fe64
      Mauro Carvalho Chehab authored
      The edac_align_ptr() function is used to prepare data for a single
      memory allocation kzalloc() call. It counts how many bytes are needed
      by some data structure.
      
      Using it as-is is not that trivial, as the quantity of memory elements
      reserved is not there, but, instead, it is on a next call.
      
      In order to avoid mistakes when using it, move the number of allocated
      elements into it, making easier to use it.
      Reviewed-by: default avatarBorislav Petkov <bp@amd64.org>
      Cc: Aristeu Rozanski <arozansk@redhat.com>
      Cc: Doug Thompson <norsk5@yahoo.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      93e4fe64
    • Mauro Carvalho Chehab's avatar
      edac: move nr_pages to dimm struct · a895bf8b
      Mauro Carvalho Chehab authored
      The number of pages is a dimm property. Move it to the dimm struct.
      
      After this change, it is possible to add sysfs nodes for the DIMM's that
      will properly represent the DIMM stick properties, including its size.
      
      A TODO fix here is to properly represent dual-rank/quad-rank DIMMs when
      the memory controller represents the memory via chip select rows.
      Reviewed-by: default avatarAristeu Rozanski <arozansk@redhat.com>
      Acked-by: default avatarBorislav Petkov <borislav.petkov@amd.com>
      Acked-by: default avatarChris Metcalf <cmetcalf@tilera.com>
      Cc: Doug Thompson <norsk5@yahoo.com>
      Cc: Mark Gross <mark.gross@intel.com>
      Cc: Jason Uhlenkott <juhlenko@akamai.com>
      Cc: Tim Small <tim@buttersideup.com>
      Cc: Ranganathan Desikan <ravi@jetztechnologies.com>
      Cc: "Arvind R." <arvino55@gmail.com>
      Cc: Olof Johansson <olof@lixom.net>
      Cc: Egor Martovetsky <egor@pasemi.com>
      Cc: Michal Marek <mmarek@suse.cz>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Joe Perches <joe@perches.com>
      Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Hitoshi Mitake <h.mitake@gmail.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: "Niklas Söderlund" <niklas.soderlund@ericsson.com>
      Cc: Shaohui Xie <Shaohui.Xie@freescale.com>
      Cc: Josh Boyer <jwboyer@gmail.com>
      Cc: linuxppc-dev@lists.ozlabs.org
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      a895bf8b
    • Mauro Carvalho Chehab's avatar
      edac: Don't initialize csrow's first_page & friends when not needed · 5e2af0c0
      Mauro Carvalho Chehab authored
      Almost all edac	drivers	initialize csrow_info->first_page,
      csrow_info->last_page and csrow_info->page_mask. Those vars are
      used inside the EDAC core, in order to calculate the csrow affected
      by an error, by using the routine edac_mc_find_csrow_by_page().
      
      However, very few drivers actually use it:
              e752x_edac.c
              e7xxx_edac.c
              i3000_edac.c
              i82443bxgx_edac.c
              i82860_edac.c
              i82875p_edac.c
              i82975x_edac.c
              r82600_edac.c
      
      There also a few other drivers that have their own calculus
      formula internally using those vars.
      
      All the others are just wasting time by initializing those
      data.
      
      While initializing data without using them won't cause any troubles, as
      those information is stored at the wrong place (at csrows structure), it
      is better to remove what is unused, in order to simplify the next patch.
      Reviewed-by: default avatarAristeu Rozanski <arozansk@redhat.com>
      Acked-by: default avatarBorislav Petkov <borislav.petkov@amd.com>
      Acked-by: default avatarChris Metcalf <cmetcalf@tilera.com>
      Cc: Doug Thompson <norsk5@yahoo.com>
      Cc: Hitoshi Mitake <h.mitake@gmail.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: "Niklas Söderlund" <niklas.soderlund@ericsson.com>
      Cc: Josh Boyer <jwboyer@gmail.com>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      5e2af0c0
    • Mauro Carvalho Chehab's avatar
      edac: move dimm properties to struct dimm_info · 084a4fcc
      Mauro Carvalho Chehab authored
      On systems based on chip select rows, all channels need to use memories
      with the same properties, otherwise the memories on channels A and B
      won't be recognized.
      
      However, such assumption is not true for all types of memory
      controllers.
      
      Controllers for FB-DIMM's don't have such requirements.
      
      Also, modern Intel controllers seem to be capable of handling such
      differences.
      
      So, we need to get rid of storing the DIMM information into a per-csrow
      data, storing it, instead at the right place.
      
      The first step is to move grain, mtype, dtype and edac_mode to the
      per-dimm struct.
      Reviewed-by: default avatarAristeu Rozanski <arozansk@redhat.com>
      Reviewed-by: default avatarBorislav Petkov <borislav.petkov@amd.com>
      Acked-by: default avatarChris Metcalf <cmetcalf@tilera.com>
      Cc: Doug Thompson <norsk5@yahoo.com>
      Cc: Borislav Petkov <borislav.petkov@amd.com>
      Cc: Mark Gross <mark.gross@intel.com>
      Cc: Jason Uhlenkott <juhlenko@akamai.com>
      Cc: Tim Small <tim@buttersideup.com>
      Cc: Ranganathan Desikan <ravi@jetztechnologies.com>
      Cc: "Arvind R." <arvino55@gmail.com>
      Cc: Olof Johansson <olof@lixom.net>
      Cc: Egor Martovetsky <egor@pasemi.com>
      Cc: Michal Marek <mmarek@suse.cz>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Joe Perches <joe@perches.com>
      Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Hitoshi Mitake <h.mitake@gmail.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: James Bottomley <James.Bottomley@parallels.com>
      Cc: "Niklas Söderlund" <niklas.soderlund@ericsson.com>
      Cc: Shaohui Xie <Shaohui.Xie@freescale.com>
      Cc: Josh Boyer <jwboyer@gmail.com>
      Cc: Mike Williams <mike@mikebwilliams.com>
      Cc: linuxppc-dev@lists.ozlabs.org
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      084a4fcc
    • Mauro Carvalho Chehab's avatar
      edac: Create a dimm struct and move the labels into it · a7d7d2e1
      Mauro Carvalho Chehab authored
      The way a DIMM is currently represented implies that they're
      linked into a per-csrow struct. However, some drivers don't see
      csrows, as they're ridden behind some chip like the AMB's
      on FBDIMM's, for example.
      
      This forced drivers to fake^Wvirtualize a csrow struct, and to create
      a mess under csrow/channel original's concept.
      
      Move the DIMM labels into a per-DIMM struct, and add there
      the real location of the socket, in terms of csrow/channel.
      Latter patches will modify the location to properly represent the
      memory architecture.
      
      All other drivers will use a per-csrow type of location.
      Some of those drivers will require a latter conversion, as
      they also fake the csrows internally.
      
      TODO: While this patch doesn't change the existing behavior, on
      csrows-based memory controllers, a csrow/channel pair points to a memory
      rank. There's a known bug at the EDAC core that allows having different
      labels for the same DIMM, if it has more than one rank. A latter patch
      is need to merge the several ranks for a DIMM into the same dimm_info
      struct, in order to avoid having different labels for the same DIMM.
      
      The edac_mc_alloc() will now contain a per-dimm initialization loop that
      will be changed by latter patches in order to match other types of
      memory architectures.
      Reviewed-by: default avatarAristeu Rozanski <arozansk@redhat.com>
      Reviewed-by: default avatarBorislav Petkov <borislav.petkov@amd.com>
      Cc: Doug Thompson <norsk5@yahoo.com>
      Cc: Ranganathan Desikan <ravi@jetztechnologies.com>
      Cc: "Arvind R." <arvino55@gmail.com>
      Cc: "Niklas Söderlund" <niklas.soderlund@ericsson.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      a7d7d2e1
  2. 20 May, 2012 1 commit
  3. 19 May, 2012 5 commits
    • Linus Torvalds's avatar
      Merge tag 'parisc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/parisc-2.6 · d6c77973
      Linus Torvalds authored
      Pull PA-RISC fixes from James Bottomley:
       "This is a set of three bug fixes that gets parisc running again on
        systems with PA1.1 processors.
      
        Two fix regressions introduced in 2.6.39 and one fixes a prefetch bug
        that only affects PA7300LC processors.  We also have another pending
        fix to do with the sectional arrangement of vmlinux.lds, but there's a
        query on it during testing on one particular system type, so I'll hold
        off sending it in for now."
      
      * tag 'parisc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/parisc-2.6:
        [PARISC] fix panic on prefetch(NULL) on PA7300LC
        [PARISC] fix crash in flush_icache_page_asm on PA1.1
        [PARISC] fix PA1.1 oops on boot
      d6c77973
    • Linus Torvalds's avatar
      Merge branch 'x86/ld-fix' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 5d120458
      Linus Torvalds authored
      Pull x86 linker bug workarounds from Peter Anvin.
      
      GNU ld-2.22.52.0.[12] (*) has an unfortunate bug where it incorrectly
      turns certain relocation entries absolute.  Section-relative symbols
      that are part of otherwise empty sections are silently changed them to
      absolute.  We rely on section-relative symbols staying section-relative,
      and actually have several sections in the linker script solely for this
      purpose.
      
      See for example
      
         http://sourceware.org/bugzilla/show_bug.cgi?id=14052
      
      We could just black-list the buggy linker, but it appears that it got
      shipped in at least F17, and possibly other distros too, so it's sadly
      not some rare unusual case.
      
      This backports the workaround from the x86/trampoline branch, and as
      Peter says: "This is not a minimal fix, not at all, but it is a tested
      code base."
      
      * 'x86/ld-fix' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        x86, relocs: When printing an error, say relative or absolute
        x86, relocs: Workaround for binutils 2.22.52.0.1 section bug
        x86, realmode: 16-bit real-mode code support for relocs tool
      
      (*) That's a manly release numbering system. Stupid, sure. But manly.
      5d120458
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.dk/linux-block · 14e931a2
      Linus Torvalds authored
      Pull block layer fixes from Jens Axboe:
       "A few small, but important fixes.  Most of them are marked for stable
        as well
      
         - Fix failure to release a semaphore on error path in mtip32xx.
         - Fix crashable condition in bio_get_nr_vecs().
         - Don't mark end-of-disk buffers as mapped, limit it to i_size.
         - Fix for build problem with CONFIG_BLOCK=n on arm at least.
         - Fix for a buffer overlow on UUID partition printing.
         - Trivial removal of unused variables in dac960."
      
      * 'for-linus' of git://git.kernel.dk/linux-block:
        block: fix buffer overflow when printing partition UUIDs
        Fix blkdev.h build errors when BLOCK=n
        bio allocation failure due to bio_get_nr_vecs()
        block: don't mark buffers beyond end of disk as mapped
        mtip32xx: release the semaphore on an error path
        dac960: Remove unused variables from DAC960_CreateProcEntries()
      14e931a2
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net · a2ae9787
      Linus Torvalds authored
      Pull one more networking bug-fix from David Miller:
       "One last straggler.
      
        Eric Dumazet's pktgen unload oops fix was not entirely complete, but
        all the cases should be handled properly now....  fingers crossed."
      
      * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net:
        pktgen: fix module unload for good
      a2ae9787
    • Hugh Dickins's avatar
      memcg,thp: fix res_counter:96 regression · 62ade86a
      Hugh Dickins authored
      Occasionally, testing memcg's move_charge_at_immigrate on rc7 shows
      a flurry of hundreds of warnings at kernel/res_counter.c:96, where
      res_counter_uncharge_locked() does WARN_ON(counter->usage < val).
      
      The first trace of each flurry implicates __mem_cgroup_cancel_charge()
      of mc.precharge, and an audit of mc.precharge handling points to
      mem_cgroup_move_charge_pte_range()'s THP handling in commit 12724850
      ("memcg: avoid THP split in task migration").
      
      Checking !mc.precharge is good everywhere else, when a single page is to
      be charged; but here the "mc.precharge -= HPAGE_PMD_NR" likely to
      follow, is liable to result in underflow (a lot can change since the
      precharge was estimated).
      
      Simply check against HPAGE_PMD_NR: there's probably a better
      alternative, trying precharge for more, splitting if unsuccessful; but
      this one-liner is safer for now - no kernel/res_counter.c:96 warnings
      seen in 26 hours.
      Signed-off-by: default avatarHugh Dickins <hughd@google.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      62ade86a