CoreSight

coresight@lists.linaro.org

4 participants
2643 discussions

[PATCH] MAINTAINERS: Adding help for coresight subsystem

by Mathieu Poirier

With the steady stream of new features coming into the subsystem it has been clear for some time now that help is needed. Suzuki and Leo have worked extensively on various parts of the project and have agreed to help. While at it add the new location for the coresight git tree. Signed-off-by: Mathieu Poirier <mathieu.poirier(a)linaro.org> --- MAINTAINERS | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index e73636b75f29..8d0b008c7781 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1723,11 +1723,13 @@ F: arch/arm/mach-ep93xx/micro9.c ARM/CORESIGHT FRAMEWORK AND DRIVERS M: Mathieu Poirier <mathieu.poirier(a)linaro.org> -R: Suzuki K Poulose <suzuki.poulose(a)arm.com> +M: Suzuki K Poulose <suzuki.poulose(a)arm.com> R: Mike Leach <mike.leach(a)linaro.org> +R: Leo Yan <leo.yan(a)linaro.org> L: coresight(a)lists.linaro.org (moderated for non-subscribers) L: linux-arm-kernel(a)lists.infradead.org (moderated for non-subscribers) S: Maintained +T: git git://git.kernel.org/pub/scm/linux/kernel/git/coresight/linux.git F: Documentation/ABI/testing/sysfs-bus-coresight-devices-* F: Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt F: Documentation/devicetree/bindings/arm/coresight-cti.yaml -- 2.25.1

5 years, 3 months

New PPE Stock

by Tony FB

Hi There, Hope you are staying safe and well. Just wanted to update you about items we added to the PPE list: We have stock in Los Angeles, Ready to ship today: 01. N95 - Niosh Approved - CDC List (Makrite) 02. Nitrile Gloves 03. KN95 - CDC list 04. Face Shield 05. Infrared Thermometer 06. Wet Wipes 07. Isolation Gowns 08. Hand Sanitizer 09. Shoe and Head Cover 10. 3Ply Masks We are FDA approved and also PPAI / SAGE supplier. Let me know what you are looking for and what quantity so we can get the shipment going for you. Thanks and Regards, -- Tony FB 310 800 6438 8Health by Dioz Group You may unsubscribe <http://ec2-52-26-194-35.us-west-2.compute.amazonaws.com/x/u?u=cfdafefb-8f41…> to stop receiving our emails.

5 years, 3 months

PERF_RECORD_AUXTRACE_INFO problems

by Al Grant

Hi, I've encountered a perf.data file whose PERF_RECORD_AUXTRACE_INFO has an additional ETM register per CPU (i.e. the metadata for each CPU is 8 bytes longer than normal). Some patch somewhere must be adding this register for reasons unknown. Upstream perf won't even print this file, it reports failure to process record type 70 and errors out. The metadata reading code in util/cs-etm.c expects exactly CS_ETMV4_PRIV_MAX registers, no more. I.e. it won't go skipping past extra ones to find the next "magic" number. It's unfortunate that "perf report -D" errors out, when the reason for using -D may be to investigate why perf in general isn't working. I want to fix this at least. Now firstly, has anyone got any ideas why there might be an additional register, does anyone know of a patch that does this? And secondly, could/should we make the metadata format more robust? Cases of more or fewer registers than expected can, to some extent, be handled by looking for the magic number, but that assumes that registers don't legitimately have values equal to the magic number. The version number could help us evolve upstream to a new format but it isn't really an answer to robust interchange in general. Should we at least have the metadata describe its own length (i.e. number of registers) so that perf tools can read it, even if they might not be able to fully understand it. Al

5 years, 3 months

Private Label (Clothing)

by Jeff FB

