CoreSight

coresight@lists.linaro.org

4 participants
2387 discussions

Bug report: lockdep warning for CTI probe

by Leo Yan

Hi all, After I enabled kernel configs CONFIG_LOCKDEP and CONFIG_LOCK_STAT on the mainline kernel, the kernel reports warning as below. Read a bit the code, the issue seems is related with the CTI's SysFS attribution: "cti_desc.groups = drvdata->ctidev.con_groups;", which might not initialize properly so cause this warning. [ 5.372901] coresight etm0: CPU0: ETM v4.0 initialized [ 5.376694] coresight etm1: CPU1: ETM v4.0 initialized [ 5.380785] coresight etm2: CPU2: ETM v4.0 initialized [ 5.385851] coresight etm3: CPU3: ETM v4.0 initialized [ 5.389808] BUG: key ffff00000564a798 has not been registered! [ 5.392456] ------------[ cut here ]------------ [ 5.398195] DEBUG_LOCKS_WARN_ON(1) [ 5.398233] WARNING: CPU: 1 PID: 32 at kernel/locking/lockdep.c:4623 lockdep_init_map_waits+0x14c/0x260 [ 5.406149] Modules linked in: [ 5.415411] CPU: 1 PID: 32 Comm: kworker/1:1 Not tainted 5.9.0-12034-gbbe85027ce80 #51 [ 5.418553] Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT) [ 5.426453] Workqueue: events amba_deferred_retry_func [ 5.433299] pstate: 40000005 (nZcv daif -PAN -UAO -TCO BTYPE=--) [ 5.438252] pc : lockdep_init_map_waits+0x14c/0x260 [ 5.444410] lr : lockdep_init_map_waits+0x14c/0x260 [ 5.449007] sp : ffff800012bbb720 [ 5.453862] x29: ffff800012bbb720 x28: ffff00000564a680 [ 5.457342] x27: ffff00000564a780 x26: 0000000000001000 [ 5.462725] x25: 0000000000000000 x24: 0000000000000000 [ 5.468020] x23: ffff00000564a880 x22: 0000000000000000 [ 5.473315] x21: ffff800012a0f000 x20: ffff00000564a798 [ 5.478610] x19: ffff00000564f848 x18: ffffffffffffffff [ 5.483905] x17: 000000000000000e x16: ffff00000396ce91 [ 5.489200] x15: ffff800012231e08 x14: 0720072007200720 [ 5.494496] x13: 0720072007200720 x12: 0720072007200720 [ 5.499790] x11: 0720072007200720 x10: 0720072007200720 [ 5.505085] x9 : 00000035a0335c60 x8 : ffff8000122af890 [ 5.510380] x7 : 0000000000000001 x6 : ffff800012bbb330 [ 5.515676] x5 : 0000000000000000 x4 : ffff00000366d040 [ 5.520971] x3 : ffff800012232000 x2 : 0000000000000000 [ 5.526266] x1 : 8a612923d8958600 x0 : 0000000000000000 [ 5.531561] Call trace: [ 5.536847] lockdep_init_map_waits+0x14c/0x260 [ 5.539027] __kernfs_create_file+0xa8/0x1c8 [ 5.543539] sysfs_add_file_mode_ns+0xd0/0x208 [ 5.548054] internal_create_group+0x118/0x3c8 [ 5.552307] internal_create_groups+0x58/0xb8 [ 5.556733] sysfs_create_groups+0x2c/0x38 [ 5.561160] device_add+0x2d8/0x768 [ 5.565148] device_register+0x28/0x38 [ 5.568537] coresight_register+0xf8/0x320 [ 5.572358] cti_probe+0x1b0/0x3f0 [ 5.576433] amba_probe+0xc0/0x168 [ 5.579820] really_probe+0x118/0x408 [ 5.583207] driver_probe_device+0x5c/0xc0 [ 5.586940] __device_attach_driver+0x98/0xc8 [ 5.590933] bus_for_each_drv+0x80/0xe0 [ 5.595359] __device_attach+0xf4/0x158 [ 5.599006] device_initial_probe+0x24/0x30 [ 5.602825] bus_probe_device+0xa0/0xa8 [ 5.606992] device_add+0x47c/0x768 [ 5.610809] amba_device_try_add+0x1f4/0x310 [ 5.614284] amba_deferred_retry+0x54/0xb8 [ 5.618797] amba_deferred_retry_func+0x14/0x50 [ 5.622706] process_one_work+0x2b8/0x698 [ 5.627130] worker_thread+0x50/0x458 [ 5.631297] kthread+0x11c/0x150 Thanks, Leo

