Skip to content
Snippets Groups Projects
  1. Jul 30, 2012
  2. Jul 20, 2012
  3. Jul 16, 2012
  4. Jul 02, 2012
  5. Jun 25, 2012
  6. May 30, 2012
  7. May 25, 2012
  8. May 24, 2012
    • Mike Galbraith's avatar
      tick: Add tick skew boot option · 5307c955
      Mike Galbraith authored
      
      Let the user decide whether power consumption or jitter is the
      more important consideration for their machines.
      
      Quoting removal commit af5ab277:
      
      "Historically, Linux has tried to make the regular timer tick on the
       various CPUs not happen at the same time, to avoid contention on
       xtime_lock.
          
       Nowadays, with the tickless kernel, this contention no longer happens
       since time keeping and updating are done differently. In addition,
       this skew is actually hurting power consumption in a measurable way on
       many-core systems."
      
      Problems:
      
      - Contrary to the above, systems do encounter contention on both
        xtime_lock and RCU structure locks when the tick is synchronized.
        
      - Moderate sized RT systems suffer intolerable jitter due to the tick
        being synchronized.
      
      - SGI reports the same for their large systems.
      
      - Fully utilized systems reap no power saving benefit from skew removal,
        but do suffer from resulting induced lock contention.
      
      - 0209f649 rcu: limit rcu_node leaf-level fanout
        This patch was born to combat lock contention which testing showed
        to have been _induced by_ skew removal.  Skew the tick, contention
        disappeared virtually completely.
      
      Signed-off-by: default avatarMike Galbraith <mgalbraith@suse.de>
      Link: http://lkml.kernel.org/r/1336472458.21924.78.camel@marge.simpson.net
      
      
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      5307c955
  9. May 22, 2012
  10. May 21, 2012
  11. May 18, 2012
  12. May 17, 2012
    • Paul Gortmaker's avatar
      MCA: delete all remaining traces of microchannel bus support. · bb8187d3
      Paul Gortmaker authored
      
      Hardware with MCA bus is limited to 386 and 486 class machines
      that are now 20+ years old and typically with less than 32MB
      of memory.  A quick search on the internet, and you see that
      even the MCA hobbyist/enthusiast community has lost interest
      in the early 2000 era and never really even moved ahead from
      the 2.4 kernels to the 2.6 series.
      
      This deletes anything remaining related to CONFIG_MCA from core
      kernel code and from the x86 architecture.  There is no point in
      carrying this any further into the future.
      
      One complication to watch for is inadvertently scooping up
      stuff relating to machine check, since there is overlap in
      the TLA name space (e.g. arch/x86/boot/mca.c).
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: James Bottomley <JBottomley@Parallels.com>
      Cc: x86@kernel.org
      Acked-by: default avatarIngo Molnar <mingo@elte.hu>
      Acked-by: default avatarH. Peter Anvin <hpa@zytor.com>
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      bb8187d3
  13. Apr 30, 2012
    • Bjorn Helgaas's avatar
      PCI: work around Stratus ftServer broken PCIe hierarchy · 284f5f9d
      Bjorn Helgaas authored
      
      A PCIe downstream port is a P2P bridge.  Its secondary interface is
      a link that should lead only to device 0 (unless ARI is enabled)[1], so
      we don't probe for non-zero device numbers.
      
      Some Stratus ftServer systems have a PCIe downstream port (02:00.0) that
      leads to both an upstream port (03:00.0) and a downstream port (03:01.0),
      and 03:01.0 has important devices below it:
      
        [0000:02]-+-00.0-[03-3c]--+-00.0-[04-09]--...
                                  \-01.0-[0a-0d]--+-[USB]
                                                  +-[NIC]
                                                  +-...
      
      Previously, we didn't enumerate device 03:01.0, so USB and the network
      didn't work.  This patch adds a DMI quirk to scan all device numbers,
      not just 0, below a downstream port.
      
      Based on a patch by Prarit Bhargava.
      
      [1] PCIe spec r3.0, sec 7.3.1
      
      CC: Myron Stowe <mstowe@redhat.com>
      CC: Don Dutile <ddutile@redhat.com>
      CC: James Paradis <james.paradis@stratus.com>
      CC: Matthew Wilcox <matthew.r.wilcox@intel.com>
      CC: Jesse Barnes <jbarnes@virtuousgeek.org>
      CC: Prarit Bhargava <prarit@redhat.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      284f5f9d
    • Jim Cromie's avatar
      dynamic_debug: update Documentation/*, Kconfig.debug · 29e36c9f
      Jim Cromie authored
      
      In dynamic-debug-howto.txt:
      
      - add section: Debug Messages at Module Initialization Time
      - update flags indicators in example outputs to include '='
      - make flags descriptions tabular
      - add item on '_' flag-char
      - add dyndbg, boot-args examples
      - rewrap some paragraphs with long lines
      
      In Kconfig.debug, note that compiling with -DDEBUG enables all
      pr_debug()s in that code.
      
      In kernel-parameters.txt, add dyndbg and module.dyndbg items,
      and deprecate ddebug_query.
      
      Signed-off-by: default avatarJim Cromie <jim.cromie@gmail.com>
      Acked-by: default avatarJason Baron <jbaron@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      29e36c9f
  14. Apr 25, 2012
  15. Mar 26, 2012
    • J. Bruce Fields's avatar
      nfsd4: allow numeric idmapping · e9541ce8
      J. Bruce Fields authored
      
      Mimic the client side by providing a module parameter that turns off
      idmapping in the auth_sys case, for backwards compatibility with NFSv2
      and NFSv3.
      
      Unlike in the client case, we don't have any way to negotiate, since the
      client can return an error to us if it doesn't like the id that we
      return to it in (for example) a getattr call.
      
      However, it has always been possible for servers to return numeric id's,
      and as far as we're aware clients have always been able to handle them.
      
      Also, in the auth_sys case clients already need to have numeric id's the
      same between client and server.
      
      Therefore we believe it's safe to default this to on; but the module
      parameter is available to return to previous behavior if this proves to
      be a problem in some unexpected setup.
      
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      e9541ce8
    • Dave Young's avatar
      module: add kernel param to force disable module load · 02608bef
      Dave Young authored
      
      Sometimes we need to test a kernel of same version with code or config
      option changes.
      
      We already have sysctl to disable module load, but add a kernel
      parameter will be more convenient.
      
      Since modules_disabled is int, so here use bint type in core_param.
      TODO: make sysctl accept bool and change modules_disabled to bool
      
      Signed-off-by: default avatarDave Young <dyoung@redhat.com>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      02608bef
  16. Mar 22, 2012
  17. Mar 21, 2012
    • Sachin Bhamare's avatar
      pnfs-obj: autologin: Add support for protocol autologin · 18d98f6c
      Sachin Bhamare authored
      
      The pnfs-objects protocol mandates that we autologin into devices not
      present in the system, according to information specified in the
      get_device_info returned from the server.
      
      The Protocol specifies two login hints.
      1. An IP address:port combination
      2. A string URI which is constructed as a URL with a protocol prefix
         followed by :// and a string as address. For each  protocol prefix
         the string-address format might be different.
      
      We only support the second option. The first option is just redundant
      to the second one.
      NOTE: The Kernel part of autologin does not parse the URI string. It
      just channels it to a user-mode script. So any new login protocols should
      only update the user-mode script which is a part of the nfs-utils package,
      but the Kernel need not change.
      
      We implement the autologin by using the call_usermodehelper() API.
      (Thanks to Steve Dickson <steved@redhat.com> for pointing it out)
      So there is no running daemon needed, and/or special setup.
      
      We Add the osd_login_prog Kernel module parameters which defaults to:
      	/sbin/osd_login
      
      Kernel try's to upcall the program specified in osd_login_prog. If the file is
      not found or the execution fails Kernel will disable any farther upcalls, by
      zeroing out  osd_login_prog, Until Admin re-enables it by setting the
      osd_login_prog parameter to a proper program.
      
      Also add text about the osd_login program command line API to:
      	Documentation/filesystems/nfs/pnfs.txt
      and documentation of the new  osd_login_prog  module parameter to:
      	Documentation/kernel-parameters.txt
      
      TODO: Add timeout option in the case osd_login program gets
                    stuck
      
      Signed-off-by: default avatarSachin Bhamare <sbhamare@panasas.com>
      Signed-off-by: default avatarBoaz Harrosh <bharrosh@panasas.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      18d98f6c
  18. Mar 20, 2012
    • Carsten Emde's avatar
      drm: allow loading an EDID as firmware to override broken monitor · da0df92b
      Carsten Emde authored
      
      Broken monitors and/or broken graphic boards may send erroneous or no
      EDID data. This also applies to broken KVM devices that are unable to
      correctly forward the EDID data of the connected monitor but invent
      their own fantasy data.
      
      This patch allows to specify an EDID data set to be used instead of
      probing the monitor for it. It contains built-in data sets of frequently
      used screen resolutions. In addition, a particular EDID data set may be
      provided in the /lib/firmware directory and loaded via the firmware
      interface. The name is passed to the kernel as module parameter of the
      drm_kms_helper module either when loaded
        options drm_kms_helper edid_firmware=edid/1280x1024.bin
      or as kernel commandline parameter
        drm_kms_helper.edid_firmware=edid/1280x1024.bin
      
      It is also possible to restrict the usage of a specified EDID data set
      to a particular connector. This is done by prepending the name of the
      connector to the name of the EDID data set using the syntax
        edid_firmware=[<connector>:]<edid>
      such as, for example,
        edid_firmware=DVI-I-1:edid/1920x1080.bin
      in which case no other connector will be affected.
      
      The built-in data sets are
      Resolution    Name
      --------------------------------
      1024x768      edid/1024x768.bin
      1280x1024     edid/1280x1024.bin
      1680x1050     edid/1680x1050.bin
      1920x1080     edid/1920x1080.bin
      
      They are ignored, if a file with the same name is available in the
      /lib/firmware directory.
      
      The built-in EDID data sets are based on standard timings that may not
      apply to a particular monitor and even crash it. Ideally, EDID data of
      the connected monitor should be used. They may be obtained through the
      drm/cardX/cardX-<connector>/edid entry in the /sys/devices PCI directory
      of a correctly working graphics adapter.
      
      It is even possible to specify the name of an EDID data set on-the-fly
      via the /sys/module interface, e.g.
      echo edid/myedid.bin >/sys/module/drm_kms_helper/parameters/edid_firmware
      The new screen mode is considered when the related kernel function is
      called for the first time after the change. Such calls are made when the
      X server is started or when the display settings dialog is opened in an
      already running X server.
      
      Signed-off-by: default avatarCarsten Emde <C.Emde@osadl.org>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      da0df92b
  19. Mar 18, 2012
  20. Mar 05, 2012
    • Matthew Garrett's avatar
      kmsg_dump: don't run on non-error paths by default · c22ab332
      Matthew Garrett authored
      
      Since commit 04c6862c ("kmsg_dump: add kmsg_dump() calls to the
      reboot, halt, poweroff and emergency_restart paths"), kmsg_dump() gets
      run on normal paths including poweroff and reboot.
      
      This is less than ideal given pstore implementations that can only
      represent single backtraces, since a reboot may overwrite a stored oops
      before it's been picked up by userspace.  In addition, some pstore
      backends may have low performance and provide a significant delay in
      reboot as a result.
      
      This patch adds a printk.always_kmsg_dump kernel parameter (which can also
      be changed from userspace).  Without it, the code will only be run on
      failure paths rather than on normal paths.  The option can be enabled in
      environments where there's a desire to attempt to audit whether or not a
      reboot was cleanly requested or not.
      
      Signed-off-by: default avatarMatthew Garrett <mjg@redhat.com>
      Acked-by: default avatarSeiji Aguchi <seiji.aguchi@hds.com>
      Cc: Seiji Aguchi <seiji.aguchi@hds.com>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Marco Stornelli <marco.stornelli@gmail.com>
      Cc: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
      Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Cc: Vivek Goyal <vgoyal@redhat.com>
      Cc: Don Zickus <dzickus@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      c22ab332
  21. Mar 01, 2012
  22. Feb 24, 2012
    • Yinghai Lu's avatar
      PCI: prepare pci=realloc for multiple options · b55438fd
      Yinghai Lu authored
      
      Let the user could enable and disable with pci=realloc=on or pci=realloc=off
      
      Also
      1. move variable and functions near the place they are used.
      2. change macro to function
      3. change related functions and variable to static and _init
      4. update parameter description accordingly.
      
      This will let us add a config option to control default behavior, and
      still allow the user to turn off automatic reallocation if it fails on
      their platform until a permanent solution is found.
      
      -v2: still honor pci=realloc, and treat it as pci=realloc=on
           also use enum instead of ...
      -v3: update kernel-paramenters.txt according to Jesse.
      
      Signed-off-by: default avatarYinghai Lu <yinghai@kernel.org>
      Acked-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      b55438fd
  23. Feb 23, 2012
    • MUNEDA Takahiro's avatar
      PCI: Add pcie_hp=nomsi to disable MSI/MSI-X for pciehp driver · 7570a333
      MUNEDA Takahiro authored
      
      Add a parameter to avoid using MSI/MSI-X for PCIe native hotplug; it's
      known to be buggy on some platforms.
      
      In my environment, while shutting down, following stack trace is shown
      sometimes.
      
        irq 16: nobody cared (try booting with the "irqpoll" option)
        Pid: 1081, comm: reboot Not tainted 3.2.0 #1
        Call Trace:
         <IRQ>  [<ffffffff810cec1d>] __report_bad_irq+0x3d/0xe0
         [<ffffffff810cee1c>] note_interrupt+0x15c/0x210
         [<ffffffff810cc485>] handle_irq_event_percpu+0xb5/0x210
         [<ffffffff810cc621>] handle_irq_event+0x41/0x70
         [<ffffffff810cf675>] handle_fasteoi_irq+0x55/0xc0
         [<ffffffff81015356>] handle_irq+0x46/0xb0
         [<ffffffff814fbe9d>] do_IRQ+0x5d/0xe0
         [<ffffffff814f146e>] common_interrupt+0x6e/0x6e
         [<ffffffff8106b040>] ? __do_softirq+0x60/0x210
         [<ffffffff8108aeb1>] ? hrtimer_interrupt+0x151/0x240
         [<ffffffff814fb5ec>] call_softirq+0x1c/0x30
         [<ffffffff810152d5>] do_softirq+0x65/0xa0
         [<ffffffff8106ae9d>] irq_exit+0xbd/0xe0
         [<ffffffff814fbf8e>] smp_apic_timer_interrupt+0x6e/0x99
         [<ffffffff814f9e5e>] apic_timer_interrupt+0x6e/0x80
         <EOI>  [<ffffffff814f0fb1>] ? _raw_spin_unlock_irqrestore+0x11/0x20
         [<ffffffff812629fc>] pci_bus_write_config_word+0x6c/0x80
         [<ffffffff81266fc2>] pci_intx+0x52/0xa0
         [<ffffffff8127de3d>] pci_intx_for_msi+0x1d/0x30
        [<ffffffff8127e4fb>] pci_msi_shutdown+0x7b/0x110
         [<ffffffff81269d34>] pci_device_shutdown+0x34/0x50
         [<ffffffff81326c4f>] device_shutdown+0x2f/0x140
         [<ffffffff8107b981>] kernel_restart_prepare+0x31/0x40
         [<ffffffff8107b9e6>] kernel_restart+0x16/0x60
         [<ffffffff8107bbfd>] sys_reboot+0x1ad/0x220
         [<ffffffff814f4b90>] ? do_page_fault+0x1e0/0x460
         [<ffffffff811942d0>] ? __sync_filesystem+0x90/0x90
         [<ffffffff8105c9aa>] ? __cond_resched+0x2a/0x40
         [<ffffffff814ef090>] ? _cond_resched+0x30/0x40
         [<ffffffff81169e17>] ? iterate_supers+0xb7/0xd0
         [<ffffffff814f9382>] system_call_fastpath+0x16/0x1b
        handlers:
        [<ffffffff8138a0f0>] usb_hcd_irq
        [<ffffffff8138a0f0>] usb_hcd_irq
        [<ffffffff8138a0f0>] usb_hcd_irq
        Disabling IRQ #16
      
      An un-wanted interrupt is generated when PCI driver switches from
      MSI/MSI-X to INTx while shutting down the device.  The interrupt does
      not happen if MSI/MSI-X is not used on the device.
      I confirmed that this problem does not happen if pcie_hp=nomsi was
      specified and hotplug operation worked fine as usual.
      
      v2: Automatically disable MSI/MSI-X against following device:
          PCI bridge: Integrated Device Technology, Inc. Device 807f (rev 02)
      v3: Based on the review comment, combile the if statements.
      v4: Removed module parameter.
          Move some code to build pciehp as a module.
          Move device specific code to driver/pci/quirks.c.
      v5: Drop a device specific code until getting a vendor statement.
      
      Reviewed-by: default avatarKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
      Signed-off-by: default avatarMUNEDA Takahiro <muneda.takahiro@jp.fujitsu.com>
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      7570a333
  24. Feb 21, 2012
  25. Feb 15, 2012
  26. Jan 17, 2012
  27. Jan 11, 2012
    • Stanislaw Gruszka's avatar
      mm: more intensive memory corruption debugging · c0a32fc5
      Stanislaw Gruszka authored
      
      With CONFIG_DEBUG_PAGEALLOC configured, the CPU will generate an exception
      on access (read,write) to an unallocated page, which permits us to catch
      code which corrupts memory.  However the kernel is trying to maximise
      memory usage, hence there are usually few free pages in the system and
      buggy code usually corrupts some crucial data.
      
      This patch changes the buddy allocator to keep more free/protected pages
      and to interlace free/protected and allocated pages to increase the
      probability of catching corruption.
      
      When the kernel is compiled with CONFIG_DEBUG_PAGEALLOC,
      debug_guardpage_minorder defines the minimum order used by the page
      allocator to grant a request.  The requested size will be returned with
      the remaining pages used as guard pages.
      
      The default value of debug_guardpage_minorder is zero: no change from
      current behaviour.
      
      [akpm@linux-foundation.org: tweak documentation, s/flg/flag/]
      Signed-off-by: default avatarStanislaw Gruszka <sgruszka@redhat.com>
      Cc: Mel Gorman <mgorman@suse.de>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
      Cc: Christoph Lameter <cl@linux-foundation.org>
      Cc: Pekka Enberg <penberg@cs.helsinki.fi>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      c0a32fc5
  28. Jan 09, 2012
    • Trond Myklebust's avatar
      NFSv4: Change the default setting of the nfs4_disable_idmapping parameter · 074b1d12
      Trond Myklebust authored
      
      Now that the use of numeric uids/gids is officially sanctioned in
      RFC3530bis, it is time to change the default here to 'enabled'.
      
      By doing so, we ensure that NFSv4 copies the behaviour of NFSv3 when we're
      using the default AUTH_SYS authentication (i.e. when the client uses the
      numeric uids/gids as authentication tokens), so that when new files are
      created, they will appear to have the correct user/group.
      It also fixes a number of backward compatibility issues when migrating
      from NFSv3 to NFSv4 on a platform where the server uses different uid/gid
      mappings than the client.
      
      Note also that this setting has been successfully tested against servers
      that do not support numeric uids/gids at several Connectathon/Bakeathon
      events at this point, and the fall back to using string names/groups has
      been shown to work well in all those test cases.
      
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      074b1d12
  29. Dec 27, 2011
  30. Dec 21, 2011
  31. Dec 12, 2011
    • Joerg Roedel's avatar
      iommu/amd: Put IOMMUv2 capable devices in pt_domain · 5abcdba4
      Joerg Roedel authored
      
      If the device starts to use IOMMUv2 features the dma handles
      need to stay valid. The only sane way to do this is to use a
      identity mapping for the device and not translate it by the
      iommu. This is implemented with this patch. Since this lifts
      the device-isolation there is also a new kernel parameter
      which allows to disable that feature.
      
      Signed-off-by: default avatarJoerg Roedel <joerg.roedel@amd.com>
      5abcdba4
  32. Dec 07, 2011
    • Andreas Krebbel's avatar
      oprofile, s390: Add event interface to the System z hardware sampling module · dd3c4670
      Andreas Krebbel authored
      
      With this patch the OProfile Basic Mode Sampling support for System z
      is enhanced with a counter file system.  That way hardware sampling
      can be configured using the user space tools with only little
      modifications.
      
      With the patch by default new cpu_types (s390/z10, s390/z196) are
      returned in order to indicate that we are running a CPU which provides
      the hardware sampling facility.  Existing user space tools will
      complain about an unknown cpu type. In order to be compatible with
      existing user space tools the `cpu_type' module parameter has been
      added.  Setting the parameter to `timer' will force the module to
      return `timer' as cpu_type.  The module will still try to use hardware
      sampling if available and the hwsampling virtual filesystem will be
      also be available for configuration.  So this has a different effect
      than using the generic oprofile module parameter `timer=1'.
      
      If the basic mode sampling is enabled on the machine and the
      cpu_type=timer parameter is not used the kernel module will provide
      the following virtual filesystem:
      
      /dev/oprofile/0/enabled
      /dev/oprofile/0/event
      /dev/oprofile/0/count
      /dev/oprofile/0/unit_mask
      /dev/oprofile/0/kernel
      /dev/oprofile/0/user
      
      In the counter file system only the values of 'enabled', 'count',
      'kernel', and 'user' are evaluated by the kernel module. Everything
      else must contain fixed values.
      
      The 'event' value only supports a single event - HWSAMPLING with value
      0.
      
      The 'count' value specifies the hardware sampling rate as it is passed
      to the CPU measurement facility.
      
      The 'kernel' and 'user' flags can now be used to filter for samples
      when using hardware sampling.
      
      Additionally also the following file will be created:
      /dev/oprofile/timer/enabled
      
      This will always be the inverted value of /dev/oprofile/0/enabled. 0
      is not accepted without hardware sampling.
      
      Signed-off-by: default avatarAndreas Krebbel <krebbel@linux.vnet.ibm.com>
      Signed-off-by: default avatarRobert Richter <robert.richter@amd.com>
      dd3c4670
  33. Dec 06, 2011
  34. Dec 05, 2011
Loading