Skip to content
Snippets Groups Projects
  1. May 15, 2008
  2. May 14, 2008
    • Alex Chiang's avatar
      [IA64] allow user to force_pal_cache_flush · f13ae30e
      Alex Chiang authored
      
      The sequence executed in check_sal_cache_flush:
      
      	- pend a timer interrupt
      	- call SAL_CACHE_FLUSH
      	- see if interrupt is still pending
      
      can hang HP machines with buggy SAL_CACHE_FLUSH implementations.
      
      Provide a kernel command-line argument to allow users skip this
      check if desired. Using this parameter will force ia64_sal_cache_flush
      to call ia64_pal_cache_flush() instead of SAL_CACHE_FLUSH.
      
      Signed-off-by: default avatarAlex Chiang <achiang@hp.com>
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      f13ae30e
  3. May 05, 2008
  4. Apr 30, 2008
    • Thomas Gleixner's avatar
      infrastructure to debug (dynamic) objects · 3ac7fe5a
      Thomas Gleixner authored
      
      We can see an ever repeating problem pattern with objects of any kind in the
      kernel:
      
      1) freeing of active objects
      2) reinitialization of active objects
      
      Both problems can be hard to debug because the crash happens at a point where
      we have no chance to decode the root cause anymore.  One problem spot are
      kernel timers, where the detection of the problem often happens in interrupt
      context and usually causes the machine to panic.
      
      While working on a timer related bug report I had to hack specialized code
      into the timer subsystem to get a reasonable hint for the root cause.  This
      debug hack was fine for temporary use, but far from a mergeable solution due
      to the intrusiveness into the timer code.
      
      The code further lacked the ability to detect and report the root cause
      instantly and keep the system operational.
      
      Keeping the system operational is important to get hold of the debug
      information without special debugging aids like serial consoles and special
      knowledge of the bug reporter.
      
      The problems described above are not restricted to timers, but timers tend to
      expose it usually in a full system crash.  Other objects are less explosive,
      but the symptoms caused by such mistakes can be even harder to debug.
      
      Instead of creating specialized debugging code for the timer subsystem a
      generic infrastructure is created which allows developers to verify their code
      and provides an easy to enable debug facility for users in case of trouble.
      
      The debugobjects core code keeps track of operations on static and dynamic
      objects by inserting them into a hashed list and sanity checking them on
      object operations and provides additional checks whenever kernel memory is
      freed.
      
      The tracked object operations are:
      - initializing an object
      - adding an object to a subsystem list
      - deleting an object from a subsystem list
      
      Each operation is sanity checked before the operation is executed and the
      subsystem specific code can provide a fixup function which allows to prevent
      the damage of the operation.  When the sanity check triggers a warning message
      and a stack trace is printed.
      
      The list of operations can be extended if the need arises.  For now it's
      limited to the requirements of the first user (timers).
      
      The core code enqueues the objects into hash buckets.  The hash index is
      generated from the address of the object to simplify the lookup for the check
      on kfree/vfree.  Each bucket has it's own spinlock to avoid contention on a
      global lock.
      
      The debug code can be compiled in without being active.  The runtime overhead
      is minimal and could be optimized by asm alternatives.  A kernel command line
      option enables the debugging code.
      
      Thanks to Ingo Molnar for review, suggestions and cleanup patches.
      
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Cc: Greg KH <greg@kroah.com>
      Cc: Randy Dunlap <randy.dunlap@oracle.com>
      Cc: Kay Sievers <kay.sievers@vrfy.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      3ac7fe5a
    • Samuel Thibault's avatar
      Basic braille screen reader support · f7511d5f
      Samuel Thibault authored
      
      This adds a minimalistic braille screen reader support.  This is meant to
      be used by blind people e.g.  on boot failures or when / cannot be mounted
      etc and thus the userland screen readers can not work.
      
      [akpm@linux-foundation.org: fix exports]
      Signed-off-by: default avatarSamuel Thibault <samuel.thibault@ens-lyon.org>
      Cc: Jiri Kosina <jikos@jikos.cz>
      Cc: Dmitry Torokhov <dtor@mail.ru>
      Acked-by: default avatarAlan Cox <alan@redhat.com>
      Cc: Randy Dunlap <randy.dunlap@oracle.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      f7511d5f
  5. Apr 29, 2008
  6. Apr 27, 2008
  7. Apr 21, 2008
    • mark gross's avatar
      PCI: iommu: iotlb flushing · 5e0d2a6f
      mark gross authored
      
      This patch is for batching up the flushing of the IOTLB for the DMAR
      implementation found in the Intel VT-d hardware.  It works by building a list
      of to be flushed IOTLB entries and a bitmap list of which DMAR engine they are
      from.
      
      After either a high water mark (250 accessible via debugfs) or 10ms the list
      of iova's will be reclaimed and the DMAR engines associated are IOTLB-flushed.
      
      This approach recovers 15 to 20% of the performance lost when using the IOMMU
      for my netperf udp stream benchmark with small packets.  It can be disabled
      with a kernel boot parameter "intel_iommu=strict".
      
      Its use does weaken the IOMMU protections a bit.
      
      Signed-off-by: default avatarMark Gross <mgross@linux.intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      5e0d2a6f
    • Greg Kroah-Hartman's avatar
      PCI: remove initial bios sort of PCI devices on x86 · 1ba6ab11
      Greg Kroah-Hartman authored
      
      We currently keep 2 lists of PCI devices in the system, one in the
      driver core, and one all on its own.  This second list is sorted at boot
      time, in "BIOS" order, to try to remain compatible with older kernels
      (2.2 and earlier days).  There was also a "nosort" option to turn this
      sorting off, to remain compatible with even older kernel versions, but
      that just ends up being what we have been doing from 2.5 days...
      
      Unfortunately, the second list of devices is not really ever used to 
      determine the probing order of PCI devices or drivers[1].  That is done
      using the driver core list instead.  This change happened back in the
      early 2.5 days.
      
      Relying on BIOS ording for the binding of drivers to specific device
      names is problematic for many reasons, and userspace tools like udev
      exist to properly name devices in a persistant manner if that is needed,
      no reliance on the BIOS is needed.
      
      Matt Domsch and others at Dell noticed this back in 2006, and added a
      boot option to sort the PCI device lists (both of them) in a
      breadth-first manner to help remain compatible with the 2.4 order, if
      needed for any reason.  This option is not going away, as some systems
      rely on them.
      
      This patch removes the sorting of the internal PCI device list in "BIOS"
      mode, as it's not needed at all anymore, and hasn't for many years.
      I've also removed the PCI flags for this from some other arches that for
      some reason defined them, but never used them.
      
      This should not change the ordering of any drivers or device probing.
      
      [1] The old-style pci_get_device and pci_find_device() still used this
      sorting order, but there are very few drivers that use these functions,
      as they are deprecated for use in this manner.  If for some reason, a
      driver rely on the order and uses these functions, the breadth-first
      boot option will resolve any problem.
      
      Cc: Matt Domsch <Matt_Domsch@dell.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      1ba6ab11
  8. Apr 19, 2008
  9. Apr 17, 2008
  10. Apr 11, 2008
  11. Apr 04, 2008
    • Paul Menage's avatar
      cgroups: add cgroup support for enabling controllers at boot time · 8bab8dde
      Paul Menage authored
      
      The effects of cgroup_disable=foo are:
      
      - foo isn't auto-mounted if you mount all cgroups in a single hierarchy
      - foo isn't visible as an individually mountable subsystem
      
      As a result there will only ever be one call to foo->create(), at init time;
      all processes will stay in this group, and the group will never be mounted on
      a visible hierarchy.  Any additional effects (e.g.  not allocating metadata)
      are up to the foo subsystem.
      
      This doesn't handle early_init subsystems (their "disabled" bit isn't set be,
      but it could easily be extended to do so if any of the early_init systems
      wanted it - I think it would just involve some nastier parameter processing
      since it would occur before the command-line argument parser had been run.
      
      Hugh said:
      
        Ballpark figures, I'm trying to get this question out rather than
        processing the exact numbers: CONFIG_CGROUP_MEM_RES_CTLR adds 15% overhead
        to the affected paths, booting with cgroup_disable=memory cuts that back to
        1% overhead (due to slightly bigger struct page).
      
        I'm no expert on distros, they may have no interest whatever in
        CONFIG_CGROUP_MEM_RES_CTLR=y; and the rest of us can easily build with or
        without it, or apply the cgroup_disable=memory patches.
      
      Unix bench's execl test result on x86_64 was
      
      == just after boot without mounting any cgroup fs.==
      mem_cgorup=off : Execl Throughput       43.0     3150.1      732.6
      mem_cgroup=on  : Execl Throughput       43.0     2932.6      682.0
      ==
      
      [lizf@cn.fujitsu.com: fix boot option parsing]
      Signed-off-by: default avatarBalbir Singh <balbir@linux.vnet.ibm.com>
      Cc: Paul Menage <menage@google.com>
      Cc: Balbir Singh <balbir@linux.vnet.ibm.com>
      Cc: Pavel Emelyanov <xemul@openvz.org>
      Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: Hugh Dickins <hugh@veritas.com>
      Cc: Sudhir Kumar <skumar@linux.vnet.ibm.com>
      Cc: YAMAMOTO Takashi <yamamoto@valinux.co.jp>
      Cc: David Rientjes <rientjes@google.com>
      Signed-off-by: default avatarLi Zefan <lizf@cn.fujitsu.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      8bab8dde
    • Fenghua Yu's avatar
      [IA64] Kernel parameter for max number of concurrent global TLB purges · a6c75b86
      Fenghua Yu authored
      
      The patch defines kernel parameter "nptcg=". The parameter overrides max number
      of concurrent global TLB purges which is reported from either PAL_VM_SUMMARY or
      SAL PALO.
      
      Signed-off-by: default avatarFenghua Yu <fenghua.yu@intel.com>
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      a6c75b86
  12. Apr 01, 2008
    • Rafael J. Wysocki's avatar
      ACPI PM: Restore the 2.6.24 suspend ordering · 7731ce63
      Rafael J. Wysocki authored
      Some time ago it turned out that our suspend code ordering broke some
      NVidia-based systems that hung if _PTS was executed with one of the PCI
      devices, specifically a USB controller, in a low power state.
      
      Then, it was noticed that the suspend code ordering was not compliant
      with ACPI 1.0, although it was compliant with ACPI 2.0 (and later), and
      it was argued that the code had to be changed for that reason (ref.
      http://bugzilla.kernel.org/show_bug.cgi?id=9528).
      
      So we did, but evidently we did wrong, because it's now turning out that
      some systems have been broken by this change. Refs:
      	http://bugzilla.kernel.org/show_bug.cgi?id=10340
      	https://bugzilla.novell.com/show_bug.cgi?id=374217#c16
      
      [ I said at that time that something like this might happend, but the
        majority of people involved thought that it was improbable due to the
        necessity to preserve the compliance of hardware with ACPI 1.0. ]
      
      This actually is a quite serious regression from 2.6.24.
      
      Moreover, the ACPI 1.0 ordering of suspend code introduced another issue
      that I have only noticed recently.  Namely, if the suspend of one of
      devices fails, the already suspended devices will be resumed without
      executing _WAK before, which leads to problems on some systems (for
      example, in such situations thermal management is broken on my HP
      nx6325).  Consequently, it also breaks suspend debugging on the affected
      systems.
      
      Note also, that the requirement to execute _PTS before suspending
      devices does not really make sense, because the device in question may
      be put into a low power state at run time for a reason unrelated to a
      system-wide suspend.
      
      For the reasons outlined above, the change of the suspend ordering
      should be reverted, which is done by the patch below.
      
      [ Felix Möller: "I am the reporter from the original Novell Bug:
      
      	https://bugzilla.novell.com/show_bug.cgi?id=374217
      
      
      
        I just tried current git head (two hours ago) with the patch (the one
        from the beginning of this thread) from Rafael and without it.  With
        the patch my MacBook does suspend without it does not." ]
      
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      Tested-by: default avatarFelix Möller <felix@derklecks.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      7731ce63
    • Robert Brose's avatar
      [POWERPC] Add kernel parameter to set l3cr for MPC745x · a78bfbfc
      Robert Brose authored
      
      Old-world powermacs don't set L2CR or L3CR on processor upgrade cards.
      This simple patch allows the setting of L3CR via a kernel parameter
      (like the existing kernel parameter to set L2CR).
      
      Signed-off-by: default avatarRobert Brose <bob@qbjnet.com>
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      a78bfbfc
  13. Mar 25, 2008
  14. Mar 15, 2008
    • Linus Torvalds's avatar
      ACPI: Remove ACPI_CUSTOM_DSDT_INITRD option · 9a9e0d68
      Linus Torvalds authored
      
      This essentially reverts commit 71fc47a9
      ("ACPI: basic initramfs DSDT override support"), because the code simply
      isn't ready.
      
      It did ugly things to the init sequence to populate the rootfs image
      early, but that just ended up showing other problems with the whole
      approach.  The fact is, the VFS layer simply isn't initialized this
      early, and the relevant ACPI code should either run much later, or this
      shouldn't be done at all.
      
      For 2.6.25, we'll just pick the latter option.  We can revisit this
      concept later if necessary.
      
      Cc: Dave Hansen <haveblue@us.ibm.com>
      Cc: Tilman Schmidt <tilman@imap.cc>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Thomas Renninger <trenn@suse.de>
      Cc: Eric Piel <eric.piel@tremplin-utc.net>
      Cc: Len Brown <len.brown@intel.com>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Markus Gaugusch <dsdt@gaugusch.at>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      9a9e0d68
  15. Mar 14, 2008
  16. Mar 12, 2008
  17. Mar 07, 2008
  18. Feb 20, 2008
    • Tejun Heo's avatar
      libata: implement libata.force module parameter · 33267325
      Tejun Heo authored
      
      This patch implements libata.force module parameter which can
      selectively override ATA port, link and device configurations
      including cable type, SATA PHY SPD limit, transfer mode and NCQ.
      
      For example, you can say "use 1.5Gbps for all fan-out ports attached
      to the second port but allow 3.0Gbps for the PMP device itself, oh,
      the device attached to the third fan-out port chokes on NCQ and
      shouldn't go over UDMA4" by the following.
      
       libata.force=2:1.5g,2.15:3.0g,2.03:noncq,udma4
      
      Signed-off-by: default avatarTejun Heo <htejun@gmail.com>
      Signed-off-by: default avatarJeff Garzik <jeff@garzik.org>
      33267325
  19. Feb 19, 2008
  20. Feb 08, 2008
  21. Feb 07, 2008
  22. Feb 06, 2008
  23. Feb 03, 2008
  24. Feb 01, 2008
  25. Jan 30, 2008
Loading