1. 15 8月, 2008 1 次提交
  2. 03 8月, 2008 1 次提交
  3. 30 5月, 2008 1 次提交
  4. 01 3月, 2008 1 次提交
  5. 04 2月, 2008 1 次提交
    • R
      [ARM] 4736/1: Export atags to userspace and allow kexec to use customised atags · 4cd9d6f7
      Richard Purdie 提交于
      Currently, the atags used by kexec are fixed to the ones originally used
      to boot the kernel. This is less than ideal as changing the commandline,
      initrd and other options would be a useful feature.
      
      This patch exports the atags used for the current kernel to userspace
      through an "atags" file in procfs. The presence of the file is
      controlled by its own Kconfig option and cleans up several ifdef blocks
      into a separate file. The tags for the new kernel are assumed to be at
      a fixed location before the kernel image itself. The location of the
      tags used to boot the original kernel is unimportant and no longer
      saved.
      
      Based on a patch from Uli Luckas <u.luckas@road.de>
      Signed-off-by: NRichard Purdie <rpurdie@rpsys.net>
      Acked-by: NUli Luckas <u.luckas@road.de>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      4cd9d6f7
  6. 13 10月, 2007 1 次提交
    • M
      [ARM] 4599/1: Preserve ATAG list for use with kexec (2.6.23) · 033b8ffe
      Mike Westerhof 提交于
      This patch resolves a kexec boot failure that can occur because
      no ATAGs are passed in to the kexec'd kernel. Currently the
      newly-kexec'd kernel may fail if it requires specific ATAGs, or
      it may fail because the fixed memory location at which it expects
      to find the ATAGs may contain random data instead of ATAGs.
      
      The patch ensures that any ATAGs passed to the current kernel
      at boot time are copied to a static buffer, and are copied back
      when kexec copies the new kernel into place. Thus the new
      kernel sees the same ATAGs from kexec and the boot loader.
      
      The boot parameters are copied without regard to type, content,
      or length -- this patch's scope is limited soley to saving and
      restoring a fixed-size block of memory containing the kernel's
      boot parameters. Additional functionality to examine, alter, or
      replace the ATAGs (using kexec, for example) can be implemented
      by manipulating the static buffer containing the preserved ATAGs.
      
      Note: the size of the buffer (1.5KB) is selected to comfortably
      hold one of each ATAG type, including a maximum-length command
      line and the maximum number of ATAG_MEM structures currently
      supported by the kernel. Should an ATAG list exceed that limit,
      the list will be silently truncated to that limit (to do other-
      wise at that point in the boot process would make a simple
      problem exceedingly complicated).
      
      [Note: this is the same patch as 4579, modified to accomodate
      the ATAG changes introduced in 2.6.23]
      
      Signed-off-by: Mike Westerhof <mwester at dls.net>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      033b8ffe
  7. 09 5月, 2007 1 次提交
    • S
      kdump/kexec: calculate note size at compile time · 6672f76a
      Simon Horman 提交于
      Currently the size of the per-cpu region reserved to save crash notes is
      set by the per-architecture value MAX_NOTE_BYTES.  Which in turn is
      currently set to 1024 on all supported architectures.
      
      While testing ia64 I recently discovered that this value is in fact too
      small.  The particular setup I was using actually needs 1172 bytes.  This
      lead to very tedious failure mode where the tail of one elf note would
      overwrite the head of another if they ended up being alocated sequentially
      by kmalloc, which was often the case.
      
      It seems to me that a far better approach is to caclculate the size that
      the area needs to be.  This patch does just that.
      
      If a simpler stop-gap patch for ia64 to be squeezed into 2.6.21(.X) is
      needed then this should be as easy as making MAX_NOTE_BYTES larger in
      arch/asm-ia64/kexec.h.  Perhaps 2048 would be a good choice.  However, I
      think that the approach in this patch is a much more robust idea.
      Acked-by: NVivek Goyal <vgoyal@in.ibm.com>
      Signed-off-by: NSimon Horman <horms@verge.net.au>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      6672f76a
  8. 16 2月, 2007 1 次提交
    • R
      [ARM] 4137/1: Add kexec support · c587e4a6
      Richard Purdie 提交于
      Add kexec support to ARM.
      
      Improvements like commandline handling could be made but this patch gives
      basic functional support. It uses the next available syscall number, 347.
      
      Once the syscall number is known, userspace support will be
      finalised/submitted to kexec-tools, various patches already exist.
      
      Originally based on a patch by Maxim Syrchin but updated and forward
      ported by various people.
      Signed-off-by: NRichard Purdie <rpurdie@rpsys.net>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      c587e4a6
  9. 27 9月, 2006 2 次提交
  10. 17 1月, 2006 1 次提交