1. 26 6月, 2008 2 次提交
  2. 02 5月, 2008 1 次提交
  3. 04 4月, 2008 1 次提交
  4. 31 7月, 2007 1 次提交
  5. 26 7月, 2007 1 次提交
  6. 20 7月, 2007 1 次提交
  7. 12 5月, 2007 1 次提交
  8. 09 5月, 2007 1 次提交
  9. 10 2月, 2007 1 次提交
  10. 13 12月, 2006 1 次提交
    • 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
  11. 08 12月, 2006 1 次提交
    • Z
      [IA64] IA64 Kexec/kdump · a7956113
      Zou Nan hai 提交于
      Changes and updates.
      
      1. Remove fake rendz path and related code according to discuss with Khalid Aziz.
      2. fc.i offset fix in relocate_kernel.S.
      3. iospic shutdown code eoi and mask race fix from Fujitsu.
      4. Warm boot hook in machine_kexec to SN SAL code from Jack Steiner.
      5. Send slave to SAL slave loop patch from Jay Lan.
      6. Kdump on non-recoverable MCA event patch from Jay Lan
      7. Use CTL_UNNUMBERED in kdump_on_init sysctl.
      Signed-off-by: NZou Nan hai <nanhai.zou@intel.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      a7956113
  12. 01 11月, 2006 2 次提交
  13. 26 10月, 2005 1 次提交
  14. 29 6月, 2005 1 次提交
  15. 22 6月, 2005 1 次提交
  16. 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