Re: [alsa-devel] next/master boot bisection: next-20190528 on sun8i-h3-libretech-all-h3-cc

From: Pierre-Louis Bossart
Date: Fri Jun 07 2019 - 16:13:04 EST

This is a multi-part message in MIME format.

On 6/7/19 2:00 PM, Mark Brown wrote:
On Fri, Jun 07, 2019 at 05:31:12PM +0100, Guillaume Tucker wrote:
On 30/05/2019 16:53, Takashi Iwai wrote:

+ mutex_lock(&client_mutex);
for_each_rtdcom(rtd, rtdcom) {
component = rtdcom->component;
if (component->driver->remove_order == order)
+ mutex_unlock(&client_mutex);

Ranjani, which code path your patch tries to address? Maybe better to
wrap client_mutex() in the caller side like snd_soc_unbind_card()?

Is anyone looking into this issue?

It is still occurring in next-20190606, there was a bisection
today which landed on the same commit. There just hasn't been
any new bisection reports because they have been temporarily
disabled while we fix some issues on

I was expecting that Ranjani or one of the other Intel people was
looking into it...

Ack. We've all been underwater this week and this wasn't addressed, sorry about the delay. It's probably wise to revert this commit at this point while we look for an alternate solution?

There was an initial proposal submitted on GitHub [1] (patch attached) which implemented what Takashi suggested in his comments. This proposal was later optimized further, it could be that the optimization was one bridge too far.

Could you let us know if this attached patch has any negative effects on non-Intel platforms?