1. 13 2月, 2007 3 次提交
  2. 12 2月, 2007 2 次提交
  3. 08 2月, 2007 1 次提交
  4. 06 2月, 2007 1 次提交
  5. 03 2月, 2007 3 次提交
  6. 23 1月, 2007 1 次提交
  7. 11 1月, 2007 2 次提交
    • M
      [PATCH] x86-64: tighten up printks · b92cc559
      Muli Ben-Yehuda 提交于
      Signed-off-by: NMuli Ben-Yehuda <muli@il.ibm.com>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Cc: Andi Kleen <ak@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      b92cc559
    • J
      [PATCH] x86-64: - Ignore long SMI interrupts in clock calibration · ed5316d4
      Jack Steiner 提交于
      Ensure that no SMI interrupts occur between the read of the HPET & TSC
      in the clock calibration loop.
      
      I noticed that a 2.66GHz system incorrectly detected the processor
      clock speed about 1/7 of the time:
      
      	time.c: Detected 2660.005 MHz processor.	(most of the time)
      	time.c: Detected 2988.203 MHz processor.	(sometime)
      
      The problem is caused by an SMI interrupt occuring in hpet_calibrate_tsc()
      between the read of the HPET & TSC. Prior to switching the BIOS into
      ACPI mode, it appears that every 27msec an SMI interrupt occurs. The
      SMI interrupt takes 4.8 msec to process.
      
      Note: On my test system, TICK_MIN had to be >380. I picked 5000
      to minimize risk of having a value that is too small for other
      platforms.
      Signed-off-by: NJack Steiner <steiner@sgi.com>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      
       arch/x86_64/kernel/time.c |   25 +++++++++++++++++++++----
       1 file changed, 21 insertions(+), 4 deletions(-)
      ed5316d4
  8. 09 1月, 2007 1 次提交
  9. 04 1月, 2007 1 次提交
  10. 23 12月, 2006 2 次提交
    • R
      [CPUFREQ] select consistently · 917325d3
      Randy Dunlap 提交于
      Make x86_64 ACPI_CPU_FREQ select CPU_FREQ_TABLE like other methods do.
      (although we should still eliminate as much use of 'select' as possible)
      Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NDave Jones <davej@redhat.com>
      917325d3
    • I
      [PATCH] sched: fix bad missed wakeups in the i386, x86_64, ia64, ACPI and APM idle code · 0888f06a
      Ingo Molnar 提交于
      Fernando Lopez-Lezcano reported frequent scheduling latencies and audio
      xruns starting at the 2.6.18-rt kernel, and those problems persisted all
      until current -rt kernels. The latencies were serious and unjustified by
      system load, often in the milliseconds range.
      
      After a patient and heroic multi-month effort of Fernando, where he
      tested dozens of kernels, tried various configs, boot options,
      test-patches of mine and provided latency traces of those incidents, the
      following 'smoking gun' trace was captured by him:
      
                       _------=> CPU#
                      / _-----=> irqs-off
                     | / _----=> need-resched
                     || / _---=> hardirq/softirq
                     ||| / _--=> preempt-depth
                     |||| /
                     |||||     delay
         cmd     pid ||||| time  |   caller
            \   /    |||||   \   |   /
        IRQ_19-1479  1D..1    0us : __trace_start_sched_wakeup (try_to_wake_up)
        IRQ_19-1479  1D..1    0us : __trace_start_sched_wakeup <<...>-5856> (37 0)
        IRQ_19-1479  1D..1    0us : __trace_start_sched_wakeup (c01262ba 0 0)
        IRQ_19-1479  1D..1    0us : resched_task (try_to_wake_up)
        IRQ_19-1479  1D..1    0us : __spin_unlock_irqrestore (try_to_wake_up)
        ...
        <idle>-0     1...1   11us!: default_idle (cpu_idle)
        ...
        <idle>-0     0Dn.1  602us : smp_apic_timer_interrupt (c0103baf 1 0)
        ...
         <...>-5856  0D..2  618us : __switch_to (__schedule)
         <...>-5856  0D..2  618us : __schedule <<idle>-0> (20 162)
         <...>-5856  0D..2  619us : __spin_unlock_irq (__schedule)
         <...>-5856  0...1  619us : trace_stop_sched_switched (__schedule)
         <...>-5856  0D..1  619us : trace_stop_sched_switched <<...>-5856> (37 0)
      
      what is visible in this trace is that CPU#1 ran try_to_wake_up() for
      PID:5856, it placed PID:5856 on CPU#0's runqueue and ran resched_task()
      for CPU#0. But it decided to not send an IPI that no CPU - due to
      TS_POLLING. But CPU#0 never woke up after its NEED_RESCHED bit was set,
      and only rescheduled to PID:5856 upon the next lapic timer IRQ. The
      result was a 600+ usecs latency and a missed wakeup!
      
      the bug turned out to be an idle-wakeup bug introduced into the mainline
      kernel this summer via an optimization in the x86_64 tree:
      
          commit 495ab9c0
          Author: Andi Kleen <ak@suse.de>
          Date:   Mon Jun 26 13:59:11 2006 +0200
      
          [PATCH] i386/x86-64/ia64: Move polling flag into thread_info_status
      
          During some profiling I noticed that default_idle causes a lot of
          memory traffic. I think that is caused by the atomic operations
          to clear/set the polling flag in thread_info. There is actually
          no reason to make this atomic - only the idle thread does it
          to itself, other CPUs only read it. So I moved it into ti->status.
      
      the problem is this type of change:
      
              if (!hlt_counter && boot_cpu_data.hlt_works_ok) {
      -               clear_thread_flag(TIF_POLLING_NRFLAG);
      +               current_thread_info()->status &= ~TS_POLLING;
                      smp_mb__after_clear_bit();
                      while (!need_resched()) {
                              local_irq_disable();
      
      this changes clear_thread_flag() to an explicit clearing of TS_POLLING.
      clear_thread_flag() is defined as:
      
              clear_bit(flag, &ti->flags);
      
      and clear_bit() is a LOCK-ed atomic instruction on all x86 platforms:
      
        static inline void clear_bit(int nr, volatile unsigned long * addr)
        {
                __asm__ __volatile__( LOCK_PREFIX
                        "btrl %1,%0"
      
      hence smp_mb__after_clear_bit() is defined as a simple compile barrier:
      
        #define smp_mb__after_clear_bit()       barrier()
      
      but the explicit TS_POLLING clearing introduced by the patch:
      
      +               current_thread_info()->status &= ~TS_POLLING;
      
      is not an atomic op! So the clearing of the TS_POLLING bit is freely
      reorderable with the reading of the NEED_RESCHED bit - and both now
      reside in different memory addresses.
      
      CPU idle wakeup very much depends on ordered memory ops, the clearing of
      the TS_POLLING flag must always be done before we test need_resched()
      and hit the idle instruction(s). [Symmetrically, the wakeup code needs
      to set NEED_RESCHED before it tests the TS_POLLING flag, so memory
      ordering is paramount.]
      
      Fernando's dual-core Athlon64 system has a sufficiently advanced memory
      ordering model so that it triggered this scenario very often.
      
      ( And it also turned out that the reason why these latencies never
        triggered on my testsystems is that i routinely use idle=poll, which
        was the only idle variant not affected by this bug. )
      
      The fix is to change the smp_mb__after_clear_bit() to an smp_mb(), to
      act as an absolute barrier between the TS_POLLING write and the
      NEED_RESCHED read. This affects almost all idling methods (default,
      ACPI, APM), on all 3 x86 architectures: i386, x86_64, ia64.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Tested-by: NFernando Lopez-Lezcano <nando@ccrma.Stanford.EDU>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      0888f06a
  11. 21 12月, 2006 1 次提交
    • I
      [PATCH] x86_64: fix boot time hang in detect_calgary() · 136f1e7a
      Ingo Molnar 提交于
      if CONFIG_CALGARY_IOMMU is built into the kernel via
      CONFIG_CALGARY_IOMMU_ENABLED_BY_DEFAULT, or is enabled via the
      iommu=calgary boot option, then the detect_calgary() function runs to
      detect the presence of a Calgary IOMMU.
      
      detect_calgary() first searches the BIOS EBDA area for a "rio_table_hdr"
      BIOS table. It has this parsing algorithm for the EBDA:
      
      	while (offset) {
      		...
      		/* The next offset is stored in the 1st word. 0 means no more */
       		offset = *((unsigned short *)(ptr + offset));
      	}
      
      got that? Lets repeat it slowly: we've got a BIOS-supplied data
      structure, plus Linux kernel code that will only break out of an
      infinite parsing loop once the BIOS gives a zero offset. Ok?
      
      Translation: what an excellent opportunity for BIOS writers to lock up
      the Linux boot process in an utterly hard to debug place! Indeed the
      BIOS jumped on that opportunity on my box, which has the following EBDA
      chaining layout:
      
        384, 65282, 65535, 65535, 65535, 65535, 65535, 65535 ...
      
      see the pattern? So my, definitely non-Calgary system happily locks up
      in detect_calgary()!
      
      the patch below fixes the boot hang by trusting the BIOS-supplied data
      structure a bit less: the parser always has to make forward progress,
      and if it doesnt, we break out of the loop and i get the expected kernel
      message:
      
        Calgary: Unable to locate Rio Grande Table in EBDA - bailing!
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Acked-by: NMuli Ben-Yehuda <muli@il.ibm.com>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      136f1e7a
  12. 16 12月, 2006 1 次提交
    • L
      Remove stack unwinder for now · d1526e2c
      Linus Torvalds 提交于
      It has caused more problems than it ever really solved, and is
      apparently not getting cleaned up and fixed.  We can put it back when
      it's stable and isn't likely to make warning or bug events worse.
      
      In the meantime, enable frame pointers for more readable stack traces.
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      d1526e2c
  13. 11 12月, 2006 1 次提交
  14. 10 12月, 2006 2 次提交
    • A
      [PATCH] x86: Work around gcc 4.2 over aggressive optimizer · 1bac3b38
      Andi Kleen 提交于
      The new PDA code uses a dummy _proxy_pda variable to describe
      memory references to the PDA. It is never referenced
      in inline assembly, but exists as input/output arguments.
      gcc 4.2 in some cases can CSE references to this which causes
      unresolved symbols.  Define it to zero to avoid this.
      Signed-off-by: NAndi Kleen <ak@suse.de>
      1bac3b38
    • R
      [PATCH] x86: Fix boot hang due to nmi watchdog init code · 92715e28
      Ravikiran G Thirumalai 提交于
      2.6.19  stopped booting (or booted based on build/config) on our x86_64
      systems due to a bug introduced in 2.6.19.  check_nmi_watchdog schedules an
      IPI on all cpus to  busy wait on a flag, but fails to set the busywait
      flag if NMI functionality is disabled.  This causes the secondary cpus
      to spin in an endless loop, causing the kernel bootup to hang.
      Depending upon the build, the  busywait flag got overwritten (stack variable)
      and caused  the kernel to bootup on certain builds.  Following patch fixes
      the bug by setting the busywait flag before returning from check_nmi_watchdog.
      I guess using a stack variable is not good here as the calling function could
      potentially return while the busy wait loop is still spinning on the flag.
      
      AK: I redid the patch significantly to be cleaner
      Signed-off-by: NRavikiran Thirumalai <kiran@scalex86.org>
      Signed-off-by: NShai Fultheim <shai@scalex86.org>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      92715e28
  15. 09 12月, 2006 1 次提交
    • J
      [PATCH] Generic BUG for x86-64 · c31a0bf3
      Jeremy Fitzhardinge 提交于
      This makes x86-64 use the generic BUG machinery.
      
      The main advantage in using the generic BUG machinery for x86-64 is that
      the inlined overhead of BUG is just the ud2a instruction; the file+line
      information are no longer inlined into the instruction stream.  This
      reduces cache pollution.
      Signed-off-by: NJeremy Fitzhardinge <jeremy@goop.org>
      Cc: Andi Kleen <ak@muc.de>
      Cc: Hugh Dickens <hugh@veritas.com>
      Cc: Michael Ellerman <michael@ellerman.id.au>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      c31a0bf3
  16. 08 12月, 2006 6 次提交
  17. 07 12月, 2006 11 次提交