Hi Mark,
On 18.12.2019 17:24, Mark Brown wrote:
On Wed, Dec 18, 2019 at 03:48:14PM +0100, Marek Szyprowski wrote:
On 18.12.2019 14:26, Mark Brown wrote:
- snd_card_new( ) succeed in snd_soc_bind_card( ), so that userspace
can see the control
This feels like snd_card_new() is being overly enthusiastic here, I'd expect that we might have other problems elsewhere with that. I'd not expect userspace to see things until snd_card_register() since between _new() and that we're in the process of building the card up. Given this we *will* need to handle partially constructed cards after all, unless we change the ALSA core. Takashi?
I'm not sure if this is an issue about partially registered card. Here is the boot log:
https://paste.debian.net/1121543/
This oops happens when udev tries to do its job. The card is earlier fully registered and advertised by alsa:
[ 3.501198] ALSA device list: [ 3.501300] #0: Odroid-U3
That's not what the analysis I was replying to said :(
This log makes no sense to me, if this is the same card that was registered and announced earlier what caused it to become unregistered so that we are registering it now?
I've checked again the exact probe order and here is what happens in the system:
1. first call to odroid_audio_probe() is just after:
[ 2.942428] samsung-i2s 3830000.i2s-sec: DMA channels sourced from device 3830000.i2s
2. That time, i2s dai and max98090 devices are already registered. However the snd_soc_of_get_dai_link_codecs() return -EPROBE_DEFER, because it cannot get the HDMI codec component.
3. HDMI codec is being registered when Exynos DRM initializes. This happens later:
[ 3.127833] [drm] Initialized exynos 1.1.0 20180330 for exynos-drm on minor 0
4. Then odroid_audio_probe() is called again from the deferred probe worker and succeeds:
[ 3.501198] ALSA device list: [ 3.501300] #0: Odroid-U3
5. Then userspace starts:
[ 3.603825] Run /sbin/init as init process
6. when userspace init scripts (alsactl) enumerates devices in the system the lockdep warning is triggered:
[ 10.068990] ====================================================== [ 10.070970] WARNING: possible circular locking dependency detected [ 10.077136] 5.5.0-rc2-next-20191218 #7188 Not tainted [ 10.082168] ------------------------------------------------------ [ 10.088332] alsactl/1106 is trying to acquire lock:
7. then alsa utils probably tries to load the saved values for the controls, what triggers the NULL ptr dereference:
[....] Setting up ALSA...[ 10.502672] 8<--- cut here --- [ 10.502772] Unable to handle kernel NULL pointer dereference at virtual address 000000b0
If there are any useful logs for tracking this issue, let me know how to enable them, so I will provide more logs.
It'd be good to understand this unregistration/probe deferral for a start... when did the card get unregistered and why?
I hope that the above description helps.
The same issue happens on OdroidXU, which uses simple-audio-card, so this is not related to odroid_audio_card only.
Best regards