From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Sameer Pujar <spujar@nvidia.com>, alsa-devel@alsa-project.org
Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>,
tiwai@suse.de, vkoul@kernel.org, broonie@kernel.org,
Gyeongtaek Lee <gt82.lee@samsung.com>,
Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Subject: Re: [RFC PATCH v2 0/5] ASoC: soc-pcm: fix trigger race conditions with shared BE
Date: Tue, 5 Oct 2021 08:17:42 -0500 [thread overview]
Message-ID: <1efa1c31-7342-05f8-5f73-95e2462d4179@linux.intel.com> (raw)
In-Reply-To: <cce82420-d744-ee43-d514-b77ac4905ffa@nvidia.com>
> I did a quick test of your patches on my Tegra board and seeing issues
> with multiple streams. For instance, I ran it for a 2x1 mixer
> configuration and hitting below:
>
> [ 277.661886] BUG: scheduling while atomic: aplay/1306/0x00000100
> [ 287.713193] BUG: spinlock cpu recursion on CPU#0, aplay/1307
> [ 287.719138] lock: 0xffff00008cc820f0, .magic: dead4ead, .owner:
> aplay/1306, .owner_cpu: 0
> [ 287.727319] CPU: 0 PID: 1307 Comm: aplay Tainted: G W
> 5.15.0-rc3-next-20210927-00026-gffdabce987b1 #12
> [ 287.737783] Hardware name: NVIDIA Jetson AGX Xavier Developer Kit (DT)
> [ 287.744228] Call trace:
> [ 287.746656] dump_backtrace+0x0/0x1c0
> [ 287.750300] show_stack+0x18/0x28
> [ 287.753604] dump_stack_lvl+0x7c/0xa8
> [ 287.757236] dump_stack+0x18/0x34
> [ 287.760536] spin_dump+0x70/0x90
> [ 287.763732] do_raw_spin_lock+0xd8/0x120
> [ 287.767615] _raw_spin_lock_irq+0x60/0x80
> [ 287.771581] snd_pcm_stream_lock_irq+0x20/0x48 [snd_pcm]
> [ 287.776853] snd_pcm_drain+0x1ec/0x348 [snd_pcm]
> [ 287.781421] snd_pcm_common_ioctl+0xacc/0x1938 [snd_pcm]
> [ 287.786685] snd_pcm_ioctl+0x2c/0x48 [snd_pcm]
> [ 287.791101] __arm64_sys_ioctl+0xb0/0xf0
> [ 287.794982] invoke_syscall+0x44/0x108
> [ 287.798683] el0_svc_common.constprop.3+0x74/0x100
> [ 287.803416] do_el0_svc+0x24/0x90
> [ 287.806687] el0_svc+0x20/0x60
> [ 287.809705] el0t_64_sync_handler+0x94/0xb8
> [ 287.813839] el0t_64_sync+0x180/0x184
>
>
> And in some case just below:
>
> [ 1074.212276] BUG: scheduling while atomic: aplay/12327/0x00000100
> [ 1095.227509] rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
> [ 1095.233443] rcu: 0-...0: (1 GPs behind)
> idle=4af/1/0x4000000000000004 softirq=19902/19902 fqs=2626
> [ 1095.242528] rcu: 2-...0: (1 GPs behind)
> idle=9d5/1/0x4000000000000000 softirq=22707/22707 fqs=262
Thanks Sameer for the overnight tests, much appreciated.
My patches don't change anything related to a spinlock or pcm stream
management, so not sure what could cause this rather spectacular
failure. That hints at a fundamental configuration difference, possibly
caused by your component chaining?
Since in your case you have a 1:1 mapping between FE and BE, would you
mind testing by backtracking, one patch at a time to see which one of
the three last patches could cause a problem on your board?
Thanks again for your time!
-Pierre
next prev parent reply other threads:[~2021-10-05 13:18 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-04 22:54 [RFC PATCH v2 0/5] ASoC: soc-pcm: fix trigger race conditions with shared BE Pierre-Louis Bossart
2021-10-04 22:54 ` [RFC PATCH v2 1/5] ASoC: soc-pcm: remove snd_soc_dpcm_fe_can_update() Pierre-Louis Bossart
2021-10-04 22:54 ` [RFC PATCH v2 2/5] ASoC: soc-pcm: don't export local functions, use static Pierre-Louis Bossart
2021-10-04 22:54 ` [RFC PATCH v2 3/5] ASoC: soc-pcm: replace dpcm_lock with dpcm_mutex Pierre-Louis Bossart
2021-10-04 22:54 ` [RFC PATCH v2 4/5] ASoC: soc-pcm: protect for_each_dpcm_be() loops " Pierre-Louis Bossart
2021-10-04 22:54 ` [RFC PATCH v2 5/5] ASoC: soc-pcm: test refcount before triggering Pierre-Louis Bossart
2021-10-05 6:36 ` [RFC PATCH v2 0/5] ASoC: soc-pcm: fix trigger race conditions with shared BE Sameer Pujar
2021-10-05 13:17 ` Pierre-Louis Bossart [this message]
2021-10-06 14:22 ` Sameer Pujar
2021-10-06 19:47 ` Pierre-Louis Bossart
2021-10-07 11:06 ` Takashi Iwai
2021-10-07 13:31 ` Pierre-Louis Bossart
2021-10-07 14:59 ` Takashi Iwai
2021-10-07 15:24 ` Pierre-Louis Bossart
2021-10-07 15:44 ` Takashi Iwai
2021-10-07 18:13 ` Pierre-Louis Bossart
2021-10-07 21:11 ` Takashi Iwai
2021-10-07 21:27 ` Pierre-Louis Bossart
2021-10-08 6:13 ` Takashi Iwai
2021-10-08 14:41 ` Pierre-Louis Bossart
2021-10-08 14:51 ` Takashi Iwai
2021-10-08 15:41 ` Pierre-Louis Bossart
2021-10-08 19:09 ` Pierre-Louis Bossart
2021-10-11 20:06 ` Pierre-Louis Bossart
2021-10-12 6:34 ` Takashi Iwai
2021-10-12 10:42 ` Takashi Iwai
2021-10-12 13:45 ` Pierre-Louis Bossart
2021-10-12 15:07 ` Takashi Iwai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1efa1c31-7342-05f8-5f73-95e2462d4179@linux.intel.com \
--to=pierre-louis.bossart@linux.intel.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=gt82.lee@samsung.com \
--cc=kuninori.morimoto.gx@renesas.com \
--cc=peter.ujfalusi@linux.intel.com \
--cc=spujar@nvidia.com \
--cc=tiwai@suse.de \
--cc=vkoul@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox