1. 15 8月, 2010 1 次提交
  2. 11 8月, 2010 2 次提交
  3. 10 8月, 2010 1 次提交
  4. 05 8月, 2010 1 次提交
  5. 02 8月, 2010 1 次提交
  6. 31 7月, 2010 1 次提交
    • M
      x86/PCI: Add option to not assign BAR's if not already assigned · 7bd1c365
      Mike Habeck 提交于
      The Linux kernel assigns BARs that a BIOS did not assign, most likely
      to handle broken BIOSes that didn't enumerate the devices correctly.
      On UV the BIOS purposely doesn't assign I/O BARs for certain devices/
      drivers we know don't use them (examples, LSI SAS, Qlogic FC, ...).
      We purposely don't assign these I/O BARs because I/O Space is a very
      limited resource.  There is only 64k of I/O Space, and in a PCIe
      topology that space gets divided up into 4k chucks (this is due to
      the fact that a pci-to-pci bridge's I/O decoder is aligned at 4k)...
      Thus a system can have at most 16 cards with I/O BARs: (64k / 4k = 16)
      
      SGI needs to scale to >16 devices with I/O BARs.  So by not assigning
      I/O BARs on devices we know don't use them, we can do that (iff the
      kernel doesn't go and assign these BARs that the BIOS purposely didn't
      assign).
      
      This patch will not assign a resource to a device BAR if that BAR was
      not assigned by the BIOS, and the kernel cmdline option 'pci=nobar'
      was specified.   This patch is closely modeled after the 'pci=norom'
      option that currently exists in the tree.
      Signed-off-by: NMike Habeck <habeck@sgi.com>
      Signed-off-by: NMike Travis <travis@sgi.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      7bd1c365
  7. 27 7月, 2010 2 次提交
  8. 25 7月, 2010 1 次提交
  9. 14 7月, 2010 1 次提交
  10. 25 6月, 2010 1 次提交
    • T
      netfilter: complete the deprecation of CONFIG_NF_CT_ACCT · d70a011d
      Tim Gardner 提交于
      CONFIG_NF_CT_ACCT has been deprecated for awhile and
      was originally scheduled for removal by 2.6.29.
      
      Removing support for this config option also stops
      this deprecation warning message in the kernel log.
      
      [   61.669627] nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
      [   61.669850] CONFIG_NF_CT_ACCT is deprecated and will be removed soon. Please use
      [   61.669852] nf_conntrack.acct=1 kernel parameter, acct=1 nf_conntrack module option or
      [   61.669853] sysctl net.netfilter.nf_conntrack_acct=1 to enable it.
      Signed-off-by: NTim Gardner <tim.gardner@canonical.com>
      [Patrick: changed default value to 0]
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      d70a011d
  11. 19 6月, 2010 1 次提交
  12. 08 6月, 2010 1 次提交
  13. 26 5月, 2010 1 次提交
  14. 25 5月, 2010 1 次提交
  15. 21 5月, 2010 4 次提交
    • J
      echi-dbgp: Add kernel debugger support for the usb debug port · 4fe1da4e
      Jason Wessel 提交于
      This patch adds the capability to use the usb debug port with the
      kernel debugger.  It is also still possible to use this functionality
      with or without the earlyprintk=dbgpX.  It is possible to use the
      kgdbwait boot argument to debug very early in the kernel start up code.
      
      There are two ways to use this driver extension with a kernel boot argument.
      
      1) kgdbdbgp=#   -- Where # is the number of the usb debug controller
      
         You must use sysrq-g to break into the kernel debugger on another
         connection type other than the dbgp.
      
      2) kgdbdbgp=#debugControlNum#,#Seconds#
      
         In this mode, the usb debug port is polled every #Seconds# for
         character input.  It is possible to use gdb or press control-c to
         break into the kernel debugger.
      
      From the implementation perspective there are 3 high level changes.
      
      1) Allow variable retries for the the hardware via dbgp_bulk_read().
      
         The amount of retries for the dbgp_bulk_read() needed to be
         variable instead of fixed.  We do not want to poll at all when the
         kernel is operating in interrupt driven mode.  The polling only
         occurs if the kernel was booted when specifying some number of
         seconds via the kgdbdbgp boot argument (IE kgdbdbgp=0,1).  In this
         case the loop count is reduced to 1 so as introduce the smallest
         amount of latency as possible.
      
      2) Save the bulk IN endpoint address for use by the kgdb code.
      
      3) The addition of the kgdb interface code.
      
         This consisted of adding in a character read function for the dbgp
         as well as a polling thread to allow the dbgp to interrupt the
         kernel execution.  The rest is the typical kgdb I/O api.
      
      CC: Eric Biederman <ebiederm@xmission.com>
      CC: Yinghai Lu <yhlu.kernel@gmail.com>
      CC: linux-usb@vger.kernel.org
      Signed-off-by: NJason Wessel <jason.wessel@windriver.com>
      Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
      4fe1da4e
    • J
      kgdboc: Add ekgdboc for early use of the kernel debugger · 9731191f
      Jason Wessel 提交于
      The ekgdboc= differs from kgdboc= in that you can begin debuggin as
      soon as the exceptions are setup and the kgdb I/O driver is available,
      instead of waiting until the tty subsystem is available.
      
      CC: kgdb-bugreport@lists.sourceforge.net
      Signed-off-by: NJason Wessel <jason.wessel@windriver.com>
      9731191f
    • J
      kgdb,docs: Update the kgdb docs to include kdb · 84c08fd6
      Jason Wessel 提交于
      Update the kgdb docs to reflect the new directory structure and API.
      
      Merge in the kdb shell information.
      
      [Randy Dunlap <rdunlap@xenotime.net>: grammatical corrections]
      
      CC: Randy Dunlap <rdunlap@xenotime.net>
      Signed-off-by: NJason Wessel <jason.wessel@windriver.com>
      84c08fd6
    • J
      kgdboc,keyboard: Keyboard driver for kdb with kgdb · ada64e4c
      Jason Wessel 提交于
      This patch adds in the kdb PS/2 keyboard driver.  This was mostly a
      direct port from the original kdb where I cleaned up the code against
      checkpatch.pl and added the glue to stitch it into kgdb.
      
      This patch also enables early kdb debug via kgdbwait and the keyboard.
      
      All the access to configure kdb using either a serial console or the
      keyboard is done via kgdboc.
      
      If you want to use only the keyboard and want to break in early you
      would add to your kernel command arguments:
      
          kgdboc=kbd kgdbwait
      
      If you wanted serial and or the keyboard access you could use:
      
          kgdboc=kbd,ttyS0
      
      You can also configure kgdboc as a kernel module or at run time with
      the sysfs where you can activate and deactivate kgdb.
      
      Turn it on:
          echo kbd,ttyS0 > /sys/module/kgdboc/parameters/kgdboc
      
      Turn it off:
          echo "" > /sys/module/kgdboc/parameters/kgdboc
      Signed-off-by: NJason Wessel <jason.wessel@windriver.com>
      Reviewed-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      ada64e4c
  16. 20 5月, 2010 2 次提交
  17. 13 5月, 2010 1 次提交
    • D
      lockup_detector: Combine nmi_watchdog and softlockup detector · 58687acb
      Don Zickus 提交于
      The new nmi_watchdog (which uses the perf event subsystem) is very
      similar in structure to the softlockup detector.  Using Ingo's
      suggestion, I combined the two functionalities into one file:
      kernel/watchdog.c.
      
      Now both the nmi_watchdog (or hardlockup detector) and softlockup
      detector sit on top of the perf event subsystem, which is run every
      60 seconds or so to see if there are any lockups.
      
      To detect hardlockups, cpus not responding to interrupts, I
      implemented an hrtimer that runs 5 times for every perf event
      overflow event.  If that stops counting on a cpu, then the cpu is
      most likely in trouble.
      
      To detect softlockups, tasks not yielding to the scheduler, I used the
      previous kthread idea that now gets kicked every time the hrtimer fires.
      If the kthread isn't being scheduled neither is anyone else and the
      warning is printed to the console.
      
      I tested this on x86_64 and both the softlockup and hardlockup paths
      work.
      
      V2:
      - cleaned up the Kconfig and softlockup combination
      - surrounded hardlockup cases with #ifdef CONFIG_PERF_EVENTS_NMI
      - seperated out the softlockup case from perf event subsystem
      - re-arranged the enabling/disabling nmi watchdog from proc space
      - added cpumasks for hardlockup failure cases
      - removed fallback to soft events if no PMU exists for hard events
      
      V3:
      - comment cleanups
      - drop support for older softlockup code
      - per_cpu cleanups
      - completely remove software clock base hardlockup detector
      - use per_cpu masking on hard/soft lockup detection
      - #ifdef cleanups
      - rename config option NMI_WATCHDOG to LOCKUP_DETECTOR
      - documentation additions
      
      V4:
      - documentation fixes
      - convert per_cpu to __get_cpu_var
      - powerpc compile fixes
      
      V5:
      - split apart warn flags for hard and soft lockups
      
      TODO:
      - figure out how to make an arch-agnostic clock2cycles call
        (if possible) to feed into perf events as a sample period
      
      [fweisbec: merged conflict patch]
      Signed-off-by: NDon Zickus <dzickus@redhat.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Cyrill Gorcunov <gorcunov@gmail.com>
      Cc: Eric Paris <eparis@redhat.com>
      Cc: Randy Dunlap <randy.dunlap@oracle.com>
      LKML-Reference: <1273266711-18706-2-git-send-email-dzickus@redhat.com>
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      58687acb
  18. 11 5月, 2010 1 次提交
  19. 23 4月, 2010 1 次提交
  20. 22 4月, 2010 1 次提交
    • F
      tracing: Dump either the oops's cpu source or all cpus buffers · cecbca96
      Frederic Weisbecker 提交于
      The ftrace_dump_on_oops kernel parameter, sysctl and sysrq let one
      dump every cpu buffers when an oops or panic happens.
      
      It's nice when you have few cpus but it may take ages if have many,
      plus you miss the real origin of the problem in all the cpu traces.
      
      Sometimes, all you need is to dump the cpu buffer that triggered the
      opps, most of the time it is our main interest.
      
      This patch modifies ftrace_dump_on_oops to handle this choice.
      
      The ftrace_dump_on_oops kernel parameter, when it comes alone, has
      the same behaviour than before. But ftrace_dump_on_oops=orig_cpu
      will only dump the buffer of the cpu that oops'ed.
      
      Similarly, sysctl kernel.ftrace_dump_on_oops=1 and
      echo 1 > /proc/sys/kernel/ftrace_dump_on_oops keep their previous
      behaviour. But setting 2 jumps into cpu origin dump mode.
      
      v2: Fix double setup
      v3: Fix spelling issues reported by Randy Dunlap
      v4: Also update __ftrace_dump in the selftests
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      Acked-by: NSteven Rostedt <rostedt@goodmis.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Li Zefan <lizf@cn.fujitsu.com>
      Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
      cecbca96
  21. 20 4月, 2010 1 次提交
  22. 07 4月, 2010 1 次提交
  23. 26 3月, 2010 1 次提交
  24. 15 3月, 2010 2 次提交
  25. 25 2月, 2010 2 次提交
    • I
      x86, mm: Allow highmem user page tables to be disabled at boot time · 14315592
      Ian Campbell 提交于
      Distros generally (I looked at Debian, RHEL5 and SLES11) seem to
      enable CONFIG_HIGHPTE for any x86 configuration which has highmem
      enabled. This means that the overhead applies even to machines which
      have a fairly modest amount of high memory and which therefore do not
      really benefit from allocating PTEs in high memory but still pay the
      price of the additional mapping operations.
      
      Running kernbench on a 4G box I found that with CONFIG_HIGHPTE=y but
      no actual highptes being allocated there was a reduction in system
      time used from 59.737s to 55.9s.
      
      With CONFIG_HIGHPTE=y and highmem PTEs being allocated:
        Average Optimal load -j 4 Run (std deviation):
        Elapsed Time 175.396 (0.238914)
        User Time 515.983 (5.85019)
        System Time 59.737 (1.26727)
        Percent CPU 263.8 (71.6796)
        Context Switches 39989.7 (4672.64)
        Sleeps 42617.7 (246.307)
      
      With CONFIG_HIGHPTE=y but with no highmem PTEs being allocated:
        Average Optimal load -j 4 Run (std deviation):
        Elapsed Time 174.278 (0.831968)
        User Time 515.659 (6.07012)
        System Time 55.9 (1.07799)
        Percent CPU 263.8 (71.266)
        Context Switches 39929.6 (4485.13)
        Sleeps 42583.7 (373.039)
      
      This patch allows the user to control the allocation of PTEs in
      highmem from the command line ("userpte=nohigh") but retains the
      status-quo as the default.
      
      It is possible that some simple heuristic could be developed which
      allows auto-tuning of this option however I don't have a sufficiently
      large machine available to me to perform any particularly meaningful
      experiments. We could probably handwave up an argument for a threshold
      at 16G of total RAM.
      
      Assuming 768M of lowmem we have 196608 potential lowmem PTE
      pages. Each page can map 2M of RAM in a PAE-enabled configuration,
      meaning a maximum of 384G of RAM could potentially be mapped using
      lowmem PTEs.
      
      Even allowing generous factor of 10 to account for other required
      lowmem allocations, generous slop to account for page sharing (which
      reduces the total amount of RAM mappable by a given number of PT
      pages) and other innacuracies in the estimations it would seem that
      even a 32G machine would not have a particularly pressing need for
      highmem PTEs. I think 32G could be considered to be at the upper bound
      of what might be sensible on a 32 bit machine (although I think in
      practice 64G is still supported).
      
      It's seems questionable if HIGHPTE is even a win for any amount of RAM
      you would sensibly run a 32 bit kernel on rather than going 64 bit.
      Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
      LKML-Reference: <1266403090-20162-1-git-send-email-ian.campbell@citrix.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      14315592
    • J
      x86, apbt: Moorestown APB system timer driver · bb24c471
      Jacob Pan 提交于
      Moorestown platform does not have PIT or HPET platform timers.  Instead it
      has a bank of eight APB timers.  The number of available timers to the os
      is exposed via SFI mtmr tables.  All APB timer interrupts are routed via
      ioapic rtes and delivered as MSI.
      Currently, we use timer 0 and 1 for per cpu clockevent devices, timer 2
      for clocksource.
      Signed-off-by: NJacob Pan <jacob.jun.pan@intel.com>
      LKML-Reference: <43F901BD926A4E43B106BF17856F0755A318D2D2@orsmsx508.amr.corp.intel.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      bb24c471
  26. 24 2月, 2010 1 次提交
  27. 23 2月, 2010 2 次提交
    • R
      PCI PM: Make it possible to force using INTx for PCIe PME signaling · c39fae14
      Rafael J. Wysocki 提交于
      Apparently, some machines may have problems with PCI run-time power
      management if MSIs are used for the native PCIe PME signaling.  In
      particular, on the MSI Wind U-100 PCIe PME interrupts are not
      generated by a PCIe root port after a resume from suspend to RAM, if
      the system wake-up was triggered by a PME from the device attached to
      this port.  [It doesn't help to free the interrupt on suspend and
      request it back on resume, even if that is done along with disabling
      the MSI and re-enabling it, respectively.]  However, if INTx
      interrupts are used for this purpose on the same machine, everything
      works just fine.
      
      For this reason, add a kernel command line switch allowing one to
      request that MSIs be not used for the native PCIe PME signaling,
      introduce a DMI table allowing us to blacklist machines that need
      this switch to be set by default and put the MSI Wind U-100 into this
      table.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      c39fae14
    • R
      PCI PM: PCIe PME root port service driver · c7f48656
      Rafael J. Wysocki 提交于
      PCIe native PME detection mechanism is based on interrupts generated
      by root ports or event collectors every time a PCIe device sends a
      PME message upstream.
      
      Once a PME message has been sent by an endpoint device and received
      by its root port (or event collector in the case of root complex
      integrated endpoints), the Requester ID from the message header is
      registered in the root port's Root Status register.  At the same
      time, the PME Status bit of the Root Status register is set to
      indicate that there's a PME to handle.  If PCIe PME interrupt is
      enabled for the root port, it generates an interrupt once the PME
      Status has been set.  After receiving the interrupt, the kernel can
      identify the PCIe device that generated the PME using the Requester
      ID from the root port's Root Status register. [For details, see PCI
      Express Base Specification, Rev. 2.0.]
      
      Implement a driver for the PCIe PME root port service working in
      accordance with the above description.
      
      Based on a patch from Shaohua Li <shaohua.li@intel.com>.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      c7f48656
  28. 21 2月, 2010 1 次提交
    • R
      ARM: allow alignment fault mode to be configured at kernel boot · d944d549
      Russell King 提交于
      Some glibc versions intentionally create lots of alignment faults in
      their gconv code, which if not fixed up, results in segfaults during
      boot.  This can prevent systems booting properly.
      
      There is no clear hard-configurable default for this; the desired
      default depends on the nature of the userspace which is going to be
      booted.
      
      So, provide a way for the alignment fault handler to be configured via
      the kernel command line.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      d944d549
  29. 18 2月, 2010 1 次提交
  30. 05 2月, 2010 1 次提交
  31. 23 1月, 2010 1 次提交