4 years, 8 months

[PATCH] coresight: etm4x: Skip setting LPOVERRIDE bit for qcom, skip-power-up

by Sai Prakash Ranjan

There is a bug on the systems supporting to skip power up (qcom,skip-power-up) where setting LPOVERRIDE bit(low-power state override behaviour) will result in CPU hangs/lockups even on the implementations which supports it. So skip setting the LPOVERRIDE bit for such platforms. Fixes: 02510a5aa78d ("coresight: etm4x: Add support to skip trace unit power up") Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan(a)codeaurora.org> --- drivers/hwtracing/coresight/coresight-etm4x-core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c index abd706b216ac..6096d7abf80d 100644 --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c @@ -779,7 +779,7 @@ static void etm4_init_arch_data(void *info) * LPOVERRIDE, bit[23] implementation supports * low-power state override */ - if (BMVAL(etmidr5, 23, 23)) + if (BMVAL(etmidr5, 23, 23) && (!drvdata->skip_power_up)) drvdata->lpoverride = true; else drvdata->lpoverride = false; base-commit: 3477326277451000bc667dfcc4fd0774c039184c -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

4 years, 8 months

Fwd: Servicio Tributaria - N� (356384)

by Notificacion Pendiente

4 years, 8 months

Arm DevSummit - 2020 Attendees List

by Holly Richard

Hi, I believe that you are one of the Exhibitors of "Arm DevSummit 2020". If you are interested in acquiring the attendees list of "Arm DevSummit 2020" please reply to this email and I shall revert back with pricing, counts. Each record will contain details like Contact Name, Number, Email Address, Company Name, URL, Physical Address, Phone etc.. and you basically get to own these Opt-in contacts. Let us know if you are interested and we will revert back with cost and other deliverables. Thank you and I look forward to hear from you soon. Regards, Holly Richard| Inside Sales, USA & Europe| Email: <mailto:holly@reachattendee.com> holly(a)reachattendee.com "If you don't wish to receive emails from us reply back with LEAVE OUT"

4 years, 8 months

Question about the Coresight ETM4 strobe patch

by Yabin Cui

Hi Mike, I am from the Android toolchain team. We are interested in using the ETM strobe feature in Android kernels. We noticed your patch "coresight: etmv4: Adds initial complex config with ETM4 strobe feature." in https://lists.linaro.org/pipermail/coresight/2020-June/004097.html. We tested it on Pixel devices with Qualcomm chips. It works pretty well. And I have a few questions: 1. The param setting of window and period seems doesn't take effect. Not sure if it is a bug or something I misunderstand. The only place I found moving feat->params to feat->regs is in cs_cfg_reset_feat(). But that function will also reset feat->params to default values in feat_desc->params. So if I write a value to /sys/.../window, it goes to feat->params, but can't change value in feat->regs. I tried a work-around by changing cs_cfg_param_store(): * static ssize_t cs_cfg_param_store(struct device *dev, {* * ... spin_lock(param->feat->dev_spinlock);* * if (!kstrtoull(buf, 0, &val)) {* * param->current_value = val; for (i = 0; i < feat->nr_regs; i++) { reg_desc = &feat_desc->regs[i];* * flags = reg_desc->flags;* * reg = &feat->regs[i];* * if (flags & CS_CFG_REG_VAL_PARAM) {* * if (param == &feat->params[reg_desc->value.val32]) {* * coresight_cfg_init_reg_param(reg, flags, param); }* * }* * }* * }* * spin_unlock(param->feat->dev_spinlock);* * }* 2. Is my understanding below correct? If I set the window param to 1000 and the period param to 10000, then etm will trace the last 1000 cpu cycles of every 10^7 cpu cycles? And since the strobe window/period counters are saved when disabling etm, the counting should continue from the saved value the next time I enable etm. And I should still get etm data even if the traced thread is scheduled off cpu before reaching 10^7 cpu cycles each time. 3. I want to +1 Mathieu's suggestion: *Perf sessions need to be able to choose which feature they want to use rather than defaulting to a system wide configuration.* We use perf sessions to trace ETM data in Android. It's better if we can configure ETM strobe params in the perf interface (like from perf_event_attr or ioctl). And It's better for each perf session to count separately. 4. The last update on the patch is Jun 24. And it seems the patch hasn't been landed in any branch yet. So what's the future plan? We need to wait until it lands to some upstream branches to cherry pick it to Android kernels. So I want to know when it will be ready. Thanks, Yabin

