07 Jan, 2012

1 commit


21 Dec, 2011

1 commit

  • Several fields in struct cpuinfo_x86 were not defined for the
    !SMP case, likely to save space. However, those fields still
    have some meaning for UP, and keeping them allows some #ifdef
    removal from other files. The additional size of the UP kernel
    from this change is not significant enough to worry about
    keeping up the distinction:

    text data bss dec hex filename
    4737168 506459 972040 6215667 5ed7f3 vmlinux.o.before
    4737444 506459 972040 6215943 5ed907 vmlinux.o.after

    for a difference of 276 bytes for an example UP config.

    If someone wants those 276 bytes back badly then it should
    be implemented in a cleaner way.

    Signed-off-by: Kevin Winchester
    Cc: Steffen Persvold
    Link: http://lkml.kernel.org/r/1324428742-12498-1-git-send-email-kjwinchester@gmail.com
    Signed-off-by: Ingo Molnar

    Kevin Winchester
     

14 Dec, 2011

1 commit


01 Nov, 2011

3 commits

  • The edac driver for Sandy Bridge was found to be reporting "FPM"
    for edac_mode, which clearly doesn't make sense. It was found that
    sb_edac.c:get_dimm_config was reusing a variable for both mem_type
    and edac_type, and thus was overwriting the value after setting
    it correctly. This patch fixes that issue.

    Before the patch:
    /sys/devices/system/edac/mc/mc0/csrow0/edac_mode:FPM
    /sys/devices/system/edac/mc/mc0/csrow1/edac_mode:FPM
    /sys/devices/system/edac/mc/mc0/csrow2/edac_mode:FPM
    /sys/devices/system/edac/mc/mc0/csrow3/edac_mode:FPM

    After:
    /sys/devices/system/edac/mc/mc0/csrow0/edac_mode:S4ECD4ED
    /sys/devices/system/edac/mc/mc0/csrow1/edac_mode:S4ECD4ED
    /sys/devices/system/edac/mc/mc0/csrow2/edac_mode:S4ECD4ED
    /sys/devices/system/edac/mc/mc0/csrow3/edac_mode:S4ECD4ED

    Signed-off-by: Mark A. Grondona
    Signed-off-by: Mauro Carvalho Chehab

    Mark A. Grondona
     
  • Some changes on it were required due to changeset cd90cc84c6bf0, that
    changed the glue with the MCE logic.

    Signed-off-by: Mauro Carvalho Chehab

    Mauro Carvalho Chehab
     
  • This driver is known to work on mine and Tony's test environments,
    using software error injection, and a partial hardware/software
    error injection tool.

    There's no broader range test yet to double check if the error decoding
    logic will actually point to the right DIMM, so use it with care.
    More tests are required to be sure that the driver will work on all
    different types of memory configurations.

    If you're willing to risk using it, I suggest you to enable EDAC debugs
    for your test machines, as the debug logs helps to track what's going
    inside the driver.

    Please feed me with bug reports, if you notice that the driver
    is miss-behaving.

    Tested-by: Tony Luck
    Signed-off-by: Mauro Carvalho Chehab

    Mauro Carvalho Chehab