1. 19 6月, 2014 1 次提交
  2. 18 6月, 2014 2 次提交
  3. 11 6月, 2014 1 次提交
    • S
      decode_stacktrace: make stack dump output useful again · dbd1abb2
      Sasha Levin 提交于
      Right now when people try to report issues in the kernel they send stack
      dumps to eachother, which looks something like this:
      
        [    6.906437]  [<ffffffff811f0e90>] ? backtrace_test_irq_callback+0x20/0x20
        [    6.907121]  [<ffffffff84388ce8>] dump_stack+0x52/0x7f
        [    6.907640]  [<ffffffff811f0ec8>] backtrace_regression_test+0x38/0x110
        [    6.908281]  [<ffffffff813596a0>] ? proc_create_data+0xa0/0xd0
        [    6.908870]  [<ffffffff870a8040>] ? proc_modules_init+0x22/0x22
        [    6.909480]  [<ffffffff810020c2>] do_one_initcall+0xc2/0x1e0
        [...]
      
      However, most of the text you get is pure garbage.
      
      The only useful thing above is the function name.  Due to the amount of
      different kernel code versions and various configurations being used,
      the kernel address and the offset into the function are not really
      helpful in determining where the problem actually occured.
      
      Too often the result of someone looking at a stack dump is asking the
      person who sent it for a translation for one or more 'addr2line'
      translations.  Which slows down the entire process of debugging the
      issue (and really annoying).
      
      The decode_stacktrace script is an attempt to make the output more
      useful and easy to work with by translating all kernel addresses in the
      stack dump into line numbers.  Which means that the stack dump would
      look like this:
      
        [  635.148361]  dump_stack (lib/dump_stack.c:52)
        [  635.149127]  warn_slowpath_common (kernel/panic.c:418)
        [  635.150214]  warn_slowpath_null (kernel/panic.c:453)
        [  635.151031]  _oalloc_pages_slowpath+0x6a/0x7d0
        [  635.152171]  ? zone_watermark_ok (mm/page_alloc.c:1728)
        [  635.152988]  ? get_page_from_freelist (mm/page_alloc.c:1939)
        [  635.154766]  __alloc_pages_nodemask (mm/page_alloc.c:2766)
      
      It's pretty obvious why this is better than the previous stack dump
      before.
      
      Usage is pretty simple:
      
              ./decode_stacktrace.sh [vmlinux] [base path]
      
      Where vmlinux is the vmlinux to extract line numbers from and base path
      is the path that points to the root of the build tree, for example:
      
              ./decode_stacktrace.sh vmlinux /home/sasha/linux/ < input.log > output.log
      
      The stack trace should be piped through it (I, for example, just pipe
      the output of the serial console of my KVM test box through it).
      Signed-off-by: NSasha Levin <sasha.levin@oracle.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      dbd1abb2
  4. 10 6月, 2014 15 次提交
  5. 05 6月, 2014 9 次提交
  6. 29 5月, 2014 1 次提交
    • A
      ftrace: Add arm64 support to recordmcount · af64d2aa
      AKASHI Takahiro 提交于
      Recordmcount utility under scripts is run, after compiling each object,
      to find out all the locations of calling _mcount() and put them into
      specific seciton named __mcount_loc.
      Then linker collects all such information into a table in the kernel image
      (between __start_mcount_loc and __stop_mcount_loc) for later use by ftrace.
      
      This patch adds arm64 specific definitions to identify such locations.
      There are two types of implementation, C and Perl. On arm64, only C version
      is used to build the kernel now that CONFIG_HAVE_C_RECORDMCOUNT is on.
      But Perl version is also maintained.
      
      This patch also contains a workaround just in case where a header file,
      elf.h, on host machine doesn't have definitions of EM_AARCH64 nor
      R_AARCH64_ABS64. Without them, compiling C version of recordmcount will
      fail.
      Acked-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NAKASHI Takahiro <takahiro.akashi@linaro.org>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      af64d2aa
  7. 20 5月, 2014 1 次提交
  8. 15 5月, 2014 1 次提交
    • M
      firmware: Simplify directory creation · 5180d5f4
      Michal Marek 提交于
      When building the firmware blobs, use a simple loop to create
      directories in $(objtree), like in Makefile.build. This simplifies the
      rules and also makes it possible to set $(objtree) to '.' later. Before
      this change, a dependency on $(objtree)/<dir> would be satisfied by
      <dir> in $(srctree).
      
      When installing the firmware blobs, call mkdir like in Makefile.modinst.
      
      Cc: David Woodhouse <dwmw2@infradead.org>
      Acked-by: NSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NMichal Marek <mmarek@suse.cz>
      5180d5f4
  9. 14 5月, 2014 1 次提交
  10. 05 5月, 2014 1 次提交
  11. 30 4月, 2014 2 次提交
  12. 28 4月, 2014 1 次提交
  13. 24 4月, 2014 3 次提交
  14. 17 4月, 2014 1 次提交
反馈
建议
客服 返回
顶部