question about alsa tracepoints and alsa debugging

[Lars-Peter Clausen]

On 12/23/20 5:31 AM, Bert Schiettecatte wrote:
> Hi all,
>
> I have a rk3288 board I am working with, it has two ADCs and one DAC.
> The ADCs are connected via an FPGA to the rk3288. The DAC is directly
> connected to the I2S port of the rk3288. The rk3288 generates the
> master clock. I am using buildroot and busybox and kernel 5.9.12
> (stable).
>
> I have a driver which receives the ADC data from the FPGA via SDIO.
> When I run speaker-test in the background and use arecord to record
> simultaneously in the foreground, both arecord and speaker-test seem
> to lock up. When I run speaker-test alone I do not have a problem. The
> playback device uses the rockchip_i2s.c driver while the capture
> device uses my SDIO driver.
>
> My driver based on dw_mmc.c calls snd_pcm_period_elapsed() for each
> buffer of frames that is ready. I can see that this is being called
> for a while when I start arecord in the foreground, until the lockup
> occurs. The moment I start arecord, the console output from
> speaker-test stops, so it's locked up by starting arecord.
Are these implemented as two separate sound cards? If so I don't see how 
they could interfere with each other. There should not be any shared 
resources or locks between them at least on the ALSA side.
> Previously this was working fine on kernel 4.11. However, since I updated to
> kernel 5.9.12 this no longer works. Has anything changed between 4.11
> and 5.9.12 that could be the cause of the problem?

There are almost 300k commits between v4.11 and v5.9.12 one of them 
surely could have added a new issue :)

If possible try to narrow this down a bit more, this will help to track 
this down. If this is a more general issue it is quite likely that this 
is a more recently introduced problem, otherwise others would have 
already run into it. Maybe try one of the stable kernels like v5.4.

>
> commands used for starting playback / trace capture and for recording -
> ./perf record -F 99 -g -e snd_pcm:* -e sched:sched_switch -e
> sched:sched_wakeup -e irq:* speaker-test -D
> hw:CARD=ak4458ak5558aud,DEV=0 -c8 -r192000 -FS32_LE -tsine &
> arecord -Dhw:CARD=ak4458ak5558aud,DEV=1 -fS32_LE -c16 -r192000
> /mnt/ramdisk/rec.wav
>
> I enabled the kernel options as described at
> https://www.kernel.org/doc/html/v5.9/sound/designs/tracepoints.html
> and have used perf to record a trace, which can be access here -
> https://kernel-debugging.s3-us-west-1.amazonaws.com/perf.data.script.211220202054.txt
> (exported using "perf script")
>
> The trace file shows "lockdep_recursion" at some point so I am
> wondering if my problem has to do with a deadlock somehow being
> caused.

lockdep_recursion is not even a function. I think this is just an 
incorrectly resolved stack trace.

To check if there is a locking issue somewhere compile your kernel with 
CONFIG_PROVE_LOCKING=y

Do both devices I2S and MMC use the same DMA? If so I could see things 
going wrong there since that would be shared resources in the DMA 
driver. If possible try to run the MMC driver without DMA and see what 
happens.

- Lars