1. 29 3月, 2006 1 次提交
  2. 20 1月, 2006 1 次提交
  3. 06 1月, 2006 1 次提交
    • A
      [IA64] support for cpu0 removal · ff741906
      Ashok Raj 提交于
      here is the BSP removal support for IA64. Its pretty much the same thing that
      was released a while back, but has your feedback incorporated.
      
      - Removed CONFIG_BSP_REMOVE_WORKAROUND and associated cmdline param
      - Fixed compile issue with sn2/zx1 due to a undefined fix_b0_for_bsp
      - some formatting nits (whitespace etc)
      
      This has been tested on tiger and long back by alex on hp systems as well.
      Signed-off-by: NAshok Raj <ashok.raj@intel.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      ff741906
  4. 08 9月, 2005 1 次提交
  5. 16 8月, 2005 1 次提交
  6. 05 8月, 2005 1 次提交
  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. 28 6月, 2005 1 次提交
  9. 26 4月, 2005 2 次提交
  10. 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