Hi Mark,
On 18.12.2019 14:26, Mark Brown wrote:
On Fri, Dec 13, 2019 at 02:05:32AM +0800, Tzung-Bi Shih wrote:
I have no enough resources to test and trace the code temporarily. But is it possible:
- 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
If there are any useful logs for tracking this issue, let me know how to enable them, so I will provide more logs.
- code in later snd_soc_bind_card( ) decided to defer the probe
- soc_cleanup_card_resources( ) may forget to clean the control? (not
sure about this)
There's going to be a race condition where userspace can see the control on the partially built card regardless of if it gets cleaned up or not.
Best regards