-
Notifications
You must be signed in to change notification settings - Fork 322
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] dmesg does't stop flushing sof log after s3 when enter s3 with headset connected and sound setting opened. #1594
Comments
I reproduced the XRUN recovery case by modifying hda_dma_avail_data_size. For real case, hda_dma_avail_data_size will only returns 0 when status & DGCS_BNE == 0
|
I also did some changes in codecs and sof kernel driver to generate infinite XRUN recovery, but I didn't get any XRUN. (1) don't program codec for capture stream when resuming from S3. Codec will not send data to controller with this change. But no XRUN occurred. Until now, our QA still cant reproduce the bug. |
Finally got this repeated message send in dmesg issue reproduced. Can be reproduced via below steps:
After step3, if close sound setting, then do S3, the repeated message flashing issue not occurred. -> Open sound setting and highlight Headset input, then do S3 again, still the repeated message flashing issue not occurred. |
@ClarexZhou Do you have FW logs? |
Attach logs. sof-logger sof-logger-t_afterstep4.log |
@ClarexZhou Please get FW log with XRUN disabled as @keqiaozhang did it with different bug: #1578 (comment). |
@tlauda @jajanusz For this case, we found that for a special operation, capture didn't work before S3 and infinite XRUN happened after S3. Now I am working on why capture didn't work. I think you could wait for my finding and go on other work. |
The dmesg keeps flushing issue can't be reproduced after disabled xrun recovery. sof-logger:
sof-logger__xrunRecoveryDisbale.log |
@RanderWang Looks more like kernel issue. FW is not spamming anything, you just fell into some loop on your side (maybe there are some interrupts that trigger it on your side but I doubt it). There are no messages generated (by FW) but you keep rereading them, can you check what causes it? |
Probably the same issue as: thesofproject/linux#1064 |
BugLink: thesofproject/sof#1594 In ASoC, hda codecs and SOF driver set the same stream tag to hardware for a stream and this stream tag should be restored to hardware after resuming from S3. For this bug, there are two capture streams active before S3 and one is released when doing S3. After resuming from S3, hda codec driver restored stream tag for the active stream, then SOF restored another stream tag which is allocated again, and this makes controller don't get any capture data, then infinite XRUN happens in FW. Now this patch checks whether there is a stored dma data for stream resuming from S3 and reuses it. And it also removes dma data when the stream is released. Signed-off-by: Rander Wang <rander.wang@linux.intel.com>
BugLink: thesofproject/sof#1594 In ASoC, hda codecs and SOF driver set the same stream tag to hardware for a stream and this stream tag should be restored to hardware after resuming from S3. For this bug, there are two capture streams active before S3 and one is released when doing S3. After resuming from S3, hda codec driver restores stream tag for the active stream, but SOF restores another stream tag which is allocated again, and this makes controller don't get any capture data, then infinite XRUN happens in FW. Now this patch checks whether there is a stored dma data for stream resuming from S3 and reuses it. And it also removes dma data when the stream is released. Tested on whiskylake with SOF driver. Signed-off-by: Rander Wang <rander.wang@linux.intel.com>
Kernel issue, fix in thesofproject/linux#1072. |
BugLink: thesofproject/sof#1594 In ASoC, hda codecs and SOF driver set the same stream tag to hardware for a stream and this stream tag should be restored to hardware after resuming from S3. For this bug, there are two capture streams active before S3 and one is released when doing S3. After resuming from S3, hda codec driver restored stream tag for the active stream, then SOF restored another stream tag which is allocated again, and this makes controller don't get any capture data, then infinite XRUN happens in FW. Now this patch checks whether there is a stored dma data for stream resuming from S3 and reuses it. And it also removes dma data when the stream is released. Signed-off-by: Rander Wang <rander.wang@linux.intel.com>
In ASoC, hda codec and SOF driver set the same stream tag to hardware for a pcm stream and this stream tag should be restored to hardware after resuming from system suspend. For this bug, there are two capture pcm streams active before doing system suspend and one is terminated by user for the stream is unused and its stream tag is released. Later after doing system suspend the stream tag for remained active stream is released by SOF driver. After system resume, hda codec driver restores the stream tag for the active pcm stream, but SOF restores another stream tag which is allocated with a different stream tag, and this makes controller don't get any capture data, then infinite XRUN happens in FW. For stream tag is stored in both hda codec and SOF driver, it shouldn't be released only in SOF driver. This patch just keeps the stream information in dma data and checks whether there is a stored DMA data for stream resuming from S3 and restores it. And it also removes DMA data when the stream is released. Tested on Whisky Lake platform. GitHub issue: thesofproject/sof#1594 Signed-off-by: Rander Wang <rander.wang@linux.intel.com>
In ASoC, hda codec and SOF driver set the same stream tag to hardware for a pcm stream and this stream tag should be restored to hardware after resuming from system suspend. For this bug, there are two capture pcm streams active before doing system suspend and one is terminated by user for the stream is unused and its stream tag is released. Later after doing system suspend the stream tag for remained active stream is released by SOF driver. After system resume, hda codec driver restores the stream tag for the active pcm stream, but SOF goes to assign a new one, which now doesn't match with the stream tag used by codec driver, and this makes controller don't get any capture data, then infinite XRUN happens in FW. For stream tag is stored in both hda codec and SOF driver, it shouldn't be released only in SOF driver. This patch just keeps the stream information in dma data and checks whether there is a stored DMA data for stream resuming from S3 and restores it. And it also removes DMA data when the stream is released. Tested on Whiskey Lake platform. GitHub issue: thesofproject/sof#1594 Signed-off-by: Rander Wang <rander.wang@linux.intel.com>
In ASoC, hda codec and SOF driver set the same stream tag to hardware for a pcm stream and this stream tag should be restored to hardware after resuming from system suspend. For this bug, there are two capture pcm streams active before doing system suspend and one is terminated by user for the stream is unused and its stream tag is released. Later after doing system suspend the stream tag for remained active stream is released by SOF driver. After system resume, hda codec driver restores the stream tag for the active pcm stream, but SOF goes to assign a new one, which now doesn't match with the stream tag used by codec driver, and this makes controller don't get any capture data, then infinite XRUN happens in FW. For stream tag is stored in both hda codec and SOF driver, it shouldn't be released only in SOF driver. This patch just keeps the stream information in dma data and checks whether there is a stored DMA data for stream resuming from S3 and restores it. And it also removes DMA data when the stream is released. Tested on Whiskey Lake platform. GitHub issue: thesofproject/sof#1594 Signed-off-by: Rander Wang <rander.wang@linux.intel.com>
In ASoC, hda codec and SOF driver set the same stream tag to hardware for a pcm stream and this stream tag should be restored to hardware after resuming from system suspend. For this bug, there are two capture pcm streams active before doing system suspend and one is terminated by user for the stream is unused and its stream tag is released. Later after doing system suspend the stream tag for remained active stream is released by SOF driver. After system resume, hda codec driver restores the stream tag for the active pcm stream, but SOF goes to assign a new one, which now doesn't match with the stream tag used by codec driver, and this makes controller don't get any capture data, then infinite XRUN happens in FW. For stream tag is stored in both hda codec and SOF driver, it shouldn't be released only in SOF driver. This patch just keeps the stream information in dma data and checks whether there is a stored DMA data for stream resuming from S3 and restores it. And it also removes DMA data when the stream is released. Tested on Whiskey Lake platform. GitHub issue: thesofproject/sof#1594 Signed-off-by: Rander Wang <rander.wang@linux.intel.com>
In ASoC, hda codec and SOF driver set the same stream tag to hardware for a pcm stream and this stream tag should be restored to hardware after resuming from system suspend. For this bug, there are two capture pcm streams active before doing system suspend and one is terminated by user for the stream is unused and its stream tag is released. Later after doing system suspend the stream tag for remained active stream is released by SOF driver. After system resume, hda codec driver restores the stream tag for the active pcm stream, but SOF goes to assign a new one, which now doesn't match with the stream tag used by codec driver, and this makes controller don't get any capture data, then infinite XRUN happens in FW. For stream tag is stored in both hda codec and SOF driver, it shouldn't be released only in SOF driver. This patch just keeps the stream information in dma data and checks whether there is a stored DMA data for stream resuming from S3 and restores it. And it also removes DMA data when the stream is released. Tested on Whiskey Lake platform. GitHub issue: thesofproject/sof#1594 Signed-off-by: Rander Wang <rander.wang@linux.intel.com>
BugLink: https://bugs.launchpad.net/bugs/1826181 In ASoC, hda codec and SOF driver set the same stream tag to hardware for a pcm stream and this stream tag should be restored to hardware after resuming from system suspend. For this bug, there are two capture pcm streams active before doing system suspend and one is terminated by user for the stream is unused and its stream tag is released. Later after doing system suspend the stream tag for remained active stream is released by SOF driver. After system resume, hda codec driver restores the stream tag for the active pcm stream, but SOF goes to assign a new one, which now doesn't match with the stream tag used by codec driver, and this makes controller don't get any capture data, then infinite XRUN happens in FW. For stream tag is stored in both hda codec and SOF driver, it shouldn't be released only in SOF driver. This patch just keeps the stream information in dma data and checks whether there is a stored DMA data for stream resuming from S3 and restores it. And it also removes DMA data when the stream is released. Tested on Whiskey Lake platform. GitHub issue: thesofproject/sof#1594 Signed-off-by: Rander Wang <rander.wang@linux.intel.com> (cherry picked from commit 09d1ac5f488cac07a08011d7130177dac1f22184 git://github.com/thesofproject/linux.git) Signed-off-by: Hui Wang <hui.wang@canonical.com>
In ASoC, hda codec and SOF driver set the same stream tag to hardware for a pcm stream and this stream tag should be restored to hardware after resuming from system suspend. For this bug, there are two capture pcm streams active before doing system suspend and one is terminated by user for the stream is unused and its stream tag is released. Later after doing system suspend the stream tag for remained active stream is released by SOF driver. After system resume, hda codec driver restores the stream tag for the active pcm stream, but SOF goes to assign a new one, which now doesn't match with the stream tag used by codec driver, and this makes controller don't get any capture data, then infinite XRUN happens in FW. For stream tag is stored in both hda codec and SOF driver, it shouldn't be released only in SOF driver. This patch just keeps the stream information in dma data and checks whether there is a stored DMA data for stream resuming from S3 and restores it. And it also removes DMA data when the stream is released. Tested on Whiskey Lake platform. GitHub issue: thesofproject/sof#1594 Signed-off-by: Rander Wang <rander.wang@linux.intel.com>
For this bug, there are two capture pcm streams active, with one stream and its related stream tag released before suspend. Later when system suspend is done, the stream tag for the remaining active stream is released by SOF driver. After system resume, hda codec driver restores the stream tag for the active pcm stream, but SOF goes to assign a new one, which now doesn't match with the stream tag used by codec driver, and this causes DMA to fail receiving data, leading to unrecoverable XRUN condition in FW. For stream tag is stored in both hda codec and SOF driver, it shouldn't be released only in SOF driver. This patch just keeps the stream information in dma data and checks whether there is a stored DMA data for stream resuming from S3 and restores it. And it also removes DMA data when the stream is released. Tested on Whiskey Lake platform. GitHub issue: thesofproject/sof#1594 Signed-off-by: Rander Wang <rander.wang@linux.intel.com>
For this bug, there are two capture pcm streams active, with one stream and its related stream tag released before suspend. Later when system suspend is done, the stream tag for the remaining active stream is released by SOF driver. After system resume, hda codec driver restores the stream tag for the active pcm stream, but SOF goes to assign a new one, which now doesn't match with the stream tag used by codec driver, and this causes DMA to fail receiving data, leading to unrecoverable XRUN condition in FW. For stream tag is stored in both hda codec and SOF driver, it shouldn't be released only in SOF driver. This patch just keeps the stream information in dma data and checks whether there is a stored DMA data for stream resuming from S3 and restores it. And it also removes DMA data when the stream is released. Tested on Whiskey Lake platform. GitHub issue: thesofproject/sof#1594 Signed-off-by: Rander Wang <rander.wang@linux.intel.com>
For this bug, there are two capture pcm streams active, with one stream and its related stream tag released before suspend. Later when system suspend is done, the stream tag for the remaining active stream is released by SOF driver. After system resume, hda codec driver restores the stream tag for the active pcm stream, but SOF goes to assign a new one, which now doesn't match with the stream tag used by codec driver, and this causes DMA to fail receiving data, leading to unrecoverable XRUN condition in FW. For stream tag is stored in both hda codec and SOF driver, it shouldn't be released only in SOF driver. This patch just keeps the stream information in dma data and checks whether there is a stored DMA data for stream resuming from S3 and restores it. And it also removes DMA data when the stream is released. Tested on Whiskey Lake platform. GitHub issue: thesofproject/sof#1594 Signed-off-by: Rander Wang <rander.wang@linux.intel.com>
For this bug, there are two capture pcm streams active, with one stream and its related stream tag released before suspend. Later when system suspend is done, the stream tag for the remaining active stream is released by SOF driver. After system resume, hda codec driver restores the stream tag for the active pcm stream, but SOF goes to assign a new one, which now doesn't match with the stream tag used by codec driver, and this causes DMA to fail receiving data, leading to unrecoverable XRUN condition in FW. For stream tag is stored in both hda codec and SOF driver, it shouldn't be released only in SOF driver. This patch just keeps the stream information in dma data and checks whether there is a stored DMA data for stream resuming from S3 and restores it. And it also removes DMA data when the stream is released. Tested on Whiskey Lake platform. GitHub issue: thesofproject/sof#1594 Signed-off-by: Rander Wang <rander.wang@linux.intel.com>
For this bug, there are two capture pcm streams active, with one stream and its related stream tag released before suspend. Later when system suspend is done, the stream tag for the remaining active stream is released by SOF driver. After system resume, hda codec driver restores the stream tag for the active pcm stream, but SOF goes to assign a new one, which now doesn't match with the stream tag used by codec driver, and this causes DMA to fail receiving data, leading to unrecoverable XRUN condition in FW. For stream tag is stored in both hda codec and SOF driver, it shouldn't be released only in SOF driver. This patch just keeps the stream information in dma data and checks whether there is a stored DMA data for stream resuming from S3 and restores it. And it also removes DMA data when the stream is released. Tested on Whiskey Lake platform. GitHub issue: thesofproject/sof#1594 Signed-off-by: Rander Wang <rander.wang@linux.intel.com>
For this bug, there are two capture pcm streams active, with one stream and its related stream tag released before suspend. Later when system suspend is done, the stream tag for the remaining active stream is released by SOF driver. After system resume, hda codec driver restores the stream tag for the active pcm stream, but SOF goes to assign a new one, which now doesn't match with the stream tag used by codec driver, and this causes DMA to fail receiving data, leading to unrecoverable XRUN condition in FW. For stream tag is stored in both hda codec and SOF driver, it shouldn't be released only in SOF driver. This patch just keeps the stream information in dma data and checks whether there is a stored DMA data for stream resuming from S3 and restores it. And it also removes DMA data when the stream is released. Tested on Whiskey Lake platform. GitHub issue: thesofproject/sof#1594 Signed-off-by: Rander Wang <rander.wang@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
For this bug, there are two capture pcm streams active, with one stream and its related stream tag released before suspend. Later when system suspend is done, the stream tag for the remaining active stream is released by SOF driver. After system resume, hda codec driver restores the stream tag for the active pcm stream, but SOF goes to assign a new one, which now doesn't match with the stream tag used by codec driver, and this causes DMA to fail receiving data, leading to unrecoverable XRUN condition in FW. For stream tag is stored in both hda codec and SOF driver, it shouldn't be released only in SOF driver. This patch just keeps the stream information in dma data and checks whether there is a stored DMA data for stream resuming from S3 and restores it. And it also removes DMA data when the stream is released. Tested on Whiskey Lake platform. GitHub issue: thesofproject/sof#1594 Signed-off-by: Rander Wang <rander.wang@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
For this bug, there are two capture pcm streams active, with one stream and its related stream tag released before suspend. Later when system suspend is done, the stream tag for the remaining active stream is released by SOF driver. After system resume, hda codec driver restores the stream tag for the active pcm stream, but SOF goes to assign a new one, which now doesn't match with the stream tag used by codec driver, and this causes DMA to fail receiving data, leading to unrecoverable XRUN condition in FW. For stream tag is stored in both hda codec and SOF driver, it shouldn't be released only in SOF driver. This patch just keeps the stream information in dma data and checks whether there is a stored DMA data for stream resuming from S3 and restores it. And it also removes DMA data when the stream is released. Tested on Whiskey Lake platform. GitHub issue: thesofproject/sof#1594 Signed-off-by: Rander Wang <rander.wang@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20190722141402.7194-19-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
For this bug, there are two capture pcm streams active, with one stream and its related stream tag released before suspend. Later when system suspend is done, the stream tag for the remaining active stream is released by SOF driver. After system resume, hda codec driver restores the stream tag for the active pcm stream, but SOF goes to assign a new one, which now doesn't match with the stream tag used by codec driver, and this causes DMA to fail receiving data, leading to unrecoverable XRUN condition in FW. For stream tag is stored in both hda codec and SOF driver, it shouldn't be released only in SOF driver. This patch just keeps the stream information in dma data and checks whether there is a stored DMA data for stream resuming from S3 and restores it. And it also removes DMA data when the stream is released. Tested on Whiskey Lake platform. GitHub issue: thesofproject/sof#1594 Signed-off-by: Rander Wang <rander.wang@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20190722141402.7194-19-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org> (cherry picked from commit 934bf82) BUG=b:140723130 TEST=Test Audio use cases for CML with full SOF patch series applied Change-Id: I899bd5bd85f406c08a8f82c033d03ea279ea3268 Signed-off-by: Sachin Kumar <sachin.kumar@intel.com> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2010615 Tested-by: Ben Zhang <benzh@chromium.org> Commit-Queue: Ben Zhang <benzh@chromium.org> Reviewed-by: Ben Zhang <benzh@chromium.org>
Describe the bug
Headset capture not work anymore when suspend & wake up stress test with sound setting opened.
To Reproduce
Reproduction Rate
1/30
Expected behavior
Headset capture should always works after wake up
Impact
Headset capture not work, zero data is recorded. Dmesg keeps out ipc rx: 0x90020000: GLB_TRACE_MSG sof-audio-pci 0000:00:1f.3: ipc rx done: 0x90020000: GLB_TRACE_MSG repeatly.
Environment
FW: 6cc8da1 https://github.com/thesofproject/sof/tree/cml-hda-dmic-001-drop-stable
Kernel: https://github.com/thesofproject/linux/tree/release/sof-v5.0 (top commit: 1cd1a89) + PR1060
TPLG: sof-hda-generic-2ch.tplg, same branch with FW.
Dmesg:
sof logger
sof-logger-s3-mantis.log
mantis-s3-headset-fail-2.log
The text was updated successfully, but these errors were encountered: