On Thu, Dec 19, 2019 at 09:03:42AM +0100, Marek Szyprowski wrote: > On 18.12.2019 17:24, Mark Brown wrote: > 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 OK, so this is probably related to some of Morimoto-san's bisections. Is there any chance you coudld do a bisect to try to isolate where things go wrong?
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx https://mailman.alsa-project.org/mailman/listinfo/alsa-devel