1. 01 11月, 2011 1 次提交
    • P
      x86: Fix files explicitly requiring export.h for EXPORT_SYMBOL/THIS_MODULE · 69c60c88
      Paul Gortmaker 提交于
      These files were implicitly getting EXPORT_SYMBOL via device.h
      which was including module.h, but that will be fixed up shortly.
      
      By fixing these now, we can avoid seeing things like:
      
      arch/x86/kernel/rtc.c:29: warning: type defaults to ‘int’ in declaration of ‘EXPORT_SYMBOL’
      arch/x86/kernel/pci-dma.c:20: warning: type defaults to ‘int’ in declaration of ‘EXPORT_SYMBOL’
      arch/x86/kernel/e820.c:69: warning: type defaults to ‘int’ in declaration of ‘EXPORT_SYMBOL_GPL’
      
      [ with input from Randy Dunlap <rdunlap@xenotime.net> and also
        from Stephen Rothwell <sfr@canb.auug.org.au> ]
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      69c60c88
  2. 16 5月, 2011 1 次提交
    • Y
      x86, apic: Fix spurious error interrupts triggering on all non-boot APs · e503f9e4
      Youquan Song 提交于
      This patch fixes a bug reported by a customer, who found
      that many unreasonable error interrupts reported on all
      non-boot CPUs (APs) during the system boot stage.
      
      According to Chapter 10 of Intel Software Developer Manual
      Volume 3A, Local APIC may signal an illegal vector error when
      an LVT entry is set as an illegal vector value (0~15) under
      FIXED delivery mode (bits 8-11 is 0), regardless of whether
      the mask bit is set or an interrupt actually happen. These
      errors are seen as error interrupts.
      
      The initial value of thermal LVT entries on all APs always reads
      0x10000 because APs are woken up by BSP issuing INIT-SIPI-SIPI
      sequence to them and LVT registers are reset to 0s except for
      the mask bits which are set to 1s when APs receive INIT IPI.
      
      When the BIOS takes over the thermal throttling interrupt,
      the LVT thermal deliver mode should be SMI and it is required
      from the kernel to keep AP's LVT thermal monitoring register
      programmed as such as well.
      
      This issue happens when BIOS does not take over thermal throttling
      interrupt, AP's LVT thermal monitor register will be restored to
      0x10000 which means vector 0 and fixed deliver mode, so all APs will
      signal illegal vector error interrupts.
      
      This patch check if interrupt delivery mode is not fixed mode before
      restoring AP's LVT thermal monitor register.
      Signed-off-by: NYouquan Song <youquan.song@intel.com>
      Acked-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Acked-by: NYong Wang <yong.y.wang@intel.com>
      Cc: hpa@linux.intel.com
      Cc: joe@perches.com
      Cc: jbaron@redhat.com
      Cc: trenn@suse.de
      Cc: kent.liu@intel.com
      Cc: chaohong.guo@intel.com
      Cc: <stable@kernel.org> # As far back as possible
      Link: http://lkml.kernel.org/r/1303402963-17738-1-git-send-email-youquan.song@intel.comSigned-off-by: NIngo Molnar <mingo@elte.hu>
      e503f9e4
  3. 20 4月, 2011 1 次提交
  4. 29 3月, 2011 1 次提交
  5. 21 1月, 2011 1 次提交
  6. 04 1月, 2011 1 次提交
  7. 08 10月, 2010 1 次提交
  8. 06 9月, 2010 1 次提交
    • J
      therm_throt.c: Trivial printk message fix for a unsuitable abbreviation of 'thermal' · 592091c0
      Jin Dongming 提交于
      In unexpected_thermal_interrupt(), "LVT TMR interrupt" is used
      in error message.
      
      I don't think TMR is a suitable abbreviation for thermal.
        1.TMR has been used in IA32 Architectures Software Developer's
          Manual, and is the abbreviation for Trigger Mode Register.
        2.There is not an standard abbreviation "TMR" defined for thermal
          in IA32 Architectures Software Developer's Manual.
        3.Though we could understand it as Thermal Monitor Register, it is
          easy to be misunderstood as a *TIMER* interrupt also.
      
      I think this patch will fix it.
      Signed-off-by: NJin Dongming <jin.dongming@np.css.fujitsu.com>
      Reviewed-by: NJean Delvare <khali@linux-fr.org>
      Cc: Brown Len <len.brown@intel.com>
      Cc: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      LKML-Reference: <4C7C492D.5020704@np.css.fujitsu.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      592091c0
  9. 21 8月, 2010 1 次提交
  10. 04 8月, 2010 2 次提交
    • F
      x86, hwmon: Package Level Thermal/Power: power limit · 0199114c
      Fenghua Yu 提交于
      Power limit notification feature is published in Intel 64 and IA-32
      Architectures SDMV Vol 3A 14.5.6 Power Limit Notification.
      
      It is implemented first on Intel Sandy Bridge platform.
      
      The patch handles notification interrupt. Interrupt handler dumps power limit
      information in log_buf, logs the event in mce log, and increases the event
      counters (core_power_limit and package_power_limit). Upper level applications
      could use the data to detect system health or diagnose functionality/performance
      issues.
      
      In the future, the event could be handled in a more fancy way.
      Signed-off-by: NFenghua Yu <fenghua.yu@intel.com>
      LKML-Reference: <1280448826-12004-5-git-send-email-fenghua.yu@intel.com>
      Reviewed-by: NLen Brown <len.brown@intel.com>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      0199114c
    • F
      x86, hwmon: Package Level Thermal/Power: thermal throttling handler · 55d435a2
      Fenghua Yu 提交于
      Add package level thermal throttle interrupt support. The interrupt handler
      increases package level thermal throttle count. It also logs the event in MCE
      log.
      
      The package level thermal throttle interrupt happens across threads in a
      package. Each thread handles the interrupt individually. User level application
      is supposed to retrieve correct event count and log based on package/thread
      topology. This is the same situation for core level interrupt handler. In the
      future, interrupt may be reported only per package or per core.
      
      core_throttle_count and package_throttle_count are used for user interface.
      Previously only throttle_count is used for core throttle count. If you think
      new core_throttle_count name breaks user interface, I can change this part.
      Signed-off-by: NFenghua Yu <fenghua.yu@intel.com>
      LKML-Reference: <1280448826-12004-4-git-send-email-fenghua.yu@intel.com>
      Reviewed-by: NLen Brown <len.brown@intel.com>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      55d435a2
  11. 28 5月, 2010 1 次提交
  12. 14 12月, 2009 2 次提交
  13. 12 12月, 2009 1 次提交
    • M
      x86: Limit the number of processor bootup messages · 2eaad1fd
      Mike Travis 提交于
      When there are a large number of processors in a system, there
      is an excessive amount of messages sent to the system console.
      It's estimated that with 4096 processors in a system, and the
      console baudrate set to 56K, the startup messages will take
      about 84 minutes to clear the serial port.
      
      This set of patches limits the number of repetitious messages
      which contain no additional information.  Much of this information
      is obtainable from the /proc and /sysfs.   Some of the messages
      are also sent to the kernel log buffer as KERN_DEBUG messages so
      dmesg can be used to examine more closely any details specific to
      a problem.
      
      The new cpu bootup sequence for system_state == SYSTEM_BOOTING:
      
      Booting Node   0, Processors  #1 #2 #3 #4 #5 #6 #7 Ok.
      Booting Node   1, Processors  #8 #9 #10 #11 #12 #13 #14 #15 Ok.
      ...
      Booting Node   3, Processors  #56 #57 #58 #59 #60 #61 #62 #63 Ok.
      Brought up 64 CPUs
      
      After the system is running, a single line boot message is displayed
      when CPU's are hotplugged on:
      
          Booting Node %d Processor %d APIC 0x%x
      
      Status of the following lines:
      
          CPU: Physical Processor ID:		printed once (for boot cpu)
          CPU: Processor Core ID:		printed once (for boot cpu)
          CPU: Hyper-Threading is disabled	printed once (for boot cpu)
          CPU: Thermal monitoring enabled	printed once (for boot cpu)
          CPU %d/0x%x -> Node %d:		removed
          CPU %d is now offline:		only if system_state == RUNNING
          Initializing CPU#%d:		KERN_DEBUG
      Signed-off-by: NMike Travis <travis@sgi.com>
      LKML-Reference: <4B219E28.8080601@sgi.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      2eaad1fd
  14. 12 11月, 2009 1 次提交
  15. 11 11月, 2009 1 次提交
  16. 10 11月, 2009 1 次提交
    • Y
      x86: Under BIOS control, restore AP's APIC_LVTTHMR to the BSP value · a2202aa2
      Yong Wang 提交于
      On platforms where the BIOS handles the thermal monitor interrupt,
      APIC_LVTTHMR on each logical CPU is programmed to generate a SMI
      and OS must not touch it.
      
      Unfortunately AP bringup sequence using INIT-SIPI-SIPI clears all
      the LVT entries except the mask bit. Essentially this results in
      all LVT entries including the thermal monitoring interrupt set
      to masked (clearing the bios programmed value for APIC_LVTTHMR).
      
      And this leads to kernel take over the thermal monitoring
      interrupt on AP's but not on BSP (leaving the bios programmed
      value only on BSP).
      
      As a result of this, we have seen system hangs when the thermal
      monitoring interrupt is generated.
      
      Fix this by reading the initial value of thermal LVT entry on
      BSP and if bios has taken over the control, then program the
      same value on all AP's and leave the thermal monitoring
      interrupt control on all the logical cpu's to the bios.
      Signed-off-by: NYong Wang <yong.y.wang@intel.com>
      Reviewed-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Cc: Borislav Petkov <borislav.petkov@amd.com>
      Cc: Arjan van de Ven <arjan@infradead.org>
      LKML-Reference: <20091110013824.GA24940@ywang-moblin2.bj.intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Cc: stable@kernel.org
      a2202aa2
  17. 22 9月, 2009 2 次提交
    • I
      x86: mce: Fix thermal throttling message storm · b417c9fd
      Ingo Molnar 提交于
      If a system switches back and forth between hot and cold mode,
      the MCE code will print a stream of critical kernel messages.
      
      Extend the throttling code to properly notice this, by
      only printing the first hot + cold transition and omitting
      the rest up to CHECK_INTERVAL (5 minutes).
      
      This way we'll only get a single incident of:
      
       [  102.356584] CPU0: Temperature above threshold, cpu clock throttled (total events = 1)
       [  102.357000] Disabling lock debugging due to kernel taint
       [  102.369223] CPU0: Temperature/speed normal
      
      Every 5 minutes. The 'total events' count tells the number of cold/hot
      transitions detected, should overheating occur after 5 minutes again:
      
      [  402.357580] CPU0: Temperature above threshold, cpu clock throttled (total events = 24891)
      [  402.358001] CPU0: Temperature/speed normal
      [  450.704142] Machine check events logged
      
      Cc: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
      Cc: Huang Ying <ying.huang@intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      LKML-Reference: <new-submission>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      b417c9fd
    • I
      x86: mce: Clean up thermal throttling state tracking code · 39676840
      Ingo Molnar 提交于
      Instead of a mess of three separate percpu variables, consolidate
      the state into a single structure.
      
      Also clean up therm_throt_process(), use cleaner and more
      understandable variable names and a clearer logic.
      
      This, without changing the logic, makes the code more
      streamlined, more readable and smaller as well:
      
         text	   data	    bss	    dec	    hex	filename
         1487	    169	      4	   1660	    67c	therm_throt.o.before
         1432	    176	      4	   1612	    64c	therm_throt.o.after
      
      Cc: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
      Cc: Huang Ying <ying.huang@intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      LKML-Reference: <new-submission>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      39676840
  18. 16 8月, 2009 1 次提交
  19. 11 8月, 2009 1 次提交
    • D
      x86, mce: therm_throt - change when we print messages · 0d01f314
      Dmitry Torokhov 提交于
      My Latitude d630 seems to be handling thermal events in SMI by
      lowering the max frequency of the CPU till it cools down but
      still leaks the "everything is normal" events.
      
      This spams the console and with high priority printks.
      
      Adjust therm_throt driver to only print messages about the fact
      that temperatire returned back to normal when leaving the
      throttling state.
      
      Also lower the severity of "back to normal" message from
      KERN_CRIT to KERN_INFO.
      Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
      Acked-by: NH. Peter Anvin <hpa@zytor.com>
      LKML-Reference: <20090810051513.0558F526EC9@mailhub.coreip.homeip.net>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      0d01f314
  20. 30 7月, 2009 1 次提交
  21. 17 6月, 2009 4 次提交
  22. 29 5月, 2009 2 次提交
  23. 22 7月, 2008 1 次提交
    • A
      sysdev: Pass the attribute to the low level sysdev show/store function · 4a0b2b4d
      Andi Kleen 提交于
      This allow to dynamically generate attributes and share show/store
      functions between attributes. Right now most attributes are generated
      by special macros and lots of duplicated code. With the attribute
      passed it's instead possible to attach some data to the attribute
      and then use that in shared low level functions to do different things.
      
      I need this for the dynamically generated bank attributes in the x86
      machine check code, but it'll allow some further cleanups.
      
      I converted all users in tree to the new show/store prototype. It's a single
      huge patch to avoid unbisectable sections.
      
      Runtime tested: x86-32, x86-64
      Compiled only: ia64, powerpc
      Not compile tested/only grep converted: sh, arm, avr32
      Signed-off-by: NAndi Kleen <ak@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      4a0b2b4d
  24. 20 4月, 2008 1 次提交
  25. 10 2月, 2008 1 次提交
  26. 19 10月, 2007 1 次提交
  27. 18 10月, 2007 1 次提交
    • S
      i386: Fix section mismatch · 25d1b516
      Satyam Sharma 提交于
      Fix bugzilla #8679
      
      WARNING: arch/i386/kernel/built-in.o(.data+0x2148): Section mismatch: reference
      to .init.text: (between 'thermal_throttle_cpu_notifier' and 'mtrr_mutex')
      
      comes because struct notifier_block thermal_throttle_cpu_notifier in
      arch/i386/kernel/cpu/mcheck/therm_throt.c goes in .data section but the
      notifier callback function itself has been marked __cpuinit which becomes
      __init == .init.text when HOTPLUG_CPU=n.  The warning is bogus because the
      callback will never be called out if HOTPLUG_CPU=n in the first place (as
      one can see from kernel/cpu.c, the cpu_chain itself is __cpuinitdata :-)
      
      So, let's mark thermal_throttle_cpu_notifier as __cpuinitdata to fix
      the section mismatch warning.
      
      [ tglx: arch/x86 adaptation ]
      Signed-off-by: NSatyam Sharma <satyam@infradead.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      25d1b516
  28. 11 10月, 2007 1 次提交
  29. 16 7月, 2007 1 次提交
  30. 10 5月, 2007 1 次提交
    • R
      Add suspend-related notifications for CPU hotplug · 8bb78442
      Rafael J. Wysocki 提交于
      Since nonboot CPUs are now disabled after tasks and devices have been
      frozen and the CPU hotplug infrastructure is used for this purpose, we need
      special CPU hotplug notifications that will help the CPU-hotplug-aware
      subsystems distinguish normal CPU hotplug events from CPU hotplug events
      related to a system-wide suspend or resume operation in progress.  This
      patch introduces such notifications and causes them to be used during
      suspend and resume transitions.  It also changes all of the
      CPU-hotplug-aware subsystems to take these notifications into consideration
      (for now they are handled in the same way as the corresponding "normal"
      ones).
      
      [oleg@tv-sign.ru: cleanups]
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Cc: Gautham R Shenoy <ego@in.ibm.com>
      Cc: Pavel Machek <pavel@ucw.cz>
      Signed-off-by: NOleg Nesterov <oleg@tv-sign.ru>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8bb78442
  31. 09 5月, 2007 1 次提交
  32. 08 12月, 2006 1 次提交
  33. 04 12月, 2006 1 次提交