1. 23 3月, 2006 1 次提交
  2. 17 2月, 2006 1 次提交
  3. 15 2月, 2006 1 次提交
    • A
      [IA64] Count disabled cpus as potential hot-pluggable CPUs · a6b14fa6
      Ashok Raj 提交于
      Have a facility to account for potentially hot-pluggable CPUs. ACPI doesnt
      give a determinstic method to find hot-pluggable CPUs. Hence we use 2 methods
      to assist.
      
      - BIOS can mark potentially hot-pluggable CPUs as disabled in the MADT tables.
      - User can specify the number of hot-pluggable CPUs via parameter
        additional_cpus=X
      
      The option is enabled only if ACPI_CONFIG_HOTPLUG_CPU=y which enables the
      physical hotplug option. Without which user can still use logical onlining
      and offlining of CPUs by enabling CONFIG_HOTPLUG_CPU=y
      
      Adds more bits to cpu_possible_map for potentially hot-pluggable cpus.
      Signed-off-by: NAshok Raj <ashok.raj@intel.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      a6b14fa6
  4. 20 1月, 2006 1 次提交
  5. 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
  6. 28 12月, 2005 1 次提交
  7. 20 9月, 2005 1 次提交
  8. 17 9月, 2005 1 次提交
  9. 08 9月, 2005 1 次提交
  10. 25 8月, 2005 1 次提交
  11. 16 8月, 2005 1 次提交
  12. 05 8月, 2005 2 次提交
    • L
      [ACPI] Lindent all ACPI files · 4be44fcd
      Len Brown 提交于
      Signed-off-by: NLen Brown <len.brown@intel.com>
      4be44fcd
    • K
      [ACPI] acpi_register_gsi() can return error · 1f3a6a15
      Kenji Kaneshige 提交于
      Current acpi_register_gsi() function has no way to indicate errors to its
      callers even though acpi_register_gsi() can fail to register gsi because of
      some reasons (out of memory, lack of interrupt vectors, incorrect BIOS, and so
      on).  As a result, caller of acpi_register_gsi() cannot handle the case that
      acpi_register_gsi() fails.  I think failure of acpi_register_gsi() should be
      handled properly.
      
      This series of patches changes acpi_register_gsi() to return negative value on
      error, and also changes callers of acpi_register_gsi() to handle failure of
      acpi_register_gsi().
      
      This patch changes the type of return value of acpi_register_gsi() from
      "unsigned int" to "int" to indicate an error.  If acpi_register_gsi() fails to
      register gsi, it returns negative value.
      Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      1f3a6a15
  13. 12 7月, 2005 1 次提交
  14. 07 7月, 2005 1 次提交
    • T
      [IA64] fix generic/up builds · 8d7e3517
      Tony Luck 提交于
      Jesse Barnes provided the original version of this patch months ago, but
      other changes kept conflicting with it, so it got deferred.  Greg Edwards
      dug it out of obscurity just over a week ago, and almost immediately
      another conflicting patch appeared (Bob Picco's memory-less nodes).
      
      I've resolved the conflicts and got it running again.  CONFIG_SGI_TIOCX
      is set to "y" in defconfig, which causes a Tiger to not boot (oops in
      tiocx_init).  But that can be resolved later ... get this in now before it
      gets stale again.
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      8d7e3517
  15. 28 6月, 2005 2 次提交
  16. 04 5月, 2005 1 次提交
  17. 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