Messages in this thread | | | Date | Sat, 20 Sep 2008 18:16:19 +0100 | From | Sitsofe Wheeler <> | Subject | Re: 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/
| |