Eric Lee / smarc-fsl-linux-kernel

09 Apr, 2011

1 commit

  • ce9c99af8   x86, cpu: Move AMD Elan Kconfig under "Processor family" ... Browse Code »

    Currently the option resides under X86_EXTENDED_PLATFORM due to historical
    nonstandard A20M# handling. However that is no longer the case and so Elan can
    be treated as part of the standard processor choice Kconfig option.

    Signed-off-by: Ian Campbell
    Link: http://lkml.kernel.org/r/1302245177.31620.47.camel@localhost.localdomain
    Cc: H. Peter Anvin
    Signed-off-by: H. Peter Anvin

    Ian Campbell
     

30 Oct, 2010

1 commit

  • 45f81b1c9   jump label: Add work around to i386 gcc asm goto bug ... Browse Code »

    On i386 (not x86_64) early implementations of gcc would have a bug
    with asm goto causing it to produce code like the following:

    (This was noticed by Peter Zijlstra)

    56 pushl 0
    67 nopl jmp 0x6f
    popl
    jmp 0x8c

    6f mov
    test
    je 0x8c

    8c mov
    call *(%esp)

    The jump added in the asm goto skipped over the popl that matched
    the pushl 0, which lead up to a quick crash of the system when
    the jump was enabled. The nopl is defined in the asm goto () statement
    and when tracepoints are enabled, the nop changes to a jump to the label
    that was specified by the asm goto. asm goto is suppose to tell gcc that
    the code in the asm might jump to an external label. Here gcc obviously
    fails to make that work.

    The bug report for gcc is here:

    http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46226

    The bug only appears on x86 when not compiled with
    -maccumulate-outgoing-args. This option is always set on x86_64 and it
    is also the work around for a function graph tracer i386 bug.
    (See commit: 746357d6a526d6da9d89a2ec645b28406e959c2e)
    This explains why the bug only showed up on i386 when function graph
    tracer was not enabled.

    This patch now adds a CONFIG_JUMP_LABEL option that is default
    off instead of using jump labels by default. When jump labels are
    enabled, the -maccumulate-outgoing-args will be used (causing a
    slightly larger kernel image on i386). This option will exist
    until we have a way to detect if the gcc compiler in use is safe
    to use on all configurations without the work around.

    Note, there exists such a test, but for now we will keep the enabling
    of jump label as a manual option.

    Archs that know the compiler is safe with asm goto, may choose to
    select JUMP_LABEL and enable it by default.

    Reported-by: Ingo Molnar
    Cause-discovered-by: Peter Zijlstra
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Cc: Jason Baron
    Cc: H. Peter Anvin
    Cc: David Daney
    Cc: Mathieu Desnoyers
    Cc: Masami Hiramatsu
    Cc: David Miller
    Cc: Richard Henderson
    LKML-Reference:
    Signed-off-by: Steven Rostedt

    Steven Rostedt
     

09 Dec, 2009

1 commit

  • 86ed4aa45   Merge branch 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/… ... Browse Code »

    …git/tip/linux-2.6-tip

    * 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
    x86, mce: don't restart timer if disabled
    x86: Use -maccumulate-outgoing-args for sane mcount prologues
    x86: Prevent GCC 4.4.x (pentium-mmx et al) function prologue wreckage
    x86: AMD Northbridge: Verify NB's node is online
    x86 VSDO: Fix Kconfig help
    x86: Fix typo in Intel CPU cache size descriptor
    x86: Add new Intel CPU cache size descriptors

    Linus Torvalds
     

28 Nov, 2009

1 commit

  • b8b7d791a   x86: Use -maccumulate-outgoing-args for sane mcount prologues ... Browse Code »

    commit 746357d (x86: Prevent GCC 4.4.x (pentium-mmx et al) function
    prologue wreckage) uses -mtune=generic to work around the function
    prologue problem with mcount on -march=pentium-mmx and others.

    Jakub pointed out that we can use -maccumulate-outgoing-args instead
    which is selected by -mtune=generic and prevents the problem without
    losing the -march specific optimizations.

    Pointed-out-by: Jakub Jelinek
    Signed-off-by: Thomas Gleixner
    Cc: Linus Torvalds
    Cc: stable@kernel.org

    Thomas Gleixner
     

20 Nov, 2009

1 commit

  • 746357d6a   x86: Prevent GCC 4.4.x (pentium-mmx et al) function prologue wreckage ... Browse Code »

    When the kernel is compiled with -pg for tracing GCC 4.4.x inserts
    stack alignment of a function _before_ the mcount prologue if the
    -march=pentium-mmx is set and -mtune=generic is not set. This breaks
    the assumption of the function graph tracer which expects that the
    mcount prologue

    push %ebp
    mov %esp, %ebp

    is the first stack operation in a function because it needs to modify
    the function return address on the stack to trap into the tracer
    before returning to the real caller.

    The generated code is:

    push %edi
    lea 0x8(%esp),%edi
    and $0xfffffff0,%esp
    pushl -0x4(%edi)
    push %ebp
    mov %esp,%ebp

    so the tracer modifies the copy of the return address which is stored
    after the stack alignment and therefor does not trap the return which
    in turn breaks the call chain logic of the tracer and leads to a
    kernel panic.

    Aside of the fact that the generated code is horrible for no good
    reason other -march -mtune options generate the expected:

    push %ebp
    mov %esp,%ebp
    and $0xfffffff0,%esp

    which does the same and keeps everything intact.

    After some experimenting we found out that this problem is restricted
    to gcc4.4.x and to the following -march settings:

    i586, pentium, pentium-mmx, k6, k6-2, k6-3, winchip-c6, winchip2, c3,
    geode

    By adding -mtune=generic the code generator produces always the
    expected code.

    So forcing -mtune=generic when CONFIG_FUNCTION_GRAPH_TRACER=y is not
    pretty, but at the moment the only way to prevent that the kernel
    trips over gcc-shrooms induced code madness.

    Most distro kernels have CONFIG_X86_GENERIC=y anyway which forces
    -mtune=generic as well so it will not impact those.

    References: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42109
    http://lkml.org/lkml/2009/11/19/17

    Signed-off-by: Thomas Gleixner
    LKML-Reference:
    Cc: Linus Torvalds
    Cc: Andrew Morton
    Cc: Ingo Molnar
    Cc: Peter Zijlstra
    Cc: H. Peter Anvin
    Cc: Steven Rostedt
    Cc: Frederic Weisbecker ,
    Cc: Jeff Law
    Cc: gcc@gcc.gnu.org
    Cc: David Daney
    Cc: Andrew Haley
    Cc: Richard Guenther
    Cc: stable@kernel.org

    Thomas Gleixner
     

03 Oct, 2009

1 commit

23 Aug, 2009

1 commit

13 Oct, 2008

1 commit

10 Sep, 2008

1 commit

  • 28f7e66fc   x86: prevent binutils from being "smart" and generating NOPLs for us ... Browse Code »

    binutils, contrary to documented behaviour, will generate long NOPs (a
    P6-or-higher instruction which is broken on at least some VIA chips,
    Virtual PC/Virtual Server, and some versions of Qemu) depending on the
    -mtune= option, which is not supposed to change architectural
    behaviour.

    Pass an explicit override to the assembler, in case ends up passing
    the -mtune= parameter to gas (gcc 4.3.0 does not appear to.)

    Signed-off-by: H. Peter Anvin

    H. Peter Anvin
     

26 Oct, 2007

1 commit