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? > 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?
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
