1. 31 7月, 2014 1 次提交
  2. 11 6月, 2014 1 次提交
    • T
      PM / sleep: trace events for device PM callbacks · e8bca479
      Todd E Brandt 提交于
      Adds two trace events which supply the same info that initcall_debug
      provides, but via ftrace instead of dmesg. The existing initcall_debug
      calls require the pm_print_times_enabled var to be set (either via
      sysfs or via the kernel cmd line). The new trace events provide all the
      same info as the initcall_debug prints but with less overhead, and also
      with coverage of device prepare and complete device callbacks.
      
      These events replace the device_pm_report_time event (which has been
      removed). device_pm_callback_start is called first and provides the device
      and callback info. device_pm_callback_end is called after with the
      device name and error info. The time and pid are gathered from the trace
      data headers.
      Signed-off-by: NTodd Brandt <todd.e.brandt@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      e8bca479
  3. 07 6月, 2014 1 次提交
    • T
      PM / sleep: trace events for suspend/resume · bb3632c6
      Todd E Brandt 提交于
      Adds trace events that give finer resolution into suspend/resume. These
      events are graphed in the timelines generated by the analyze_suspend.py
      script. They represent large areas of time consumed that are typical to
      suspend and resume.
      
      The event is triggered by calling the function "trace_suspend_resume"
      with three arguments: a string (the name of the event to be displayed
      in the timeline), an integer (case specific number, such as the power
      state or cpu number), and a boolean (where true is used to denote the start
      of the timeline event, and false to denote the end).
      
      The suspend_resume trace event reproduces the data that the machine_suspend
      trace event did, so the latter has been removed.
      Signed-off-by: NTodd Brandt <todd.e.brandt@intel.com>
      Acked-by: NSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      bb3632c6
  4. 05 6月, 2014 5 次提交
    • A
      sched, trace: Add a tracepoint for IPI-less remote wakeups · dfc68f29
      Andy Lutomirski 提交于
      Remote wakeups of polling CPUs are a valuable performance
      improvement; add a tracepoint to make it much easier to verify that
      they're working.
      Signed-off-by: NAndy Lutomirski <luto@amacapital.net>
      Signed-off-by: NPeter Zijlstra <peterz@infradead.org>
      Cc: nicolas.pitre@linaro.org
      Cc: daniel.lezcano@linaro.org
      Cc: umgwanakikbuti@gmail.com
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mel Gorman <mgorman@suse.de>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: linux-kernel@vger.kernel.org
      Link: http://lkml.kernel.org/r/16205aee116772aa686814f9b13bccb562108047.1401902905.git.luto@amacapital.netSigned-off-by: NIngo Molnar <mingo@kernel.org>
      dfc68f29
    • V
      mm/compaction: do not count migratepages when unnecessary · f8c9301f
      Vlastimil Babka 提交于
      During compaction, update_nr_listpages() has been used to count remaining
      non-migrated and free pages after a call to migrage_pages().  The
      freepages counting has become unneccessary, and it turns out that
      migratepages counting is also unnecessary in most cases.
      
      The only situation when it's needed to count cc->migratepages is when
      migrate_pages() returns with a negative error code.  Otherwise, the
      non-negative return value is the number of pages that were not migrated,
      which is exactly the count of remaining pages in the cc->migratepages
      list.
      
      Furthermore, any non-zero count is only interesting for the tracepoint of
      mm_compaction_migratepages events, because after that all remaining
      unmigrated pages are put back and their count is set to 0.
      
      This patch therefore removes update_nr_listpages() completely, and changes
      the tracepoint definition so that the manual counting is done only when
      the tracepoint is enabled, and only when migrate_pages() returns a
      negative error code.
      
      Furthermore, migrate_pages() and the tracepoints won't be called when
      there's nothing to migrate.  This potentially avoids some wasted cycles
      and reduces the volume of uninteresting mm_compaction_migratepages events
      where "nr_migrated=0 nr_failed=0".  In the stress-highalloc mmtest, this
      was about 75% of the events.  The mm_compaction_isolate_migratepages event
      is better for determining that nothing was isolated for migration, and
      this one was just duplicating the info.
      Signed-off-by: NVlastimil Babka <vbabka@suse.cz>
      Reviewed-by: NNaoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Cc: Minchan Kim <minchan@kernel.org>
      Cc: Mel Gorman <mgorman@suse.de>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      Acked-by: NMichal Nazarewicz <mina86@mina86.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Rik van Riel <riel@redhat.com>
      Acked-by: NDavid Rientjes <rientjes@google.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f8c9301f
    • D
      mm: shrinker: add nid to tracepoint output · df9024a8
      Dave Hansen 提交于
      Now that we are doing NUMA-aware shrinking, and can have shrinkers
      running in parallel, or working on individual nodes, it seems like we
      should also be sticking the node in the output.
      Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com>
      Acked-by: NDave Chinner <david@fromorbit.com>
      Cc: Konstantin Khlebnikov <khlebnikov@openvz.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      df9024a8
    • D
      mm: shrinker trace points: fix negatives · 7fe70475
      Dave Hansen 提交于
      I was looking at a trace of the slab shrinkers (attachment in this comment):
      
      	https://bugs.freedesktop.org/show_bug.cgi?id=72742#c67
      
      and noticed that "total_scan" can go negative in some cases.  We
      used to dump out the "total_scan" variable directly, but some of
      the shrinker modifications along the way changed that.
      
      This patch just dumps it out directly, again.  It doesn't make
      any sense to derive it from new_nr and nr any more since there
      are now other shrinkers that can be running in parallel and
      mucking with those values.
      
      Here's an example of the negative numbers in the output:
      
      >          kswapd0-840   [000]   160.869398: mm_shrink_slab_end:   i915_gem_inactive_scan+0x0 0xffff8800037cbc68: unused scan count 10 new scan count 39 total_scan 29 last shrinker return val 256
      >          kswapd0-840   [000]   160.869618: mm_shrink_slab_end:   i915_gem_inactive_scan+0x0 0xffff8800037cbc68: unused scan count 39 new scan count 102 total_scan 63 last shrinker return val 256
      >          kswapd0-840   [000]   160.870031: mm_shrink_slab_end:   i915_gem_inactive_scan+0x0 0xffff8800037cbc68: unused scan count 102 new scan count 47 total_scan -55 last shrinker return val 768
      >          kswapd0-840   [000]   160.870464: mm_shrink_slab_end:   i915_gem_inactive_scan+0x0 0xffff8800037cbc68: unused scan count 47 new scan count 45 total_scan -2 last shrinker return val 768
      >          kswapd0-840   [000]   163.384144: mm_shrink_slab_end:   i915_gem_inactive_scan+0x0 0xffff8800037cbc68: unused scan count 45 new scan count 56 total_scan 11 last shrinker return val 0
      >          kswapd0-840   [000]   163.384297: mm_shrink_slab_end:   i915_gem_inactive_scan+0x0 0xffff8800037cbc68: unused scan count 56 new scan count 15 total_scan -41 last shrinker return val 256
      >          kswapd0-840   [000]   163.384414: mm_shrink_slab_end:   i915_gem_inactive_scan+0x0 0xffff8800037cbc68: unused scan count 15 new scan count 117 total_scan 102 last shrinker return val 0
      >          kswapd0-840   [000]   163.384657: mm_shrink_slab_end:   i915_gem_inactive_scan+0x0 0xffff8800037cbc68: unused scan count 117 new scan count 36 total_scan -81 last shrinker return val 512
      >          kswapd0-840   [000]   163.384880: mm_shrink_slab_end:   i915_gem_inactive_scan+0x0 0xffff8800037cbc68: unused scan count 36 new scan count 111 total_scan 75 last shrinker return val 256
      >          kswapd0-840   [000]   163.385256: mm_shrink_slab_end:   i915_gem_inactive_scan+0x0 0xffff8800037cbc68: unused scan count 111 new scan count 34 total_scan -77 last shrinker return val 768
      >          kswapd0-840   [000]   163.385598: mm_shrink_slab_end:   i915_gem_inactive_scan+0x0 0xffff8800037cbc68: unused scan count 34 new scan count 122 total_scan 88 last shrinker return val 512
      Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com>
      Acked-by: NDave Chinner <david@fromorbit.com>
      Cc: Konstantin Khlebnikov <khlebnikov@openvz.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      7fe70475
    • V
      mm: get rid of __GFP_KMEMCG · 52383431
      Vladimir Davydov 提交于
      Currently to allocate a page that should be charged to kmemcg (e.g.
      threadinfo), we pass __GFP_KMEMCG flag to the page allocator.  The page
      allocated is then to be freed by free_memcg_kmem_pages.  Apart from
      looking asymmetrical, this also requires intrusion to the general
      allocation path.  So let's introduce separate functions that will
      alloc/free pages charged to kmemcg.
      
      The new functions are called alloc_kmem_pages and free_kmem_pages.  They
      should be used when the caller actually would like to use kmalloc, but
      has to fall back to the page allocator for the allocation is large.
      They only differ from alloc_pages and free_pages in that besides
      allocating or freeing pages they also charge them to the kmem resource
      counter of the current memory cgroup.
      
      [sfr@canb.auug.org.au: export kmalloc_order() to modules]
      Signed-off-by: NVladimir Davydov <vdavydov@parallels.com>
      Acked-by: NGreg Thelen <gthelen@google.com>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Acked-by: NMichal Hocko <mhocko@suse.cz>
      Cc: Glauber Costa <glommer@gmail.com>
      Cc: Christoph Lameter <cl@linux-foundation.org>
      Cc: Pekka Enberg <penberg@kernel.org>
      Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      52383431
  5. 02 6月, 2014 1 次提交
  6. 08 5月, 2014 1 次提交
  7. 07 5月, 2014 5 次提交
  8. 23 4月, 2014 1 次提交
  9. 22 4月, 2014 1 次提交
    • L
      ASoC: Remove ASoC level IO tracing · 111c0cf5
      Lars-Peter Clausen 提交于
      The ASoC framework is in the process of migrating all IO operations to regmap.
      regmap has its own more sophisticated tracing infrastructure for IO operations,
      which means that the ASoC level IO tracing becomes redundant, hence this patch
      removes them. There are still a handful of ASoC drivers left that do not use
      regmap yet, but hopefully the removal of the ASoC IO tracing will be an
      additional incentive to switch to regmap.
      Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: NMark Brown <broonie@linaro.org>
      111c0cf5
  10. 21 4月, 2014 2 次提交
    • L
      ext4: rename uninitialized extents to unwritten · 556615dc
      Lukas Czerner 提交于
      Currently in ext4 there is quite a mess when it comes to naming
      unwritten extents. Sometimes we call it uninitialized and sometimes we
      refer to it as unwritten.
      
      The right name for the extent which has been allocated but does not
      contain any written data is _unwritten_. Other file systems are
      using this name consistently, even the buffer head state refers to it as
      unwritten. We need to fix this confusion in ext4.
      
      This commit changes every reference to an uninitialized extent (meaning
      allocated but unwritten) to unwritten extent. This includes comments,
      function names and variable names. It even covers abbreviation of the
      word uninitialized (such as uninit) and some misspellings.
      
      This commit does not change any of the code paths at all. This has been
      confirmed by comparing md5sums of the assembly code of each object file
      after all the function names were stripped from it.
      Signed-off-by: NLukas Czerner <lczerner@redhat.com>
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      556615dc
    • L
      ext4: get rid of EXT4_MAP_UNINIT flag · 090f32ee
      Lukas Czerner 提交于
      Currently EXT4_MAP_UNINIT is used in dioread_nolock case to mark the
      cases where we're using dioread_nolock and we're writing into either
      unallocated, or unwritten extent, because we need to make sure that
      any DIO write into that inode will wait for the extent conversion.
      
      However EXT4_MAP_UNINIT is not only entirely misleading name but also
      unnecessary because we can check for EXT4_MAP_UNWRITTEN in the
      dioread_nolock case instead.
      
      This commit removes EXT4_MAP_UNINIT flag.
      Signed-off-by: NLukas Czerner <lczerner@redhat.com>
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      090f32ee
  11. 15 4月, 2014 1 次提交
  12. 09 4月, 2014 1 次提交
    • M
      tracepoint: Fix sparse warnings in tracepoint.c · b725dfea
      Mathieu Desnoyers 提交于
      Fix the following sparse warnings:
      
        CHECK   kernel/tracepoint.c
      kernel/tracepoint.c:184:18: warning: incorrect type in assignment (different address spaces)
      kernel/tracepoint.c:184:18:    expected struct tracepoint_func *tp_funcs
      kernel/tracepoint.c:184:18:    got struct tracepoint_func [noderef] <asn:4>*funcs
      kernel/tracepoint.c:216:18: warning: incorrect type in assignment (different address spaces)
      kernel/tracepoint.c:216:18:    expected struct tracepoint_func *tp_funcs
      kernel/tracepoint.c:216:18:    got struct tracepoint_func [noderef] <asn:4>*funcs
      kernel/tracepoint.c:392:24: error: return expression in void function
        CC      kernel/tracepoint.o
      kernel/tracepoint.c: In function tracepoint_module_going:
      kernel/tracepoint.c:491:6: warning: symbol 'syscall_regfunc' was not declared. Should it be static?
      kernel/tracepoint.c:508:6: warning: symbol 'syscall_unregfunc' was not declared. Should it be static?
      
      Link: http://lkml.kernel.org/r/1397049883-28692-1-git-send-email-mathieu.desnoyers@efficios.comSigned-off-by: NMathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      b725dfea
  13. 08 4月, 2014 1 次提交
  14. 27 3月, 2014 1 次提交
  15. 21 3月, 2014 1 次提交
  16. 19 3月, 2014 3 次提交
  17. 14 3月, 2014 2 次提交
    • D
      i2c: Add message transfer tracepoints for SMBUS [ver #2] · 8a325997
      David Howells 提交于
      The SMBUS tracepoints can be enabled thusly:
      
      	echo 1 >/sys/kernel/debug/tracing/events/i2c/enable
      
      and will dump messages that can be viewed in /sys/kernel/debug/tracing/trace
      that look like:
      
               ... smbus_read: i2c-0 a=051 f=0000 c=fa BYTE_DATA
               ... smbus_reply: i2c-0 a=051 f=0000 c=fa BYTE_DATA l=1 [39]
               ... smbus_result: i2c-0 a=051 f=0000 c=fa BYTE_DATA rd res=0
      
      formatted as:
      
      	i2c-<adapter-nr>
      	a=<addr>
      	f=<flags>
      	c=<command>
      	<protocol-name>
      	<rd|wr>
      	res=<result>
      	l=<data-len>
      	[<data-block>]
      
      The adapters to be traced can be selected by something like:
      
      	echo adapter_nr==1 >/sys/kernel/debug/tracing/events/i2c/filter
      
      Note that this shares the same filter and enablement as i2c.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Reviewed-by: NSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      8a325997
    • D
      i2c: Add message transfer tracepoints for I2C · d9a83d62
      David Howells 提交于
      Add tracepoints into the I2C message transfer function to retrieve the message
      sent or received.  The following config options must be turned on to make use
      of the facility:
      
      	CONFIG_FTRACE
      	CONFIG_ENABLE_DEFAULT_TRACERS
      
      The I2C tracepoint can be enabled thusly:
      
      	echo 1 >/sys/kernel/debug/tracing/events/i2c/enable
      
      and will dump messages that can be viewed in /sys/kernel/debug/tracing/trace
      that look like:
      
      	... i2c_write: i2c-5 #0 a=044 f=0000 l=2 [02-14]
      	... i2c_read: i2c-5 #1 a=044 f=0001 l=4
      	... i2c_reply: i2c-5 #1 a=044 f=0001 l=4 [33-00-00-00]
      	... i2c_result: i2c-5 n=2 ret=2
      
      formatted as:
      
      	i2c-<adapter-nr>
      	#<message-array-index>
      	a=<addr>
      	f=<flags>
      	l=<datalen>
      	n=<message-array-size>
      	ret=<result>
      	[<data>]
      
      The operation is done between the i2c_write/i2c_read lines and the i2c_reply
      and i2c_result lines so that if the hardware hangs, the trace buffer can be
      consulted to determine the problematic operation.
      
      The adapters to be traced can be selected by something like:
      
      	echo adapter_nr==1 >/sys/kernel/debug/tracing/events/i2c/filter
      
      These changes are based on code from Steven Rostedt.
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Reviewed-by: NSteven Rostedt <rostedt@goodmis.org>
      [wsa: adapted path for 'enable' in the commit msg]
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      d9a83d62
  18. 13 3月, 2014 1 次提交
    • M
      Fix: module signature vs tracepoints: add new TAINT_UNSIGNED_MODULE · 66cc69e3
      Mathieu Desnoyers 提交于
      Users have reported being unable to trace non-signed modules loaded
      within a kernel supporting module signature.
      
      This is caused by tracepoint.c:tracepoint_module_coming() refusing to
      take into account tracepoints sitting within force-loaded modules
      (TAINT_FORCED_MODULE). The reason for this check, in the first place, is
      that a force-loaded module may have a struct module incompatible with
      the layout expected by the kernel, and can thus cause a kernel crash
      upon forced load of that module on a kernel with CONFIG_TRACEPOINTS=y.
      
      Tracepoints, however, specifically accept TAINT_OOT_MODULE and
      TAINT_CRAP, since those modules do not lead to the "very likely system
      crash" issue cited above for force-loaded modules.
      
      With kernels having CONFIG_MODULE_SIG=y (signed modules), a non-signed
      module is tainted re-using the TAINT_FORCED_MODULE taint flag.
      Unfortunately, this means that Tracepoints treat that module as a
      force-loaded module, and thus silently refuse to consider any tracepoint
      within this module.
      
      Since an unsigned module does not fit within the "very likely system
      crash" category of tainting, add a new TAINT_UNSIGNED_MODULE taint flag
      to specifically address this taint behavior, and accept those modules
      within Tracepoints. We use the letter 'X' as a taint flag character for
      a module being loaded that doesn't know how to sign its name (proposed
      by Steven Rostedt).
      
      Also add the missing 'O' entry to trace event show_module_flags() list
      for the sake of completeness.
      Signed-off-by: NMathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Acked-by: NSteven Rostedt <rostedt@goodmis.org>
      NAKed-by: NIngo Molnar <mingo@redhat.com>
      CC: Thomas Gleixner <tglx@linutronix.de>
      CC: David Howells <dhowells@redhat.com>
      CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      66cc69e3
  19. 11 3月, 2014 1 次提交
  20. 08 3月, 2014 1 次提交
    • D
      SUNRPC: Fix oops when trace sunrpc_task events in nfs client · 2ca310fc
      Ditang Chen 提交于
      When tracking sunrpc_task events in nfs client, the clnt pointer may be NULL.
      
      [  139.269266] BUG: unable to handle kernel NULL pointer dereference at 0000000000000004
      [  139.269915] IP: [<ffffffffa026f216>] ftrace_raw_event_rpc_task_running+0x86/0xf0 [sunrpc]
      [  139.269915] PGD 1d293067 PUD 1d294067 PMD 0
      [  139.269915] Oops: 0000 [#1] SMP
      [  139.269915] Modules linked in: nfsv4 dns_resolver nfs lockd sunrpc fscache sg ppdev e1000
      serio_raw pcspkr parport_pc parport i2c_piix4 i2c_core microcode xfs libcrc32c sd_mod sr_mod
      cdrom ata_generic crc_t10dif crct10dif_common pata_acpi ahci libahci ata_piix libata dm_mirror
      dm_region_hash dm_log dm_mod
      [  139.269915] CPU: 0 PID: 59 Comm: kworker/0:2 Not tainted 3.10.0-84.el7.x86_64 #1
      [  139.269915] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
      [  139.269915] Workqueue: rpciod rpc_async_schedule [sunrpc]
      [  139.269915] task: ffff88001b598000 ti: ffff88001b632000 task.ti: ffff88001b632000
      [  139.269915] RIP: 0010:[<ffffffffa026f216>]  [<ffffffffa026f216>] ftrace_raw_event_rpc_task_running+0x86/0xf0 [sunrpc]
      [  139.269915] RSP: 0018:ffff88001b633d70  EFLAGS: 00010206
      [  139.269915] RAX: ffff88001dfc5338 RBX: ffff88001cc37a00 RCX: ffff88001dfc5334
      [  139.269915] RDX: ffff88001dfc5338 RSI: 0000000000000000 RDI: ffff88001dfc533c
      [  139.269915] RBP: ffff88001b633db0 R08: 000000000000002c R09: 000000000000000a
      [  139.269915] R10: 0000000000062180 R11: 00000020759fb9dc R12: ffffffffa0292c20
      [  139.269915] R13: ffff88001dfc5334 R14: 0000000000000000 R15: 0000000000000000
      [  139.269915] FS:  0000000000000000(0000) GS:ffff88001fc00000(0000) knlGS:0000000000000000
      [  139.269915] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      [  139.269915] CR2: 0000000000000004 CR3: 000000001d290000 CR4: 00000000000006f0
      [  139.269915] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [  139.269915] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      [  139.269915] Stack:
      [  139.269915]  000000001b633d98 0000000000000246 ffff88001df1dc00 ffff88001cc37a00
      [  139.269915]  ffff88001bc35e60 0000000000000000 ffff88001ffa0a48 ffff88001bc35ee0
      [  139.269915]  ffff88001b633e08 ffffffffa02704b5 0000000000010000 ffff88001cc37a70
      [  139.269915] Call Trace:
      [  139.269915]  [<ffffffffa02704b5>] __rpc_execute+0x1d5/0x400 [sunrpc]
      [  139.269915]  [<ffffffffa0270706>] rpc_async_schedule+0x26/0x30 [sunrpc]
      [  139.269915]  [<ffffffff8107867b>] process_one_work+0x17b/0x460
      [  139.269915]  [<ffffffff8107942b>] worker_thread+0x11b/0x400
      [  139.269915]  [<ffffffff81079310>] ? rescuer_thread+0x3e0/0x3e0
      [  139.269915]  [<ffffffff8107fc80>] kthread+0xc0/0xd0
      [  139.269915]  [<ffffffff8107fbc0>] ? kthread_create_on_node+0x110/0x110
      [  139.269915]  [<ffffffff815d122c>] ret_from_fork+0x7c/0xb0
      [  139.269915]  [<ffffffff8107fbc0>] ? kthread_create_on_node+0x110/0x110
      [  139.269915] Code: 4c 8b 45 c8 48 8d 7d d0 89 4d c4 41 89 c9 b9 28 00 00 00 e8 9d b4 e9
      e0 48 85 c0 49 89 c5 74 a2 48 89 c7 e8 9d 3f e9 e0 48 89 c2 <41> 8b 46 04 48 8b 7d d0 4c
      89 e9 4c 89 e6 89 42 0c 0f b7 83 d4
      [  139.269915] RIP  [<ffffffffa026f216>] ftrace_raw_event_rpc_task_running+0x86/0xf0 [sunrpc]
      [  139.269915]  RSP <ffff88001b633d70>
      [  139.269915] CR2: 0000000000000004
      [  140.946406] ---[ end trace ba486328b98d7622 ]---
      Signed-off-by: NDitang Chen <chendt.fnst@cn.fujitsu.com>
      Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
      2ca310fc
  21. 07 3月, 2014 2 次提交
  22. 06 3月, 2014 2 次提交
  23. 24 2月, 2014 1 次提交
  24. 22 2月, 2014 3 次提交