4 years, 9 months

Context id tracing with kernel at EL2

by Al Grant

Hi, this is an incomplete patch for an issue with EL2 kernels, and I'm looking for feedback on how to complete it. The background is that to support tracing multiple address spaces we get ETM to embed the context id in the trace, and we build with CONFIG_PID_IN_CONTEXTIDR to get the scheduler to put the thread id in CONTEXTIDR_EL1. This is a known technique, it's what context id tracing is designed for. The problem is when the kernel is running not at EL1 (OS level) but at EL2 (hypervisor level), which is now becoming common. With HCR_EL2.E2H set, the kernel's writes to CONTEXTIDR_EL1 actually change a different physical register, CONTEXTIDR_EL2. However, ETM still traces CONTEXTIDR_EL1. So the context ids in the trace are zero, and trace cannot be reconstructed. ETM 4.1 has an option VMIDOPT to cause CONTEXTIDR_EL2 to be output in trace, in the VMID field replacing the value of VTTBR.VMID. So we can use that, but the trace follower, collecting events from OpenCSD, needs to be aware it needs to check the VMID field not the CID field. OpenCSD doesn't need to change but perf does. TRCCONFIGR is already in the metadata, so perf consumers can check it to see what's going on. The patch below does the kernel and userspace side but is not complete. The problem is that userspace perf creates the metadata copy of TRCCONFIGR based on its request (and fills in the other id registers by reading sysfs), but the detection of EL2/E2H happens in the kernel which adjusts TRCCONFIGR, and it's this config which is needed for decode. I see three ways round this: - have userspace test to see if the kernel is EL2 (somehow) and adjust the metadata to mirror what the kernel is doing - have the kernel pass the adjusted TRCCONFIGR back so perf can put it in the metadata - have the perf decoder get the thread id from whichever of VMID and CONTEXTID is available in a PE_CONTEXT element Obviously, the last is simplest, but it's a bodge, and means that OpenCSD will see VMIDs when its TRCCONFIGR says it won't. It's kind of cleanest to get the real TRCCONFIGR somehow, but how do we do that? Al diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c b/drivers/hwtracing/coresight/coresight-etm4x.c index a128b5063f46..96488a0cfdcf 100644 --- a/drivers/hwtracing/coresight/coresight-etm4x.c +++ b/drivers/hwtracing/coresight/coresight-etm4x.c @@ -353,8 +353,32 @@ static int etm4_parse_event_config(struct etmv4_drvdata *drvdata, } if (attr->config & BIT(ETM_OPT_CTXTID)) - /* bit[6], Context ID tracing bit */ - config->cfg |= BIT(ETM4_CFG_BIT_CTXTID); + { + /* + * Enable context-id tracing. The assumption is that this + * will work with CONFIG_PID_IN_CONTEXTIDR to trace process + * id changes and support decode of multiple processes. + * But ETM's context id trace traces physical CONTEXTIDR_EL1, + * while the logical CONTEXTIDR_EL1 that is written to on + * process switch is either physical CONTEXTIDR_EL1 or + * CONTEXTIDR_EL2 depending on HCR_EL2.E2H. On principle + * we should continue to use logical CONTEXTIDR_EL1. + * In order to trace physical CONTEXTIDR_EL2, we need to + * enable VMID tracing and use the VMIDOPT flag to trace + * CONTEXTIDR_EL2 rather than VTTBR.VMID in the VMID field. + * Trace decoders will need to inspect TRCCONFIGR and use + * either the CID or the VMID field from the trace packet. + */ + if (!(is_kernel_in_hyp_mode() && + (read_sysreg(hcr_el2) & BIT(34)) != 0)) { + /* bit[6], Context ID tracing bit */ + config->cfg |= BIT(ETM4_CFG_BIT_CTXTID); + } else { + /* bits[7,15], trace CONTEXTID_EL2 in VMID field */ + config->cfg |= (BIT(ETM4_CFG_BIT_VMID) | + BIT(ETM4_CFG_BIT_VMIDOPT)); + } + } /* return stack - enable if selected and supported */ if ((attr->config & BIT(ETM_OPT_RETSTK)) && drvdata->retstack) diff --git a/include/linux/coresight-pmu.h b/include/linux/coresight-pmu.h index b0e35eec6499..c2f47b25daab 100644 --- a/include/linux/coresight-pmu.h +++ b/include/linux/coresight-pmu.h @@ -19,8 +19,10 @@ /* ETMv4 CONFIGR programming bits for the ETM OPTs */ #define ETM4_CFG_BIT_CYCACC 4 #define ETM4_CFG_BIT_CTXTID 6 +#define ETM4_CFG_BIT_VMID 7 #define ETM4_CFG_BIT_TS 11 #define ETM4_CFG_BIT_RETSTK 12 +#define ETM4_CFG_BIT_VMIDOPT 15 static inline int coresight_get_trace_id(int cpu) { diff --git a/tools/include/linux/coresight-pmu.h b/tools/include/linux/coresight-pmu.h index b0e35eec6499..c2f47b25daab 100644 --- a/tools/include/linux/coresight-pmu.h +++ b/tools/include/linux/coresight-pmu.h @@ -19,8 +19,10 @@ /* ETMv4 CONFIGR programming bits for the ETM OPTs */ #define ETM4_CFG_BIT_CYCACC 4 #define ETM4_CFG_BIT_CTXTID 6 +#define ETM4_CFG_BIT_VMID 7 #define ETM4_CFG_BIT_TS 11 #define ETM4_CFG_BIT_RETSTK 12 +#define ETM4_CFG_BIT_VMIDOPT 15 static inline int coresight_get_trace_id(int cpu) { diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c index cd92a99eb89d..a54cad778841 100644 --- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c +++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c @@ -35,6 +35,7 @@ struct cs_etm_decoder { dcd_tree_handle_t dcd_tree; cs_etm_mem_cb_type mem_access; ocsd_datapath_resp_t prev_return; + uint32 thread_id_in_vmid:1; }; static u32 @@ -496,17 +497,24 @@ cs_etm_decoder__buffer_exception_ret(struct cs_etm_packet_queue *queue, static ocsd_datapath_resp_t cs_etm_decoder__set_tid(struct cs_etm_queue *etmq, + struct cs_etm_decoder *decoder, struct cs_etm_packet_queue *packet_queue, const ocsd_generic_trace_elem *elem, const uint8_t trace_chan_id) { pid_t tid; - /* Ignore PE_CONTEXT packets that don't have a valid contextID */ - if (!elem->context.ctxt_id_valid) - return OCSD_RESP_CONT; + if (!decoder->thread_id_in_vmid) { + /* Ignore PE_CONTEXT packets that don't have a valid contextID */ + if (!elem->context.ctxt_id_valid) + return OCSD_RESP_CONT; + tid = elem->context.context_id; + } else { + if (!elem->context.vmid_valid) + return OCSD_RESP_CONT; + tid = elem->context.vmid; + } - tid = elem->context.context_id; if (cs_etm__etmq_set_tid(etmq, tid, trace_chan_id)) return OCSD_RESP_FATAL_SYS_ERR; @@ -561,7 +569,7 @@ static ocsd_datapath_resp_t cs_etm_decoder__gen_trace_elem_printer( trace_chan_id); break; case OCSD_GEN_TRC_ELEM_PE_CONTEXT: - resp = cs_etm_decoder__set_tid(etmq, packet_queue, + resp = cs_etm_decoder__set_tid(etmq, decoder, packet_queue, elem, trace_chan_id); break; case OCSD_GEN_TRC_ELEM_ADDR_NACC: @@ -595,11 +603,15 @@ static int cs_etm_decoder__create_etm_packet_decoder( OCSD_BUILTIN_DCD_ETMV3 : OCSD_BUILTIN_DCD_PTM; trace_config = &config_etmv3; + decoder->thread_id_in_vmid = 0; break; case CS_ETM_PROTO_ETMV4i: cs_etm_decoder__gen_etmv4_config(t_params, &trace_config_etmv4); decoder_name = OCSD_BUILTIN_DCD_ETMV4I; trace_config = &trace_config_etmv4; + /* If VMID and VMIDOPT are set, thread id is in VMID not CID */ + decoder->thread_id_in_vmid = + ((trace_config_etmv4.reg.configr & 0x8080) == 0x8080); break; default: return -1; IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

