1. 06 2月, 2007 21 次提交
  2. 04 2月, 2007 2 次提交
  3. 12 1月, 2007 1 次提交
  4. 05 1月, 2007 1 次提交
    • J
      ACPI: Altix: ACPI _PRT support · 3948ec94
      John Keller 提交于
      Provide ACPI _PRT support for SN Altix systems.
      
      The SN Altix platform does not conform to the
      IOSAPIC IRQ routing model, so a new acpi_irq_model
      (ACPI_IRQ_MODEL_PLATFORM) has been defined. The SN
      platform specific code sets acpi_irq_model to
      this new value, and keys off of it in acpi_register_gsi()
      to avoid the iosapic code path.
      Signed-off-by: NJohn Keller <jpk@sgi.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      3948ec94
  5. 23 12月, 2006 1 次提交
    • 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
  6. 21 12月, 2006 1 次提交
  7. 14 12月, 2006 1 次提交
    • R
      [PATCH] getting rid of all casts of k[cmz]alloc() calls · 5cbded58
      Robert P. J. Day 提交于
      Run this:
      
      	#!/bin/sh
      	for f in $(grep -Erl "\([^\)]*\) *k[cmz]alloc" *) ; do
      	  echo "De-casting $f..."
      	  perl -pi -e "s/ ?= ?\([^\)]*\) *(k[cmz]alloc) *\(/ = \1\(/" $f
      	done
      
      And then go through and reinstate those cases where code is casting pointers
      to non-pointers.
      
      And then drop a few hunks which conflicted with outstanding work.
      
      Cc: Russell King <rmk@arm.linux.org.uk>, Ian Molton <spyro@f2s.com>
      Cc: Mikael Starvik <starvik@axis.com>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: Roman Zippel <zippel@linux-m68k.org>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Kyle McMartin <kyle@mcmartin.ca>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: Greg KH <greg@kroah.com>
      Cc: Jens Axboe <jens.axboe@oracle.com>
      Cc: Paul Fulghum <paulkf@microgate.com>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Cc: Karsten Keil <kkeil@suse.de>
      Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
      Cc: Jeff Garzik <jeff@garzik.org>
      Cc: James Bottomley <James.Bottomley@steeleye.com>
      Cc: Ian Kent <raven@themaw.net>
      Cc: Steven French <sfrench@us.ibm.com>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Neil Brown <neilb@cse.unsw.edu.au>
      Cc: Jaroslav Kysela <perex@suse.cz>
      Cc: Takashi Iwai <tiwai@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      5cbded58
  8. 13 12月, 2006 11 次提交
    • B
      [IA64] kprobe clears qp bits for special instructions · df3e0d1c
      bibo,mao 提交于
      On IA64 there exists some special instructions which
      always need to be executed regradless of qp bits, such
      as com.crel.unc, tbit.trel.unc etc.
      This patch clears qp bits when inserting kprobe trap code
      and disables probepoint on slot 1 for these special
      instructions.
      Signed-off-by: Nbibo,mao <bibo.mao@intel.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      df3e0d1c
    • T
      [IA64] enable trap code on slot 1 · 08ed38b6
      Tony Luck 提交于
      Because slot 1 of one instr bundle crosses border of two consecutive
      8-bytes, kprobe on slot 1 is disabled. This patch enables kprobe on
      slot1, it only replaces higher 8-bytes of the instruction bundle and
      changes the exception code to ignore the low 12 bits of the break
      number (which is across the border in the lower 8-bytes of the bundle).
      
      For those instructions which must execute regardless qp bits,
      kprobe on slot 1 is still disabled.
      Signed-off-by: Nbibo,mao <bibo.mao@intel.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      08ed38b6
    • T
      [IA64] Take defensive stance on ia64_pal_get_brand_info() · 75f6a1de
      Tony Luck 提交于
      Stephane thought he saw a problem here (but was just confused
      by the return value from ia64_pal_get_brand_info()).  But we
      should be more defensive here in case an prototype PAL for
      a future processor doesn't implement this PAL call.
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      75f6a1de
    • D
      [IA64] fix possible XPC deadlock when disconnecting · a460ef8d
      Dean Nelson 提交于
      This patch eliminates a potential deadlock that is possible when XPC
      disconnects a channel to a partition that has gone down. This deadlock will
      occur if at least one of the kthreads created by XPC for the purpose of making
      callouts to the channel's registerer is detained in the registerer and will
      not be returning back to XPC until some registerer request occurs on the now
      downed partition. The potential for a deadlock is removed by ensuring that
      there always is a kthread available to make the channel disconnecting callout
      to the registerer.
      Signed-off-by: NDean Nelson <dcn@sgi.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      a460ef8d
    • J
      [IA64] - Reduce overhead of FP exception logging messages · 1cf24bdb
      Jack Steiner 提交于
      Improve the scalability of the fpswa code that rate-limits
      logging of messages.
      
      There are 2 distinctly different problems in this code.
      
      1) If prctl is used to disable logging, last_time is never
         updated. The result is that fpu_swa_count is zeroed out on
         EVERY fp fault. This causes a very very hot cache line.
         The fix reduces the wallclock time of a 1024p FP exception test
         from 28734 sec to 19 sec!!!
      
      2) On VERY large systems, excessive messages are logged because
         multiple cpus can each reset or increment fpu_swa_count at
         about the same time. The result is that hundreds of messages
         are logged each second. The fixes reduces the logging rate
         to ~1 per second.
      Signed-off-by: NJack Steiner <steiner@sgi.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      1cf24bdb
    • T
      [IA64] fix arch/ia64/mm/contig.c:235: warning: unused variable `nid' · 8b9c1068
      Tony Luck 提交于
      This warning only shows up with CONFIG_VIRTUAL_MEM_MAP=y and
      CONFIG_FLATMEM=y.
      
      There is only one caller left for register_active_ranges() from the
      contig.c code ... so it doesn't need to pick up the node number, the
      node number is always zero.
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      8b9c1068
    • T
      [IA64] s/termios/ktermios/ in simserial.c · f889a26a
      Tony Luck 提交于
      This got missed in 606d099cSigned-off-by: NTony Luck <tony.luck@intel.com>
      f889a26a
    • H
      [IA64] kexec/kdump: tidy up declaration of relocate_new_kernel_t · 53da5763
      Horms 提交于
      * Make NORET_TYPE and ATTRIB_NORET in line with the
        declaration for other architectures
      * Add parameter names
      Signed-Off-By: NSimon Horman <horms@verge.net.au>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      53da5763
    • H
      [IA64] Kexec/Kdump: honour non-zero crashkernel offset. · ad1c3ba7
      Horms 提交于
      There seems to be a value in both allowing the kernel to determine
      the base offset of the crashkernel automatically and allowing
      users's to sepcify it.
      
      The old behaviour on ia64, which is still the current behaviour on
      most architectures is for the user to always specify the address.
      Recently ia64 was changed so that it is always automatically determined.
      
      With this patch the kernel automatically determines the offset if
      the supplied value is 0, otherwise it uses the value provided.
      
      This should probably be backed by a documentation change.
      Signed-Off-By: NSimon Horman <horms@verge.net.au>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      ad1c3ba7
    • H
      [IA64] CONFIG_KEXEC/CONFIG_CRASH_DUMP permutations · 45a98fc6
      Horms 提交于
      Actually, on reflection I think that there is a good case for
      keeping the options separate. I am thinking particularly of people
      who want a very small crashdump kernel and thus don't want to compile
      in kexec.
      
      The patch below should fix things up so that all valid combinations of
      KEXEC, CRASH_DUMP and VMCORE compile cleanly - VMCORE depends on
      CRASH_DUMP which is why I said valid combinations. In a nutshell
      it just untangles unrelated code and switches around a few defines.
      
      Please note that it creats a new file, arch/ia64/kernel/crash_dump.c
      This is in keeping with the i386 implementation.
      Signed-off-by: NSimon Horman <horms@verge.net.au>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      45a98fc6
    • J
      [IA64] Do not call SN_SAL_SET_CPU_NUMBER twice on cpu 0 · adf142e3
      Jay Lan 提交于
      This is an SN specific patch.
      
      Architectually, cpu_init is always called twice on cpu 0
      and thus resulted in two SN_SAL_SET_CPU_NUMBER calls.
      
      This was harmless in production kernel; however, it can
      cause problem on booting up a crashdump kernel at Altix.
      
      Here is the patch that detects the second sn_cpu_init
      call and skips the second call to SN_SAL_SET_CPU_NUMBER.
      Signed-Off-By: NJay Lan <jlan@sgi.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      adf142e3
  9. 09 12月, 2006 1 次提交
    • D
      [PATCH] LOG2: Implement a general integer log2 facility in the kernel · f0d1b0b3
      David Howells 提交于
      This facility provides three entry points:
      
      	ilog2()		Log base 2 of unsigned long
      	ilog2_u32()	Log base 2 of u32
      	ilog2_u64()	Log base 2 of u64
      
      These facilities can either be used inside functions on dynamic data:
      
      	int do_something(long q)
      	{
      		...;
      		y = ilog2(x)
      		...;
      	}
      
      Or can be used to statically initialise global variables with constant values:
      
      	unsigned n = ilog2(27);
      
      When performing static initialisation, the compiler will report "error:
      initializer element is not constant" if asked to take a log of zero or of
      something not reducible to a constant.  They treat negative numbers as
      unsigned.
      
      When not dealing with a constant, they fall back to using fls() which permits
      them to use arch-specific log calculation instructions - such as BSR on
      x86/x86_64 or SCAN on FRV - if available.
      
      [akpm@osdl.org: MMC fix]
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Wojtek Kaniewski <wojtekka@toxygen.net>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      f0d1b0b3