Hello, Who can I speak to about branding and custom apparel for your brand? One of the largest custom clothing manufacturer, our office is in London, Sydney, HQ in Beverly Hills, California. We currently work with some top brands and companies worldwide and would love to discuss your branding and custom clothing with you. If you can direct me in the right direction, I would truly appreciate that, as we are factory direct and can save you 30% cost on your bills. Items we manufacture: - T-Shirts - Hoodies - Jackets - Activewear - Towels - Bags, clutches, and pouches - Hats - Promotional items - Custom Cotton Masks - Sublimated Apparel - Sports Uniform We are very creative, innovative, and offer you a full design team and direct factory. We will do everything right, and provide amazing quality at competitive prices which can be very effective for your brand development and growth. Let me know if you have a moment to discuss this. I can also get some designs done for you. Our MOQ is 500 pcs per style, multiple sizes. Let me know your thoughts Thanks and stay safe, -- Jeff FB | Director of Marketing Dioz Group | Oasis Apparel | Alanic | PPE KITS | Clean Health USA HQ: Beverly Hills, CA 90211, USA Email: joe(a)oasisapparelusa.com Website: https://oasisapparel.com/ You may unsubscribe <http://ec2-52-26-194-35.us-west-2.compute.amazonaws.com/x/u?u=74d8b53f-6635…> to stop receiving our emails.

5 years, 3 months

May I humbly solicit your confidence in this transaction,

by dorathygaby＠gmail.com

Je vous ai invité à remplir le formulaire suivant : Formulaire sans titre Pour remplir ce formulaire, consultez : https://docs.google.com/forms/d/e/1FAIpQLSdkPaVLRqC8uiMrQKKxvJTaTbKOCbyZ7eh… From Mrs. Dorathy Gaby Abidjan- Cote D'Ivoire May I humbly solicit your confidence in this transaction, as being utterly confidential and top secret. But I am assuring you that you shall be very happy at the end of the day. I decided to contact you due to the urgency of this transaction, as I wish to repose my trust and confidence on your discreteness and ability in transaction of this nature. Let me start by introducing my self properly to you, my name is Mrs. Dorathy Gaby, I am the regional Bank Manager of BOA Bank Abidjan-Cote D' Ivoire. I came to know about you in my Private Search for a reliable and reputable foreigner to handle this Confidential Transaction. As the regional Bank Manager of BOA BANK; it is my duty to send a financial report to my head office at the end of each year. On the course of the 2012 year report, We discovered an excess profit of Fifteen Million Us Dollars , [ $ 15,000,000.00 ] which we have kept in SUSPENSE ACCOUNT without any beneficiary. As an officer of the bank I can not be directly connected to this Fund for Security Reasons, that is why I am contacting you for us to work together to get the said Fund into your bank account for INVESTMENT in your Country. The percentage Ratio is thus: 40% for you , 60 % for me and my colleagues . Note: There are practically no risks involved in this transaction as it is 100% risk free and will be legally bonded, it will be bank to bank transfer, all I need from you is to stand as the next of kin / Beneficiary to the original depositor of this fund who made the deposit with Kumasi branch so that my Head office can order the transfer to your designated bank account. If you accept this offer to work with me, if you find this proposal suitable for you, kindly reply for full details Via email: dorathygaby3(a)yahoo.co.jp, I will appreciate it very much, If this proposal is acceptable by you, do not make undue advantage of the trust I have bestowed on you, and I assure you that we shall achieve it successfully. Best regards, Mrs. Dorathy Gaby. Google Forms vous permet de créer des enquêtes et d'en analyser les résultats.

5 years, 3 months

[PATCH] coresight: tmc-etr: Check if page is valid before dma_map_page()

by Sai Prakash Ranjan

From: Mao Jinlong <jinlmao(a)codeaurora.org> alloc_pages_node() return should be checked before calling dma_map_page() to make sure that valid page is mapped or else it can lead to aborts as below: Unable to handle kernel paging request at virtual address ffffffc008000000 Mem abort info: <snip>... pc : __dma_inv_area+0x40/0x58 lr : dma_direct_map_page+0xd8/0x1c8 Call trace: __dma_inv_area tmc_pages_alloc tmc_alloc_data_pages tmc_alloc_sg_table tmc_init_etr_sg_table tmc_alloc_etr_buf tmc_enable_etr_sink_sysfs tmc_enable_etr_sink coresight_enable_path coresight_enable enable_source_store dev_attr_store sysfs_kf_write Fixes: 99443ea19e8b ("coresight: Add generic TMC sg table framework") Cc: stable(a)vger.kernel.org Signed-off-by: Mao Jinlong <jinlmao(a)codeaurora.org> Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan(a)codeaurora.org> --- drivers/hwtracing/coresight/coresight-tmc-etr.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c b/drivers/hwtracing/coresight/coresight-tmc-etr.c index 525f0ecc129c..a31a4d7ae25e 100644 --- a/drivers/hwtracing/coresight/coresight-tmc-etr.c +++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c @@ -217,6 +217,8 @@ static int tmc_pages_alloc(struct tmc_pages *tmc_pages, } else { page = alloc_pages_node(node, GFP_KERNEL | __GFP_ZERO, 0); + if (!page) + goto err; } paddr = dma_map_page(real_dev, page, 0, PAGE_SIZE, dir); if (dma_mapping_error(real_dev, paddr)) base-commit: c04e5d7bbf6f92a346d6b36770705e7f034df42d -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

5 years, 3 months

FAILED: patch "[PATCH] perf test: Update branch sample pattern for cs-etm" failed to apply to 5.9-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.9-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From dd94ac807a5e10e0b25b68397c473276905cca73 Mon Sep 17 00:00:00 2001 From: Leo Yan <leo.yan(a)linaro.org> Date: Tue, 10 Nov 2020 14:34:17 +0800 Subject: [PATCH] perf test: Update branch sample pattern for cs-etm Since the commit 943b69ac1884 ("perf parse-events: Set exclude_guest=1 for user-space counting"), 'exclude_guest=1' is set for user-space counting; and the branch sample's modifier has been altered, the sample event name has been changed from "branches:u:" to "branches:uH:", which gives out info for "user-space and host counting". But the cs-etm testing's regular expression cannot match the updated branch sample event and leads to test failure. This patch updates the branch sample pattern by using a more flexible expression '.*' to match branch sample's modifiers, so that allows the testing to work as expected. Fixes: 943b69ac1884 ("perf parse-events: Set exclude_guest=1 for user-space counting") Signed-off-by: Leo Yan <leo.yan(a)linaro.org> Reviewed-by: Mathieu Poirier <mathieu.poirier(a)linaro.org> Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com> Cc: Jin Yao <yao.jin(a)linux.intel.com> Cc: Jiri Olsa <jolsa(a)redhat.com> Cc: Mark Rutland <mark.rutland(a)arm.com> Cc: Mike Leach <mike.leach(a)linaro.org> Cc: Namhyung Kim <namhyung(a)kernel.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Suzuki Poulouse <suzuki.poulose(a)arm.com> Cc: coresight ml <coresight(a)lists.linaro.org> Cc: stable(a)kernel.org Link: http://lore.kernel.org/lkml/20201110063417.14467-2-leo.yan@linaro.org Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com> diff --git a/tools/perf/tests/shell/test_arm_coresight.sh b/tools/perf/tests/shell/test_arm_coresight.sh index 59d847d4981d..18fde2f179cd 100755 --- a/tools/perf/tests/shell/test_arm_coresight.sh +++ b/tools/perf/tests/shell/test_arm_coresight.sh @@ -44,7 +44,7 @@ perf_script_branch_samples() { # touch 6512 1 branches:u: ffffb22082e0 strcmp+0xa0 (/lib/aarch64-linux-gnu/ld-2.27.so) # touch 6512 1 branches:u: ffffb2208320 strcmp+0xe0 (/lib/aarch64-linux-gnu/ld-2.27.so) perf script -F,-time -i ${perfdata} | \ - egrep " +$1 +[0-9]+ .* +branches:([u|k]:)? +" + egrep " +$1 +[0-9]+ .* +branches:(.*:)? +" } perf_report_branch_samples() {

5 years, 3 months

