Re: [PATCH] perf report: fix event name reporting
Hi,
On Fri, 8 Jun 2012 16:23:27 +0400, Dmitry Antipov wrote:
> Use trace_find_event to find event name before looking through
> /sys files. This helps 'perf report' to show real event names
> instead of 'unknown:unknown' when processing perf.data recorded
> on another machine.
>
Right, it should be a default action for a tracepoint event IMHO. (But
this patch doesn't check it's a tracepoint) There are a lot of places
call event_name() to be converted like this, so I suggest changing
event_name itself (or recent perf_evsel__name() ?) instead of just a
call-site. It might require checking whether the pevent is initialized
and if not, falls back to the sysfs walking.
Thanks,
Namhyung
> Signed-off-by: Dmitry Antipov
> ---
> tools/perf/builtin-report.c |4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
> index 8c767c6..a6fd309 100644
> --- a/tools/perf/builtin-report.c
> +++ b/tools/perf/builtin-report.c
> @@ -24,6 +24,7 @@
> #include "util/evlist.h"
> #include "util/evsel.h"
> #include "util/header.h"
> +#include "util/trace-event.h"
> #include "util/session.h"
> #include "util/tool.h"
>
> @@ -314,7 +315,8 @@ static int perf_evlist__tty_browse_hists(struct
> perf_evlist *evlist,
>
> list_for_each_entry(pos, &evlist->entries, node) {
> struct hists *hists = &pos->hists;
> - const char *evname = event_name(pos);
> + struct event_format *event = trace_find_event(pos->attr.config);
> + const char *evname = event ? event->name : event_name(pos);
>
> hists__fprintf_nr_sample_events(hists, evname, stdout);
> hists__fprintf(hists, NULL, false, true, 0, 0, stdout);
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Call for topics for the 12.06 linux-linaro* trees
On 06/08/2012 07:30 PM, Andy Green wrote: > On 06/08/2012 08:25 PM, the mail apparently from Andrey Konovalov included: >> Greetings, >> >> There will be three linux-linaro trees this month. Also some LTs have >> moved to 3.5, while the others will stay on older kernels. >> >> In addition to linux-linaro-core-tracking and linux-linaro ones >> (described under >> https://wiki.linaro.org/Platform/DevPlatform/LinuxLinaroKernelTreeProcess), >> >> linux-linaro-tracking tree will be created as a merge of the tracking >> trees of TI (v3.4 based) and Samsung (currently v3.4-rc7 based) LTs. > I would be publishing 3.4 based Samsung Kernel today. So, you can use that in linux-linaro-tracking. > For reference the TI + Samsung trees I did during Connect can be found > here: > > http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git;a=shortlog;h=refs/heads/unify-samsung-ti > > > This builds and works for OMAP at least. > >> Probably more LT tracking trees would be added, but I am not sure due to >> the different bases the others use. Each LT's tracking tree act as a >> topic here, so the call for topics doesn't apply to this tree. >> >> linux-linaro-core-tracking tree is moving to 3.5 (but not published at >> git.linaro.org yet). For those using the 3.4, llct_3.4 branch has been >> created. This is a copy of the most recent v3.4 based >> linux-linaro-core-tracking tree. >> *New generic (not board specific) topics and updates to the existing >> topics are welcomed for the 3.5 based linux-linaro-core-tracking tree* >> The requirements for a topic can be found here: >> https://wiki.linaro.org/Platform/DevPlatform/LinuxLinaroKernelTreeProcess#Adding_a_topic_to_linux-linaro_kernel_and_maintaining_it >> >> >> The current topics are: >> * arm_soc/testing/multiplatform >> * svenkatr/ufs-for-linux-linaro >> * svenkatr/emmc-for-linux-linaro >> * amitdanielk/thermal_exynos4_imx6_work > > Not sure if this will now already have it, but this patch > > http://www.mail-archive.com/linux-omap@vger.kernel.org/msg63852.html > > is important for OMAP... thanks to Tushar for digging up the context of > it for us. We're carrying a replica of it in our tracking atm but since > what was > > tracking-thermal_exynos4_imx6-3.4-2012.05 > > had just one of the pair of patches in older llct, it should be improved > to have both, if it doesn't already with this update. > > -Andy > -- Tushar Behera ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: android-3.4 ... / Audit of OOT android code
On 06/10/2012 05:53 PM, the mail apparently from Andy Green included: These are the suspicious things I found from the diff between linaro-android-3.4 (from http://git.linaro.org/gitweb?p=people/jstultz/android.git;a=shortlog;h=refs/heads/linaro-android-3.4 at HEAD 8674fd7a65aeff35c3879cf0d56e78c93ee62e2c) vs v3.4. Some are clear cut and others change code I don't really understand, but others on this list will. I noticed while making patches for these that the basis for the diff was upstream/android-3.4 instead of linaro-android-3.4 I thought I was using. Studying the diff between those two, I see there are already changes addressing some of these problems. 1) drivers/input/evdev.c: adds wakelock code not dependent on ANDROID *** need discussion *** Wakelocks got changed in their include file to generate empty structs and apis in case CONFIG_WAKELOCK is not defined. That solves the wakelock part of 16, 17, 18. 16 introduces a flag in mmc code, I am not sure if nulling out the wakelock code but leaving the flag is the same as not having the flag. 3) add net/activity_stats.c contingent on NET_ACTIVITY_STATS *** BUG *** default y fixed 4) net/Kconfig: add ANDROID_PARANOID_NETWORK *** BUG *** default Y: needs changing fixed > 8) kernel/power/Kconfig: ***BUG*** HAS_WAKELOCK, WAKELOCK, > USER_WAKELOCK all introduced as default y fixed The debug_ll printk problem is also solved. > 13) drivers/char/Kconfig: Add DEVMEM *** BUG *** default y ; add > DCC_TTY (harmless) fixed That leaves the following: > 2) *** BUG *** changes net/wireless/scan.c not protected by > CFG80211_ALLOW_RECONNECT: IEEE80211_SCAN_RESULT_EXPIRE reduced to 3s > from 15s whether configured or not > 5) mm/page_alloc.c: replace constant of 1 with filescope int min_free_order_shift defaults to 1 but changeable from sysctl *** Needs comment *** 6) fs/proc.c: add support for Android-specific OOM adjust interface... ***BUG*** should be contingent on CONFIG_ANDROID or the ANDROID OOM config 7) kernel/cgroup.c: adds a "queue of wairer to do rmdir() cgroup", removes most content from free_css_set_work(), screws with much else in there, no idea if that makes cgroups better or worse, but the changes are not contingent on anything *** needs discussion *** 9) kernel/printk.c: *** BUG? *** unconditionally remove CPU_DYING notification from console_cpu_notify, log_buf_get_len, log_buf_clear, log_buf_copy apis added 10) kernel/sched/core.c: __might_sleep_init_called flag introduction (harmless) change __might_sleep processing *** Needs checking ***; add allow_attach cgroup api callback, if not same task actig on itself then confirm CAP_SYS_NICE, or effective uid is suid (seems good); only requeue task if any "ancestors" are the one element in queue as well as if it's just us (seems good) 11) kernel/sysctl.c: add min_order_free_shift change (pagealloc.c) interface *** Needs comment *** 12) drivers/base/power/main.c: add driver suspend / resume timeout concept, no driver may take more than 12s suspending or BUG(), not dependent on any CONFIG_ probably benficial but *** Needs discussion *** 14) drivers/cpuidle/governors/menu.c: remove scaling formula "mult += 2 * get_loadavg();" *** needs discussion *** 15) drivers/mmc/card/block.c: change computation in mmc_get_devidx() *** needs discussion ***; add pr_err if r/w command fails or we abort, harmless; deferred resume implementation properly protected by config, harmless; set md->disk->flags to GENHD_FL_EXT_DEVT *** needs discussion *** 16) drivers/mmc/core/core.c: mmc_resume_bus() introduction; extend wakelock flag, other unconditonal changes *** needs discussion *** 17) drivers/mmc/core/host.c:adds pm_notifier if not flagged MMC_PM_IGNORE_PM_NOTIFY *** needs discussion *** 18) drivers/power/power_supply_core.c: change power_supply_changed() processing *** needs discussion *** 19) arch/arm/boot/compressed/head.S: wrap older chip IDs from colliding with v7 *** needs discussion *** 20) arch/arm/include/asm/hardware/coresight.h: various lowlevel io changes *** need discussion *** 21) arch/arm/include/asm/mach/mmc.h: extra stuff for embedded_sdio_data, declares mmc_platform_data ??? *** needs discussion *** 22) arch/arm/kernel/etm.c: mass changes, no idea *** needs discussion *** 23) arch/arm/mm/cache-l2x0.c: add sets and ways count, service CONFIG_PL310_ERRATA_727915, two magic debug_writel *** needs discussion *** 24) arch/arm/mm/cache-v6.S: support CONFIG_CACHE_FLUSH_RANGE_LIMIT *** needs discussion *** 25) arch/arm/mm/mmu.c: simplify early_pte_alloc() args, add force_pages to alloc_init_pud(), more changes *** needs discussion *** 26) arch/arm/vfp/entry.S: thumb2 code added *** needs discussion *** 27) arch/arm/vfp/vfpmodule.c: add SMP code *** needs discussion *** 28) linux/amba/mmci.h: hmmm also defines s
Kernel not booting with Linaro GCC?
There's an interaction between Linaro GCC or FSF GCC 4.7 and Linux kernels before 3.2 which causes the kernel to halt straight after showing 'Uncompressing Linux'. The question comes up every couple of months so I've blogged about it: http://seabright.co.nz/2012/06/11/kernel-not-booting-with-linaro-gcc/ """ Is your ARM Linux kernel not booting when building with Linaro GCC or FSF GCC 4.7? Does it halt shortly after showing ‘Uncompressing Linux’? You may have run into an interaction between older kernels and the new unaligned access support in GCC. This affects Linaro GCC from 4.6-2011.11 onwards, GCC from 4.7.0 on, and kernels earlier than 3.2 including the Galaxy Nexus Icecream Sandwich release. The work-around is to add -mno-unaligned-access to KBUILD_CFLAGS in the top level kernel Makefile or to backport 8428e84d42179c2a00f5f6450866e70d802d1d05 from the current kernel tree. ARMv6K and later processors have hardware support for doing unaligned loads and stores which is faster than the old byte-by-byte/recombine that was done in software. Later versions of GCC use this to do quicker loads when working on known unaligned data, such as when working on a protocol buffer or a packed structure. The CPU can be configured to trap on unaligned access. This trap is off at reset, but pre 3.2 kernels turn this on during the initial boot. An interaction between -fconserve-stack and -munaligned-access on a char buffer lead to an unaligned access, which causes a trap, which causes the kernel to halt. This does not affect userspace programs as they run with the trap turned off. """ -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Raspberry pi - Linaro builds
On 10 June 2012 09:24, Anoop CH wrote: > Hi, > Thank you for your work on the dev boards. Recently i had been working with > Android. Your work saved a lot of time for me. > > I request you to also consider support the raspberry pi board. Which is > quite useful for many people. Enduses as well as devs.. Hi there. We're focused on the Cortex-A series and aren't actively working on ARMv6 devices like the Raspberry Pi. There's a good community building up around the Pi - you might want to try stock Debian or the ARMv6 hard float rebuild, Raspbian. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
