1. 05 9月, 2005 2 次提交
  2. 30 8月, 2005 5 次提交
  3. 20 8月, 2005 1 次提交
  4. 28 7月, 2005 1 次提交
  5. 27 7月, 2005 1 次提交
    • E
      [PATCH] Add emergency_restart() · 7c903473
      Eric W. Biederman 提交于
      When the kernel is working well and we want to restart cleanly
      kernel_restart is the function to use.   But in many instances
      the kernel wants to reboot when thing are expected to be working
      very badly such as from panic or a software watchdog handler.
      
      This patch adds the function emergency_restart() so that
      callers can be clear what semantics they expect when calling
      restart.  emergency_restart() is expected to be callable
      from interrupt context and possibly reliable in even more
      trying circumstances.
      
      This is an initial generic implementation for all architectures.
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      7c903473
  6. 25 7月, 2005 5 次提交
  7. 12 7月, 2005 2 次提交
  8. 11 7月, 2005 3 次提交
  9. 09 7月, 2005 1 次提交
  10. 07 7月, 2005 1 次提交
  11. 05 7月, 2005 2 次提交
    • D
      [SPARC64]: Do proper DMA IRQ syncing on Tomatillo · bb6743f4
      David S. Miller 提交于
      This was the main impetus behind adding the PCI IRQ shim.
      
      In order to properly order DMA writes wrt. interrupts, you have to
      write to a PCI controller register, then poll for that bit clearing.
      There is one bit for each interrupt source, and setting this register
      bit tells Tomatillo to drain all pending DMA from that device.
      
      Furthermore, Tomatillo's with revision less than 4 require us to do a
      block store due to some memory transaction ordering issues it has on
      JBUS.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bb6743f4
    • D
      [SPARC64]: Add support for IRQ pre-handlers. · 088dd1f8
      David S. Miller 提交于
      This allows a PCI controller to shim into IRQ delivery
      so that DMA queues can be drained, if necessary.
      
      If some bus specific code needs to run before an IRQ
      handler is invoked, the bus driver simply needs to setup
      the function pointer in bucket->irq_info->pre_handler and
      the two args bucket->irq_info->pre_handler_arg[12].
      
      The Schizo PCI driver is converted over to use a pre-handler
      for the DMA write-sync processing it needs when a device
      is behind a PCI->PCI bus deeper than the top-level APB
      bridges.
      
      While we're here, clean up all of the action allocation
      and handling.  Now, we allocate the irqaction as part of
      the bucket->irq_info area.  There is an array of 4 irqaction
      (for PCI irq sharing) and a bitmask saying which entries
      are active.
      
      The bucket->irq_info is allocated at build_irq() time, not
      at request_irq() time.  This simplifies request_irq() and
      free_irq() tremendously.
      
      The SMP dynamic IRQ retargetting code got removed in this
      change too.  It was disabled for a few months now, and we
      can resurrect it in the future if we want.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      088dd1f8
  12. 28 6月, 2005 4 次提交
    • A
      [PATCH] PCI: fix up errors after dma bursting patch and CONFIG_PCI=n · bb4a61b6
      Andrew Morton 提交于
      With CONFIG_PCI=n:
      
      In file included from include/linux/pci.h:917,
                       from lib/iomap.c:6:
      include/asm/pci.h:104: warning: `enum pci_dma_burst_strategy' declared inside parameter list
      include/asm/pci.h:104: warning: its scope is only this definition or declaration, which is probably not what you want.
      include/asm/pci.h: In function `pci_dma_burst_advice':
      include/asm/pci.h:106: dereferencing pointer to incomplete type
      include/asm/pci.h:106: `PCI_DMA_BURST_INFINITY' undeclared (first use in this function)
      include/asm/pci.h:106: (Each undeclared identifier is reported only once
      include/asm/pci.h:106: for each function it appears in.)
      make[1]: *** [lib/iomap.o] Error 1
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      bb4a61b6
    • D
      [PATCH] PCI: DMA bursting advice · e24c2d96
      David S. Miller 提交于
      After seeing, at best, "guesses" as to the following kind
      of information in several drivers, I decided that we really
      need a way for platforms to specifically give advice in this
      area for what works best with their PCI controller implementation.
      
      Basically, this new interface gives DMA bursting advice on
      PCI.  There are three forms of the advice:
      
      1) Burst as much as possible, it is not necessary to end bursts
         on some particular boundary for best performance.
      
      2) Burst on some byte count multiple.  A DMA burst to some multiple of
         number of bytes may be done, but it is important to end the burst
         on an exact multiple for best performance.
      
         The best example of this I am aware of are the PPC64 PCI
         controllers, where if you end a burst mid-cacheline then
         chip has to refetch the data and the IOMMU translations
         which hurts performance a lot.
      
      3) Burst on a single byte count multiple.  Bursts shall end
         exactly on the next multiple boundary for best performance.
      
         Sparc64 and Alpha's PCI controllers operate this way.  They
         disconnect any device which tries to burst across a cacheline
         boundary.
      
         Actually, newer sparc64 PCI controllers do not have this behavior.
         That is why the "pdev" is passed into the interface, so I can
         add code later to check which PCI controller the system is using
         and give advice accordingly.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      e24c2d96
    • D
      [SPARC64]: Get rid of fast IRQ feature. · 63b61452
      David S. Miller 提交于
      The only real user was the assembler floppy interrupt
      handler, which does not need to be in assembly.
      
      This makes it so that there are less pieces of code which
      know about the internal layout of ivector_table[] and
      friends.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      63b61452
    • D
      [SPARC64]: Avoid membar instructions in delay slots. · b445e26c
      David S. Miller 提交于
      In particular, avoid membar instructions in the delay
      slot of a jmpl instruction.
      
      UltraSPARC-I, II, IIi, and IIe have a bug, documented in
      the UltraSPARC-IIi User's Manual, Appendix K, Erratum 51
      
      The long and short of it is that if the IMU unit misses
      on a branch or jmpl, and there is a store buffer synchronizing
      membar in the delay slot, the chip can stop fetching instructions.
      
      If interrupts are enabled or some other trap is enabled, the
      chip will unwedge itself, but performance will suffer.
      
      We already had a workaround for this bug in a few spots, but
      it's better to have the entire tree sanitized for this rule.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b445e26c
  13. 26 6月, 2005 2 次提交
    • N
      [PATCH] sched: cleanup context switch locking · 4866cde0
      Nick Piggin 提交于
      Instead of requiring architecture code to interact with the scheduler's
      locking implementation, provide a couple of defines that can be used by the
      architecture to request runqueue unlocked context switches, and ask for
      interrupts to be enabled over the context switch.
      
      Also replaces the "switch_lock" used by these architectures with an oncpu
      flag (note, not a potentially slow bitflag).  This eliminates one bus
      locked memory operation when context switching, and simplifies the
      task_running function.
      Signed-off-by: NNick Piggin <nickpiggin@yahoo.com.au>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      4866cde0
    • P
      [PATCH] RCU: clean up a few remaining synchronize_kernel() calls · b2b18660
      Paul E. McKenney 提交于
      2.6.12-rc6-mm1 has a few remaining synchronize_kernel()s, some (but not
      all) in comments.  This patch changes these synchronize_kernel() calls (and
      comments) to synchronize_rcu() or synchronize_sched() as follows:
      
      - arch/x86_64/kernel/mce.c mce_read(): change to synchronize_sched() to
        handle races with machine-check exceptions (synchronize_rcu() would not cut
        it given RCU implementations intended for hardcore realtime use.
      
      - drivers/input/serio/i8042.c i8042_stop(): change to synchronize_sched() to
        handle races with i8042_interrupt() interrupt handler.  Again,
        synchronize_rcu() would not cut it given RCU implementations intended for
        hardcore realtime use.
      
      - include/*/kdebug.h comments: change to synchronize_sched() to handle races
        with NMIs.  As before, synchronize_rcu() would not cut it...
      
      - include/linux/list.h comment: change to synchronize_rcu(), since this
        comment is for list_del_rcu().
      
      - security/keys/key.c unregister_key_type(): change to synchronize_rcu(),
        since this is interacting with RCU read side.
      
      - security/keys/process_keys.c install_session_keyring(): change to
        synchronize_rcu(), since this is interacting with RCU read side.
      Signed-off-by: N"Paul E. McKenney" <paulmck@us.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      b2b18660
  14. 25 6月, 2005 1 次提交
  15. 24 6月, 2005 2 次提交
  16. 22 6月, 2005 3 次提交
    • D
      [PATCH] Hugepage consolidation · 63551ae0
      David Gibson 提交于
      A lot of the code in arch/*/mm/hugetlbpage.c is quite similar.  This patch
      attempts to consolidate a lot of the code across the arch's, putting the
      combined version in mm/hugetlb.c.  There are a couple of uglyish hacks in
      order to covert all the hugepage archs, but the result is a very large
      reduction in the total amount of code.  It also means things like hugepage
      lazy allocation could be implemented in one place, instead of six.
      
      Tested, at least a little, on ppc64, i386 and x86_64.
      
      Notes:
      	- this patch changes the meaning of set_huge_pte() to be more
      	  analagous to set_pte()
      	- does SH4 need s special huge_ptep_get_and_clear()??
      Acked-by: NWilliam Lee Irwin <wli@holomorphy.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      63551ae0
    • I
      [PATCH] smp_processor_id() cleanup · 39c715b7
      Ingo Molnar 提交于
      This patch implements a number of smp_processor_id() cleanup ideas that
      Arjan van de Ven and I came up with.
      
      The previous __smp_processor_id/_smp_processor_id/smp_processor_id API
      spaghetti was hard to follow both on the implementational and on the
      usage side.
      
      Some of the complexity arose from picking wrong names, some of the
      complexity comes from the fact that not all architectures defined
      __smp_processor_id.
      
      In the new code, there are two externally visible symbols:
      
       - smp_processor_id(): debug variant.
      
       - raw_smp_processor_id(): nondebug variant. Replaces all existing
         uses of _smp_processor_id() and __smp_processor_id(). Defined
         by every SMP architecture in include/asm-*/smp.h.
      
      There is one new internal symbol, dependent on DEBUG_PREEMPT:
      
       - debug_smp_processor_id(): internal debug variant, mapped to
                                   smp_processor_id().
      
      Also, i moved debug_smp_processor_id() from lib/kernel_lock.c into a new
      lib/smp_processor_id.c file.  All related comments got updated and/or
      clarified.
      
      I have build/boot tested the following 8 .config combinations on x86:
      
       {SMP,UP} x {PREEMPT,!PREEMPT} x {DEBUG_PREEMPT,!DEBUG_PREEMPT}
      
      I have also build/boot tested x64 on UP/PREEMPT/DEBUG_PREEMPT.  (Other
      architectures are untested, but should work just fine.)
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NArjan van de Ven <arjan@infradead.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      39c715b7
    • D
      [SPARC64]: Add prefetch support. · 7049e680
      David S. Miller 提交于
      The implementation is optimal for UltraSPARC-III and later.
      It will work, however suboptimally, on UltraSPARC-II and
      be treated as a NOP on UltraSPARC-I.
      
      It is not worth code patching this thing as the highest cost
      is the code space, and code patching cannot eliminate that.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7049e680
  17. 08 6月, 2005 1 次提交
    • K
      [PATCH] AGP fix for Xen VMM · 07eee78e
      Keir Fraser 提交于
      When Linux is running on the Xen virtual machine monitor, physical
      addresses are virtualised and cannot be directly referenced by the AGP
      GART.  This patch fixes the GART driver for Xen by adding a layer of
      abstraction between physical addresses and 'GART addresses'.
      
      Architecture-specific functions are also defined for allocating and freeing
      the GATT.  Xen requires this to ensure that table really is contiguous from
      the point of view of the GART.
      
      These extra interface functions are defined as 'no-ops' for all existing
      architectures that use the GART driver.
      Signed-off-by: NKeir Fraser <keir@xensource.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NDave Jones <davej@redhat.com>
      07eee78e
  18. 01 6月, 2005 1 次提交
  19. 24 5月, 2005 1 次提交
    • D
      [SPARC64]: Add boot option to force UltraSPARC-III P-Cache on. · 816242da
      David S. Miller 提交于
      Older UltraSPARC-III chips have a P-Cache bug that makes us disable it
      by default at boot time.
      
      However, this does hurt performance substantially, particularly with
      memcpy(), and the bug is _incredibly_ obscure.  I have never seen it
      triggered in practice, ever.
      
      So provide a "-P" boot option that forces the P-Cache on.  It taints
      the kernel, so if it does trigger and cause some data corruption or
      OOPS, we will find out in the logs that this option was on when it
      happened.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      816242da
  20. 06 5月, 2005 1 次提交