Amazon.co.jp にご登録のアカウント（名前、パスワード、その他個人情報）の確認

by Amazon.co.jp

Аmazon お客様 coresight(a)lists.linaro.org АmaNRHR72507zon に登録いただいたNRHR498398お客様に、АmaNRHR454510zon アカウントの情報更NRHR334071新をお届けします。残念NRHR74249ながら、АmNRHR380007azoNRHR81514n のアカウントをNRHR162061更新できませんNRHR172347でした。今回は、カードが期限NRHR145386切れになってるか、請求NRHR246141先住所が変NRHR472650更されたなど、さまNRHR422979ざまな理由でカーNRHR139367ドの情報を更NRHR236657新できませNRHR93084んでした。アカウント情報のNRHR462211一部が誤っている故NRHR191117に、お客様のアNRHR488406カウントをNRHR168138維持するためNRHR198073 АmaNRHR23651zon アカウンNRHR399556トの情報を確認すNRHR423130る必要があります。下かNRHR250962らアカウントをログイNRHR504492ンし、情報を更NRHR352548新してください。 Аmazon ログインなお、24時NRHR184179間以内にご確NRHR461107認がない場合、誠に申しNRHR480472訳ございません、おNRHR27040客様の安全の為、アカNRHR276505ウントの利用制限をさNRHR161874せていただきますNRHR342165ので、予NRHR442884めご了NRHR478164承ください。アカウNRHR374716ントに登録NRHR499963のEメールアNRHR506726ドレスにアクセスでNRHR459830きない場合お問い合わせ： Amazonカスタマーサービス。お知らせ: パスワードは誰にNRHR339633も教えないNRHR454169でください。個人情NRHR335287報と関係がなNRHR237568く、推測しにくいNRHR153367パスワードを作NRHR98117成してください。大文字とNRHR308251小文字、数字、およびNRHR232964記号を必ずNRHR39001使用してください。オンライNRHR305613ンアカウントNRHR124574ごとに、異なるパNRHR13273スワードをNRHR239673使NRHR507050用してください。どうぞよろNRHR525160しくお願いいたNRHR251843します。 Аmazon

5 years, 3 months

[RFC] cycle threshold

by Al Grant

