Hi Suzuki,
On 1/18/2019 5:34 PM, Suzuki K Poulose wrote:
If you would like to use the scatter-gather mode, you must specify it
explicitly. We have had some other boards with broken scatter-gather
mode integration which causes mysterious issues when used. So we have
a white-list approach for
On 1/18/2019 4:50 PM, Pintu Agarwal wrote:
Could you please tell which QCOM SoC this board is based on?
Snapdragon 845 with kernel 4.9.x
I want to know from which subsystem it is triggered:drivers/soc/qcom/
Irqchip driver is "drivers/irqchip/irq-gic-v3.c". The kernel you are
using is
Hi Suzuki,
On 1/18/2019 4:27 PM, Suzuki K Poulose wrote:
If you want to use the scatter-gather mode, you must add
"arm,scatter-gather"
property to the node here.
Have you tested the scatter-gather mode on the chip ? Does that work at
all ?
Note: You could try this by setting a buffer_size
On 1/18/2019 4:18 PM, Pintu Agarwal wrote:
On Fri, Jan 18, 2019 at 3:54 PM Sai Prakash Ranjan
wrote:
Hi Pintu-san,
On 1/18/2019 3:38 PM, Pintu Agarwal wrote:
Hi All,
Currently, I am trying to debug a boot up crash on some qualcomm
snapdragon arm64 board with kernel 4.9.
I could find
Hi Pintu-san,
On 1/18/2019 3:38 PM, Pintu Agarwal wrote:
Hi All,
Currently, I am trying to debug a boot up crash on some qualcomm
snapdragon arm64 board with kernel 4.9.
I could find the cause of the failure, but I am unable to locate from
which subsystem/drivers this is getting triggered.
If
Add coresight components found on Qualcomm SDM845 SoC.
Signed-off-by: Sai Prakash Ranjan
---
This depends on AMBA bus pclk change by Bjorn Andersson [1].
Also depends on patch ("arm64: dts: qcom: sdm845: Increase address
and size cells for soc") [2].
[1]
https://lore.kerne
-etm4x 764.etm: CPU6: ETM v4.2 initialized
[6.705646] coresight-etm4x 774.etm: CPU7: ETM v4.2 initialized
Signed-off-by: Sai Prakash Ranjan
---
drivers/hwtracing/coresight/coresight-etm4x.c | 2 +-
drivers/hwtracing/coresight/coresight-etm4x.h | 2 +-
2 files changed, 2 insertions
Remove the duplicate inclusion of qcom,gcc-sdm845.h
mistakenly introduced by commit 6e17f8140521 ("arm64:
dts: sdm845: add prng-ee node").
Signed-off-by: Sai Prakash Ranjan
Reviewed-by: Douglas Anderson
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 1 -
1 file changed, 1 deletion(-)
* Addressed Mathieu's feedback about masking the minor version in
etm4_arch_supported() and added a comment for reason to bypass
the AMBA bus discovery method.
Sai Prakash Ranjan (3):
arm64: dts: qcom: sdm845: Add Coresight support
coresight: etm4x: Add support to enable ETMv4.2
arm64: dts: qcom
From: Vivek Gautam
Enable coresight support by adding device nodes for the
available source, sinks and channel blocks on msm8996.
This also adds coresight cpu debug nodes.
Signed-off-by: Vivek Gautam
Signed-off-by: Sai Prakash Ranjan
---
arch/arm64/boot/dts/qcom/msm8996.dtsi | 447
On 1/18/2019 9:23 AM, Guenter Roeck wrote:
On 1/17/19 6:58 PM, Sai Prakash Ranjan wrote:
On 1/17/2019 11:46 PM, Guenter Roeck wrote:
On Thu, Jan 17, 2019 at 08:49:42PM +0530, Sai Prakash Ranjan wrote:
This adds the support for qcom watchdog suspend and resume
when entering and exiting deep
On 1/18/2019 1:20 AM, Bjorn Andersson wrote:
There seems to be some variations of this, but we try to keep everything
sorted in sdm845.dtsi to avoid having to jump around between the various
files. So please merge it into sdm845.dtsi (sorted by address).
Sure will do it.
Thanks,
Sai
--
On 1/17/2019 11:46 PM, Guenter Roeck wrote:
On Thu, Jan 17, 2019 at 08:49:42PM +0530, Sai Prakash Ranjan wrote:
This adds the support for qcom watchdog suspend and resume
when entering and exiting deep sleep states. Otherwise
having watchdog active after suspend would result in unwanted
crashes
On 1/17/2019 8:48 PM, Joel Fernandes wrote:
On Thu, Jan 17, 2019 at 11:56:20AM +0530, Sai Prakash Ranjan wrote:
commit b05c950698fe ("pstore/ram: Simplify ramoops_get_next_prz()
arguments") changed update assignment in getting next persistent
ram zone by adding a check for r
On 1/17/2019 8:49 PM, Sai Prakash Ranjan wrote:
This adds the support for qcom watchdog suspend and resume
when entering and exiting deep sleep states. Otherwise
having watchdog active after suspend would result in unwanted
crashes/resets if resume happens after a long time.
Signed-off-by: Sai
This adds the support for qcom watchdog suspend and resume
when entering and exiting deep sleep states. Otherwise
having watchdog active after suspend would result in unwanted
crashes/resets if resume happens after a long time.
Signed-off-by: Sai Prakash Ranjan
---
v2:
* Use __maybe_unused
Hi Guenter,
On 1/17/2019 8:00 PM, Guenter Roeck wrote:
I personally very much prefer __maybe_unused over #ifdef, for the reasons
stated above. Other maintainers may think differently.
Thanks for making your preference clear. I will post the second version
soon with the changes.
- Sai
--
On 1/17/2019 4:57 PM, Brian Masney wrote:
That attribute suppresses a warning from the compiler if the function is
unused when PM_SLEEP is disabled. I don't consider it hackish since the
function name no longer appears outside the #ifdef. For example:
#ifdef CONFIG_PM_SLEEP
Hi Brian,
On 1/17/2019 3:01 PM, Brian Masney wrote:
You can use the __maybe_unused attribute to remove the #ifdef:
static int __maybe_unused qcom_wdt_suspend(struct device *dev)
Thanks for looking into this.
As for __maybe_unused, I think it's better to keep #ifdef rather than
this
This adds the support for qcom watchdog suspend and resume
when entering and exiting deep sleep states. Otherwise
having watchdog active after suspend would result in unwanted
crashes/resets if resume happens after a long time.
Signed-off-by: Sai Prakash Ranjan
---
drivers/watchdog/qcom-wdt.c
ps_get_next_prz() arguments")
Signed-off-by: Sai Prakash Ranjan
---
I guess commit msg can be improved.
---
fs/pstore/ram.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
index 96f7d32cd184..441a44215456 100644
--- a/fs/pstore/ram.c
+
Hi Mathieu,
On 1/14/2019 9:05 PM, Mathieu Poirier wrote:
On Sat, Jan 12, 2019 at 06:21:00PM +0530, saiprakash.ran...@codeaurora.org
wrote:
Hi Mathieu,
+
+ etm@704 {
+ compatible = "arm,coresight-etm4x", "arm,primecell";
+ arm,primecell-periphid =
Hi Bjorn,
Thanks for the review. Please find my comments inline.
On 1/13/2019 12:53 PM, Bjorn Andersson wrote:
On Wed 09 Jan 09:46 PST 2019, Sai Prakash Ranjan wrote:
Add coresight components found on Qualcomm SDM845 SoC.
Signed-off-by: Sai Prakash Ranjan
Hi Sai,
The content
/
Tested-by: Sai Prakash Ranjan
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
Hi Doug,
On 1/10/2019 4:27 AM, Doug Anderson wrote:
This was on my TODO list, but you beat me to it. This could land any
time and is completely separate from the other patches in this series.
Reviewed-by: Douglas Anderson
Thanks for the review. Sorry I missed keeping you and Bjorn in CC.
Remove the duplicate inclusion of qcom,gcc-sdm845.h
mistakenly introduced by commit 6e17f8140521 ("arm64:
dts: sdm845: add prng-ee node").
Signed-off-by: Sai Prakash Ranjan
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/boo
Add coresight components found on Qualcomm SDM845 SoC.
Signed-off-by: Sai Prakash Ranjan
---
.../arm64/boot/dts/qcom/sdm845-coresight.dtsi | 437 ++
arch/arm64/boot/dts/qcom/sdm845.dtsi | 2 +
2 files changed, 439 insertions(+)
create mode 100644 arch/arm64/boot/dts
-etm4x 764.etm: CPU6: ETM v4.2 initialized
[6.705646] coresight-etm4x 774.etm: CPU7: ETM v4.2 initialized
Signed-off-by: Sai Prakash Ranjan
---
drivers/hwtracing/coresight/coresight-etm4x.c | 2 +-
drivers/hwtracing/coresight/coresight-etm4x.h | 2 +-
2 files changed, 2 insertions
depends on below AOSS QMP patches by Bjorn:
https://patchwork.kernel.org/patch/10749469/
https://patchwork.kernel.org/patch/10749481/
https://patchwork.kernel.org/patch/10749479/
https://patchwork.kernel.org/patch/10749475/
This patch series has been tested on SDM845 MTP.
Sai Prakash Ranjan (3
Hi Bjorn,
On 11/12/2018 1:35 PM, Bjorn Andersson wrote:
The AOSS QMP genpd provider implements control over power-related
resources related to low-power state associated with the remoteprocs in
the system as well as control over a set of clocks related to debug
hardware in the SoC.
Hi Bjorn,
On 11/12/2018 1:35 PM, Bjorn Andersson wrote:
The AOSS QMP genpd provider implements control over power-related
resources related to low-power state associated with the remoteprocs in
the system as well as control over a set of clocks related to debug
hardware in the SoC.
Hi Bjorn,
On 11/12/2018 1:35 PM, Bjorn Andersson wrote:
The AOSS QMP genpd provider implements control over power-related
resources related to low-power state associated with the remoteprocs in
the system as well as control over a set of clocks related to debug
hardware in the SoC.
Hi Bjorn,
On 11/12/2018 1:35 PM, Bjorn Andersson wrote:
The AOSS QMP genpd provider implements control over power-related
resources related to low-power state associated with the remoteprocs in
the system as well as control over a set of clocks related to debug
hardware in the SoC.
On 11/16/2018 4:23 PM, Viresh Kumar wrote:
Hi,
On 16-11-18, 16:16, Sai Prakash Ranjan wrote:
iface clock is shared with other drivers, which may reconfigure
this before the serial driver comes up. This may lead to
crashes like the one below where GCC_BLSP1_AHB_CLK is same across
multiple
On 11/16/2018 4:23 PM, Viresh Kumar wrote:
Hi,
On 16-11-18, 16:16, Sai Prakash Ranjan wrote:
iface clock is shared with other drivers, which may reconfigure
this before the serial driver comes up. This may lead to
crashes like the one below where GCC_BLSP1_AHB_CLK is same across
multiple
On 11/16/2018 9:09 AM, Viresh Kumar wrote:
On Thu, Nov 15, 2018 at 4:23 PM Srinivas Kandagatla
wrote:
Yes, this is not the solution, but it proves that the hand-off between
booloaders and kernel is the issue.
In general there is wider issue with resources hand-off between
bootloader and
On 11/16/2018 9:09 AM, Viresh Kumar wrote:
On Thu, Nov 15, 2018 at 4:23 PM Srinivas Kandagatla
wrote:
Yes, this is not the solution, but it proves that the hand-off between
booloaders and kernel is the issue.
In general there is wider issue with resources hand-off between
bootloader and
3.164853] sci_init+0x24/0x3c
<4>[3.164859] do_one_initcall+0x54/0x248
<4>[3.164866] kernel_init_freeable+0x210/0x378
<4>[3.164872] kernel_init+0x18/0x118
<4>[3.164878] ret_from_fork+0x10/0x1c
<0>[3.164884] Code: aa1e03e0 8b2142
3.164853] sci_init+0x24/0x3c
<4>[3.164859] do_one_initcall+0x54/0x248
<4>[3.164866] kernel_init_freeable+0x210/0x378
<4>[3.164872] kernel_init+0x18/0x118
<4>[3.164878] ret_from_fork+0x10/0x1c
<0>[3.164884] Code: aa1e03e0 8b2142
On 11/13/2018 3:14 PM, Srinivas Kandagatla wrote:
Hi Sai,
On 25/10/18 15:36, saiprakash.ran...@codeaurora.org wrote:
"If I disable dma node and LS-UART0, then I don't see any crash and
ftrace also works fine"
And one more observation is that even without ftrace cmdline, if I use
earlycon
On 11/13/2018 3:14 PM, Srinivas Kandagatla wrote:
Hi Sai,
On 25/10/18 15:36, saiprakash.ran...@codeaurora.org wrote:
"If I disable dma node and LS-UART0, then I don't see any crash and
ftrace also works fine"
And one more observation is that even without ftrace cmdline, if I use
earlycon
On 10/21/2018 9:16 AM, Sai Prakash Ranjan wrote:
On 10/20/2018 9:57 PM, Joel Fernandes wrote:
On Sat, Oct 20, 2018 at 12:02:37PM +0530, Sai Prakash Ranjan wrote:
On 10/20/2018 10:55 AM, Joel Fernandes wrote:
On Sun, Sep 09, 2018 at 01:57:01AM +0530, Sai Prakash Ranjan wrote:
Hi,
This patch
On 10/21/2018 9:16 AM, Sai Prakash Ranjan wrote:
On 10/20/2018 9:57 PM, Joel Fernandes wrote:
On Sat, Oct 20, 2018 at 12:02:37PM +0530, Sai Prakash Ranjan wrote:
On 10/20/2018 10:55 AM, Joel Fernandes wrote:
On Sun, Sep 09, 2018 at 01:57:01AM +0530, Sai Prakash Ranjan wrote:
Hi,
This patch
On 10/20/2018 9:57 PM, Joel Fernandes wrote:
On Sat, Oct 20, 2018 at 12:02:37PM +0530, Sai Prakash Ranjan wrote:
On 10/20/2018 10:55 AM, Joel Fernandes wrote:
On Sun, Sep 09, 2018 at 01:57:01AM +0530, Sai Prakash Ranjan wrote:
Hi,
This patch series adds Event tracing support to pstore
On 10/20/2018 9:57 PM, Joel Fernandes wrote:
On Sat, Oct 20, 2018 at 12:02:37PM +0530, Sai Prakash Ranjan wrote:
On 10/20/2018 10:55 AM, Joel Fernandes wrote:
On Sun, Sep 09, 2018 at 01:57:01AM +0530, Sai Prakash Ranjan wrote:
Hi,
This patch series adds Event tracing support to pstore
On 10/20/2018 10:55 AM, Joel Fernandes wrote:
On Sun, Sep 09, 2018 at 01:57:01AM +0530, Sai Prakash Ranjan wrote:
Hi,
This patch series adds Event tracing support to pstore and is continuation
to the RFC patch introduced to add a new tracing facility for register
accesses called Register Trace
On 10/20/2018 10:55 AM, Joel Fernandes wrote:
On Sun, Sep 09, 2018 at 01:57:01AM +0530, Sai Prakash Ranjan wrote:
Hi,
This patch series adds Event tracing support to pstore and is continuation
to the RFC patch introduced to add a new tracing facility for register
accesses called Register Trace
On 10/19/2018 7:21 PM, Steven Rostedt wrote:
On Fri, 19 Oct 2018 12:24:05 +0530
Sai Prakash Ranjan wrote:
Anyone see any problems here?
This seems sane to me, he says in the other thread that he put 'notrace' to
the msm serial functions (which AIUI should prevent ftrace instrumentation
On 10/19/2018 7:21 PM, Steven Rostedt wrote:
On Fri, 19 Oct 2018 12:24:05 +0530
Sai Prakash Ranjan wrote:
Anyone see any problems here?
This seems sane to me, he says in the other thread that he put 'notrace' to
the msm serial functions (which AIUI should prevent ftrace instrumentation
On 10/19/2018 9:47 AM, Joel Fernandes wrote:
On Thu, Oct 18, 2018 at 09:17:06AM -0400, Steven Rostedt wrote:
On Thu, 18 Oct 2018 10:51:18 +0530
Sai Prakash Ranjan wrote:
So something else is causing an issue besides just msm_read.
Can you do an objdump -dr of the entire vmlinux binary
On 10/19/2018 9:47 AM, Joel Fernandes wrote:
On Thu, Oct 18, 2018 at 09:17:06AM -0400, Steven Rostedt wrote:
On Thu, 18 Oct 2018 10:51:18 +0530
Sai Prakash Ranjan wrote:
So something else is causing an issue besides just msm_read.
Can you do an objdump -dr of the entire vmlinux binary
On 10/18/2018 8:03 AM, Steven Rostedt wrote:
On Wed, 17 Oct 2018 00:36:05 +0530
Sai Prakash Ranjan wrote:
On 10/17/2018 12:33 AM, Steven Rostedt wrote:
On Wed, 17 Oct 2018 00:31:03 +0530
Sai Prakash Ranjan wrote:
Haa seems like you are right! With "ftrace=function
ftrace_f
On 10/18/2018 8:03 AM, Steven Rostedt wrote:
On Wed, 17 Oct 2018 00:36:05 +0530
Sai Prakash Ranjan wrote:
On 10/17/2018 12:33 AM, Steven Rostedt wrote:
On Wed, 17 Oct 2018 00:31:03 +0530
Sai Prakash Ranjan wrote:
Haa seems like you are right! With "ftrace=function
ftrace_f
ise looks good to me,
Reviewed-by: Joel Fernandes (Google)
Tested this on top of Joel's patch, works fine on getting early crash
pstore dmesg logs, thanks.
Tested-by: Sai Prakash Ranjan
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
ise looks good to me,
Reviewed-by: Joel Fernandes (Google)
Tested this on top of Joel's patch, works fine on getting early crash
pstore dmesg logs, thanks.
Tested-by: Sai Prakash Ranjan
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
On 10/17/2018 5:08 PM, Sai Prakash Ranjan wrote:
What do you think about the (untested) patch below? It seems to me
that it
should solve the issue of missing early crash dumps, but I have not
tested it
yet. Sai, would you mind trying it out and let me know if you can see the
early crash
On 10/17/2018 5:08 PM, Sai Prakash Ranjan wrote:
What do you think about the (untested) patch below? It seems to me
that it
should solve the issue of missing early crash dumps, but I have not
tested it
yet. Sai, would you mind trying it out and let me know if you can see the
early crash
On 10/17/2018 4:39 AM, Joel Fernandes wrote:
On Tue, Oct 16, 2018 at 05:08:25PM +0530, Sai Prakash Ranjan wrote:
Hi,
On dragonboard 410c, with "ftrace=function" boot args, the console output
slows down and board resets without any backtrace as below. This is tested
on latest kernel
On 10/17/2018 4:39 AM, Joel Fernandes wrote:
On Tue, Oct 16, 2018 at 05:08:25PM +0530, Sai Prakash Ranjan wrote:
Hi,
On dragonboard 410c, with "ftrace=function" boot args, the console output
slows down and board resets without any backtrace as below. This is tested
on latest kernel
On 10/17/2018 3:43 PM, Joel Fernandes wrote:
Hi Kees,
On Tue, Oct 16, 2018 at 10:02:53AM -0700, Kees Cook wrote:
On Tue, Oct 16, 2018 at 8:29 AM, Steven Rostedt wrote:
On Tue, 16 Oct 2018 17:08:25 +0530
Sai Prakash Ranjan wrote:
One more thing is for pstore dmesg-ramoops, I had to change
On 10/17/2018 3:43 PM, Joel Fernandes wrote:
Hi Kees,
On Tue, Oct 16, 2018 at 10:02:53AM -0700, Kees Cook wrote:
On Tue, Oct 16, 2018 at 8:29 AM, Steven Rostedt wrote:
On Tue, 16 Oct 2018 17:08:25 +0530
Sai Prakash Ranjan wrote:
One more thing is for pstore dmesg-ramoops, I had to change
On 10/17/2018 2:21 AM, Stephen Boyd wrote:
Quoting Sai Prakash Ranjan (2018-10-16 12:35:57)
On 10/17/2018 12:45 AM, Steven Rostedt wrote:
On Wed, 17 Oct 2018 00:36:05 +0530
Sai Prakash Ranjan wrote:
On 10/17/2018 12:33 AM, Steven Rostedt wrote:
On Wed, 17 Oct 2018 00:31:03 +0530
Sai
On 10/17/2018 2:21 AM, Stephen Boyd wrote:
Quoting Sai Prakash Ranjan (2018-10-16 12:35:57)
On 10/17/2018 12:45 AM, Steven Rostedt wrote:
On Wed, 17 Oct 2018 00:36:05 +0530
Sai Prakash Ranjan wrote:
On 10/17/2018 12:33 AM, Steven Rostedt wrote:
On Wed, 17 Oct 2018 00:31:03 +0530
Sai
On 10/17/2018 12:46 AM, Steven Rostedt wrote:
On Tue, 16 Oct 2018 15:15:16 -0400
Steven Rostedt wrote:
I'd like to see the full command line as well. I bet if you remove the
qcom,msm-uartdm from the command line, and had just ftrace=function, it
may also boot fine too. Can you try that?
On 10/17/2018 12:46 AM, Steven Rostedt wrote:
On Tue, 16 Oct 2018 15:15:16 -0400
Steven Rostedt wrote:
I'd like to see the full command line as well. I bet if you remove the
qcom,msm-uartdm from the command line, and had just ftrace=function, it
may also boot fine too. Can you try that?
On 10/17/2018 12:33 AM, Steven Rostedt wrote:
On Wed, 17 Oct 2018 00:31:03 +0530
Sai Prakash Ranjan wrote:
Haa seems like you are right! With "ftrace=function
ftrace_filter=msm_read" , I can trigger the crash, but
sadly "ftrace_notrace=msm_read" also crashes.
So t
On 10/17/2018 12:33 AM, Steven Rostedt wrote:
On Wed, 17 Oct 2018 00:31:03 +0530
Sai Prakash Ranjan wrote:
Haa seems like you are right! With "ftrace=function
ftrace_filter=msm_read" , I can trigger the crash, but
sadly "ftrace_notrace=msm_read" also crashes.
So t
On 10/17/2018 12:11 AM, Steven Rostedt wrote:
On Tue, 16 Oct 2018 23:55:14 +0530
Sai Prakash Ranjan wrote:
On 10/16/2018 11:46 PM, Steven Rostedt wrote:
[ Removed ivan.iva...@linaro.org due to getting mail delivery errors ]
On Tue, 16 Oct 2018 23:35:00 +0530
Sai Prakash Ranjan wrote
On 10/17/2018 12:11 AM, Steven Rostedt wrote:
On Tue, 16 Oct 2018 23:55:14 +0530
Sai Prakash Ranjan wrote:
On 10/16/2018 11:46 PM, Steven Rostedt wrote:
[ Removed ivan.iva...@linaro.org due to getting mail delivery errors ]
On Tue, 16 Oct 2018 23:35:00 +0530
Sai Prakash Ranjan wrote
On 10/16/2018 11:46 PM, Steven Rostedt wrote:
[ Removed ivan.iva...@linaro.org due to getting mail delivery errors ]
On Tue, 16 Oct 2018 23:35:00 +0530
Sai Prakash Ranjan wrote:
Ok got it, this sounds fun. I'll give it a try.
Awesome, I'm looking forward to seeing what you come up
On 10/16/2018 11:46 PM, Steven Rostedt wrote:
[ Removed ivan.iva...@linaro.org due to getting mail delivery errors ]
On Tue, 16 Oct 2018 23:35:00 +0530
Sai Prakash Ranjan wrote:
Ok got it, this sounds fun. I'll give it a try.
Awesome, I'm looking forward to seeing what you come up
On 10/16/2018 11:18 PM, Steven Rostedt wrote:
On Tue, 16 Oct 2018 23:06:24 +0530
Sai Prakash Ranjan wrote:
On 10/16/2018 10:27 PM, Steven Rostedt wrote:
OK, can you add to the command line:
ftrace=function ftrace_filter=*schedule*
to see if it's a specific function that may be causing
On 10/16/2018 11:18 PM, Steven Rostedt wrote:
On Tue, 16 Oct 2018 23:06:24 +0530
Sai Prakash Ranjan wrote:
On 10/16/2018 10:27 PM, Steven Rostedt wrote:
OK, can you add to the command line:
ftrace=function ftrace_filter=*schedule*
to see if it's a specific function that may be causing
On 10/16/2018 10:27 PM, Steven Rostedt wrote:
OK, can you add to the command line:
ftrace=function ftrace_filter=*schedule*
to see if it's a specific function that may be causing the issue (but
hopefully it's not one of the scheduling functions that caused it).
Target boots fine with
On 10/16/2018 10:27 PM, Steven Rostedt wrote:
OK, can you add to the command line:
ftrace=function ftrace_filter=*schedule*
to see if it's a specific function that may be causing the issue (but
hopefully it's not one of the scheduling functions that caused it).
Target boots fine with
On 10/16/2018 8:59 PM, Steven Rostedt wrote:
On Tue, 16 Oct 2018 17:08:25 +0530
Sai Prakash Ranjan wrote:
Hi,
On dragonboard 410c, with "ftrace=function" boot args, the console
output slows down and board resets without any backtrace as below. This
is tested on latest kernel
On 10/16/2018 8:59 PM, Steven Rostedt wrote:
On Tue, 16 Oct 2018 17:08:25 +0530
Sai Prakash Ranjan wrote:
Hi,
On dragonboard 410c, with "ftrace=function" boot args, the console
output slows down and board resets without any backtrace as below. This
is tested on latest kernel
On 10/16/2018 5:14 PM, Greg Kroah-Hartman wrote:
On Tue, Oct 16, 2018 at 05:08:25PM +0530, Sai Prakash Ranjan wrote:
Hi,
On dragonboard 410c, with "ftrace=function" boot args, the console output
slows down and board resets without any backtrace as below. This is tested
on lat
On 10/16/2018 5:14 PM, Greg Kroah-Hartman wrote:
On Tue, Oct 16, 2018 at 05:08:25PM +0530, Sai Prakash Ranjan wrote:
Hi,
On dragonboard 410c, with "ftrace=function" boot args, the console output
slows down and board resets without any backtrace as below. This is tested
on lat
Hi,
On dragonboard 410c, with "ftrace=function" boot args, the console
output slows down and board resets without any backtrace as below. This
is tested on latest kernel and seems to exist even in older kernels as well.
[2.949164] EINJ: ACPI disabled.
[3.133001] Serial: 8250/16550
Hi,
On dragonboard 410c, with "ftrace=function" boot args, the console
output slows down and board resets without any backtrace as below. This
is tested on latest kernel and seems to exist even in older kernels as well.
[2.949164] EINJ: ACPI disabled.
[3.133001] Serial: 8250/16550
On 10/9/2018 4:10 AM, Joel Fernandes wrote:
On Mon, Oct 08, 2018 at 10:36:59AM -0400, Steven Rostedt wrote:
On Mon, 8 Oct 2018 19:46:15 +0530
Sai Prakash Ranjan wrote:
Hi Joel,
Sorry for the long delay in updating this thread.
But I just observed one weird behaviour in ftrace-ramoops when I
On 10/9/2018 4:10 AM, Joel Fernandes wrote:
On Mon, Oct 08, 2018 at 10:36:59AM -0400, Steven Rostedt wrote:
On Mon, 8 Oct 2018 19:46:15 +0530
Sai Prakash Ranjan wrote:
Hi Joel,
Sorry for the long delay in updating this thread.
But I just observed one weird behaviour in ftrace-ramoops when I
On 9/26/2018 3:16 PM, Sai Prakash Ranjan wrote:
On 9/26/2018 2:55 AM, Joel Fernandes wrote:
On Sat, Sep 8, 2018 at 1:28 PM Sai Prakash Ranjan
wrote:
Add the kernel command line tp_pstore option that will have
tracepoints go to persistent ram buffer as well as to the
trace buffer for further
On 9/26/2018 3:16 PM, Sai Prakash Ranjan wrote:
On 9/26/2018 2:55 AM, Joel Fernandes wrote:
On Sat, Sep 8, 2018 at 1:28 PM Sai Prakash Ranjan
wrote:
Add the kernel command line tp_pstore option that will have
tracepoints go to persistent ram buffer as well as to the
trace buffer for further
On 9/26/2018 2:10 AM, Joel Fernandes wrote:
On Tue, Sep 25, 2018 at 1:39 PM, Joel Fernandes wrote:
On Tue, Sep 25, 2018 at 1:37 PM, Joel Fernandes wrote:
On Sun, Sep 23, 2018 at 8:33 AM, Sai Prakash Ranjan
wrote:
On 9/22/2018 10:07 PM, Sai Prakash Ranjan wrote:
On 9/22/2018 2:35 PM, Joel
On 9/26/2018 2:10 AM, Joel Fernandes wrote:
On Tue, Sep 25, 2018 at 1:39 PM, Joel Fernandes wrote:
On Tue, Sep 25, 2018 at 1:37 PM, Joel Fernandes wrote:
On Sun, Sep 23, 2018 at 8:33 AM, Sai Prakash Ranjan
wrote:
On 9/22/2018 10:07 PM, Sai Prakash Ranjan wrote:
On 9/22/2018 2:35 PM, Joel
On 9/26/2018 2:55 AM, Joel Fernandes wrote:
On Sat, Sep 8, 2018 at 1:28 PM Sai Prakash Ranjan
wrote:
Add the kernel command line tp_pstore option that will have
tracepoints go to persistent ram buffer as well as to the
trace buffer for further debugging. This is similar to tp_printk
cmdline
On 9/26/2018 2:55 AM, Joel Fernandes wrote:
On Sat, Sep 8, 2018 at 1:28 PM Sai Prakash Ranjan
wrote:
Add the kernel command line tp_pstore option that will have
tracepoints go to persistent ram buffer as well as to the
trace buffer for further debugging. This is similar to tp_printk
cmdline
On 9/22/2018 10:07 PM, Sai Prakash Ranjan wrote:
On 9/22/2018 2:35 PM, Joel Fernandes wrote:
On Sat, Sep 8, 2018 at 4:28 PM Sai Prakash Ranjan
wrote:
+
+ trace_seq_init(>seq);
+ iter->ent = fbuffer->entry;
+ event_call->event.funcs->trace
On 9/22/2018 10:07 PM, Sai Prakash Ranjan wrote:
On 9/22/2018 2:35 PM, Joel Fernandes wrote:
On Sat, Sep 8, 2018 at 4:28 PM Sai Prakash Ranjan
wrote:
+
+ trace_seq_init(>seq);
+ iter->ent = fbuffer->entry;
+ event_call->event.funcs->trace
On 9/22/2018 10:07 PM, Sai Prakash Ranjan wrote:
On 9/22/2018 2:35 PM, Joel Fernandes wrote:
On Sat, Sep 8, 2018 at 4:28 PM Sai Prakash Ranjan
wrote:
Also I think this spinlock can be moved further down.
OK. Something like this would suffice?
{{{
spin_lock_irqsave(>buf_lock, fl
On 9/22/2018 10:07 PM, Sai Prakash Ranjan wrote:
On 9/22/2018 2:35 PM, Joel Fernandes wrote:
On Sat, Sep 8, 2018 at 4:28 PM Sai Prakash Ranjan
wrote:
Also I think this spinlock can be moved further down.
OK. Something like this would suffice?
{{{
spin_lock_irqsave(>buf_lock, fl
On 9/22/2018 10:07 PM, Sai Prakash Ranjan wrote:
On 9/22/2018 2:35 PM, Joel Fernandes wrote:
On Sat, Sep 8, 2018 at 4:28 PM Sai Prakash Ranjan
wrote:
Could you just split the pstore space into a per-cpu event buffer like
we are doing for ftrace-on-pstore? Then you don't need to lock. I fear
On 9/22/2018 10:07 PM, Sai Prakash Ranjan wrote:
On 9/22/2018 2:35 PM, Joel Fernandes wrote:
On Sat, Sep 8, 2018 at 4:28 PM Sai Prakash Ranjan
wrote:
Could you just split the pstore space into a per-cpu event buffer like
we are doing for ftrace-on-pstore? Then you don't need to lock. I fear
On 9/22/2018 2:35 PM, Joel Fernandes wrote:
On Sat, Sep 8, 2018 at 4:28 PM Sai Prakash Ranjan
wrote:
Could you just split the pstore space into a per-cpu event buffer like
we are doing for ftrace-on-pstore? Then you don't need to lock. I fear
the lock contention will be apparent. The pstore
On 9/22/2018 2:35 PM, Joel Fernandes wrote:
On Sat, Sep 8, 2018 at 4:28 PM Sai Prakash Ranjan
wrote:
Could you just split the pstore space into a per-cpu event buffer like
we are doing for ftrace-on-pstore? Then you don't need to lock. I fear
the lock contention will be apparent. The pstore
On 9/19/2018 2:43 AM, Sai Prakash Ranjan wrote:
On 9/19/2018 2:14 AM, Steven Rostedt wrote:
On Tue, 18 Sep 2018 23:22:48 +0530
Sai Prakash Ranjan wrote:
On 9/18/2018 5:04 AM, Steven Rostedt wrote:
It looks like pstore_event_call() gets called from a trace event. You
can't call kmalloc
On 9/19/2018 2:43 AM, Sai Prakash Ranjan wrote:
On 9/19/2018 2:14 AM, Steven Rostedt wrote:
On Tue, 18 Sep 2018 23:22:48 +0530
Sai Prakash Ranjan wrote:
On 9/18/2018 5:04 AM, Steven Rostedt wrote:
It looks like pstore_event_call() gets called from a trace event. You
can't call kmalloc
On 9/19/2018 2:14 AM, Steven Rostedt wrote:
On Tue, 18 Sep 2018 23:22:48 +0530
Sai Prakash Ranjan wrote:
On 9/18/2018 5:04 AM, Steven Rostedt wrote:
It looks like pstore_event_call() gets called from a trace event. You
can't call kmalloc() from one. One thing is that kmalloc has
tracepoints
601 - 700 of 781 matches
Mail list logo
