Eric Lee / smarc-fsl-linux-kernel

01 Jun, 2010

1 commit

  • 1f7389786   Merge branch 'for-35' of git://repo.or.cz/linux-kbuild ... Browse Code »

    * 'for-35' of git://repo.or.cz/linux-kbuild: (81 commits)
    kbuild: Revert part of e8d400a to resolve a conflict
    kbuild: Fix checking of scm-identifier variable
    gconfig: add support to show hidden options that have prompts
    menuconfig: add support to show hidden options which have prompts
    gconfig: remove show_debug option
    gconfig: remove dbg_print_ptype() and dbg_print_stype()
    kconfig: fix zconfdump()
    kconfig: some small fixes
    add random binaries to .gitignore
    kbuild: Include gen_initramfs_list.sh and the file list in the .d file
    kconfig: recalc symbol value before showing search results
    .gitignore: ignore *.lzo files
    headerdep: perlcritic warning
    scripts/Makefile.lib: Align the output of LZO
    kbuild: Generate modules.builtin in make modules_install
    Revert "kbuild: specify absolute paths for cscope"
    kbuild: Do not unnecessarily regenerate modules.builtin
    headers_install: use local file handles
    headers_check: fix perl warnings
    export_report: fix perl warnings
    ...

    Linus Torvalds
     

06 Feb, 2010

2 commits

  • 59dde3853   markup_oops.pl: minor fixes ... Browse Code »

    1. Fix a little format issue.
    2. Check the return of "Getopt::Long::GetOptions". Output usage and
    exit if it get error.
    3. Change $ARGV[$#ARGV] to $ARGV[0].
    4. Change the code which get $modulefile from modinfo. Replace the
    pipeline with `modinfo -F filename $module`.
    4. Change usage from "Specify the module directory name" to "Specify the
    module filename".

    Signed-off-by: Hui Zhu
    Signed-off-by: Michal Marek

    Hui Zhu
     
  • 52e13e219   markup_oops.pl: add options to improve cross-sompilation environments ... Browse Code »

    The markup_oops.pl have 3 troubles to support cross-compiler environment:
    1. It use objdump directly.
    2. It use modinfo to get the message of module.
    3. It use hex function that cannot support 64-bit number in 32-bit arch.

    This patch add 3 options to markup_oops.pl:
    1. -c CROSS_COMPILE Specify the prefix used for toolchain.
    2. -m MODULE_DIRNAME Specify the module directory name.
    3. Change hex function to Math::BigInt->from_hex.

    After this patch, parse the x8664 oops in x86, we can:
    cat amd64m | perl ~/kernel/tmp/m.pl -c /home/teawater/kernel/bin/x8664- -m ./e.ko vmlinux

    Thanks,
    Hui

    Signed-off-by: Hui Zhu
    Cc: Andrew Morton
    Cc: Arjan van de Ven
    Cc: Sam Ravnborg
    Cc: ozan@pardus.org.tr
    Cc: Matthew Wilcox
    Acked-by: WANG Cong
    Signed-off-by: Michal Marek

    Hui Zhu
     

03 Feb, 2010

1 commit

  • ef2b9b054   markup_oops.pl: fix $func_offset error with x86_64 ... Browse Code »

    When I use markup_oops.pl parse a x8664 oops, I got:

    objdump: --start-address: bad number: NaN
    No matching code found
    This is because:
    main::(./m.pl:228): open(FILE, "objdump -dS --adjust-vma=$vmaoffset --start-address=$decodestart --stop-address=$decodestop $filename |") || die "Cannot start objdump";
    DB p $decodestart
    NaN

    This NaN is from:
    main::(./m.pl:176): my $decodestart = Math::BigInt->from_hex("0x$target") - Math::BigInt->from_hex("0x$func_offset");
    DB p $func_offset
    0x175

    There is already a "0x" in $func_offset, another 0x makes it a NaN.

    The $func_offset is from line:

    if ($line =~ /RIP: 0010:\[\\] \[\\] ([a-zA-Z0-9\_]+)\+(0x[0-9a-f]+)\/0x[a-f0-9]/) {
    $function = $1;
    $func_offset = $2;
    }

    I make a patch to change "(0x[0-9a-f]+)\/0x[a-f0-9]/)" to "0x([0-9a-f]+)\/0x[a-f0-9]/)".

    Signed-off-by: Hui Zhu
    Cc: Arjan van de Ven
    Cc: Michal Marek
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Hui Zhu
     

02 Feb, 2010

1 commit

  • 0139f1d95   markup_oops.pl: fix for faulting instruction in the first line of a range ... Browse Code »

    I got a "No matching code found" when I use markup_oops.pl parse a error
    in a x86_64 module.

    cat e.c

    int init_module(void)
    {
    char *buf = 0;

    buf[0] = 3;

    return 0;
    }

    void cleanup_module(void)
    {
    //char *buf = 0;

    //buf[0] = 3;
    }

    MODULE_AUTHOR("Hui Zhu");
    MODULE_LICENSE("GPL");

    0000000000000000 :
    init_module():
    /home/teawater/study/kernel/stack2core/example/e.c:10
    0: c6 04 25 00 00 00 00 movb $0x3,0x0
    7: 03
    /home/teawater/study/kernel/stack2core/example/e.c:13
    8: 31 c0 xor %eax,%eax
    a: c3 retq
    b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)

    0000000000000010 :
    cleanup_module():
    /home/teawater/study/kernel/stack2core/example/e.c:20
    10: f3 c3 repz retq
    12: 90 nop
    13: 90 nop
    Disassembly of section .modinfo:

    This is because the faulting instruction "movb $0x3,0x0" is the first
    line of the range.

    In the markup_oops.pl:
    main::(./scripts/markup_oops.pl:245):
    245: if (InRange($1, $target)) {
    DB p $line
    ffffffffa001b000: c6 04 25 00 00 00 00 movb $0x3,0x0
    DB p $counter
    0

    It just set $center in next loop. So it cannot get the $center.

    And even if $center is set to the right value 0.
    if ($center == 0) {
    print "No matching code found \n";
    exit;
    }
    The first line $center will be 0, so I change the default value to -1.

    Signed-off-by: Hui Zhu
    Signed-off-by: Michal Marek

    Hui Zhu
     

17 Jan, 2010

1 commit

  • 1f8cdae43   markup_oops.pl: fix error with x86 ... Browse Code »

    When I try to use markup_oops.pl in x86, I always get:

    cat 1 | perl markup_oops.pl ./vmlinux
    objdump: --start-address: bad number: NaN
    No matching code found

    This is because in line:
    if ($line =~ /EIP is at ([a-zA-Z0-9\_]+)\+0x([0-9a-f]+)\/[a-f0-9]/) {
    $function = $1;
    $func_offset = $2;
    }

    $func_offset will get a number like "0x2"

    But in follow code:

    my $decodestart = Math::BigInt->from_hex("0x$target") -
    Math::BigInt->from_hex("0x$func_offset");

    It add other ox to ox2. Then this value will be set to NaN.

    So I made a small patch to fix it.

    Signed-off-by: Hui Zhu
    Acked-by: Arjan van de Ven
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Hui Zhu
     

20 Sep, 2009

1 commit

30 Jul, 2009

1 commit

15 Feb, 2009

2 commits

13 Jan, 2009

1 commit

  • d32ad102c   script: improve markup_oops.pl to also decode oopses in modules ... Browse Code »

    There has been some light flamewar on lkml about decoding oopses
    in modules (as part of the crashdump flamewar).

    Now this isn't rocket science, just the markup_oops.pl script
    cheaped out and didn't handle modules. But really; a flamewar
    all about that?? What happened to C++ in the kernel or reading
    files from inside the kernel?

    This patch adds module support to markup_oops.pl; it's not the
    most pretty perl but it works for my testcases...

    Signed-off-by: Arjan van de Ven
    Signed-off-by: Linus Torvalds

    Arjan van de Ven
     

07 Jan, 2009

1 commit

  • 5aea50b5c   scripts: script from kerneloops.org to pretty print oops dumps ... Browse Code »

    We're struggling all the time to figure out where the code came from that
    oopsed.. The script below (a adaption from a script used by
    kerneloops.org) can help developers quite a bit, at least for non-module
    cases.

    It works and looks like this:

    [/home/arjan/linux]$ dmesg | perl scripts/markup_oops.pl vmlinux
    {
    struct agp_memory *memory;

    memory = agp_allocate_memory(agp_bridge, pg_count, type);
    c055c10f: 89 c2 mov %eax,%edx
    if (memory == NULL)
    c055c111: 74 19 je c055c12c
    /* This function must only be called when current_controller != NULL */
    static void agp_insert_into_pool(struct agp_memory * temp)
    {
    struct agp_memory *prev;

    prev = agp_fe.current_controller->pool;
    c055c113: a1 ec dc 8f c0 mov 0xc08fdcec,%eax
    *c055c118: 8b 40 10 mov 0x10(%eax),%eax
    prev->prev = temp;
    c055c11f: 89 50 04 mov %edx,0x4(%eax)
    temp->next = prev;
    c055c122: 89 02 mov %eax,(%edx)
    }
    agp_fe.current_controller->pool = temp;
    c055c124: a1 ec dc 8f c0 mov 0xc08fdcec,%eax
    c055c129: 89 50 10 mov %edx,0x10(%eax)
    if (memory == NULL)
    return NULL;

    agp_insert_into_pool(memory);

    so in this case, we faulted while dereferencing agp_fe.current_controller
    pointer, and we get to see exactly which function and line it affects...
    Personally I find this very useful, and I can see value for having this
    script in the kernel for more-than-just-me to use.

    Caveats:
    * It only works for oopses not-in-modules
    * It only works nicely for kernels compiled with CONFIG_DEBUG_INFO
    * It's not very fast.
    * It only works on x86

    Signed-off-by: Arjan van de Ven
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Arjan van de Ven