Hi, When using the /cycacc=1/ option the cycle-counting threshold (setting the minimum gap between cycle packets) is set to a default of 256, which is very high and gives poor cycle resolution. Cores can manage far better than this (single digits, if not 1). The threshold can be set lower via sysfs, but it's capped by an ID register which has a (CPU-specific) minimum possible value. Unfortunately on some widely used cores this ID register incorrectly reports 0x100 i.e. 256. The intended value for these cores is 0b100 i.e. 4. The default threshold is rather high and means we don't get as much value out of this feature as we could. In fact, we typically get timestamp packets more often than we get cycle count packets (timestamp packets also have cycle counts, but take up more space in the trace, so it's not the best way to get high resolution cycle counting). The effect of writing a threshold value below what the ID register says, is architecturally unpredictable. So it's not something we can do generally. What I would suggest as the way forward is to: - set the default lower - cap it against the value in the ID register (i.e. the default might be 10, but if the ID register on a given core says 20, program the ETM to 20) - add an event parameter to set the threshold: -e cs_etm/cycacc=1,cycthreshold=10/ - add a 1-bit event parameter to override the checking of the ID register: -e cs_etm/cycacc=1,cycthreshold=10,cycoverride=1/ We could use the CPU errata mechanism to work around the incorrect ID register, but it seems overkill in this case. I'd suggest a default of 8 for the threshold, and 10 bits for the cycthreshold event parameter. If anyone has other ideas, please say. Al

5 years, 3 months

[RFC PATCH] perf session: Fixup timestamp for ordered events

by Leo Yan

Perf tool relies on MMAP/MMAP2 events to prepare DSO maps, it allocates DSO maps for MMAP/MMAP2 events which is used for parsing symbol. Thus, during the recording, perf tool implictly expects the MMAP/MMAP2 events should arrive before AUX event, in other words, MMAP/MMAP2's timestamp should less than AUX event's timestamp, and the MMAP/MMAP2 events will be added into the front of ordered event list; this can allow the DSO maps to be prepared and can be consumed when process AUX event. See the function perf_evlist__prepare_workload(), though it uses pipes to handshake before perf process (the parent process) and forked process for the profiled program, it cannot promise the timing between MMAP/MMAP2 events and AUX event. On Arm Juno board, the AUX event can be observed to arrive ahead than MMAP2 event, with the command: perf record -e cs_etm/@tmc_etr0/ -S -- dd if=/dev/zero of=/dev/null The follow diagram depicts the flow for how the AUX event is arriving ahead than MMAP2 event: T1: T3: T4: perf process Open PMU device Perf is scheduled out; invoke perf_aux_output_end() and generate AUX event ^ ^ ^ | | | CPU0 ---------------------------------------------------> (T) \ \ Forked process is placed on another CPU V CPU1 ---------------------------------------------------> (T) | | V V T2: T5: Invoke execvp() for profiled Record MMAP2 event program In this scenario, the perf main process runs on CPU0 and the profiled program (which is forked child process) runs on CPU1. The main process opens PMU device for AUX trace (T3) and it will generate AUX event until the perf process is scheduled out (T4); the profiled program will be launched by execvp() (T2) and later will record MMAP event for memory mapping (T5). Usually, the AUX event will be later than MMAP2 event, but on the Arm Juno platform, it has chance that AUX event occurs prior to MMAP2 event with two reasons: - Arm Juno platform is big.LITTLE architecture, so CPU0 is big CPU and CPU1 is LITTLE CPU, the performance between big CPU and LITTLE CPU is significant, this gives chance for the perf main process to run much faster than the profiled program; - In the kernel, the RT thread (like kernel's CPUFreq thread) has chance to preempt perf main thread, so when the perf main thread is switched out, the AUX event will be generated and it might be early than profiled program's MMAP2 event. To fix this issue, this patch records the first AUX event's timestamp into 'aux_timestamp', if find any MMAP/MMAP2 event is late coming, it fixes up the MMAP/MMAP2 events' timestamp as 'aux_timestamp-1', so the MMAP/MMAP2 event will be inserted into ordered list ahead than AUX event and also will be handled before AUX event. Signed-off-by: Leo Yan <leo.yan(a)linaro.org> --- tools/perf/util/session.c | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c index 098080287c68..1aa54941bf81 100644 --- a/tools/perf/util/session.c +++ b/tools/perf/util/session.c @@ -1753,11 +1753,36 @@ static s64 perf_session__process_event(struct perf_session *session, if (tool->ordered_events) { u64 timestamp = -1ULL; + static u64 aux_timestamp = -1ULL; ret = perf_evlist__parse_sample_timestamp(evlist, event, &timestamp); if (ret && ret != -1) return ret; + /* + * Cache the first AUX event's timestamp into 'aux_timestamp', + * which is used to fixup MMAP/MMAP2's timestamp. + */ + if ((event->header.type == PERF_RECORD_AUX) && + (aux_timestamp == -1ULL)) + aux_timestamp = timestamp; + + /* + * If the AUX event arrives prior to MMAP/MMAP2 events, it's + * possible to have no chance to create DSOs when decode AUX + * trace data, thus the symbol cannot be parsed properly. + * To allow the DSOs are prepared before process AUX event, + * fixup the MMAP/MMAP2 events' timestamp to be prior to any + * AUX event's timestamp, so MMAP/MMAP2 events will be + * handled ahead and the DSO map will be prepared before AUX + * event handling. + */ + if (event->header.type == PERF_RECORD_MMAP2 || + event->header.type == PERF_RECORD_MMAP) { + if (timestamp > aux_timestamp) + timestamp = aux_timestamp - 1; + } + ret = perf_session__queue_event(session, event, timestamp, file_offset); if (ret != -ETIME) return ret; -- 2.17.1

5 years, 3 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight