Eric Lee / smarc-fsl-linux-kernel

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
     

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