1. 17 Aug, 2018 1 commit
  2. 14 Mar, 2018 2 commits
    • Tony Luck's avatar
      EDAC: Add new memory type for non-volatile DIMMs · 001f8613
      Tony Luck authored
      There are now non-volatile versions of DIMMs. Add a new entry to "enum
      mem_type" and a new string in edac_mem_types[].
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      Cc: Aristeu Rozanski <aris@redhat.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Jean Delvare <jdelvare@suse.com>
      Cc: Len Brown <lenb@kernel.org>
      Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
      Cc: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
      Cc: linux-acpi@vger.kernel.org
      Cc: linux-edac <linux-edac@vger.kernel.org>
      Cc: linux-nvdimm@lists.01.org
      Link: http://lkml.kernel.org/r/20180312182430.10335-3-tony.luck@intel.comSigned-off-by: default avatarBorislav Petkov <bp@suse.de>
      001f8613
    • Tony Luck's avatar
      EDAC: Drop duplicated array of strings for memory type names · d6dd77eb
      Tony Luck authored
      Somehow we ended up with two separate arrays of strings to describe the
      "enum mem_type" values.
      
      In edac_mc.c we have an exported list edac_mem_types[] that is used
      by a couple of drivers in debug messaged.
      
      In edac_mc_sysfs.c we have a private list that is used to display
      values in:
        /sys/devices/system/edac/mc/mc*/dimm*/dimm_mem_type
        /sys/devices/system/edac/mc/mc*/csrow*/mem_type
      
      This list was missing a value for MEM_LRDDR3.
      
      The string values in the two lists were different :-(
      
      Combining the lists, I kept the values so that the sysfs output
      will be unchanged as some scripts may depend on that.
      Reported-by: default avatarBorislav Petkov <bp@suse.de>
      Acked-by: default avatarBorislav Petkov <bp@suse.de>
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      Cc: Aristeu Rozanski <aris@redhat.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Jean Delvare <jdelvare@suse.com>
      Cc: Len Brown <lenb@kernel.org>
      Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
      Cc: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
      Cc: linux-acpi@vger.kernel.org
      Cc: linux-edac <linux-edac@vger.kernel.org>
      Cc: linux-nvdimm@lists.01.org
      Link: http://lkml.kernel.org/r/20180312182430.10335-2-tony.luck@intel.comSigned-off-by: default avatarBorislav Petkov <bp@suse.de>
      d6dd77eb
  3. 25 Sep, 2017 1 commit
  4. 10 Apr, 2017 6 commits
  5. 28 Jan, 2017 1 commit
  6. 24 Dec, 2016 1 commit
  7. 15 Dec, 2016 2 commits
  8. 14 Nov, 2016 1 commit
  9. 03 Jun, 2016 1 commit
    • Nicholas Krause's avatar
      EDAC: Fix workqueues poll period resetting · fbedcaf4
      Nicholas Krause authored
      After the workqueue cleanup, we're registering workqueues based on
      the presence of an ->edac_check function. When that is the case,
      we're setting OP_RUNNING_POLL. But we forgot to check that in
      edac_mc_reset_delay_period(), leading to:
      
        BUG: unable to handle kernel paging request at 0000000000015d10
        IP: [ .. ] queued_spin_lock_slowpath
        PGD 3ffcc8067 PUD 3ffc56067 PMD 0
        Oops: 0002 [#1] SMP
        Modules linked in: ...
        CPU: 1 PID: 2792 Comm: edactest Not tainted 4.6.0-dirty #1
        Hardware name: HP ProLiant MicroServer, BIOS O41     10/01/2013
        Stack:
        Call Trace:
          ? _raw_spin_lock_irqsave
          ? lock_timer_base.isra.34
          ? del_timer
          ? try_to_grab_pending
          ? mod_delayed_work_on
          ? edac_mc_reset_delay_period
          ? edac_set_poll_msec
          ? param_attr_store
          ? module_attr_store
          ? kernfs_fop_write
          ? __vfs_write
          ? __vfs_read
          ? __alloc_fd
          ? vfs_write
          ? SyS_write
          ? entry_SYSCALL_64_fastpath
        Code:
        RIP  [ .. ] queued_spin_lock_slowpath
         RSP <>
        CR2: 0000000000015d10
        ---[ end trace 3f286bc71cca15d1 ]---
        Kernel panic - not syncing: Fatal exception
      
      Fix it.
      Signed-off-by: Nicholas Krause's avatarNicholas Krause <xerofoify@gmail.com>
      Cc: <stable@vger.kernel.org> # 4.5
      Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
      Cc: linux-edac <linux-edac@vger.kernel.org>
      Link: http://lkml.kernel.org/r/1463697958-13406-1-git-send-email-xerofoify@gmail.com
      [ Rewrite commit message. ]
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      fbedcaf4
  10. 23 Apr, 2016 1 commit
  11. 02 Feb, 2016 3 commits
  12. 11 Dec, 2015 2 commits
    • Borislav Petkov's avatar
      EDAC: Rework workqueue handling · c4cf3b45
      Borislav Petkov authored
      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
      
        91b99041 ("drivers/edac: updated PCI monitoring")
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      c4cf3b45
    • Borislav Petkov's avatar
      EDAC: Robustify workqueues destruction · fcd5c4dd
      Borislav Petkov authored
      EDAC workqueue destruction is really fragile. We cancel delayed work
      but if it is still running and requeues itself, we still go ahead and
      destroy the workqueue and the queued work explodes when workqueue core
      attempts to run it.
      
      Make the destruction more robust by switching op_state to offline so
      that requeuing stops. Cancel any pending work *synchronously* too.
      
        EDAC i7core: Driver loaded.
        general protection fault: 0000 [#1] SMP
        CPU 12
        Modules linked in:
        Supported: Yes
        Pid: 0, comm: kworker/0:1 Tainted: G          IE   3.0.101-0-default #1 HP ProLiant DL380 G7
        RIP: 0010:[<ffffffff8107dcd7>]  [<ffffffff8107dcd7>] __queue_work+0x17/0x3f0
        < ... regs ...>
        Process kworker/0:1 (pid: 0, threadinfo ffff88019def6000, task ffff88019def4600)
        Stack:
         ...
        Call Trace:
         call_timer_fn
         run_timer_softirq
         __do_softirq
         call_softirq
         do_softirq
         irq_exit
         smp_apic_timer_interrupt
         apic_timer_interrupt
         intel_idle
         cpuidle_idle_call
         cpu_idle
        Code: ...
        RIP  __queue_work
         RSP <...>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Cc: <stable@vger.kernel.org>
      fcd5c4dd
  13. 22 Oct, 2015 1 commit
  14. 28 May, 2015 1 commit
    • Borislav Petkov's avatar
      EDAC: Cleanup atomic_scrub mess · b01aec9b
      Borislav Petkov authored
      So first of all, this atomic_scrub() function's naming is bad. It looks
      like an atomic_t helper. Change it to edac_atomic_scrub().
      
      The bigger problem is that this function is arch-specific and every new
      arch which doesn't necessarily need that functionality still needs to
      define it, otherwise EDAC doesn't compile.
      
      So instead of doing that and including arch-specific headers, have each
      arch define an EDAC_ATOMIC_SCRUB symbol which can be used in edac_mc.c
      for ifdeffery. Much cleaner.
      
      And we already are doing this with another symbol - EDAC_SUPPORT. This
      is also much cleaner than having CONFIG_EDAC enumerate all the arches
      which need/have EDAC support and drivers.
      
      This way I can kill the useless edac.h header in tile too.
      Acked-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Acked-by: Michael Ellerman's avatarMichael Ellerman <mpe@ellerman.id.au>
      Acked-by: default avatarChris Metcalf <cmetcalf@ezchip.com>
      Acked-by: default avatarIngo Molnar <mingo@kernel.org>
      Acked-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Doug Thompson <dougthompson@xmission.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-edac@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Cc: linux-mips@linux-mips.org
      Cc: linuxppc-dev@lists.ozlabs.org
      Cc: "Maciej W. Rozycki" <macro@codesourcery.com>
      Cc: Markos Chandras <markos.chandras@imgtec.com>
      Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: "Steven J. Hill" <Steven.Hill@imgtec.com>
      Cc: x86@kernel.org
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      b01aec9b
  15. 23 Feb, 2015 1 commit
  16. 20 Oct, 2014 2 commits
  17. 02 Sep, 2014 1 commit
  18. 23 Jun, 2014 1 commit
  19. 09 May, 2014 1 commit
  20. 14 Feb, 2014 2 commits
  21. 04 Nov, 2013 1 commit
  22. 23 Jul, 2013 1 commit
    • Borislav Petkov's avatar
      EDAC: Fix lockdep splat · 88d84ac9
      Borislav Petkov authored
      Fix the following:
      
      BUG: key ffff88043bdd0330 not in .data!
      ------------[ cut here ]------------
      WARNING: at kernel/lockdep.c:2987 lockdep_init_map+0x565/0x5a0()
      DEBUG_LOCKS_WARN_ON(1)
      Modules linked in: glue_helper sb_edac(+) edac_core snd acpi_cpufreq lrw gf128mul ablk_helper iTCO_wdt evdev i2c_i801 dcdbas button cryptd pcspkr iTCO_vendor_support usb_common lpc_ich mfd_core soundcore mperf processor microcode
      CPU: 2 PID: 599 Comm: modprobe Not tainted 3.10.0 #1
      Hardware name: Dell Inc. Precision T3600/0PTTT9, BIOS A08 01/24/2013
       0000000000000009 ffff880439a1d920 ffffffff8160a9a9 ffff880439a1d958
       ffffffff8103d9e0 ffff88043af4a510 ffffffff81a16e11 0000000000000000
       ffff88043bdd0330 0000000000000000 ffff880439a1d9b8 ffffffff8103dacc
      Call Trace:
        dump_stack
        warn_slowpath_common
        warn_slowpath_fmt
        lockdep_init_map
        ? trace_hardirqs_on_caller
        ? trace_hardirqs_on
        debug_mutex_init
        __mutex_init
        bus_register
        edac_create_sysfs_mci_device
        edac_mc_add_mc
        sbridge_probe
        pci_device_probe
        driver_probe_device
        __driver_attach
        ? driver_probe_device
        bus_for_each_dev
        driver_attach
        bus_add_driver
        driver_register
        __pci_register_driver
        ? 0xffffffffa0010fff
        sbridge_init
        ? 0xffffffffa0010fff
        do_one_initcall
        load_module
        ? unset_module_init_ro_nx
        SyS_init_module
        tracesys
      ---[ end trace d24a70b0d3ddf733 ]---
      EDAC MC0: Giving out device to 'sbridge_edac.c' 'Sandy Bridge Socket#0': DEV 0000:3f:0e.0
      EDAC sbridge: Driver loaded.
      
      What happens is that bus_register needs a statically allocated lock_key
      because the last is handed in to lockdep. However, struct mem_ctl_info
      embeds struct bus_type (the whole struct, not a pointer to it) and the
      whole thing gets dynamically allocated.
      
      Fix this by using a statically allocated struct bus_type for the MC bus.
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Acked-by: default avatarMauro Carvalho Chehab <mchehab@infradead.org>
      Cc: Markus Trippelsdorf <markus@trippelsdorf.de>
      Cc: stable@kernel.org # v3.10
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      88d84ac9
  23. 16 Mar, 2013 1 commit
  24. 21 Feb, 2013 4 commits
  25. 30 Jan, 2013 1 commit