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 -- Marek Szyprowski, PhD Samsung R&D Institute Poland _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
