Steps to reproduce:
1. rfkill block bluetooth
2. start bluetoothd
3. kill bluetoothd
Hi Luiz,
On Tue, Oct 20, 2009, Luiz Augusto von Dentz wrote:
> On Tue, Oct 20, 2009 at 10:38 AM, Johan Hedberg <[email protected]> wrote:
> > Hi,
> >
> > On Fri, Oct 16, 2009, Valmantas Palik?a wrote:
> >> Steps to reproduce:
> >> 1. rfkill block bluetooth
> >> 2. start bluetoothd
> >> 3. kill bluetoothd
> >
> > I don't seem to have rfkill support (at least using that command) on my
> > laptop so I can't verify this fix, but could you try the attached patch
> > and see if it resolves the issue? The problem seems to be that in this use
> > case we never load/probe the adapter drivers but still call their remove
> > callbacks when the adapter initialization fails. This causes some drivers
> > to call btd_adapter_unref on adapter objects for which they do not own a
> > reference.
>
> Yep, it fixes the problem.
Great! The patch is now pushed upstream.
Johan
Hi,
On Tue, Oct 20, 2009 at 10:38 AM, Johan Hedberg <[email protected]> wrote:
> Hi,
>
> On Fri, Oct 16, 2009, Valmantas Palikša wrote:
>> Steps to reproduce:
>> 1. rfkill block bluetooth
>> 2. start bluetoothd
>> 3. kill bluetoothd
>
> I don't seem to have rfkill support (at least using that command) on my
> laptop so I can't verify this fix, but could you try the attached patch
> and see if it resolves the issue? The problem seems to be that in this use
> case we never load/probe the adapter drivers but still call their remove
> callbacks when the adapter initialization fails. This causes some drivers
> to call btd_adapter_unref on adapter objects for which they do not own a
> reference.
Yep, it fixes the problem.
--
Luiz Augusto von Dentz
Engenheiro de Computação
Hi,
On Fri, Oct 16, 2009, Valmantas Palik?a wrote:
> Steps to reproduce:
> 1. rfkill block bluetooth
> 2. start bluetoothd
> 3. kill bluetoothd
I don't seem to have rfkill support (at least using that command) on my
laptop so I can't verify this fix, but could you try the attached patch
and see if it resolves the issue? The problem seems to be that in this use
case we never load/probe the adapter drivers but still call their remove
callbacks when the adapter initialization fails. This causes some drivers
to call btd_adapter_unref on adapter objects for which they do not own a
reference.
Johan