1. 16 5月, 2015 1 次提交
  2. 28 4月, 2015 1 次提交
  3. 15 4月, 2015 3 次提交
    • V
      Documentation: update arch list in the 'memtest' entry · e4b0db72
      Vladimir Murzin 提交于
      Since arm64/arm support memtest command line option update the "memtest"
      entry.
      Signed-off-by: NVladimir Murzin <vladimir.murzin@arm.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e4b0db72
    • T
      lib/ioremap.c: add huge I/O map capability interfaces · 0ddab1d2
      Toshi Kani 提交于
      Add ioremap_pud_enabled() and ioremap_pmd_enabled(), which return 1 when
      I/O mappings with pud/pmd are enabled on the kernel.
      
      ioremap_huge_init() calls arch_ioremap_pud_supported() and
      arch_ioremap_pmd_supported() to initialize the capabilities at boot-time.
      
      A new kernel option "nohugeiomap" is also added, so that user can disable
      the huge I/O map capabilities when necessary.
      Signed-off-by: NToshi Kani <toshi.kani@hp.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Robert Elliott <Elliott@hp.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0ddab1d2
    • U
      watchdog: enable the new user interface of the watchdog mechanism · 195daf66
      Ulrich Obergfell 提交于
      With the current user interface of the watchdog mechanism it is only
      possible to disable or enable both lockup detectors at the same time.
      This series introduces new kernel parameters and changes the semantics of
      some existing kernel parameters, so that the hard lockup detector and the
      soft lockup detector can be disabled or enabled individually.  With this
      series applied, the user interface is as follows.
      
      - parameters in /proc/sys/kernel
      
        . soft_watchdog
          This is a new parameter to control and examine the run state of
          the soft lockup detector.
      
        . nmi_watchdog
          The semantics of this parameter have changed. It can now be used
          to control and examine the run state of the hard lockup detector.
      
        . watchdog
          This parameter is still available to control the run state of both
          lockup detectors at the same time. If this parameter is examined,
          it shows the logical OR of soft_watchdog and nmi_watchdog.
      
        . watchdog_thresh
          The semantics of this parameter are not affected by the patch.
      
      - kernel command line parameters
      
        . nosoftlockup
          The semantics of this parameter have changed. It can now be used
          to disable the soft lockup detector at boot time.
      
        . nmi_watchdog=0 or nmi_watchdog=1
          Disable or enable the hard lockup detector at boot time. The patch
          introduces '=1' as a new option.
      
        . nowatchdog
          The semantics of this parameter are not affected by the patch. It
          is still available to disable both lockup detectors at boot time.
      
      Also, remove the proc_dowatchdog() function which is no longer needed.
      
      [dzickus@redhat.com: wrote changelog]
      [dzickus@redhat.com: update documentation for kernel params and sysctl]
      Signed-off-by: NUlrich Obergfell <uobergfe@redhat.com>
      Signed-off-by: NDon Zickus <dzickus@redhat.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      195daf66
  4. 10 4月, 2015 1 次提交
  5. 08 4月, 2015 1 次提交
  6. 04 4月, 2015 1 次提交
  7. 01 4月, 2015 2 次提交
  8. 25 3月, 2015 1 次提交
  9. 12 3月, 2015 1 次提交
    • P
      rcu: Provide diagnostic option to slow down grace-period initialization · 37745d28
      Paul E. McKenney 提交于
      Grace-period initialization normally proceeds quite quickly, so
      that it is very difficult to reproduce races against grace-period
      initialization.  This commit therefore allows grace-period
      initialization to be artificially slowed down, increasing
      race-reproduction probability.  A pair of new Kconfig parameters are
      provided, CONFIG_RCU_TORTURE_TEST_SLOW_INIT to enable the slowdowns, and
      CONFIG_RCU_TORTURE_TEST_SLOW_INIT_DELAY to specify the number of jiffies
      of slowdown to apply.  A boot-time parameter named rcutree.gp_init_delay
      allows boot-time delay to be specified.  By default, no delay will be
      applied even if CONFIG_RCU_TORTURE_TEST_SLOW_INIT is set.
      Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      37745d28
  10. 27 2月, 2015 1 次提交
  11. 26 2月, 2015 1 次提交
    • B
      PM / sleep: add configurable delay for pm_test · 1d4a9c17
      Brian Norris 提交于
      When CONFIG_PM_DEBUG=y, we provide a sysfs file (/sys/power/pm_test) for
      selecting one of a few suspend test modes, where rather than entering a
      full suspend state, the kernel will perform some subset of suspend
      steps, wait 5 seconds, and then resume back to normal operation.
      
      This mode is useful for (among other things) observing the state of the
      system just before entering a sleep mode, for debugging or analysis
      purposes. However, a constant 5 second wait is not sufficient for some
      sorts of analysis; for example, on an SoC, one might want to use
      external tools to probe the power states of various on-chip controllers
      or clocks.
      
      This patch turns this 5 second delay into a configurable module
      parameter, so users can determine how long to wait in this
      pseudo-suspend state before resuming the system.
      
      Example (wait 30 seconds);
      
        # echo 30 > /sys/module/suspend/parameters/pm_test_delay
        # echo core > /sys/power/pm_test
        # time echo mem  > /sys/power/state
        ...
        [   17.583625] suspend debug: Waiting for 30 second(s).
        ...
        real	0m30.381s
        user	0m0.017s
        sys	0m0.080s
      Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
      Acked-by: NPavel Machek <pavel@ucw.cz>
      Reviewed-by: NKevin Cernekee <cernekee@chromium.org>
      Acked-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      1d4a9c17
  12. 07 2月, 2015 1 次提交
  13. 03 2月, 2015 1 次提交
  14. 23 1月, 2015 1 次提交
  15. 10 1月, 2015 1 次提交
  16. 08 1月, 2015 1 次提交
  17. 15 12月, 2014 1 次提交
  18. 14 12月, 2014 3 次提交
    • J
      mm/page_owner: keep track of page owners · 48c96a36
      Joonsoo Kim 提交于
      This is the page owner tracking code which is introduced so far ago.  It
      is resident on Andrew's tree, though, nobody tried to upstream so it
      remain as is.  Our company uses this feature actively to debug memory leak
      or to find a memory hogger so I decide to upstream this feature.
      
      This functionality help us to know who allocates the page.  When
      allocating a page, we store some information about allocation in extra
      memory.  Later, if we need to know status of all pages, we can get and
      analyze it from this stored information.
      
      In previous version of this feature, extra memory is statically defined in
      struct page, but, in this version, extra memory is allocated outside of
      struct page.  It enables us to turn on/off this feature at boottime
      without considerable memory waste.
      
      Although we already have tracepoint for tracing page allocation/free,
      using it to analyze page owner is rather complex.  We need to enlarge the
      trace buffer for preventing overlapping until userspace program launched.
      And, launched program continually dump out the trace buffer for later
      analysis and it would change system behaviour with more possibility rather
      than just keeping it in memory, so bad for debug.
      
      Moreover, we can use page_owner feature further for various purposes.  For
      example, we can use it for fragmentation statistics implemented in this
      patch.  And, I also plan to implement some CMA failure debugging feature
      using this interface.
      
      I'd like to give the credit for all developers contributed this feature,
      but, it's not easy because I don't know exact history.  Sorry about that.
      Below is people who has "Signed-off-by" in the patches in Andrew's tree.
      
      Contributor:
      Alexander Nyberg <alexn@dsv.su.se>
      Mel Gorman <mgorman@suse.de>
      Dave Hansen <dave@linux.vnet.ibm.com>
      Minchan Kim <minchan@kernel.org>
      Michal Nazarewicz <mina86@mina86.com>
      Andrew Morton <akpm@linux-foundation.org>
      Jungsoo Son <jungsoo.son@lge.com>
      Signed-off-by: NJoonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: Mel Gorman <mgorman@suse.de>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Minchan Kim <minchan@kernel.org>
      Cc: Dave Hansen <dave@sr71.net>
      Cc: Michal Nazarewicz <mina86@mina86.com>
      Cc: Jungsoo Son <jungsoo.son@lge.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      48c96a36
    • J
      mm/debug-pagealloc: make debug-pagealloc boottime configurable · 031bc574
      Joonsoo Kim 提交于
      Now, we have prepared to avoid using debug-pagealloc in boottime.  So
      introduce new kernel-parameter to disable debug-pagealloc in boottime, and
      makes related functions to be disabled in this case.
      
      Only non-intuitive part is change of guard page functions.  Because guard
      page is effective only if debug-pagealloc is enabled, turning off
      according to debug-pagealloc is reasonable thing to do.
      Signed-off-by: NJoonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: Mel Gorman <mgorman@suse.de>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Minchan Kim <minchan@kernel.org>
      Cc: Dave Hansen <dave@sr71.net>
      Cc: Michal Nazarewicz <mina86@mina86.com>
      Cc: Jungsoo Son <jungsoo.son@lge.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      031bc574
    • L
      hugetlb: fix hugepages= entry in kernel-parameters.txt · 27ec26ec
      Luiz Capitulino 提交于
      The hugepages= entry in kernel-parameters.txt states that 1GB pages can
      only be allocated at boot time and not freed afterwards.  This is not
      true since commit 944d9fec ("hugetlb: add support for gigantic page
      allocation at runtime"), at least for x86_64.
      
      Instead of adding arch-specifc observations to the hugepages= entry,
      this commit just drops the out of date information.  Further information
      about arch-specific support and available features can be obtained in
      the hugetlb documentation.
      Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Acked-by: NDavid Rientjes <rientjes@google.com>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Davidlohr Bueso <dave@stgolabs.net>
      Acked-by: NNaoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      27ec26ec
  19. 11 12月, 2014 2 次提交
    • P
      kernel: add panic_on_warn · 9e3961a0
      Prarit Bhargava 提交于
      There have been several times where I have had to rebuild a kernel to
      cause a panic when hitting a WARN() in the code in order to get a crash
      dump from a system.  Sometimes this is easy to do, other times (such as
      in the case of a remote admin) it is not trivial to send new images to
      the user.
      
      A much easier method would be a switch to change the WARN() over to a
      panic.  This makes debugging easier in that I can now test the actual
      image the WARN() was seen on and I do not have to engage in remote
      debugging.
      
      This patch adds a panic_on_warn kernel parameter and
      /proc/sys/kernel/panic_on_warn calls panic() in the
      warn_slowpath_common() path.  The function will still print out the
      location of the warning.
      
      An example of the panic_on_warn output:
      
      The first line below is from the WARN_ON() to output the WARN_ON()'s
      location.  After that the panic() output is displayed.
      
          WARNING: CPU: 30 PID: 11698 at /home/prarit/dummy_module/dummy-module.c:25 init_dummy+0x1f/0x30 [dummy_module]()
          Kernel panic - not syncing: panic_on_warn set ...
      
          CPU: 30 PID: 11698 Comm: insmod Tainted: G        W  OE  3.17.0+ #57
          Hardware name: Intel Corporation S2600CP/S2600CP, BIOS RMLSDP.86I.00.29.D696.1311111329 11/11/2013
           0000000000000000 000000008e3f87df ffff88080f093c38 ffffffff81665190
           0000000000000000 ffffffff818aea3d ffff88080f093cb8 ffffffff8165e2ec
           ffffffff00000008 ffff88080f093cc8 ffff88080f093c68 000000008e3f87df
          Call Trace:
           [<ffffffff81665190>] dump_stack+0x46/0x58
           [<ffffffff8165e2ec>] panic+0xd0/0x204
           [<ffffffffa038e05f>] ? init_dummy+0x1f/0x30 [dummy_module]
           [<ffffffff81076b90>] warn_slowpath_common+0xd0/0xd0
           [<ffffffffa038e040>] ? dummy_greetings+0x40/0x40 [dummy_module]
           [<ffffffff81076c8a>] warn_slowpath_null+0x1a/0x20
           [<ffffffffa038e05f>] init_dummy+0x1f/0x30 [dummy_module]
           [<ffffffff81002144>] do_one_initcall+0xd4/0x210
           [<ffffffff811b52c2>] ? __vunmap+0xc2/0x110
           [<ffffffff810f8889>] load_module+0x16a9/0x1b30
           [<ffffffff810f3d30>] ? store_uevent+0x70/0x70
           [<ffffffff810f49b9>] ? copy_module_from_fd.isra.44+0x129/0x180
           [<ffffffff810f8ec6>] SyS_finit_module+0xa6/0xd0
           [<ffffffff8166cf29>] system_call_fastpath+0x12/0x17
      
      Successfully tested by me.
      
      hpa said: There is another very valid use for this: many operators would
      rather a machine shuts down than being potentially compromised either
      functionally or security-wise.
      Signed-off-by: NPrarit Bhargava <prarit@redhat.com>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Acked-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Cc: Fabian Frederick <fabf@skynet.be>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9e3961a0
    • E
      intel_pstate: add kernel parameter to force loading · aa4ea34d
      Ethan Zhao 提交于
      To force loading on Oracle Sun X86 servers, provide one kernel command line
      parameter
      
        intel_pstate = force
      
      For those who are aware of the risk of no power capping capabily working
      and try to get better performance with this driver.
      Signed-off-by: NEthan Zhao <ethan.zhao@oracle.com>
      Tested-by: NAlexey Kodanev <alexey.kodanev@oracle.com>
      Reviewed-by: NLinda Knippers <linda.knippers@hp.com>
      Acked-by: NKristen Carlson Accardi <kristen@linux.intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      aa4ea34d
  20. 04 12月, 2014 1 次提交
  21. 14 11月, 2014 1 次提交
  22. 12 11月, 2014 1 次提交
    • D
      intel_pstate: Add support for HWP · 2f86dc4c
      Dirk Brandewie 提交于
      Add support of Hardware Managed Performance States (HWP) described in Volume 3
      section 14.4 of the SDM.
      
      With HWP enbaled intel_pstate will no longer be responsible for selecting P
      states for the processor. intel_pstate will continue to register to
      the cpufreq core as the scaling driver for CPUs implementing
      HWP. In HWP mode intel_pstate provides three functions reporting
      frequency to the cpufreq core, support for the set_policy() interface
      from the core and maintaining the intel_pstate sysfs interface in
      /sys/devices/system/cpu/intel_pstate.  User preferences expressed via
      the set_policy() interface or the sysfs interface are forwared to the
      CPU via the HWP MSR interface.
      Signed-off-by: NDirk Brandewie <dirk.j.brandewie@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      2f86dc4c
  23. 08 11月, 2014 1 次提交
  24. 07 11月, 2014 1 次提交
  25. 01 11月, 2014 1 次提交
  26. 30 10月, 2014 1 次提交
  27. 27 10月, 2014 1 次提交
  28. 25 10月, 2014 1 次提交
  29. 13 10月, 2014 2 次提交
    • R
      ima: added support for new kernel cmdline parameter ima_template_fmt · c2426d2a
      Roberto Sassu 提交于
      This patch allows users to provide a custom template format through the
      new kernel command line parameter 'ima_template_fmt'. If the supplied
      format is not valid, IMA uses the default template descriptor.
      
      Changelog:
       - v3:
         - added check for 'fields' and 'num_fields' in
           template_desc_init_fields() (suggested by Mimi Zohar)
      
       - v2:
         - using template_desc_init_fields() to validate a format string
           (Roberto Sassu)
         - updated documentation by stating that only the chosen template
           descriptor is initialized (Roberto Sassu)
      
       - v1:
         - simplified code of ima_template_fmt_setup()
           (Roberto Sassu, suggested by Mimi Zohar)
      Signed-off-by: NRoberto Sassu <roberto.sassu@polito.it>
      Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
      c2426d2a
    • N
      powerpc/numa: Add ability to disable and debug topology updates · 2d73bae1
      Nishanth Aravamudan 提交于
      We have hit a few customer issues with the topology update code (VPHN
      and PRRN). It would be nice to be able to debug the notifications coming
      from the hypervisor in both cases to the LPAR, as well as to disable
      responding to the notifications at boot-time, to narrow down the source
      of the problems. Add a basic level of such functionality, similar to the
      numa= command-line parameter. We already have a toggle in
      /proc/powerpc/topology_updates that allows run-time enabling/disabling,
      so the updates can be started at run-time if desired. But the bugs we've
      run into have occured during boot or very shortly after coming to login,
      and have resulted in a broken NUMA topology.
      Signed-off-by: NNishanth Aravamudan <nacc@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      2d73bae1
  30. 12 10月, 2014 1 次提交
    • D
      Input: i8042 - disable active multiplexing by default · 68da1664
      Dmitry Torokhov 提交于
      Active multiplexing is a nice feature as it allows several pointing devices
      (such as touchpad and external mouse) use their native protocols at the
      same time. Unfortunately many manufacturers do not implement the feature
      properly even though they advertise it. The problematic implementations are
      never fixed, since Windows by default does not use this mode, and move from
      one BIOS/model of laptop to another. When active multiplexing is broken
      turning it on usually results in touchpad, keyboard, or both unresponsive.
      
      With PS/2 usage on decline (most of PS/2 devices in use nowadays are
      internal laptop touchpads), I expect number of users who have laptops with
      working MUX implementation, docking stations with external PS/2 ports, and
      who are still using external PS/2 mice, to be rather small. Let's flip the
      default to be OFF and allow activating it through i8042.nomux=0 kernel
      option.  We'll also keep DMI table where we can record known good models.
      Acked-by: NJiri Kosina <jkosina@suse.cz>
      Acked-by: NHans de Goede <hdegoede@redhat.com>
      Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      68da1664
  31. 10 10月, 2014 2 次提交
  32. 04 10月, 2014 1 次提交