[Sound-open-firmware] [PATCH] dai: use verbose trace call to prevent trace buffer overflow
This patch changes the trace message to use the verbose option to prevent trace buffer overflow.
Signed-off-by: Ranjani Sridharan ranjani.sridharan@linux.intel.com --- Tested with Minnowboard Turbot with RT5651 Kernel: https://github.com/plbossart/sound.git branch: topic/sof-v4.14 SOF: 1.1-stable SOFT: 1.1-stable --- --- src/audio/dai.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/audio/dai.c b/src/audio/dai.c index 53536ed..f1b4a8e 100644 --- a/src/audio/dai.c +++ b/src/audio/dai.c @@ -82,7 +82,7 @@ static void dai_dma_cb(void *data, uint32_t type, struct dma_sg_elem *next) struct comp_buffer *dma_buffer; uint32_t copied_size;
- trace_dai("irq"); + tracev_dai("irq");
/* is stream stopped or paused and we are not handling XRUN ? */ if (dev->state != COMP_STATE_ACTIVE && dd->xrun == 0) {
On 2018年03月27日 10:32, Ranjani Sridharan wrote:
This patch changes the trace message to use the verbose option to prevent trace buffer overflow.
Signed-off-by: Ranjani Sridharan ranjani.sridharan@linux.intel.com
Tested with Minnowboard Turbot with RT5651 Kernel: https://github.com/plbossart/sound.git branch: topic/sof-v4.14 SOF: 1.1-stable SOFT: 1.1-stable
src/audio/dai.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/audio/dai.c b/src/audio/dai.c index 53536ed..f1b4a8e 100644 --- a/src/audio/dai.c +++ b/src/audio/dai.c @@ -82,7 +82,7 @@ static void dai_dma_cb(void *data, uint32_t type, struct dma_sg_elem *next) struct comp_buffer *dma_buffer; uint32_t copied_size;
- trace_dai("irq");
- tracev_dai("irq");
I am not enthusiastic on changing trace to verbose to avoid problem happens of dma trace, those several lines of trace per millisecond is quite normal/common/basic needed for debugging/tracing for playback/capture, what we need to think about(or root cause) is how to fix the issue.
At least, it still have problem when we switch on tracev, those macros are designed for us to use.
Thanks, ~Keyon
/* is stream stopped or paused and we are not handling XRUN ? */ if (dev->state != COMP_STATE_ACTIVE && dd->xrun == 0) {
On Tue, 2018-03-27 at 10:54 +0800, Keyon Jie wrote:
On 2018年03月27日 10:32, Ranjani Sridharan wrote:
This patch changes the trace message to use the verbose option to prevent trace buffer overflow.
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com
Tested with Minnowboard Turbot with RT5651 Kernel: https://github.com/plbossart/sound.git branch: topic/sof- v4.14 SOF: 1.1-stable SOFT: 1.1-stable
src/audio/dai.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/audio/dai.c b/src/audio/dai.c index 53536ed..f1b4a8e 100644 --- a/src/audio/dai.c +++ b/src/audio/dai.c @@ -82,7 +82,7 @@ static void dai_dma_cb(void *data, uint32_t type, struct dma_sg_elem *next) struct comp_buffer *dma_buffer; uint32_t copied_size;
- trace_dai("irq");
- tracev_dai("irq");
I am not enthusiastic on changing trace to verbose to avoid problem happens of dma trace, those several lines of trace per millisecond is quite normal/common/basic needed for debugging/tracing for playback/capture, what we need to think about(or root cause) is how to fix the issue.
At least, it still have problem when we switch on tracev, those macros are designed for us to use.
Thanks, ~Keyon
Please correct me if I am wrong. I am not sure how to prevent this error if the trace buffer is thrashed with messages at a high rate. Is this an error or should this be a warning? But at least with tracev, we're kind of signing up for it.
/* is stream stopped or paused and we are not handling XRUN ? */ if (dev->state != COMP_STATE_ACTIVE && dd->xrun == 0) {
Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
On Mon, 2018-03-26 at 20:19 -0700, Ranjani Sridharan wrote:
On Tue, 2018-03-27 at 10:54 +0800, Keyon Jie wrote:
On 2018年03月27日 10:32, Ranjani Sridharan wrote:
This patch changes the trace message to use the verbose option to prevent trace buffer overflow.
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.c om
Tested with Minnowboard Turbot with RT5651 Kernel: https://github.com/plbossart/sound.git branch: topic/sof- v4.14 SOF: 1.1-stable SOFT: 1.1-stable
src/audio/dai.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/audio/dai.c b/src/audio/dai.c index 53536ed..f1b4a8e 100644 --- a/src/audio/dai.c +++ b/src/audio/dai.c @@ -82,7 +82,7 @@ static void dai_dma_cb(void *data, uint32_t type, struct dma_sg_elem *next) struct comp_buffer *dma_buffer; uint32_t copied_size;
- trace_dai("irq");
- tracev_dai("irq");
I am not enthusiastic on changing trace to verbose to avoid problem happens of dma trace, those several lines of trace per millisecond is quite normal/common/basic needed for debugging/tracing for playback/capture, what we need to think about(or root cause) is how to fix the issue.
At least, it still have problem when we switch on tracev, those macros are designed for us to use.
Thanks, ~Keyon
Please correct me if I am wrong. I am not sure how to prevent this error if the trace buffer is thrashed with messages at a high rate. Is this an error or should this be a warning? But at least with tracev, we're kind of signing up for it.
IMHO, this trace should be used tracev instead of trace so far. It is called very hight frequently. Even if I increase DMA local buffer size from 4KB to 32KB on DSP side, it still will cause overflow.
I will continue to investigate this issue.
Currently I have one initial idea for compressing it. For high frequent repeated traces like irq callback, it may save and transfer timestamp with one special mask only excluding trace string. The trace string will be fixed like "irq". It will reduce about 1/2 trace size. But even if it works, the number of the timestamp data will still be huge. Need more improvement.
Yan Wang
/* is stream stopped or paused and we are not handling XRUN ? */ if (dev->state != COMP_STATE_ACTIVE && dd->xrun == 0) {
Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmwar e
Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
participants (3)
-
Keyon Jie -
Ranjani Sridharan -
yanwang