lkml.org 
[lkml]   [2008]   [Sep]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Reading EeePC900 battery info causes stalls
Steven Rostedt wrote:
> OK, that is probably the known bug you are hitting. Simply disable the
> CONFIG_FTRACE_STARTUP_TEST and you should have the wakeup tracer. The bug
> is with the test, not the tracer, so it should not hurt you.

Thanks - this made the wakeup tracer appear a you said. I have put two
wakeup traces up:

http://sucs.org/~sits/test/eeepc-debug/20080920/latency_trace.txt.gz
http://sucs.org/~sits/test/eeepc-debug/20080920/trace.txt.gz
(each file is around 6Mbytes uncompressed)

Here's a small extract of latency_trace.txt:

> # tracer: wakeup
> #
> wakeup latency trace v1.1.5 on 2.6.27-rc6skw-dirty
> --------------------------------------------------------------------
> latency: 3232905 us, #65620/6180619, CPU#0 | (M:desktop VP:0, KP:0, SP:0 HP:0)
> -----------------
> | task: speaker-test-5074 (uid:1000 nice:0 policy:1 rt_prio:25)
> -----------------
>
> # _------=> CPU#
> # / _-----=> irqs-off
> # | / _----=> need-resched
> # || / _---=> hardirq/softirq
> # ||| / _--=> preempt-depth
> # |||| /
> # ||||| delay
> # cmd pid ||||| time | caller
> # \ / ||||| \ | /
> cat-6743 0.N.. 3198412us : acpi_ut_update_ref_count (acpi_ut_update_object_reference)
> cat-6743 0.N.. 3198413us : acpi_ut_pop_generic_state (acpi_ut_update_object_reference)
> cat-6743 0.N.. 3198413us : acpi_ut_delete_generic_state (acpi_ut_update_object_reference)
> cat-6743 0.N.. 3198414us : acpi_os_release_object (acpi_ut_delete_generic_state)
> cat-6743 0.N.. 3198414us : kmem_cache_free (acpi_os_release_object)
[...]
> cat-6743 0.N.. 3232893us : acpi_ut_create_update_state (acpi_ut_create_update_state_and_push)
> cat-6743 0.N.. 3232893us : acpi_ut_create_generic_state (acpi_ut_create_update_state)
> cat-6743 0.N.. 3232894us : kmem_cache_alloc (acpi_ut_create_generic_state)
> cat-6743 0dN.. 3232895us : __slab_alloc (kmem_cache_alloc)
> cat-6743 0dN.. 3232895us : deactivate_slab (__slab_alloc)
> cat-6743 0.N.. 3232896us+: __alloc_pages_internal (__slab_alloc)
> cat-6743 0d... 3232904us+: marker_probe_cb (schedule)
> cat-6743 0d... 3232905us!: schedule (__cond_resched)
> cat-6743 0.N.. 3198412us : acpi_ut_push_generic_state (acpi_ut_create_update_state_and_push)

Is it intentional that the last event has a time earlier closer to that
of the first event?

--
Sitsofe | http://sucs.org/~sits/


\
 
 \ /
  Last update: 2008-09-20 19:19    [W:0.058 / U:0.916 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site