1. 14 8月, 2007 1 次提交
  2. 18 7月, 2007 3 次提交
  3. 09 5月, 2007 1 次提交
  4. 30 6月, 2006 1 次提交
  5. 22 6月, 2006 1 次提交
  6. 08 9月, 2005 1 次提交
    • A
      [PATCH] x86/x86_64: deferred handling of writes to /proc/irqxx/smp_affinity · 54d5d424
      Ashok Raj 提交于
      When handling writes to /proc/irq, current code is re-programming rte
      entries directly. This is not recommended and could potentially cause
      chipset's to lockup, or cause missing interrupts.
      
      CONFIG_IRQ_BALANCE does this correctly, where it re-programs only when the
      interrupt is pending. The same needs to be done for /proc/irq handling as well.
      Otherwise user space irq balancers are really not doing the right thing.
      
      - Changed pending_irq_balance_cpumask to pending_irq_migrate_cpumask for
        lack of a generic name.
      - added move_irq out of IRQ_BALANCE, and added this same to X86_64
      - Added new proc handler for write, so we can do deferred write at irq
        handling time.
      - Display of /proc/irq/XX/smp_affinity used to display CPU_MASKALL, instead
        it now shows only active cpu masks, or exactly what was set.
      - Provided a common move_irq implementation, instead of duplicating
        when using generic irq framework.
      
      Tested on i386/x86_64 and ia64 with CONFIG_PCI_MSI turned on and off.
      Tested UP builds as well.
      
      MSI testing: tbd: I have cards, need to look for a x-over cable, although I
      did test an earlier version of this patch.  Will test in a couple days.
      Signed-off-by: NAshok Raj <ashok.raj@intel.com>
      Acked-by: NZwane Mwaikambo <zwane@holomorphy.com>
      Grudgingly-acked-by: NAndi Kleen <ak@muc.de>
      Signed-off-by: NCoywolf Qi Hunt <coywolf@lovecn.org>
      Signed-off-by: NAshok Raj <ashok.raj@intel.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      54d5d424
  7. 12 7月, 2005 1 次提交
    • K
      [IA64] assign_irq_vector() should not panic · 3b5cc090
      Kenji Kaneshige 提交于
      Current assign_irq_vector() will panic if interrupt vectors is running
      out. But I think how to handle the case of lack of interrupt vectors
      should be handled by the caller of this function. For example, some
      PCI devices can raise the interrupt signal via both MSI and I/O
      APIC. So even if the driver for these device fails to allocate a
      vector for MSI, the driver still has a chance to use I/O APIC based
      interrupt. But currently there is no chance for these driver to use
      I/O APIC based interrupt because kernel will panic when
      assign_irq_vector() fails to allocate interrupt vector.
      
      The following patch changes assign_irq_vector() for ia64 to return
      -ENOSPC on error instead of panic (as i386 and x86_64 versions do).
      Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      3b5cc090
  8. 26 4月, 2005 1 次提交
    • K
      [IA64] vector sharing (Large I/O system support) · 24eeb568
      Kenji Kaneshige 提交于
      Current ia64 linux cannot handle greater than 184 interrupt sources
      because of the lack of vectors. The following patch enables ia64 linux
      to handle greater than 184 interrupt sources by allowing the same
      vector number to be shared by multiple IOSAPIC's RTEs. The design of
      this patch is besed on "Intel(R) Itanium(R) Processor Family Interrupt
      Architecture Guide".
      
      Even if you don't have a large I/O system, you can see the behavior of
      vector sharing by changing IOSAPIC_LAST_DEVICE_VECTOR to fewer value.
      Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      24eeb568
  9. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4