Skip to content
Snippets Groups Projects
  1. Sep 20, 2009
    • Sam Ravnborg's avatar
      kbuild: use INSTALLKERNEL to select customized installkernel script · caa27b66
      Sam Ravnborg authored
      
      Replace the use of CROSS_COMPILE to select a customized
      installkernel script with the possibility to set INSTALLKERNEL
      to select a custom installkernel script when running make:
      
          make INSTALLKERNEL=arm-installkernel install
      
      With this patch we are now more consistent across
      different architectures - they did not all support use
      of CROSS_COMPILE.
      
      The use of CROSS_COMPILE was a hack as this really belongs
      to gcc/binutils and the installkernel script does not change
      just because we change toolchain.
      
      The use of CROSS_COMPILE caused troubles with an upcoming patch
      that saves CROSS_COMPILE when a kernel is built - it would no
      longer be installable.
      [Thanks to Peter Z. for this hint]
      
      This patch undos what Ian did in commit:
      
        0f8e2d62
        ("use ${CROSS_COMPILE}installkernel in arch/*/boot/install.sh")
      
      The patch has been lightly tested on x86 only - but all changes
      looks obvious.
      
      Acked-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Acked-by: Mike Frysinger <vapier@gentoo.org> [blackfin]
      Acked-by: Russell King <linux@arm.linux.org.uk> [arm]
      Acked-by: Paul Mundt <lethal@linux-sh.org> [sh]
      Acked-by: "H. Peter Anvin" <hpa@zytor.com> [x86]
      Cc: Ian Campbell <icampbell@arcom.com>
      Cc: Tony Luck <tony.luck@intel.com> [ia64]
      Cc: Fenghua Yu <fenghua.yu@intel.com> [ia64]
      Cc: Hirokazu Takata <takata@linux-m32r.org> [m32r]
      Cc: Geert Uytterhoeven <geert@linux-m68k.org> [m68k]
      Cc: Kyle McMartin <kyle@mcmartin.ca> [parisc]
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> [powerpc]
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> [s390]
      Cc: Thomas Gleixner <tglx@linutronix.de> [x86]
      Cc: Ingo Molnar <mingo@redhat.com> [x86]
      Signed-off-by: default avatarSam Ravnborg <sam@ravnborg.org>
      caa27b66
  2. Aug 20, 2009
  3. Jul 04, 2009
  4. Jun 26, 2009
  5. Jun 18, 2009
    • Peter Oberparleiter's avatar
      gcov: enable GCOV_PROFILE_ALL for x86_64 · 7bf99fb6
      Peter Oberparleiter authored
      
      Enable gcov profiling of the entire kernel on x86_64. Required changes
      include disabling profiling for:
      
      * arch/kernel/acpi/realmode and arch/kernel/boot/compressed:
        not linked to main kernel
      * arch/vdso, arch/kernel/vsyscall_64 and arch/kernel/hpet:
        profiling causes segfaults during boot (incompatible context)
      
      Signed-off-by: default avatarPeter Oberparleiter <oberpar@linux.vnet.ibm.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Huang Ying <ying.huang@intel.com>
      Cc: Li Wei <W.Li@Sun.COM>
      Cc: Michael Ellerman <michaele@au1.ibm.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Heiko Carstens <heicars2@linux.vnet.ibm.com>
      Cc: Martin Schwidefsky <mschwid2@linux.vnet.ibm.com>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: WANG Cong <xiyou.wangcong@gmail.com>
      Cc: Sam Ravnborg <sam@ravnborg.org>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      7bf99fb6
  6. Jun 17, 2009
  7. Jun 03, 2009
  8. May 26, 2009
    • Tejun Heo's avatar
      x86, relocs: ignore R_386_NONE in kernel relocation entries · 46176b4f
      Tejun Heo authored
      
      For relocatable 32bit kernels, boot/compressed/relocs.c processes
      relocation entries in the kernel image and appends it to the kernel
      image such that boot/compressed/head_32.S can relocate the kernel.
      The kernel image is one statically linked object and only uses two
      relocation types - R_386_PC32 and R_386_32, of the two only the latter
      needs massaging during kernel relocation and thus handled by relocs.
      R_386_PC32 is ignored and all other relocation types are considered
      error.
      
      When the target of a relocation resides in a discarded section,
      binutils doesn't throw away the relocation record but nullifies it by
      changing it to R_386_NONE, which unfortunately makes relocs fail.
      
      The problem was triggered by yet out-of-tree x86 stack unwind patches
      but given the binutils behavior, ignoring R_386_NONE is the right
      thing to do.
      
      The problem has been tracked down to binutils behavior by Jan Beulich.
      
      [ Impact: fix build with certain binutils by ignoring R_386_NONE ]
      
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Cc: Jan Beulich <JBeulich@novell.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      LKML-Reference: <4A1B8150.40702@kernel.org>
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      46176b4f
  9. May 22, 2009
    • H. Peter Anvin's avatar
      x86, setup: revert ACPI 3 E820 extended attributes support · bca23dba
      H. Peter Anvin authored
      Remove ACPI 3 E820 extended memory attributes support.  At least one
      vendor actively set all the flags to zero, but left ECX on return at
      24.  This bug may be present in other BIOSes.
      
      The breakage functionally means the ACPI 3 flags are probably
      completely useless, and that no OS any time soon is going to rely on
      their existence.  Therefore, drop support completely.  We may want to
      revisit this question in the future, if we find ourselves actually
      needing the flags.
      
      This reverts all or part of the following checkins:
      
           cd670599
           c549e71d
      
      However, retain the part from the latter commit that copies e820 into
      a temporary buffer; that is an unrelated BIOS workaround.  Put in a
      comment to explain that part.
      
      See https://bugzilla.redhat.com/show_bug.cgi?id=499396
      
       for some
      additional information.
      
      [ Impact: detect all memory on affected machines ]
      
      Reported-by: default avatarThomas J. Baker <tjb@unh.edu>
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      Acked-by: default avatarLen Brown <len.brown@intel.com>
      Cc: Chuck Ebbert <cebbert@redhat.com>
      Cc: Kyle McMartin <kmcmartin@redhat.com>
      Cc: Matt Domsch <matt_domsch@dell.com>
      bca23dba
  10. May 20, 2009
  11. May 12, 2009
    • H. Peter Anvin's avatar
      x86, boot: correct sanity checks in boot/compressed/misc.c · 7ed42a28
      H. Peter Anvin authored
      
      arch/x86/boot/compressed/misc.c contains several sanity checks on the
      output address.  Correct constraints that are no longer correct:
      
      - the alignment test should be MIN_KERNEL_ALIGN on both 32 and 64
        bits.
      - the 64 bit maximum address was set to 2^40, which was the limit of
        one specific x86-64 implementation.  Change the test to 2^46, the
        current Linux limit, and at least try to test the end rather than
        the beginning.
      - for non-relocatable kernels, test against LOAD_PHYSICAL_ADDR on both
        32 and 64 bits.
      
      [ Impact: fix potential boot failure due to invalid tests ]
      
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      7ed42a28
    • H. Peter Anvin's avatar
      x86: add extension fields for bootloader type and version · 5031296c
      H. Peter Anvin authored
      
      A long ago, in days of yore, it all began with a god named Thor.
      There were vikings and boats and some plans for a Linux kernel
      header.  Unfortunately, a single 8-bit field was used for bootloader
      type and version.  This has generally worked without *too* much pain,
      but we're getting close to flat running out of ID fields.
      
      Add extension fields for both type and version.  The type will be
      extended if it the old field is 0xE; the version is a simple MSB
      extension.
      
      Keep /proc/sys/kernel/bootloader_type containing
      (type << 4) + (ver & 0xf) for backwards compatiblity, but also add
      /proc/sys/kernel/bootloader_version which contains the full version
      number.
      
      [ Impact: new feature to support more bootloaders ]
      
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      5031296c
    • H. Peter Anvin's avatar
      x86, boot: make kernel_alignment adjustable; new bzImage fields · 37ba7ab5
      H. Peter Anvin authored
      
      Make the kernel_alignment field adjustable; this allows us to set it
      to a large value (intended to be 16 MB to avoid ZONE_DMA contention,
      memory holes and other weirdness) while a smart bootloader can still
      force a loading at a lesser alignment if absolutely necessary.
      
      Also export pref_address (preferred loading address, corresponding to
      the link-time address) and init_size, the total amount of linear
      memory the kernel will require during initialization.
      
      [ Impact: allows better kernel placement, gives bootloader more info ]
      
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      37ba7ab5
  12. May 11, 2009
  13. May 09, 2009
  14. Apr 30, 2009
  15. Apr 27, 2009
    • Linus Torvalds's avatar
      x86: unify arch/x86/boot/compressed/vmlinux_*.lds · 51b26ada
      Linus Torvalds authored
      
      Look at the:
      
      	diff -u arch/x86/boot/compressed/vmlinux_*.lds
      
      output and realize that they're basially exactly the same except for
      trivial naming differences, and the fact that the 64-bit version has a
      "pgtable" thing.
      
      So unify them.
      
      There's some trivial cleanup there (make the output format a Kconfig thing
      rather than doing #ifdef's for it, and unify both 32-bit and 64-bit BSS
      end to "_ebss", where 32-bit used to use the traditional "_end"), but
      other than that it's really very mindless and straigt conversion.
      
      For example, I think we should aim to remove "startup_32" vs "startup_64",
      and just call it "startup", and get rid of one more difference. I didn't
      do that.
      
      Also, notice the comment in the unified vmlinux.lds.S talks about
      "head_64" and "startup_32" which is an odd and incorrect mix, but that was
      actually what the old 64-bit only lds file had, so the confusion isn't
      new, and now that mixing is arguably more accurate thanks to the
      vmlinux.lds.S file being shared between the two cases ;)
      
      [ Impact: cleanup, unification ]
      
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Acked-by: default avatarSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      51b26ada
  16. Apr 12, 2009
  17. Apr 09, 2009
  18. Apr 07, 2009
    • H. Peter Anvin's avatar
      x86, setup: un-resequence mode setting for VGA 80x34 and 80x60 modes · 1e274a58
      H. Peter Anvin authored
      
      Impact: Fixes these modes on at least one system
      
      The rewrite of the setup code into C resequenced the font setting and
      register reprogramming phases of configuring nonstandard VGA modes
      which use 480 scan lines in text mode.  However, there exists at least
      one board (Micro-Star MS-7383 version 2.0) on which this resequencing
      causes an unusable display.
      
      Revert to the original sequencing: set up 480-line mode, install the
      font, and then adjust the vertical end register appropriately.
      
      This failure was masked by the fact that the 480-line setup was broken
      until checkin 5f641356 (therefore this
      is not a -stable candidate bug fix.)
      
      Reported-by: default avatarAndi Kleen <andi@firstfloor.org>
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
      1e274a58
  19. Apr 03, 2009
  20. Apr 01, 2009
  21. Mar 29, 2009
    • H. Peter Anvin's avatar
      x86, setup: ACPI 3, BIOS workaround for E820-probing code · c549e71d
      H. Peter Anvin authored
      
      Impact: ACPI 3 spec compliance, BIOS bug workaround
      
      The ACPI 3 spec added another field to the E820 buffer -- which is
      backwards incompatible, since it contains a validity bit.
      Furthermore, there has been at least one report of a BIOS which
      assumes that the buffer it is pointed at is the same buffer as for the
      previous E820 call.  Therefore, read the data into a temporary buffer
      and copy the standard part of it if and only if the valid bit is set.
      
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      c549e71d
Loading