1. 23 7月, 2007 1 次提交
  2. 22 7月, 2007 1 次提交
    • T
      x86_64: support poll() on /dev/mcelog · e02e68d3
      Tim Hockin 提交于
      Background:
       /dev/mcelog is typically polled manually.  This is less than optimal for
       situations where accurate accounting of MCEs is important.  Calling
       poll() on /dev/mcelog does not work.
      
      Description:
       This patch adds support for poll() to /dev/mcelog.  This results in
       immediate wakeup of user apps whenever the poller finds MCEs.  Because
       the exception handler can not take any locks, it can not call the wakeup
       itself.  Instead, it uses a thread_info flag (TIF_MCE_NOTIFY) which is
       caught at the next return from interrupt or exit from idle, calling the
       mce_user_notify() routine.  This patch also disables the "fake panic"
       path of the mce_panic(), because it results in printk()s in the exception
       handler and crashy systems.
      
       This patch also does some small cleanup for essentially unused variables,
       and moves the user notification into the body of the poller, so it is
       only called once per poll, rather than once per CPU.
      
      Result:
       Applications can now poll() on /dev/mcelog.  When an error is logged
       (whether through the poller or through an exception) the applications are
       woken up promptly.  This should not affect any previous behaviors.  If no
       MCEs are being logged, there is no overhead.
      
      Alternatives:
       I considered simply supporting poll() through the poller and not using
       TIF_MCE_NOTIFY at all.  However, the time between an uncorrectable error
       happening and the user application being notified is *the*most* critical
       window for us.  Many uncorrectable errors can be logged to the network if
       given a chance.
      
       I also considered doing the MCE poll directly from the idle notifier, but
       decided that was overkill.
      
      Testing:
       I used an error-injecting DIMM to create lots of correctable DRAM errors
       and verified that my user app is woken up in sync with the polling interval.
       I also used the northbridge to inject uncorrectable ECC errors, and
       verified (printk() to the rescue) that the notify routine is called and the
       user app does wake up.  I built with PREEMPT on and off, and verified
       that my machine survives MCEs.
      
      [wli@holomorphy.com: build fix]
      Signed-off-by: NTim Hockin <thockin@google.com>
      Signed-off-by: NWilliam Irwin <bill.irwin@oracle.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e02e68d3
  3. 13 2月, 2007 1 次提交
    • A
      [PATCH] x86-64: Allow to run a program when a machine check event is detected · a98f0dd3
      Andi Kleen 提交于
      When a machine check event is detected (including a AMD RevF threshold
      overflow event) allow to run a "trigger" program. This allows user space
      to react to such events sooner.
      
      The trigger is configured using a new trigger entry in the
      machinecheck sysfs interface. It is currently shared between
      all CPUs.
      
      I also fixed the AMD threshold handler to run the machine
      check polling code immediately to actually log any events
      that might have caused the threshold interrupt.
      
      Also added some documentation for the mce sysfs interface.
      Signed-off-by: NAndi Kleen <ak@suse.de>
      a98f0dd3
  4. 26 9月, 2006 1 次提交
    • D
      [PATCH] x86: Refactor thermal throttle processing · 15d5f839
      Dmitriy Zavin 提交于
      Refactor the event processing (syslog messaging and rate limiting)
      into separate file therm_throt.c. This allows consistent reporting
      of CPU thermal throttle events.
      
      After ACK'ing the interrupt, if the event is current, the user
      (p4.c/mce_intel.c) calls therm_throt_process to log (and rate limit)
      the event. If that function returns 1, the user has the option to log
      things further (such as to mce_log in x86_64).
      
      AK: minor cleanup
      Signed-off-by: NDmitriy Zavin <dmitriyz@google.com>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      15d5f839
  5. 27 6月, 2006 2 次提交
  6. 10 4月, 2006 1 次提交
  7. 15 11月, 2005 1 次提交
    • J
      [PATCH] x86_64: Support for AMD specific MCE Threshold. · 89b831ef
      Jacob Shin 提交于
      MC4_MISC - DRAM Errors Threshold Register realized under AMD K8 Rev F.
      This register is used to count correctable and uncorrectable ECC errors that occur during DRAM read operations.
      The user may interface through sysfs files in order to change the threshold configuration.
      
      bank%d/error_count - reads current error count, write to clear.
      bank%d/interrupt_enable - set/clear interrupt enable.
      bank%d/threshold_limit - read/write the threshold limit.
      
      APIC vector 0xF9 in hw_irq.h.
      5 software defined bank ids in mce.h.
      new apic.c function to setup threshold apic lvt.
      defaults to interrupt off, count enabled, and threshold limit max.
      sysfs interface created on /sys/devices/system/threshold.
      
      AK: added some ifdefs to make it compile on UP
      Signed-off-by: NJacob Shin <jacob.shin@amd.com>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      89b831ef
  8. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4