1. 17 Mar, 2006 3 commits
  2. 14 Mar, 2006 1 commit
  3. 09 Mar, 2006 1 commit
  4. 08 Mar, 2006 2 commits
    • Andi Kleen's avatar
      [PATCH] i386: port ATI timer fix from x86_64 to i386 II · f9262c12
      Andi Kleen authored
      ATI chipsets tend to generate double timer interrupts for the local APIC
      timer when both the 8254 and the IO-APIC timer pins are enabled.  This is
      because they route it to both and the result is anded together and the CPU
      ends up processing it twice.
      This patch changes check_timer to disable the 8254 routing for interrupt 0.
      I think it would be safe on all chipsets actually (i tested it on a couple
      and it worked everywhere) and Windows seems to do it in a similar way, but
      to be conservative this patch only enables this mode on ATI (and adds
      options to enable/disable too)
      Ported over from a similar x86-64 change.
      I reused the ACPI earlyquirk infrastructure for the ATI bridge check, but
      tweaked it a bit to work even without ACPI.
      Inspired by a patch from Chuck Ebbert, but redone.
      Cc: Chuck Ebbert <76306.1226@compuserve.com>
      Cc: "Brown, Len" <len.brown@intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    • Dipankar Sarma's avatar
      [PATCH] rcu batch tuning · 21a1ea9e
      Dipankar Sarma authored
      This patch adds new tunables for RCU queue and finished batches.  There are
      two types of controls - number of completed RCU updates invoked in a batch
      (blimit) and monitoring for high rate of incoming RCUs on a cpu (qhimark,
      By default, the per-cpu batch limit is set to a small value.  If the input
      RCU rate exceeds the high watermark, we do two things - force quiescent
      state on all cpus and set the batch limit of the CPU to INTMAX.  Setting
      batch limit to INTMAX forces all finished RCUs to be processed in one shot.
       If we have more than INTMAX RCUs queued up, then we have bigger problems
      anyway.  Once the incoming queued RCUs fall below the low watermark, the
      batch limit is set to the default.
      Signed-off-by: default avatarDipankar Sarma <dipankar@in.ibm.com>
      Cc: "Paul E. McKenney" <paulmck@us.ibm.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
  5. 04 Mar, 2006 1 commit
  6. 03 Mar, 2006 3 commits
  7. 27 Feb, 2006 1 commit
  8. 26 Feb, 2006 1 commit
    • Andi Kleen's avatar
      [PATCH] x86_64: Better ATI timer fix · ab9b32ee
      Andi Kleen authored
      The previous experiment for using apicmaintimer on ATI systems didn't
      work out very well.  In particular laptops with C2/C3 support often
      don't let it tick during idle, which makes it useless.  There were also
      some other bugs that made the apicmaintimer often not used at all.
      I tried some other experiments - running timer over RTC and some other
      things but they didn't really work well neither.
      I rechecked the specs now and it turns out this simple change is
      actually enough to avoid the double ticks on the ATI systems.  We just
      turn off IRQ 0 in the 8254 and only route it directly using the IO-APIC.
      I tested it on a few ATI systems and it worked there.  In fact it worked
      on all chipsets (NVidia, Intel, AMD, ATI) I tried it on.
      According to the ACPI spec routing should always work through the
      IO-APIC so I think it's the correct thing to do anyways (and most of the
      old gunk in check_timer should be thrown away for x86-64).
      But for 2.6.16 it's best to do a fairly minimal change:
       - Use the known to be working everywhere-but-ATI IRQ0 both over 8254
         and IO-APIC setup everywhere
       - Except on ATI disable IRQ0 in the 8254
       - Remove the code to select apicmaintimer on ATI chipsets
       - Add some boot options to allow to override this (just paranoia)
      In 2.6.17 I hope to switch the default over to this for everybody.
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
  9. 24 Feb, 2006 2 commits
  10. 22 Feb, 2006 1 commit
    • Greg Kroah-Hartman's avatar
      Revert mount/umount uevent removal · fa675765
      Greg Kroah-Hartman authored
      This change reverts the 033b96fd
      from Kay Sievers that removed the mount/umount uevents from the kernel.
      Some older versions of HAL still depend on these events to detect when a
      new device has been mounted.  These events are not correctly emitted,
      and are broken by design, and so, should not be relied upon by any
      future program.  Instead, the /proc/mounts file should be polled to
      properly detect this kind of event.
      A feature-removal-schedule.txt entry has been added, noting when this
      interface will be removed from the kernel.
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
  11. 21 Feb, 2006 1 commit
    • Hugh Dickins's avatar
      [PATCH] tmpfs: fix mount mpol nodelist parsing · b00dc3ad
      Hugh Dickins authored
      I've been dissatisfied with the mpol_nodelist mount option which was
      added to tmpfs earlier in -rc.  Replace it by mpol=policy:nodelist.
      And it was broken: a nodelist is a comma-separated list of numbers and
      ranges; the mount options are a comma-separated list of token=values.
      Whoops, blindly strsep'ing on commas doesn't work so well: since we've
      no numeric tokens, and unlikely to add them, use that to distinguish.
      Move the mpol= parsing to shmem_parse_mpol under CONFIG_NUMA, reject
      all its options as invalid if not NUMA.  /proc shows MPOL_PREFERRED
      as "prefer", so use that name for the policy instead of "preferred".
      Enforce that mpol=default has no nodelist; that mpol=prefer has one
      node only; that mpol=bind has a nodelist; but let mpol=interleave use
      node_online_map if no nodelist given.  Describe this in tmpfs.txt.
      Signed-off-by: default avatarHugh Dickins <hugh@veritas.com>
      Acked-by: default avatarRobin Holt <holt@sgi.com>
      Acked-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
  12. 20 Feb, 2006 3 commits
  13. 17 Feb, 2006 3 commits
  14. 16 Feb, 2006 1 commit
  15. 15 Feb, 2006 1 commit
  16. 14 Feb, 2006 3 commits
    • David Howells's avatar
      [PATCH] FRV: Use virtual interrupt disablement · 28baebae
      David Howells authored
      Make the FRV arch use virtual interrupt disablement because accesses to the
      processor status register (PSR) are relatively slow and because we will
      soon have the need to deal with multiple interrupt controls at the same
      time (separate h/w and inter-core interrupts).
      The way this is done is to dedicate one of the four integer condition code
      registers (ICC2) to maintaining a virtual interrupt disablement state
      whilst inside the kernel.  This uses the ICC2.Z flag (Zero) to indicate
      whether the interrupts are virtually disabled and the ICC2.C flag (Carry)
      to indicate whether the interrupts are physically disabled.
      ICC2.Z is set to indicate interrupts are virtually disabled.  ICC2.C is set
      to indicate interrupts are physically enabled.  Under normal running
      conditions Z==0 and C==1.
      Disabling interrupts with local_irq_disable() doesn't then actually
      physically disable interrupts - it merely sets ICC2.Z to 1.  Should an
      interrupt then happen, the exception prologue will note ICC2.Z is set and
      branch out of line using one instruction (an unlikely BEQ).  Here it will
      physically disable interrupts and clear ICC2.C.
      When it comes time to enable interrupts (local_irq_enable()), this simply
      clears the ICC2.Z flag and invokes a trap #2 if both Z and C flags are
      clear (the HI integer condition).  This can be done with the TIHI
      conditional trap instruction.
      The trap then physically reenables interrupts and sets ICC2.C again.  Upon
      returning the interrupt will be taken as interrupts will then be enabled.
      Note that whilst processing the trap, the whole exceptions system is
      disabled, and so an interrupt can't happen till it returns.
      If no pending interrupt had happened, ICC2.C would still be set, the HI
      condition would not be fulfilled, and no trap will happen.
      Saving interrupts (local_irq_save) is simply a matter of pulling the ICC2.Z
      flag out of the CCR register, shifting it down and masking it off.  This
      gives a result of 0 if interrupts were enabled and 1 if they weren't.
      Restoring interrupts (local_irq_restore) is then a matter of taking the
      saved value mentioned previously and XOR'ing it against 1.  If it was one,
      the result will be zero, and if it was zero the result will be non-zero.
      This result is then used to affect the ICC2.Z flag directly (it is a
      condition code flag after all).  An XOR instruction does not affect the
      Carry flag, and so that bit of state is unchanged.  The two flags can then
      be sampled to see if they're both zero using the trap (TIHI) as for the
      unconditional reenablement (local_irq_enable).
      This patch also:
       (1) Modifies the debugging stub (break.S) to handle single-stepping crossing
           into the trap #2 handler and into virtually disabled interrupts.
       (2) Removes superseded fixup pointers from the second instructions in the trap
           tables (there's no a separate fixup table for this).
       (3) Declares the trap #3 vector for use in .org directives in the trap table.
       (4) Moves irq_enter() and irq_exit() in do_IRQ() to avoid problems with
           virtual interrupt handling, and removes the duplicate code that has now
           been folded into irq_exit() (softirq and preemption handling).
       (5) Tells the compiler in the arch Makefile that ICC2 is now reserved.
       (6) Documents the in-kernel ABI, including the virtual interrupts.
       (7) Renames the old irq management functions to different names.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    • Jim Keniston's avatar
      [PATCH] kprobes: Update Documentation/kprobes.txt · 8861da31
      Jim Keniston authored
      Update Documentation/kprobes.txt to reflect Kprobes enhancements and other
      recent developments.
      Acked-by: default avatarAnanth Mavinakayanahalli <mananth@in.ibm.com>
      Signed-off-by: default avatarJim Keniston <jkenisto@us.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    • Ralf Baechle's avatar
  17. 13 Feb, 2006 1 commit
  18. 09 Feb, 2006 1 commit
  19. 07 Feb, 2006 2 commits
  20. 06 Feb, 2006 6 commits
  21. 04 Feb, 2006 2 commits
    • Andi Kleen's avatar
      [PATCH] x86_64: Calibrate APIC timer using PM timer · 0c3749c4
      Andi Kleen authored
      On some broken motherboards (at least one NForce3 based AMD64 laptop)
      the PIT timer runs at a incorrect frequency.  This patch adds a new
      option "apicpmtimer" that allows to use the APIC timer and calibrate it
      using the PMTimer.  It requires the earlier patch that allows to run the
      main timer from the APIC.
      Specifying apicpmtimer implies apicmaintimer.
      The option defaults to off for now.
      I tested it on a few systems and the resulting APIC timer frequencies
      were usually a bit off, but always <1%, which should be tolerable.
      TBD figure out heuristic to enable this automatically on the affected
      systems TBD perhaps do it on all NForce3s or using DMI?
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    • Andi Kleen's avatar
      [PATCH] x86_64: Allow to run main time keeping from the local APIC interrupt · 73dea47f
      Andi Kleen authored
      Another piece from the no-idle-tick patch.
      This can be enabled with the "apicmaintimer" option.
      This is mainly useful when the PIT/HPET interrupt is unreliable.
      Note there are some systems that are known to stop the APIC
      timer in C3. For those it will never work, but this case
      should be automatically detected.
      It also only works with PM timer right now. When HPET is used
      the way the main timer handler computes the delay doesn't work.
      It should be a bit more efficient because there is one less
      regular interrupt to process on the boot processor.
      Requires earlier bugfix from Venkatesh
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>