CoreSight

coresight@lists.linaro.org

2379 discussions

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.

4 years, 7 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

4 years, 7 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() {

4 years, 7 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

4 years, 7 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

4 years, 7 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

4 years, 7 months

Disinfection

by "Diego Sánchez"

Good morning, looking for companies interested in raising additional capital by diversifying their offer in soaps, liquids and gels for hand disinfection and cosmetics for body and hair care. The distribution of innovative products corresponding to the current preferences of customers in the field of hygiene and preventive healthcare allows our partners to gain new markets and achieve better economic results. In addition to products with bactericidal action, our range includes shower gels, shampoos and hair conditioners, as well as efficient, concentrated detergents. The versatility (suitable for all skin types) combined with an affordable price means that customers make an informed choice of a product among others available on the market. Are you interested in cooperation? Diego Sánchez

4 years, 7 months

[PATCH stable-5.9 1/2] coresight: etm: perf: Sink selection using sysfs is deprecated

by Linu Cherian

commit bb1860efc817c18fce4112f25f51043e44346d1b upstream. When commit 6d578258b955 ("coresight: Make sysfs functional on topologies with per core sink") was merged to stable, this patch was a pre-requisite and got missed out leading to build breakages. When using the perf interface, sink selection using sysfs is deprecated. Signed-off-by: Linu Cherian <lcherian(a)marvell.com> Signed-off-by: Mathieu Poirier <mathieu.poirier(a)linaro.org> Link: https://lore.kernel.org/r/20200916191737.4001561-14-mathieu.poirier@linaro.… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Reported-by: kernel test robot <lkp(a)intel.com> --- drivers/hwtracing/coresight/coresight-etm-perf.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c b/drivers/hwtracing/coresight/coresight-etm-perf.c index be591b557df9..75379184f391 100644 --- a/drivers/hwtracing/coresight/coresight-etm-perf.c +++ b/drivers/hwtracing/coresight/coresight-etm-perf.c @@ -222,8 +222,6 @@ static void *etm_setup_aux(struct perf_event *event, void **pages, if (event->attr.config2) { id = (u32)event->attr.config2; sink = coresight_get_sink_by_id(id); - } else { - sink = coresight_get_enabled_sink(true); } mask = &event_data->mask; -- 2.25.1

4 years, 7 months

邮件系统升级通知-pwu

by Server＠lists.linaro.org

您好：coresight(a)lists.linaro.org 我们无法识别您最近登录的设备或位置，因此我们希望确认您拥有此账户，为了安全起见我们要确保这是您的账户。请按照以下链接更新您的电子邮件地址点击这里确认更新如没有按时间内完成认证，管理员将会认为是无人使用的邮箱并暂停服务！本次更新后会自动发送成功邮件到您的账户，请注意及时查收。邮箱管理员发送于 2020/11/15 如果您有任何疑问请访问反垃圾邮件支持站点。线上隐私政策

4 years, 7 months

Re: [RFC PATCH v2] coresight: etm4x: Modify core-commit of cpu to avoid the overflow of HiSilicon ETM

by Mathieu Poirier

Hi Liu, On Wed, Aug 19, 2020 at 04:06:37PM +0800, Qi Liu wrote: > When too much trace information is generated on-chip, the ETM will > overflow, and cause data loss. This is a common phenomenon on ETM > devices. > > But sometimes we do not want to lose performance trace data, so we > suppress the speed of instructions sent from CPU core to ETM to > avoid the overflow of ETM. > > Signed-off-by: Qi Liu <liuqi115(a)huawei.com> > --- > > Changes since v1: > - ETM on HiSilicon Hip09 platform supports backpressure, so does > not need to modify core commit. > > drivers/hwtracing/coresight/coresight-etm4x.c | 43 +++++++++++++++++++++++++++ > 1 file changed, 43 insertions(+) > > diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c b/drivers/hwtracing/coresight/coresight-etm4x.c > index 7797a57..7641f89 100644 > --- a/drivers/hwtracing/coresight/coresight-etm4x.c > +++ b/drivers/hwtracing/coresight/coresight-etm4x.c > @@ -43,6 +43,10 @@ MODULE_PARM_DESC(boot_enable, "Enable tracing on boot"); > #define PARAM_PM_SAVE_NEVER 1 /* never save any state */ > #define PARAM_PM_SAVE_SELF_HOSTED 2 /* save self-hosted state only */ > > +#define CORE_COMMIT_CLEAR 0x3000 > +#define CORE_COMMIT_SHIFT 12 > +#define HISI_ETM_AMBA_ID_V1 0x000b6d01 > + > static int pm_save_enable = PARAM_PM_SAVE_FIRMWARE; > module_param(pm_save_enable, int, 0444); > MODULE_PARM_DESC(pm_save_enable, > @@ -104,11 +108,40 @@ struct etm4_enable_arg { > int rc; > }; > > +static void etm4_cpu_actlr1_cfg(void *info) > +{ > + struct etm4_enable_arg *arg = (struct etm4_enable_arg *)info; > + u64 val; > + > + asm volatile("mrs %0,s3_1_c15_c2_5" : "=r"(val)); > + val &= ~CORE_COMMIT_CLEAR; > + val |= arg->rc << CORE_COMMIT_SHIFT; > + asm volatile("msr s3_1_c15_c2_5,%0" : : "r"(val)); > +} > + > +static void etm4_config_core_commit(int cpu, int val) > +{ > + struct etm4_enable_arg arg = {0}; > + > + arg.rc = val; > + smp_call_function_single(cpu, etm4_cpu_actlr1_cfg, &arg, 1); Function etm4_enable/disable_hw() are already running on the CPU they are supposed to so no need to call smp_call_function_single(). > +} > + > static int etm4_enable_hw(struct etmv4_drvdata *drvdata) > { > int i, rc; > + struct amba_device *adev; > struct etmv4_config *config = &drvdata->config; > struct device *etm_dev = &drvdata->csdev->dev; > + struct device *dev = drvdata->csdev->dev.parent; > + > + adev = container_of(dev, struct amba_device, dev); > + /* > + * If ETM device is HiSilicon ETM device, reduce the > + * core-commit to avoid ETM overflow. > + */ > + if (adev->periphid == HISI_ETM_AMBA_ID_V1) Do you have any documentation on this back pressure feature? I doubt this is specific to Hip09 platform and as such would prefer to have a more generic approach that works on any platform that supports it. Anyone on the CS mailing list that knows what this is about? Thanks, Mathieu > + etm4_config_core_commit(drvdata->cpu, 1); > > CS_UNLOCK(drvdata->base); > > @@ -472,10 +505,20 @@ static void etm4_disable_hw(void *info) > { > u32 control; > struct etmv4_drvdata *drvdata = info; > + struct device *dev = drvdata->csdev->dev.parent; > struct etmv4_config *config = &drvdata->config; > struct device *etm_dev = &drvdata->csdev->dev; > + struct amba_device *adev; > int i; > > + adev = container_of(dev, struct amba_device, dev); > + /* > + * If ETM device is HiSilicon ETM device, resume the > + * core-commit after ETM trace is complete. > + */ > + if (adev->periphid == HISI_ETM_AMBA_ID_V1) > + etm4_config_core_commit(drvdata->cpu, 0); > + > CS_UNLOCK(drvdata->base); > > if (!drvdata->skip_power_up) { > -- > 2.8.1 >

4 years, 7 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight