Skip to content
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][ARL] DSP panic when freeing dmic capture pipeline #8503

Closed
kv2019i opened this issue Nov 20, 2023 · 2 comments
Closed

[BUG][ARL] DSP panic when freeing dmic capture pipeline #8503

kv2019i opened this issue Nov 20, 2023 · 2 comments
Assignees
Labels
ARL Applies to Intel Arrow Lake platform bug Something isn't working as expected DMIC Digital Microphone DSP panic DSP panic observed P1 Blocker bugs or important features
Milestone

Comments

@kv2019i
Copy link
Collaborator

kv2019i commented Nov 20, 2023

Describe the bug
DSP panic is hit at end of dmic capture pipeline playback. The issue only happens with dmic pipeline, HDA codec capture is ok as is playback.

To Reproduce
arecord -c4 -fS32_LE -r48000 -Dhw:sofhdadsp,6 -traw -d10 /dev/null

Reproduction Rate
100%

Expected behavior
No DSP crash.

Impact
showstopper

Environment

  1. Branch name and commit hash of the 2 repositories: sof (firmware/topology) and linux (kernel driver).
    Kernel: sof-dev f8d998e836de400abc185788b0e9af3d48cb5429
    SOF: 8b1a01f
  2. Name of the topology file
    Topology: sof-hda-generic.tplg
  3. Name of the platform(s) on which the bug is observed.
    Platform: arl

Screenshots or console output

DSP crash log

[  111.324070] <inf> dai_intel_dmic: dai_dmic_update_bits: dai_dmic_update_bits base 10000, reg 2020, mask 2, value 2
[  111.324081] <inf> dma_intel_adsp_gpdma: intel_adsp_gpdma_power_off: intel_adsp_gpdma_power_off: dma dma@7c000 power off
[  111.324108] <inf> eq_iir: eq_iir_reset: comp:0 0x10 eq_iir_reset()
[  111.324135] <err> os: xtensa_excint1_c:  ** FATAL EXCEPTION
[  111.324143] <err> os: xtensa_excint1_c:  ** CPU 0 EXCCAUSE 13 (load/store PIF data error)
[  111.324148] <err> os: xtensa_excint1_c:  **  PC 0xa003ce60 VADDR 0x7c3a0
[  111.324153] <err> os: xtensa_excint1_c:  **  PS 0x60120
[  111.324158] <err> os: xtensa_excint1_c:  **    (INTLEVEL:0 EXCM: 0 UM:1 RING:0 WOE:1 OWB:1 CALLINC:2)
[  111.324163] <err> os: z_xtensa_dump_stack:  **  A0 0xa006a34e  SP 0xa0106530  A2 0xffffffea  A3 (nil)
[  111.324168] <err> os: z_xtensa_dump_stack:  **  A4 0x400ecb40  A5 (nil)  A6 0xa00d5090  A7 0xa0106530
[  111.324173] <err> os: z_xtensa_dump_stack:  **  A8 0x7c000  A9 (nil) A10 0xa00ea2fc A11 0x60123
[  111.324178] <err> os: z_xtensa_dump_stack:  ** A12 0x3 A13 0xa0110b80 A14 0x60320 A15 0x1
[  111.324183] <err> os: z_xtensa_dump_stack:  ** LBEG 0xa003d9ea LEND 0xa003d9f9 LCOUNT 0xa0077c57
[  111.324188] <err> os: z_xtensa_dump_stack:  ** SAR 0x20
[  111.327041] <err> coredump_error: coredump_mem_window_backend_start: #CD:BEGIN#
[  111.327313] <err> coredump_error: coredump_mem_window_backend_end: #CD:END#


Backtrace:0xa003ce5d:0xa0106530 0xa006a34b:0xa0106570 0xa003da16:0xa0106590 0xa0077c56:0xa01065d0 0xa007dfbb:0xa01065f0 0xa007d586:0xa0106610 0xa007a575:0xa0106650 0xa0050acc:0xa0106680 0xa004381d:0xa01066b0 0xa0043993:0xa0106700 0xa004386d:0xa0106730 0xa0043993:0xa0106780 0xa004386d:0xa01067b0 0xa006f31d:0xa0106800 0xa006b4ed:0xa0106850 0xa003e7bd:0xa0106880 0xa003e3ea:0xa01068f0 0xa003e176:0xa0106920 0xa006d2ae:0xa0106950 0xa006c
@kv2019i kv2019i added bug Something isn't working as expected P1 Blocker bugs or important features ARL Applies to Intel Arrow Lake platform labels Nov 20, 2023
@kv2019i kv2019i added this to the v2.9 milestone Nov 20, 2023
@kv2019i kv2019i added the DMIC Digital Microphone label Nov 20, 2023
@mengdonglin mengdonglin added the DSP panic DSP panic observed label Nov 21, 2023
@kv2019i
Copy link
Collaborator Author

kv2019i commented Nov 27, 2023

Reproduced the bug, happens both with SOF main and also with latest mtl-007 branch. Debug continues.

kv2019i added a commit to kv2019i/zephyr that referenced this issue Nov 27, 2023
The DMA interface allows start and stop to be called multiple
times and driver should ensure nothing bad happens if the calls
are not balanced.

Fix an issue with following sequence:
 - dma_start -> device powered up
 - dma_stop  -> device powered down
 - dma_stop  -> call to dw_dma_is_enabled() and crash

Fix the issue by tracking hardware status in the driver, and
blocking the stop if hardware is already powered down. Multiple
starts are already handled in dw_dma_start().

Link: thesofproject/sof#8503
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
@kv2019i kv2019i self-assigned this Nov 27, 2023
kv2019i added a commit to kv2019i/zephyr that referenced this issue Nov 28, 2023
The DMA interface allows start and stop to be called multiple
times and driver should ensure nothing bad happens if the calls
are not balanced.

Fix an issue where after a start-stop sequence the DMA would be
powered down, and then a subsequent stop would result in a crash
as driver accesses registers of a powered down hardware block.

Fix the issue by handling stop without actually reading the hw
registers to check channel status.

Link: thesofproject/sof#8503
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
kv2019i added a commit to kv2019i/zephyr that referenced this issue Dec 7, 2023
The DMA interface allows start and stop to be called multiple
times and driver should ensure nothing bad happens if the calls
are not balanced.

Fix an issue where after a start-stop sequence the DMA would be
powered down, and then a subsequent stop would result in a crash
as driver accesses registers of a powered down hardware block.

Fix the issue by handling stop without actually reading the hw
registers to check channel status.

Link: thesofproject/sof#8503
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
kv2019i added a commit to kv2019i/zephyr that referenced this issue Dec 14, 2023
The DMA interface allows start and stop to be called multiple
times and driver should ensure nothing bad happens if the calls
are not balanced.

Fix an issue where after a start-stop sequence the DMA would be
powered down, and then a subsequent stop would result in a crash
as driver accesses registers of a powered down hardware block.

Fix the issue by handling stop without actually reading the hw
registers to check channel status.

Link: thesofproject/sof#8503
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
kv2019i added a commit to kv2019i/zephyr that referenced this issue Dec 14, 2023
The DMA interface allows start and stop to be called multiple
times and driver should ensure nothing bad happens if the calls
are not balanced.

Fix an issue where after a start-stop sequence the DMA would be
powered down, and then a subsequent stop would result in a crash
as driver accesses registers of a powered down hardware block.

Fix the issue by handling stop without actually reading the hw
registers to check channel status.

Link: thesofproject/sof#8503
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
fabiobaltieri pushed a commit to zephyrproject-rtos/zephyr that referenced this issue Dec 15, 2023
The DMA interface allows start and stop to be called multiple
times and driver should ensure nothing bad happens if the calls
are not balanced.

Fix an issue where after a start-stop sequence the DMA would be
powered down, and then a subsequent stop would result in a crash
as driver accesses registers of a powered down hardware block.

Fix the issue by handling stop without actually reading the hw
registers to check channel status.

Link: thesofproject/sof#8503
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
kv2019i added a commit to kv2019i/sof that referenced this issue Dec 19, 2023
Update Zephyr to bring in total of 169 commits, including
the following related to SOF targets:

dab6f665ca77 xtensa: fix build errors with cache functions
039e5ef1b813 intel_adsp: remove rimage sign() from `west flash`
c7e3ccd51ad4 drivers: dma: intel_adsp_gpdma: fix issue with stop and PM refcounts

Link: thesofproject#8503
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
lgirdwood pushed a commit that referenced this issue Dec 20, 2023
Update Zephyr to bring in total of 169 commits, including
the following related to SOF targets:

dab6f665ca77 xtensa: fix build errors with cache functions
039e5ef1b813 intel_adsp: remove rimage sign() from `west flash`
c7e3ccd51ad4 drivers: dma: intel_adsp_gpdma: fix issue with stop and PM refcounts

Link: #8503
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
@kv2019i
Copy link
Collaborator Author

kv2019i commented Dec 22, 2023

Fix merged via #8650

@kv2019i kv2019i closed this as completed Dec 22, 2023
coreboot-org-bot pushed a commit to coreboot/zephyr-cros that referenced this issue Dec 23, 2023
The DMA interface allows start and stop to be called multiple
times and driver should ensure nothing bad happens if the calls
are not balanced.

Fix an issue where after a start-stop sequence the DMA would be
powered down, and then a subsequent stop would result in a crash
as driver accesses registers of a powered down hardware block.

Fix the issue by handling stop without actually reading the hw
registers to check channel status.

(cherry picked from commit c7e3ccd)

Original-Link: thesofproject/sof#8503
Original-Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
GitOrigin-RevId: c7e3ccd
Change-Id: I9373f09038d2eccf6007c7aac440d1b747e0f3b6
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/zephyr/+/5129136
Tested-by: ChromeOS Prod (Robot) <chromeos-ci-prod@chromeos-bot.iam.gserviceaccount.com>
Commit-Queue: Fabio Baltieri <fabiobaltieri@google.com>
Reviewed-by: Yuval Peress <peress@google.com>
Reviewed-by: Fabio Baltieri <fabiobaltieri@google.com>
Tested-by: Fabio Baltieri <fabiobaltieri@google.com>
Reviewed-by: Keith Short <keithshort@chromium.org>
abonislawski pushed a commit to abonislawski/zephyr that referenced this issue Jan 22, 2024
The DMA interface allows start and stop to be called multiple
times and driver should ensure nothing bad happens if the calls
are not balanced.

Fix an issue where after a start-stop sequence the DMA would be
powered down, and then a subsequent stop would result in a crash
as driver accesses registers of a powered down hardware block.

Fix the issue by handling stop without actually reading the hw
registers to check channel status.

Link: thesofproject/sof#8503
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
abonislawski pushed a commit to abonislawski/zephyr that referenced this issue Jan 22, 2024
The DMA interface allows start and stop to be called multiple
times and driver should ensure nothing bad happens if the calls
are not balanced.

Fix an issue where after a start-stop sequence the DMA would be
powered down, and then a subsequent stop would result in a crash
as driver accesses registers of a powered down hardware block.

Fix the issue by handling stop without actually reading the hw
registers to check channel status.

Link: thesofproject/sof#8503
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
tmleman pushed a commit to tmleman/zephyr that referenced this issue Jan 25, 2024
The DMA interface allows start and stop to be called multiple
times and driver should ensure nothing bad happens if the calls
are not balanced.

Fix an issue where after a start-stop sequence the DMA would be
powered down, and then a subsequent stop would result in a crash
as driver accesses registers of a powered down hardware block.

Fix the issue by handling stop without actually reading the hw
registers to check channel status.

Link: thesofproject/sof#8503
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ARL Applies to Intel Arrow Lake platform bug Something isn't working as expected DMIC Digital Microphone DSP panic DSP panic observed P1 Blocker bugs or important features
Projects
None yet
Development

No branches or pull requests

2 participants