You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
KWD: Sometimes wait for buffer empty timeout issue happens during draining #1406
@keyonjie Draining is done on passive level, so the only potential problem I can see is preemption in hda_dma_wait_for_buffer_empty(). If it happens at the wrong time, we can throw an error without even checking the BNE value.
Check with this change:
diff --git a/src/drivers/intel/cavs/hda-dma.c b/src/drivers/intel/cavs/hda-dma.c
index 24e435a..611f0d4 100644
--- a/src/drivers/intel/cavs/hda-dma.c+++ b/src/drivers/intel/cavs/hda-dma.c@@ -293,6 +293,9 @@ static int hda_dma_wait_for_buffer_empty(struct dma *dma,
while (host_dma_reg_read(dma, chan->index, DGCS) & DGCS_BNE) {
if (deadline < platform_timer_get(platform_timer)) {
+ if (!(host_dma_reg_read(dma, chan->index, DGCS) & DGCS_BNE))+ return 0;+
trace_hddma_error("hda-dmac: %d wait for buffer empty "
"timeout", dma->plat_data.id);
return -ETIME;
Slowing down draining is an option but opens up another issue - we may be catched by real time copy before history buffer is emptied completely. Therefore a more advanced solution is needed. I am working on it now.
@mmaka1 if you have went though the patches I pasted above, it doesn't slow down the draining necessarily, it depends on the size of host_period_bytes to decide whether to slow down and how much we should slow it down. But I am open if you have advanced solution to fix that.
Activity
tlauda commentedon May 10, 2019
@keyonjie Draining is done on passive level, so the only potential problem I can see is preemption in hda_dma_wait_for_buffer_empty(). If it happens at the wrong time, we can throw an error without even checking the BNE value.
Check with this change:
keyonjie commentedon May 14, 2019
PR#1415 help?
mengdonglin commentedon May 14, 2019
@keqiaozhang please verify #1415
keqiaozhang commentedon May 14, 2019
no above trace error with PR #1415 . But I run into below new error:
dmesg:
tlauda commentedon May 14, 2019
@keqiaozhang Please fill the separate issue for the new finding.
keqiaozhang commentedon May 14, 2019
Please refer to #1423
keyonjie commentedon May 14, 2019
@tlauda I still seeing occasional "wait for buffer empty timeout" issue in my KWD capture draining case, after applied PR #1415
tlauda commentedon May 14, 2019
@keyonjie Could you try also with #1426? It seems that APL needs longer time to fully exit L1.
keyonjie commentedon May 15, 2019
@tlauda looks #1426 can improve it, still seeing the issue with lower reproduce rate.
tlauda commentedon May 15, 2019
@keyonjie Could you try with L1SEN = 0? It can be set on the host side.
keyonjie commentedon May 16, 2019
@tlauda sorry, don't get you with L1SEN = 0. Are you meaning FDHDL1E bit in SVCFG?
keyonjie commentedon May 16, 2019
Once the issue happened, if we try to run "arecord" again, DSP panic from FW:
keyonjie commentedon May 16, 2019
I tried non-blocking mode also, though we won't log out "wait for buffer empty timeout", the FW will hang and there is SA warning in error log:
9 remaining items
keyonjie commentedon May 22, 2019
On FW side, patch here:
keyonjie commentedon May 22, 2019
It might require kernel and ABI changes also, here it's my patch for that:
mrajwa commentedon May 22, 2019
Slowing down draining is an option but opens up another issue - we may be catched by real time copy before history buffer is emptied completely. Therefore a more advanced solution is needed. I am working on it now.
keyonjie commentedon May 23, 2019
@mmaka1 if you have went though the patches I pasted above, it doesn't slow down the draining necessarily, it depends on the size of host_period_bytes to decide whether to slow down and how much we should slow it down. But I am open if you have advanced solution to fix that.
jajanusz commentedon Jun 7, 2019
@mrajwa @keyonjie @tlauda Is it still a problem?
mengdonglin commentedon Jun 14, 2019
@keyonjie @keqiaozhang @tlauda Is this issue also fixed by PR #1546 ?
tlauda commentedon Jun 14, 2019
@mengdonglin No.
mrajwa commentedon Jun 14, 2019
@mengdonglin, @tlauda this issue is fixed by:
https://github.com/mrajwa/sof/commits/cml-005-drop-stable [FW]
thesofproject/linux#1037 [Kernel]
keqiaozhang commentedon Jun 17, 2019
@mrajwa
I tested above recipe on GLK Chromebook, but I run to DSP panic after draining, The reproduction rate is 100%.
console output
dmesg
trace
No obvious trace errors, the trace logs are attached.
logger.log
logger-t.log
dmesg.log
test recipe
Kernel: cros-sof-v4.14-rebase/18a233 +PR1037
SOF/TPLG: https://github.com/mrajwa/sof/commits/cml-005-drop-stable
Platform: GLK-Chromebook/ChromeOS
YvonneYang2 commentedon Jun 18, 2019
Tested on GLK Chromebook with test recipe as below. Not found DSP panic in dmesg log but console showed Xrun alert info, and arecored failed.
test recipe
Kernel: https://github.com/thesofproject/linux/tree/topic/keyword_detect 9c95e6f +PR1037
SOF/TPLG: https://github.com/mrajwa/sof/commits/cml-005-drop-stable
Platform: GLK-Chromebook/ChromeOS
frequency
8/10
console
logger
dmesg
xrun_error_dmesg.log
xrun_error_logger.log
mrajwa commentedon Jul 8, 2019
This issue is fixed on https://github.com/thesofproject/sof/tree/cml-005-drop-stable
michalgrodzicki commentedon Jul 8, 2019
@mrajwa please submit code from release branch to the master,
once you will do it validation team will be able to confirm/reject fix.