Hi Arend, Hi Hante,

Do you think you could get some feedback on Broadcom side to the following
question: when is it *not* a good timing to load the Bluetooth firmware via
btattach during the Linux boot on combo Wi-Fi & BT chipsets? Are there some
conditions that a Broadcom combo chip needs to respect to avoid getting in a
stalled Bluetooth state?

I am asking this question because with a BCM43241 rev B5 chip (on a Lenovo
ThinkPad 8 tablet), enabling Bluetooth automatically via scripts during boot
seems quite heavily timing dependent to succeed. The working / non-working
cases are 100% reproducible with Linux 4.6 up to 4.8(rc5) on my setup.

Could you please forward this question internally, if you think some
Broadcom colleagues may have the right knowledge on that topic?

Please find quite a few details below already and earlier in the thread too.
If other inputs would be useful, I would be glad to try to provide them.

> > I've shared my results so far here on StackExchange:
> > 
> > http://unix.stackexchange.com/questions/309219/how-to-enable-bluetooth-
> > automatically-at-boot-for-recent-intel-and-broadcom-ch/309263#309263

> > To sum up in a few words:
> > 1/ launching btattach from a udev rule enables Bluetooth but it gets
> > killed.
> > 2/ launching btattach via systemd works, only when adding a few sec
> > delay.
> > 3/ launching the systemd service from 2/ directly via udev, using the
> > exact same trigger conditions as in 1/ ends up with Bluetooth not
> > working...
> > 
> > What leaves me really puzzled is the difference between 1/ and 3/, as
> > they
> > launch exactly the same command at almost the same time during the boot
> > process, but they give a different result in a 100% reproducible way.
> 
> I am attaching 5 different dmesg outputs to give a sense of the boot
> timing in the different scenarios:
> 
> - dmesg.simple-udev-rule corresponds to 1/ -> OK
> 
> - dmesg.systemd-standalone-rule-with-1s-delay corresponds to 2/ -> OK
> - dmesg.systemd-standalone-rule-no-delay : 2/ without the 1s delay -> KO 
> 
> - dmesg.systemd-triggered-by-udev-rule-no-delay corresponds to 3/ -> KO
> - dmesg.systemd-tigggered-by-udev-rule-with-1s-delay -> OK
> 
> with the line:
>    "bluetooth hci0: firmware: direct-loading firmware brcm/BCM.hcd"
> giving a good indication of when btattach is launched during the sequence.
>  
> Maybe these files will help reveal some clues?

An idea I had at first was that perhaps the firmware loading with btattach
was triggered "too early" during the boot sequence somehow. 

However, scenario 1 with a pure udev rule (not systemd at all) is working
fine consistently and is the fastest among all the cases I've tried.

The scenarios using systemd work only when adding a delay (1s being enough
in my own experiences) and they trigger the firmware loading later than when
using the pure udev rule.

These are the scenarios in between time-wise that lead to the stalled
situations (reproduced using systemd but without adding the 1s delay hack).
btattach is still running in the list of processes, dmesg is showing the BT
firmware loading properly with no errors, but Bluetooth is simply not
working at the end of the boot. bluetoothctl blocks when launched and the
Gnome BT settings page remain grayed out until I kill / relaunch btattach.

I'm making the assumption that something is going wrong when the BT firmware
is loading at the same time than other on-going events on the combo chipet
(on the Wi-Fi side?). Or maybe the "deadlock" is linked to other parts of
the Bluetooth stack still initializing though.

I am out of ideas to deep dive more just by myself, so any hints would be
really appreciated to help solve this weird but annoying issue. Thanks a
lot.

Regards,

Jérôme