4 years, 9 months

UPS Invoice Notification

by Invoice-notification＠ups.com

Your new invoice is now available.To view/download your invoice,click on the attached document.For questions about your invoice, or invoice payment, please call (800) 811-1648 Monday through Friday 8:00 am to 9:00 pm Eastern Time.For technical support questions regarding your electronic invoicing, please call 877-289-6418.Thank you for using UPS.This is a post only email; please do not respond to this message.Notice: This email message and all attachments transmitted with it may contain proprietary information intended solely for the use of the addressee. If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by electronic mail at customer.service(a)ups.com and delete this message and all copies and backups thereof. Thank you.

4 years, 9 months

COVID 19: Face Masks & Hand Sanitizer

by Candice Cromwell

[ ]( # ) Hello Dear, We are FDA approved and PPAI - Sage suppliers. We have stock in Los Angeles, Ready to ship today: 1. N95 - Niosh Approved - CDC List (Makrite Brand) 2. KN95 - CDC list (Weini Brand) 3. Face Shield 4. Infrared Thermometer 5. Nitrile Gloves (Medical & Industrial Grade) 6. Isolation Gowns 7. Hand Sanitizers 8. Wet Wipes 9. Vinyl Gloves Please visit our website: www.8health.org We can ship right away from Los Angeles. Thanks and Regards, -- Candice Cromwell 310 596 5555 8Health by Dioz Group of Companies 8health.org HQ: Beverly Hills, California Corporate offices in Australia and U.K [ ]( # ) [ ]( # ) This email was sent to coresight(a)lists.linaro.org You received this email because you are registered with Alanic International [ Unsubscribe here ]( http://r.ppequipment.online/mk/un/XIWBLtiR-gfmOX_VsgI05tOnkcmhLdRZz-dPLS5LS… ) [ ]( http://r.ppequipment.online/mk/cl/f/5e9hZNOMDGwYjNxvKUmqHBkIiX1ti-738CYtOpJ… ) [ ]( # ) © 2020 Alanic International

4 years, 9 months

Invitation to Research Design, SurveyCTO mobile data collection and GIS mapping, Data analysis using NVIVO and STATA training

by FDC Training

4 years, 9 months

E-mails concerning Arm DevSummit attendees

by Forbes, Michael J.

To whom it may concern: I am an attorney writing on behalf of Arm. It has come to Arm’s attention that one or more emails originating from this email address have claimed to offer a database of personal information of Arm DevSummit attendees. Please be advised that Arm strongly believes that such solicitations are unauthorized and may constitute violations of one or more state and/or federal laws. In addition, the use of Arm’s federally registered trademark for CoreSight (U.S. Trademark No. 4930183) as a portion of an email address offering to sell confidential information regarding Arm DevSummit attendees is likely to cause confusion regarding the source of your offer. The use of a registered trademark in a manner that is likely to cause confusion or to deceive is a violation of 15 U.S.C. § 1114, and a trademark registrant may recover damages, including costs and attorneys’ fees, under 15 U.S.C. § 1117. If you contend that you are an authorized custodian of this information and that your e‐mail solicitations are lawful, please provide an explanation. Otherwise, Arm hereby demands that you and any affiliates cease and desist any and all solicitations purporting to offer to sell the personal information of Arm DevSummit attendees. In addition, Arm hereby demands that you and any affiliates cease any use of the CoreSight registered trademark in any manner which falsely suggests a connection between you and Arm or that is likely to cause confusion. Please be advised that Arm intends to explore additional appropriate means to cease this activity, including alerting the U.S. Federal Trade Commission and the Office of the Attorney General of California. Regards, -mjf Michael J. Forbes mforbes(a)reedsmith.com<mailto:mforbes@reedsmith.com> Reed Smith LLP Suite 1700 811 Main Street Houston, TX 77002-6110 Direct 713.469.3864 Fax 713.469.3899 * * * This E-mail, along with any attachments, is considered confidential and may well be legally privileged. If you have received it in error, you are on notice of its status. Please notify us immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person. Thank you for your cooperation. Disclaimer Version RS.US.201.407.01

4 years, 9 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight