1. 19 Jul, 2007 1 commit
  2. 12 Jul, 2007 2 commits
  3. 02 May, 2007 9 commits
    • Andi Kleen's avatar
      fac15a8e
    • Andi Kleen's avatar
      [PATCH] x86-64: Drop -traditional for arch/x86_64/boot · fa0a0091
      Andi Kleen authored
      
      
      Follows i386 and useful cleanup.
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      fa0a0091
    • Jeremy Fitzhardinge's avatar
      [PATCH] x86: deflate stack usage in lib/inflate.c · 35c74226
      Jeremy Fitzhardinge authored
      
      
      inflate_fixed and huft_build together use around 2.7k of stack.  When
      using 4k stacks, I saw stack overflows from interrupts arriving while
      unpacking the root initrd:
      
      do_IRQ: stack overflow: 384
       [<c0106b64>] show_trace_log_lvl+0x1a/0x30
       [<c01075e6>] show_trace+0x12/0x14
       [<c010763f>] dump_stack+0x16/0x18
       [<c0107ca4>] do_IRQ+0x6d/0xd9
       [<c010202b>] xen_evtchn_do_upcall+0x6e/0xa2
       [<c0106781>] xen_hypervisor_callback+0x25/0x2c
       [<c010116c>] xen_restore_fl+0x27/0x29
       [<c0330f63>] _spin_unlock_irqrestore+0x4a/0x50
       [<c0117aab>] change_page_attr+0x577/0x584
       [<c0117b45>] kernel_map_pages+0x8d/0xb4
       [<c016a314>] cache_alloc_refill+0x53f/0x632
       [<c016a6c2>] __kmalloc+0xc1/0x10d
       [<c0463d34>] malloc+0x10/0x12
       [<c04641c1>] huft_build+0x2a7/0x5fa
       [<c04645a5>] inflate_fixed+0x91/0x136
       [<c04657e2>] unpack_to_rootfs+0x5f2/0x8c1
       [<c0465acf>] populate_rootfs+0x1e/0xe4
      
      (This was under Xen, but there's no reason it couldn't happen on bare
        hardware.)
      
      This patch mallocs the local variables, thereby reducing the stack
      usage to sane levels.
      
      Also, up the heap size for the kernel decompressor to deal with the
      extra allocation.
      Signed-off-by: default avatarJeremy Fitzhardinge <jeremy@xensource.com>
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Cc: Tim Yamin <plasmaroo@gentoo.org>
      Cc: Andi Kleen <ak@suse.de>
      Cc: Matt Mackall <mpm@selenic.com>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: Ian Molton <spyro@f2s.com>
      35c74226
    • Jan Beulich's avatar
      [PATCH] x86-64: adjust EDID retrieval · dd4ecfc2
      Jan Beulich authored
      commit 5e518d76
      
       did the same change to
      i386's variant.
      
      With this change, i386's and x86-64's versions are identical, raising
      the question whether the x86-64 one should go (just like there's only
      one instance of edd.S).
      Signed-off-by: default avatarJan Beulich <jbeulich@novell.com>
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      dd4ecfc2
    • Bernhard Walle's avatar
      [PATCH] x86: add command line length to boot protocol · 8f9aeca7
      Bernhard Walle authored
      
      
      Because the command line is increased to 2048 characters after 2.6.21, it's
      not possible for boot loaders and userspace tools to determine the length
      of the command line the kernel can understand.  The benefit of knowing the
      length is that users can be warned if the command line size is too long
      which prevents surprise if things don't work after bootup.
      
      This patch updates the boot protocol to contain a field called
      "cmdline_size" that contain the length of the command line (excluding the
      terminating zero).
      
      The patch also adds missing fields (of protocol version 2.05) to the x86_64
      setup code.
      Signed-off-by: default avatarBernhard Walle <bwalle@suse.de>
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Cc: Alon Bar-Lev <alon.barlev@gmail.com>
      Acked-by: default avatarH. Peter Anvin <hpa@zytor.com>
      Cc: Andi Kleen <ak@suse.de>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      8f9aeca7
    • Vivek Goyal's avatar
      [PATCH] x86-64: Move cpu verification code to common file · a4831e08
      Vivek Goyal authored
      
      
      o This patch moves the code to verify long mode and SSE to a common file.
        This code is now shared by trampoline.S, wakeup.S, boot/setup.S and
        boot/compressed/head.S
      
      o So far we used to do very limited check in trampoline.S, wakeup.S and
        in 32bit entry point. Now all the entry paths are forced to do the
        exhaustive check, including SSE because verify_cpu is shared.
      
      o I am keeping this patch as last in the x86 relocatable series because
        previous patches have got quite some amount of testing done and don't want
        to distrub that. So that if there is problem introduced by this patch, at
        least it can be easily isolated.
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: default avatarVivek Goyal <vgoyal@in.ibm.com>
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      a4831e08
    • Vivek Goyal's avatar
      [PATCH] x86-64: Extend bzImage protocol for relocatable bzImage · 8035d3ea
      Vivek Goyal authored
      
      
      o Extend the bzImage protocol (same as i386) to allow bzImage loaders to
        load the protected mode kernel at non-1MB address. Now protected mode
        component is relocatable and can be loaded at non-1MB addresses.
      
      o As of today kdump uses it to run a second kernel from a reserved memory
        area.
      Signed-off-by: default avatarVivek Goyal <vgoyal@in.ibm.com>
      Signed-off-by: default avatarVivek Goyal <vgoyal@in.ibm.com>
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      8035d3ea
    • Vivek Goyal's avatar
      [PATCH] x86-64: build-time checking · 6a50a664
      Vivek Goyal authored
      
      
      o X86_64 kernel should run from 2MB aligned address for two reasons.
      	- Performance.
      	- For relocatable kernels, page tables are updated based on difference
      	  between compile time address and load time physical address.
      	  This difference should be multiple of 2MB as kernel text and data
      	  is mapped using 2MB pages and PMD should be pointing to a 2MB
      	  aligned address. Life is simpler if both compile time and load time
      	  kernel addresses are 2MB aligned.
      
      o Flag the error at compile time if one is trying to build a kernel which
        does not meet alignment restrictions.
      Signed-off-by: default avatarVivek Goyal <vgoyal@in.ibm.com>
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Andi Kleen <ak@suse.de>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      6a50a664
    • Vivek Goyal's avatar
      [PATCH] x86-64: Relocatable Kernel Support · 1ab60e0f
      Vivek Goyal authored
      
      
      This patch modifies the x86_64 kernel so that it can be loaded and run
      at any 2M aligned address, below 512G.  The technique used is to
      compile the decompressor with -fPIC and modify it so the decompressor
      is fully relocatable.  For the main kernel the page tables are
      modified so the kernel remains at the same virtual address.  In
      addition a variable phys_base is kept that holds the physical address
      the kernel is loaded at.  __pa_symbol is modified to add that when
      we take the address of a kernel symbol.
      
      When loaded with a normal bootloader the decompressor will decompress
      the kernel to 2M and it will run there.  This both ensures the
      relocation code is always working, and makes it easier to use 2M
      pages for the kernel and the cpu.
      
      AK: changed to not make RELOCATABLE default in Kconfig
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: default avatarVivek Goyal <vgoyal@in.ibm.com>
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      1ab60e0f
  4. 02 Apr, 2007 1 commit
  5. 14 Nov, 2006 1 commit
    • Steven Rostedt's avatar
      [PATCH] x86-64: shorten the x86_64 boot setup GDT to what the comment says · 51d67a48
      Steven Rostedt authored
      
      
      Stephen Tweedie, Herbert Xu, and myself have been struggling with a very
      nasty bug in Xen.  But it also pointed out a small bug in the x86_64
      kernel boot setup.
      
      The GDT limit being setup by the initial bzImage code when entering into
      protected mode is way too big.  The comment by the code states that the
      size of the GDT is 2048, but the actual size being set up is much bigger
      (32768). This happens simply because of one extra '0'.
      
      Instead of setting up a 0x800 size, 0x8000 is set up.  On bare metal this
      is fine because the CPU wont load any segments unless  they are
      explicitly used.  But unfortunately, this breaks Xen on vmx FV, since it
      (for now) blindly loads all the segments into the VMCS if they are less
      than the gdt limit. Since the real mode segments are around 0x3000, we are
      getting junk into the VMCS and that later causes an exception.
      
      Stephen Tweedie has written up a patch to fix the Xen side and will be
      submitting that to those folks. But that doesn't excuse the GDT limit
      being a magnitude too big.
      
      AK: changed to compute true gdt size in assembler, fixed comment
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      51d67a48
  6. 04 Oct, 2006 1 commit
  7. 26 Sep, 2006 2 commits
    • Paolo 'Blaisorblade' Giarrusso's avatar
      [PATCH] Fix boot code head.S warning · b3698c03
      Paolo 'Blaisorblade' Giarrusso authored
      
      
      When compiling a 64-bit kernel on an Ubuntu 6.06 32bit system (whose GCC is also
      a cross-compiler for x86_64) I've seen that head.o is compiled as a 64-bit file
      (while it should not) and ld complaining about this during linking:
      [AK: it happens on all systems with new binutils]
      
      ld: warning: i386:x86-64 architecture of input file
      `arch/x86_64/boot/compressed/head.o' is incompatible with i386 output
      
      I've verified that removing -m64 from compilation flags to turn
      "-m64 -traditional -m32" into "-traditional -m32" fixes the issue.
      Signed-off-by: default avatarPaolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      b3698c03
    • Diego Calleja's avatar
      [PATCH] x86: AUX_DEVICE_INFO is one byte long, use 'movb' · 606bd58d
      Diego Calleja authored
      
      
      Bugzilla #6552 says:
      
      "In arch/i386/boot/setup.S, movw is used instead of movb for PS/2 mouse
      information, although it is unsigned char. This does not harm, because
      the jmp instruction overwritten by movw is used before executing movw,
      and never be used again"
      
      I've no idea if this is a real bug or how it gets fixed, so I'm submitting
      it for review instead of letting it die of boredom in bugzilla. Aditionally
      to i386, I've changed x86-64, which mirrors the same code.
      
      Credits to Yoshinori K. Okuji, who found the problem and suggested a fix.
      Signed-off-by: default avatarDiego Calleja <diegocg@gmail.com>
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      606bd58d
  8. 03 Jul, 2006 1 commit
    • Sam Ravnborg's avatar
      kbuild: introduce utsrelease.h · 63104eec
      Sam Ravnborg authored
      
      
      include/linux/version.h contained both actual KERNEL version
      and UTS_RELEASE that contains a subset from git SHA1 for when
      kernel was compiled as part of a git repository.
      This had the unfortunate side-effect that all files including version.h
      would be recompiled when some git changes was made due to changes SHA1.
      Split it out so we keep independent parts in separate files.
      
      Also update checkversion.pl script to no longer check for UTS_RELEASE.
      Signed-off-by: default avatarSam Ravnborg <sam@ravnborg.org>
      63104eec
  9. 30 Jun, 2006 1 commit
  10. 26 Jun, 2006 4 commits
  11. 11 Apr, 2006 1 commit
  12. 26 Mar, 2006 1 commit
  13. 09 Jan, 2006 1 commit
  14. 08 Jan, 2006 1 commit
  15. 01 Jan, 2006 1 commit
  16. 12 Sep, 2005 2 commits
  17. 07 Sep, 2005 1 commit
  18. 25 Jun, 2005 3 commits
    • Domen Puncer's avatar
      [PATCH] x86_64: coding style and whitespace fixups · f4549448
      Domen Puncer authored
      
      
      Remove some of the unnecessary differences between arch/i386 and
      arch/x86_64.  This patch fixes more whitespace issues, some miscellaneous
      typos, a wrong URL and a factually incorrect statement about the current
      boot sector code.
      Signed-off-by: default avatarDomen Puncer <domen@coderock.org>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      f4549448
    • randy_dunlap's avatar
      [PATCH] x86-64: add memcpy/memset prototypes · 09dbb476
      randy_dunlap authored
      
      
      Put function prototypes for memset() and memcpy() ahead of where
      there are used, to kill sparse warnings:
      
      arch/x86_64/boot/compressed/../../../../lib/inflate.c:317:3: warning: undefined identifier 'memset'
      arch/x86_64/boot/compressed/../../../../lib/inflate.c:601:11: warning: undefined identifier 'memcpy'
      arch/x86_64/boot/compressed/misc.c:151:2: warning: undefined identifier 'memcpy'
      arch/x86_64/boot/compressed/../../../../lib/inflate.c:317:3: warning: call with no type!
      arch/x86_64/boot/compressed/../../../../lib/inflate.c:601:17: warning: call with no type!
      arch/x86_64/boot/compressed/misc.c:151:9: warning: call with no type!
      Signed-off-by: default avatarrandy_dunlap <rdunlap@xenotime.net>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      09dbb476
    • Eric W. Biederman's avatar
      [PATCH] kexec: x86_64: add CONFIG_PHYSICAL_START · d0537508
      Eric W. Biederman authored
      
      
      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_64 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: default avatarEric Biederman <ebiederm@xmission.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      d0537508
  19. 23 Jun, 2005 1 commit
    • Ian Campbell's avatar
      [PATCH] use ${CROSS_COMPILE}installkernel in arch/*/boot/install.sh · 0f8e2d62
      Ian Campbell authored
      
      
      The attached patch causes the various arch specific install.sh scripts to
      look for ${CROSS_COMPILE}installkernel rather than just installkernel (in
      both /sbin/ and ~/bin/ where the script already did this).  This allows you
      to have e.g.  arm-linux-installkernel as a handy way to install on your
      cross target.  It also prevents the script picking up on the host
      /sbin/installkernel which causes the script to fall through and do the
      install itself (which is what I actually use myself, with $INSTALL_PATH
      set).
      
      I don't believe it causes back-compatibility problems since calling the
      host installkernel was never likely to work or be what you wanted when
      cross compiling anyway.  If $CROSS_COMPILE isn't set then nothing changes.
      
      I only use ARM and i386 myself but I figured it couldn't hurt to do the
      whole lot.  I've cc'd those who I hope are the arch maintainers for files
      that I've touched.
      Signed-off-by: default avatarIan Campbell <icampbell@arcom.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      0f8e2d62
  20. 05 May, 2005 1 commit
  21. 01 May, 2005 1 commit
    • Venkatesh Pallipadi's avatar
      [PATCH] Increase number of e820 entries hard limit from 32 to 128 · f9ba7053
      Venkatesh Pallipadi authored
      
      
      The specifications that talk about E820 map doesn't have an upper limit on
      the number of e820 entries.  But, today's kernel has a hard limit of 32.
      With increase in memory size, we are seeing the number of E820 entries
      reaching close to 32.  Patch below bumps the number upto 128.
      
      The patch changes the location of EDDBUF in zero-page (as it comes after E820).
      As, EDDBUF is not used by boot loaders, this patch should not have any effect
      on bootloader-setup code interface.
      
      Patch covers both i386 and x86-64.
      
      Tested on:
      * grub booting bzImage
      * lilo booting bzImage with EDID info enabled
      * pxeboot of bzImage
      
      Side-effect:
      bss increases by ~ 2K and init.data increases by ~7.5K
      on all systems, due to increase in size of static arrays.
      Signed-off-by: default avatarVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      f9ba7053
  22. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      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