1. 26 6月, 2005 2 次提交
    • E
      [PATCH] kexec: x86: add CONFIG_PYSICAL_START · 3d345e3f
      Eric W. Biederman 提交于
      For one kernel to report a crash another kernel has created we need
      to have 2 kernels loaded simultaneously in memory.  To accomplish this
      the two kernels need to built to run at different physical addresses.
      
      This patch adds the CONFIG_PHYSICAL_START option to the x86 kernel
      so we can do just that.  You need to know what you are doing and
      the ramifications are before changing this value, and most users
      won't care so I have made it depend on CONFIG_EMBEDDED
      
      bzImage kernels will work and run at a different address when compiled
      with this option but they will still load at 1MB.  If you need a kernel
      loaded at a different address as well you need to boot a vmlinux.
      Signed-off-by: NEric Biederman <ebiederm@xmission.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      3d345e3f
    • E
      [PATCH] kexec: x86: vmlinux: fix physical addresses · ad0d75eb
      Eric W. Biederman 提交于
      The vmlinux on i386 does not report the correct physical address of
      the kernel.  Instead in the physical address field it currently
      reports the virtual address of the kernel.
      
      This is patch is a bug fix that corrects vmlinux to report the
      proper physical addresses.
      
      This is potentially a help for crash dump analysis tools.
      
      This definitiely allows bootloaders that load vmlinux as a standard
      ELF executable.  Bootloaders directly loading vmlinux become of
      practical importance when we consider the kexec on panic case.
      Signed-off-by: NEric Biederman <ebiederm@xmission.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      ad0d75eb
  2. 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