To avoid the firmware loading race between Bluetooth and WiFi on Intel
8260, load firmware exclusively when BT_INTEL is enabled.
Signed-off-by: Kai-Heng Feng <[email protected]>
---
.../net/wireless/intel/iwlwifi/pcie/trans.c | 37 ++++++++++++++++++-
1 file changed, 36 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
index cc8c53dc0ab6..c30d3989e2a8 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
@@ -71,6 +71,7 @@
#include <linux/vmalloc.h>
#include <linux/pm_runtime.h>
#include <linux/module.h>
+#include <linux/intel-wifi-bt.h>
#include "iwl-drv.h"
#include "iwl-trans.h"
@@ -1335,6 +1336,10 @@ static int iwl_trans_pcie_start_fw(struct iwl_trans *trans,
bool hw_rfkill;
int ret;
+#if IS_ENABLED(CONFIG_BT_INTEL)
+ void (*firmware_lock_func)(void);
+ void (*firmware_unlock_func)(void);
+#endif
/* This may fail if AMT took ownership of the device */
if (iwl_pcie_prepare_card_hw(trans)) {
IWL_WARN(trans, "Exit HW not ready\n");
@@ -1394,6 +1399,7 @@ static int iwl_trans_pcie_start_fw(struct iwl_trans *trans,
* RF-Kill switch is toggled, we will find out after having loaded
* the firmware and return the proper value to the caller.
*/
+
iwl_enable_fw_load_int(trans);
/* really make sure rfkill handshake bits are cleared */
@@ -1401,8 +1407,37 @@ static int iwl_trans_pcie_start_fw(struct iwl_trans *trans,
iwl_write32(trans, CSR_UCODE_DRV_GP1_CLR, CSR_UCODE_SW_BIT_RFKILL);
/* Load the given image to the HW */
- if (trans->cfg->device_family >= IWL_DEVICE_FAMILY_8000)
+ if (trans->cfg->device_family >= IWL_DEVICE_FAMILY_8000) {
+#if IS_ENABLED(CONFIG_BT_INTEL)
+ firmware_lock_func = symbol_request(btintel_firmware_lock);
+ firmware_unlock_func = symbol_request(btintel_firmware_unlock);
+ if (!firmware_lock_func || !firmware_unlock_func) {
+ if (firmware_lock_func) {
+ symbol_put(btintel_firmware_lock);
+ firmware_lock_func = NULL;
+ }
+
+ if (firmware_unlock_func) {
+ symbol_put(btintel_firmware_unlock);
+ firmware_unlock_func = NULL;
+ }
+ }
+
+ if (firmware_lock_func)
+ firmware_lock_func();
+#endif
ret = iwl_pcie_load_given_ucode_8000(trans, fw);
+
+#if IS_ENABLED(CONFIG_BT_INTEL)
+ if (firmware_unlock_func) {
+ firmware_unlock_func();
+ symbol_put(btintel_firmware_lock);
+ firmware_lock_func = NULL;
+ symbol_put(btintel_firmware_unlock);
+ firmware_unlock_func = NULL;
+ }
+#endif
+ }
else
ret = iwl_pcie_load_given_ucode(trans, fw);
--
2.17.1
On Wed, 2018-10-03 at 15:15 +0800, Kai-Heng Feng wrote:
> To avoid the firmware loading race between Bluetooth and WiFi on Intel
> 8260, load firmware exclusively when BT_INTEL is enabled.
>
> Signed-off-by: Kai-Heng Feng <[email protected]>
> ---
Where is this coming from? Can you explain what "the firmware loading
race" is?
> .../net/wireless/intel/iwlwifi/pcie/trans.c | 37 ++++++++++++++++++-
> 1 file changed, 36 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
> index cc8c53dc0ab6..c30d3989e2a8 100644
> --- a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
> +++ b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
> @@ -71,6 +71,7 @@
> #include <linux/vmalloc.h>
> #include <linux/pm_runtime.h>
> #include <linux/module.h>
> +#include <linux/intel-wifi-bt.h>
I don't see this upstream. Is it something that was recently added?
Looks odd...
Regardless, this should also be protected on CONFIG_BT_INTEL.
> #include "iwl-drv.h"
> #include "iwl-trans.h"
> @@ -1335,6 +1336,10 @@ static int iwl_trans_pcie_start_fw(struct iwl_trans *trans,
> bool hw_rfkill;
> int ret;
>
> +#if IS_ENABLED(CONFIG_BT_INTEL)
> + void (*firmware_lock_func)(void);
> + void (*firmware_unlock_func)(void);
> +#endif
> /* This may fail if AMT took ownership of the device */
> if (iwl_pcie_prepare_card_hw(trans)) {
> IWL_WARN(trans, "Exit HW not ready\n");
> @@ -1394,6 +1399,7 @@ static int iwl_trans_pcie_start_fw(struct iwl_trans *trans,
> * RF-Kill switch is toggled, we will find out after having loaded
> * the firmware and return the proper value to the caller.
> */
> +
Stray empty line.
> iwl_enable_fw_load_int(trans);
>
> /* really make sure rfkill handshake bits are cleared */
> @@ -1401,8 +1407,37 @@ static int iwl_trans_pcie_start_fw(struct iwl_trans *trans,
> iwl_write32(trans, CSR_UCODE_DRV_GP1_CLR, CSR_UCODE_SW_BIT_RFKILL);
>
> /* Load the given image to the HW */
> - if (trans->cfg->device_family >= IWL_DEVICE_FAMILY_8000)
> + if (trans->cfg->device_family >= IWL_DEVICE_FAMILY_8000) {
> +#if IS_ENABLED(CONFIG_BT_INTEL)
> + firmware_lock_func = symbol_request(btintel_firmware_lock);
> + firmware_unlock_func = symbol_request(btintel_firmware_unlock);
> + if (!firmware_lock_func || !firmware_unlock_func) {
> + if (firmware_lock_func) {
> + symbol_put(btintel_firmware_lock);
> + firmware_lock_func = NULL;
> + }
> +
> + if (firmware_unlock_func) {
> + symbol_put(btintel_firmware_unlock);
> + firmware_unlock_func = NULL;
> + }
> + }
> +
> + if (firmware_lock_func)
> + firmware_lock_func();
> +#endif
> ret = iwl_pcie_load_given_ucode_8000(trans, fw);
> +
> +#if IS_ENABLED(CONFIG_BT_INTEL)
> + if (firmware_unlock_func) {
> + firmware_unlock_func();
> + symbol_put(btintel_firmware_lock);
> + firmware_lock_func = NULL;
> + symbol_put(btintel_firmware_unlock);
> + firmware_unlock_func = NULL;
> + }
> +#endif
> + }
> else
> ret = iwl_pcie_load_given_ucode(trans, fw);
>
I'm not sure I like adding this BT-specific stuff here, especially not
without a detailed explanation.
Did you also send the other patches in this series to linux-wireless? I
can't see them...
--
Cheers,
Luca.
> On Oct 3, 2018, at 3:24 PM, Luciano Coelho <[email protected]> wrote:
>
> On Wed, 2018-10-03 at 15:15 +0800, Kai-Heng Feng wrote:
>> To avoid the firmware loading race between Bluetooth and WiFi on Intel
>> 8260, load firmware exclusively when BT_INTEL is enabled.
>>
>> Signed-off-by: Kai-Heng Feng <[email protected]>
>> ---
>
> Where is this coming from? Can you explain what "the firmware loading
> race" is?
Looks like the patch is not correctly threaded. I’ll resend the series.
>
>
>> .../net/wireless/intel/iwlwifi/pcie/trans.c | 37 ++++++++++++++++++-
>> 1 file changed, 36 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
>> index cc8c53dc0ab6..c30d3989e2a8 100644
>> --- a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
>> +++ b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
>> @@ -71,6 +71,7 @@
>> #include <linux/vmalloc.h>
>> #include <linux/pm_runtime.h>
>> #include <linux/module.h>
>> +#include <linux/intel-wifi-bt.h>
>
> I don't see this upstream. Is it something that was recently added?
> Looks odd...
>
> Regardless, this should also be protected on CONFIG_BT_INTEL.
Thanks, I’ll update this one.
>
>
>> #include "iwl-drv.h"
>> #include "iwl-trans.h"
>> @@ -1335,6 +1336,10 @@ static int iwl_trans_pcie_start_fw(struct iwl_trans *trans,
>> bool hw_rfkill;
>> int ret;
>>
>> +#if IS_ENABLED(CONFIG_BT_INTEL)
>> + void (*firmware_lock_func)(void);
>> + void (*firmware_unlock_func)(void);
>> +#endif
>> /* This may fail if AMT took ownership of the device */
>> if (iwl_pcie_prepare_card_hw(trans)) {
>> IWL_WARN(trans, "Exit HW not ready\n");
>> @@ -1394,6 +1399,7 @@ static int iwl_trans_pcie_start_fw(struct iwl_trans *trans,
>> * RF-Kill switch is toggled, we will find out after having loaded
>> * the firmware and return the proper value to the caller.
>> */
>> +
>
> Stray empty line.
>
>> iwl_enable_fw_load_int(trans);
>>
>> /* really make sure rfkill handshake bits are cleared */
>> @@ -1401,8 +1407,37 @@ static int iwl_trans_pcie_start_fw(struct iwl_trans *trans,
>> iwl_write32(trans, CSR_UCODE_DRV_GP1_CLR, CSR_UCODE_SW_BIT_RFKILL);
>>
>> /* Load the given image to the HW */
>> - if (trans->cfg->device_family >= IWL_DEVICE_FAMILY_8000)
>> + if (trans->cfg->device_family >= IWL_DEVICE_FAMILY_8000) {
>> +#if IS_ENABLED(CONFIG_BT_INTEL)
>> + firmware_lock_func = symbol_request(btintel_firmware_lock);
>> + firmware_unlock_func = symbol_request(btintel_firmware_unlock);
>> + if (!firmware_lock_func || !firmware_unlock_func) {
>> + if (firmware_lock_func) {
>> + symbol_put(btintel_firmware_lock);
>> + firmware_lock_func = NULL;
>> + }
>> +
>> + if (firmware_unlock_func) {
>> + symbol_put(btintel_firmware_unlock);
>> + firmware_unlock_func = NULL;
>> + }
>> + }
>> +
>> + if (firmware_lock_func)
>> + firmware_lock_func();
>> +#endif
>> ret = iwl_pcie_load_given_ucode_8000(trans, fw);
>> +
>> +#if IS_ENABLED(CONFIG_BT_INTEL)
>> + if (firmware_unlock_func) {
>> + firmware_unlock_func();
>> + symbol_put(btintel_firmware_lock);
>> + firmware_lock_func = NULL;
>> + symbol_put(btintel_firmware_unlock);
>> + firmware_unlock_func = NULL;
>> + }
>> +#endif
>> + }
>> else
>> ret = iwl_pcie_load_given_ucode(trans, fw);
>>
>
> I'm not sure I like adding this BT-specific stuff here, especially not
> without a detailed explanation.
>
> Did you also send the other patches in this series to linux-wireless? I
> can't see them…
I’ll resend one soon.
Thanks!
Kai-Heng
>
> --
> Cheers,
> Luca.
I think Canonical were facing some wifi fw load error from some 8260
earlier module during the BT still loading the fw.
I believe we had later 8260 sku that fixed this issue.
Hi Kai-Heng,
Can you check with OEM for which SKU they are reporting the issue ?
Kai Heng Feng <[email protected]> 於 2018年10月3日 週三 下午3:28寫道：
>
>
>
> > On Oct 3, 2018, at 3:24 PM, Luciano Coelho <[email protected]> wrote:
> >
> > On Wed, 2018-10-03 at 15:15 +0800, Kai-Heng Feng wrote:
> >> To avoid the firmware loading race between Bluetooth and WiFi on Intel
> >> 8260, load firmware exclusively when BT_INTEL is enabled.
> >>
> >> Signed-off-by: Kai-Heng Feng <[email protected]>
> >> ---
> >
> > Where is this coming from? Can you explain what "the firmware loading
> > race" is?
>
> Looks like the patch is not correctly threaded. I’ll resend the series.
>
> >
> >
> >> .../net/wireless/intel/iwlwifi/pcie/trans.c | 37 ++++++++++++++++++-
> >> 1 file changed, 36 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
> >> index cc8c53dc0ab6..c30d3989e2a8 100644
> >> --- a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
> >> +++ b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
> >> @@ -71,6 +71,7 @@
> >> #include <linux/vmalloc.h>
> >> #include <linux/pm_runtime.h>
> >> #include <linux/module.h>
> >> +#include <linux/intel-wifi-bt.h>
> >
> > I don't see this upstream. Is it something that was recently added?
> > Looks odd...
> >
> > Regardless, this should also be protected on CONFIG_BT_INTEL.
>
> Thanks, I’ll update this one.
>
> >
> >
> >> #include "iwl-drv.h"
> >> #include "iwl-trans.h"
> >> @@ -1335,6 +1336,10 @@ static int iwl_trans_pcie_start_fw(struct iwl_trans *trans,
> >> bool hw_rfkill;
> >> int ret;
> >>
> >> +#if IS_ENABLED(CONFIG_BT_INTEL)
> >> + void (*firmware_lock_func)(void);
> >> + void (*firmware_unlock_func)(void);
> >> +#endif
> >> /* This may fail if AMT took ownership of the device */
> >> if (iwl_pcie_prepare_card_hw(trans)) {
> >> IWL_WARN(trans, "Exit HW not ready\n");
> >> @@ -1394,6 +1399,7 @@ static int iwl_trans_pcie_start_fw(struct iwl_trans *trans,
> >> * RF-Kill switch is toggled, we will find out after having loaded
> >> * the firmware and return the proper value to the caller.
> >> */
> >> +
> >
> > Stray empty line.
> >
> >> iwl_enable_fw_load_int(trans);
> >>
> >> /* really make sure rfkill handshake bits are cleared */
> >> @@ -1401,8 +1407,37 @@ static int iwl_trans_pcie_start_fw(struct iwl_trans *trans,
> >> iwl_write32(trans, CSR_UCODE_DRV_GP1_CLR, CSR_UCODE_SW_BIT_RFKILL);
> >>
> >> /* Load the given image to the HW */
> >> - if (trans->cfg->device_family >= IWL_DEVICE_FAMILY_8000)
> >> + if (trans->cfg->device_family >= IWL_DEVICE_FAMILY_8000) {
> >> +#if IS_ENABLED(CONFIG_BT_INTEL)
> >> + firmware_lock_func = symbol_request(btintel_firmware_lock);
> >> + firmware_unlock_func = symbol_request(btintel_firmware_unlock);
> >> + if (!firmware_lock_func || !firmware_unlock_func) {
> >> + if (firmware_lock_func) {
> >> + symbol_put(btintel_firmware_lock);
> >> + firmware_lock_func = NULL;
> >> + }
> >> +
> >> + if (firmware_unlock_func) {
> >> + symbol_put(btintel_firmware_unlock);
> >> + firmware_unlock_func = NULL;
> >> + }
> >> + }
> >> +
> >> + if (firmware_lock_func)
> >> + firmware_lock_func();
> >> +#endif
> >> ret = iwl_pcie_load_given_ucode_8000(trans, fw);
> >> +
> >> +#if IS_ENABLED(CONFIG_BT_INTEL)
> >> + if (firmware_unlock_func) {
> >> + firmware_unlock_func();
> >> + symbol_put(btintel_firmware_lock);
> >> + firmware_lock_func = NULL;
> >> + symbol_put(btintel_firmware_unlock);
> >> + firmware_unlock_func = NULL;
> >> + }
> >> +#endif
> >> + }
> >> else
> >> ret = iwl_pcie_load_given_ucode(trans, fw);
> >>
> >
> > I'm not sure I like adding this BT-specific stuff here, especially not
> > without a detailed explanation.
> >
> > Did you also send the other patches in this series to linux-wireless? I
> > can't see them…
>
> I’ll resend one soon.
>
> Thanks!
>
> Kai-Heng
>
> >
> > --
> > Cheers,
> > Luca.
>
> On Oct 3, 2018, at 3:29 PM, Matt Chen <[email protected]> wrote:
>
> I think Canonical were facing some wifi fw load error from some 8260
> earlier module during the BT still loading the fw.
> I believe we had later 8260 sku that fixed this issue.
But there are already 8260 that is affected by this bug in the wild.
Search "Bluetooth: hci0: Failed to send firmware data (-38)” and there are lots of user are affected.
Kai-Heng
>
> Hi Kai-Heng,
>
> Can you check with OEM for which SKU they are reporting the issue ?
> Kai Heng Feng <[email protected]> 於 2018年10月3日 週三 下午3:28寫道：
>>
>>
>>
>>> On Oct 3, 2018, at 3:24 PM, Luciano Coelho <[email protected]> wrote:
>>>
>>> On Wed, 2018-10-03 at 15:15 +0800, Kai-Heng Feng wrote:
>>>> To avoid the firmware loading race between Bluetooth and WiFi on Intel
>>>> 8260, load firmware exclusively when BT_INTEL is enabled.
>>>>
>>>> Signed-off-by: Kai-Heng Feng <[email protected]>
>>>> ---
>>>
>>> Where is this coming from? Can you explain what "the firmware loading
>>> race" is?
>>
>> Looks like the patch is not correctly threaded. I’ll resend the series.
>>
>>>
>>>
>>>> .../net/wireless/intel/iwlwifi/pcie/trans.c | 37 ++++++++++++++++++-
>>>> 1 file changed, 36 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
>>>> index cc8c53dc0ab6..c30d3989e2a8 100644
>>>> --- a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
>>>> +++ b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
>>>> @@ -71,6 +71,7 @@
>>>> #include <linux/vmalloc.h>
>>>> #include <linux/pm_runtime.h>
>>>> #include <linux/module.h>
>>>> +#include <linux/intel-wifi-bt.h>
>>>
>>> I don't see this upstream. Is it something that was recently added?
>>> Looks odd...
>>>
>>> Regardless, this should also be protected on CONFIG_BT_INTEL.
>>
>> Thanks, I’ll update this one.
>>
>>>
>>>
>>>> #include "iwl-drv.h"
>>>> #include "iwl-trans.h"
>>>> @@ -1335,6 +1336,10 @@ static int iwl_trans_pcie_start_fw(struct iwl_trans *trans,
>>>> bool hw_rfkill;
>>>> int ret;
>>>>
>>>> +#if IS_ENABLED(CONFIG_BT_INTEL)
>>>> + void (*firmware_lock_func)(void);
>>>> + void (*firmware_unlock_func)(void);
>>>> +#endif
>>>> /* This may fail if AMT took ownership of the device */
>>>> if (iwl_pcie_prepare_card_hw(trans)) {
>>>> IWL_WARN(trans, "Exit HW not ready\n");
>>>> @@ -1394,6 +1399,7 @@ static int iwl_trans_pcie_start_fw(struct iwl_trans *trans,
>>>> * RF-Kill switch is toggled, we will find out after having loaded
>>>> * the firmware and return the proper value to the caller.
>>>> */
>>>> +
>>>
>>> Stray empty line.
>>>
>>>> iwl_enable_fw_load_int(trans);
>>>>
>>>> /* really make sure rfkill handshake bits are cleared */
>>>> @@ -1401,8 +1407,37 @@ static int iwl_trans_pcie_start_fw(struct iwl_trans *trans,
>>>> iwl_write32(trans, CSR_UCODE_DRV_GP1_CLR, CSR_UCODE_SW_BIT_RFKILL);
>>>>
>>>> /* Load the given image to the HW */
>>>> - if (trans->cfg->device_family >= IWL_DEVICE_FAMILY_8000)
>>>> + if (trans->cfg->device_family >= IWL_DEVICE_FAMILY_8000) {
>>>> +#if IS_ENABLED(CONFIG_BT_INTEL)
>>>> + firmware_lock_func = symbol_request(btintel_firmware_lock);
>>>> + firmware_unlock_func = symbol_request(btintel_firmware_unlock);
>>>> + if (!firmware_lock_func || !firmware_unlock_func) {
>>>> + if (firmware_lock_func) {
>>>> + symbol_put(btintel_firmware_lock);
>>>> + firmware_lock_func = NULL;
>>>> + }
>>>> +
>>>> + if (firmware_unlock_func) {
>>>> + symbol_put(btintel_firmware_unlock);
>>>> + firmware_unlock_func = NULL;
>>>> + }
>>>> + }
>>>> +
>>>> + if (firmware_lock_func)
>>>> + firmware_lock_func();
>>>> +#endif
>>>> ret = iwl_pcie_load_given_ucode_8000(trans, fw);
>>>> +
>>>> +#if IS_ENABLED(CONFIG_BT_INTEL)
>>>> + if (firmware_unlock_func) {
>>>> + firmware_unlock_func();
>>>> + symbol_put(btintel_firmware_lock);
>>>> + firmware_lock_func = NULL;
>>>> + symbol_put(btintel_firmware_unlock);
>>>> + firmware_unlock_func = NULL;
>>>> + }
>>>> +#endif
>>>> + }
>>>> else
>>>> ret = iwl_pcie_load_given_ucode(trans, fw);
>>>>
>>>
>>> I'm not sure I like adding this BT-specific stuff here, especially not
>>> without a detailed explanation.
>>>
>>> Did you also send the other patches in this series to linux-wireless? I
>>> can't see them…
>>
>> I’ll resend one soon.
>>
>> Thanks!
>>
>> Kai-Heng
>>
>>>
>>> --
>>> Cheers,
>>> Luca.
>>
Luciano Coelho <[email protected]> writes:
>> +#if IS_ENABLED(CONFIG_BT_INTEL)
>> + if (firmware_unlock_func) {
>> + firmware_unlock_func();
>> + symbol_put(btintel_firmware_lock);
>> + firmware_lock_func = NULL;
>> + symbol_put(btintel_firmware_unlock);
>> + firmware_unlock_func = NULL;
>> + }
>> +#endif
>> + }
>> else
>> ret = iwl_pcie_load_given_ucode(trans, fw);
>>
>
> I'm not sure I like adding this BT-specific stuff here, especially not
> without a detailed explanation.
This looks like an ugly hack and the commit log tells nothing. This
really needs strong justifications to even consider doing something like
this.
--
Kalle Valo
Hi Kai-Heng,
>> I think Canonical were facing some wifi fw load error from some 8260
>> earlier module during the BT still loading the fw.
>> I believe we had later 8260 sku that fixed this issue.
>
> But there are already 8260 that is affected by this bug in the wild.
>
> Search "Bluetooth: hci0: Failed to send firmware data (-38)” and there are lots of user are affected.
which SKUs are these actually. What are the initial details about the boot loader. For the Bluetooth side, you should be able to grab them from dmesg or by running btmon.
So I am not in favor of this kind of hack and creating dependencies between drivers. If you only have a hammer, then everything looks like a nail. And this is a massive hammer trying to squash everything. This problem needs to be debugged. And this starts by providing affected SKU information and firmware information. So get the details about the SKU and its Bluetooth and WiFi boot loaders.
Regards
Marcel
Hi Marcel,
> On Oct 4, 2018, at 2:25 AM, Marcel Holtmann <[email protected]> wrote:
>
> Hi Kai-Heng,
>
>>> I think Canonical were facing some wifi fw load error from some 8260
>>> earlier module during the BT still loading the fw.
>>> I believe we had later 8260 sku that fixed this issue.
>>
>> But there are already 8260 that is affected by this bug in the wild.
>>
>> Search "Bluetooth: hci0: Failed to send firmware data (-38)” and there are lots of user are affected.
>
> which SKUs are these actually. What are the initial details about the boot loader. For the Bluetooth side, you should be able to grab them from dmesg or by running btmon.
Here’s the dmesg | grep Bluetooth:
[ 6.086600] Bluetooth: Core ver 2.22
[ 6.086618] Bluetooth: HCI device and connection manager initialized
[ 6.086621] Bluetooth: HCI socket layer initialized
[ 6.086625] Bluetooth: L2CAP socket layer initialized
[ 6.086632] Bluetooth: SCO socket layer initialized
[ 6.107794] Bluetooth: hci0: Bootloader revision 0.0 build 2 week 52 2014
[ 6.112803] Bluetooth: hci0: Device revision is 5
[ 6.112805] Bluetooth: hci0: Secure boot is enabled
[ 6.112805] Bluetooth: hci0: OTP lock is enabled
[ 6.112806] Bluetooth: hci0: API lock is enabled
[ 6.112807] Bluetooth: hci0: Debug lock is disabled
[ 6.112808] Bluetooth: hci0: Minimum firmware build 1 week 10 2014
[ 6.115231] Bluetooth: hci0: Found device firmware: intel/ibt-11-5.sfi
[ 6.210353] Bluetooth: hci0: Failed to send firmware data (-38)
[ 8.153357] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 8.153358] Bluetooth: BNEP filters: protocol multicast
[ 8.153362] Bluetooth: BNEP socket layer initialized
[ 13.563790] Bluetooth: hci0: Bootloader revision 0.0 build 2 week 52 2014
[ 13.568806] Bluetooth: hci0: Device revision is 5
[ 13.568808] Bluetooth: hci0: Secure boot is enabled
[ 13.568809] Bluetooth: hci0: OTP lock is enabled
[ 13.568810] Bluetooth: hci0: API lock is enabled
[ 13.568811] Bluetooth: hci0: Debug lock is disabled
[ 13.568813] Bluetooth: hci0: Minimum firmware build 1 week 10 2014
[ 13.569072] Bluetooth: hci0: Found device firmware: intel/ibt-11-5.sfi
[ 15.220327] Bluetooth: hci0: Waiting for firmware download to complete
[ 15.220805] Bluetooth: hci0: Firmware loaded in 1618764 usecs
[ 15.220877] Bluetooth: hci0: Waiting for device to boot
[ 15.233031] Bluetooth: hci0: Device booted in 11881 usecs
[ 15.233274] Bluetooth: hci0: Found Intel DDC parameters: intel/ibt-11-5.ddc
[ 15.236794] Bluetooth: hci0: Applying Intel DDC parameters completed
[ 17.232497] Bluetooth: RFCOMM TTY layer initialized
[ 17.232505] Bluetooth: RFCOMM socket layer initialized
[ 17.232510] Bluetooth: RFCOMM ver 1.11
I’ll file a Bugzilla if we need full dmesg as attachment.
>
> So I am not in favor of this kind of hack and creating dependencies between drivers. If you only have a hammer, then everything looks like a nail. And this is a massive hammer trying to squash everything. This problem needs to be debugged. And this starts by providing affected SKU information and firmware information. So get the details about the SKU and its Bluetooth and WiFi boot loaders.
Apology for the hammer approach, which is the best way I can think of. Of course it’s much better if we can solve this without the ugly hack.
Kai-Heng
>
> Regards
>
> Marcel
>
Hello Marcel,
> On Oct 4, 2018, at 2:25 AM, Marcel Holtmann <[email protected]> wrote:
>
> Hi Kai-Heng,
>
>>> I think Canonical were facing some wifi fw load error from some 8260
>>> earlier module during the BT still loading the fw.
>>> I believe we had later 8260 sku that fixed this issue.
>>
>> But there are already 8260 that is affected by this bug in the wild.
>>
>> Search "Bluetooth: hci0: Failed to send firmware data (-38)” and there are lots of user are affected.
>
> which SKUs are these actually. What are the initial details about the boot loader. For the Bluetooth side, you should be able to grab them from dmesg or by running btmon.
>
> So I am not in favor of this kind of hack and creating dependencies between drivers. If you only have a hammer, then everything looks like a nail. And this is a massive hammer trying to squash everything. This problem needs to be debugged. And this starts by providing affected SKU information and firmware information. So get the details about the SKU and its Bluetooth and WiFi boot loaders.
>
I have a Lenovo Yoga 900 which presents this problem and has the same bootloader / firmware information as Kai-Heng already posted:
[ 5.992426] Bluetooth: Core ver 2.22
[ 5.992438] Bluetooth: HCI device and connection manager initialized
[ 5.992442] Bluetooth: HCI socket layer initialized
[ 5.992444] Bluetooth: L2CAP socket layer initialized
[ 5.992450] Bluetooth: SCO socket layer initialized
[ 6.004941] Bluetooth: hci0: Bootloader revision 0.0 build 2 week 52 2014
[ 6.010922] Bluetooth: hci0: Device revision is 5
[ 6.010923] Bluetooth: hci0: Secure boot is enabled
[ 6.010924] Bluetooth: hci0: OTP lock is enabled
[ 6.010925] Bluetooth: hci0: API lock is enabled
[ 6.010926] Bluetooth: hci0: Debug lock is disabled
[ 6.010927] Bluetooth: hci0: Minimum firmware build 1 week 10 2014
[ 6.014253] bluetooth hci0: firmware: direct-loading firmware intel/ibt-11-5.sfi
[ 6.014256] Bluetooth: hci0: Found device firmware: intel/ibt-11-5.sfi
[ 6.613961] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 6.613966] Bluetooth: BNEP filters: protocol multicast
[ 6.613974] Bluetooth: BNEP socket layer initialized
[ 6.983804] Bluetooth: hci0: Failed to send firmware data (-38)
And the following product id and revision, from usb-devices:
T: Bus=01 Lev=01 Prnt=01 Port=06 Cnt=02 Dev#= 3 Spd=12 MxCh= 0
D: Ver= 2.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=8087 ProdID=0a2b Rev=00.01
C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I understand the drawbacks with the approach presented here and lack of clear explanation of the problem, but I can confirm these patches work around the problem on my machine. Is there any extra info or test result I can provide to help debug this? I can also dedicate time to help write a different solution if some guidance is provided.
Kai-Heng, did you end up filling a Bugzilla entry for this?
Please CC-me on the replies as I'm not receiving emails from linux-bluetooth or linux-wireless anymore.
Thanks,
--
João Paulo Rechi Vita
http://about.me/jprvita
+ linux-bluetooth
On Thu, Nov 8, 2018 at 4:08 PM João Paulo Rechi Vita <[email protected]> wrote:
>
> Hello Marcel,
>
> > On Oct 4, 2018, at 2:25 AM, Marcel Holtmann <[email protected]> wrote:
> >
> > Hi Kai-Heng,
> >
> >>> I think Canonical were facing some wifi fw load error from some 8260
> >>> earlier module during the BT still loading the fw.
> >>> I believe we had later 8260 sku that fixed this issue.
> >>
> >> But there are already 8260 that is affected by this bug in the wild.
> >>
> >> Search "Bluetooth: hci0: Failed to send firmware data (-38)” and there are lots of user are affected.
> >
> > which SKUs are these actually. What are the initial details about the boot loader. For the Bluetooth side, you should be able to grab them from dmesg or by running btmon.
> >
> > So I am not in favor of this kind of hack and creating dependencies between drivers. If you only have a hammer, then everything looks like a nail. And this is a massive hammer trying to squash everything. This problem needs to be debugged. And this starts by providing affected SKU information and firmware information. So get the details about the SKU and its Bluetooth and WiFi boot loaders.
> >
>
> I have a Lenovo Yoga 900 which presents this problem and has the same bootloader / firmware information as Kai-Heng already posted:
>
> [ 5.992426] Bluetooth: Core ver 2.22
> [ 5.992438] Bluetooth: HCI device and connection manager initialized
> [ 5.992442] Bluetooth: HCI socket layer initialized
> [ 5.992444] Bluetooth: L2CAP socket layer initialized
> [ 5.992450] Bluetooth: SCO socket layer initialized
> [ 6.004941] Bluetooth: hci0: Bootloader revision 0.0 build 2 week 52 2014
> [ 6.010922] Bluetooth: hci0: Device revision is 5
> [ 6.010923] Bluetooth: hci0: Secure boot is enabled
> [ 6.010924] Bluetooth: hci0: OTP lock is enabled
> [ 6.010925] Bluetooth: hci0: API lock is enabled
> [ 6.010926] Bluetooth: hci0: Debug lock is disabled
> [ 6.010927] Bluetooth: hci0: Minimum firmware build 1 week 10 2014
> [ 6.014253] bluetooth hci0: firmware: direct-loading firmware intel/ibt-11-5.sfi
> [ 6.014256] Bluetooth: hci0: Found device firmware: intel/ibt-11-5.sfi
> [ 6.613961] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
> [ 6.613966] Bluetooth: BNEP filters: protocol multicast
> [ 6.613974] Bluetooth: BNEP socket layer initialized
> [ 6.983804] Bluetooth: hci0: Failed to send firmware data (-38)
>
> And the following product id and revision, from usb-devices:
>
> T: Bus=01 Lev=01 Prnt=01 Port=06 Cnt=02 Dev#= 3 Spd=12 MxCh= 0
> D: Ver= 2.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
> P: Vendor=8087 ProdID=0a2b Rev=00.01
> C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
> I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
>
> I understand the drawbacks with the approach presented here and lack of clear explanation of the problem, but I can confirm these patches work around the problem on my machine. Is there any extra info or test result I can provide to help debug this? I can also dedicate time to help write a different solution if some guidance is provided.
>
> Kai-Heng, did you end up filling a Bugzilla entry for this?
>
> Please CC-me on the replies as I'm not receiving emails from linux-bluetooth or linux-wireless anymore.
>
> Thanks,
>
> --
> João Paulo Rechi Vita
> http://about.me/jprvita
Hi Joao Paulo,
>>>> I think Canonical were facing some wifi fw load error from some 8260
>>>> earlier module during the BT still loading the fw.
>>>> I believe we had later 8260 sku that fixed this issue.
>>>
>>> But there are already 8260 that is affected by this bug in the wild.
>>>
>>> Search "Bluetooth: hci0: Failed to send firmware data (-38)” and there are lots of user are affected.
>>
>> which SKUs are these actually. What are the initial details about the boot loader. For the Bluetooth side, you should be able to grab them from dmesg or by running btmon.
>>
>> So I am not in favor of this kind of hack and creating dependencies between drivers. If you only have a hammer, then everything looks like a nail. And this is a massive hammer trying to squash everything. This problem needs to be debugged. And this starts by providing affected SKU information and firmware information. So get the details about the SKU and its Bluetooth and WiFi boot loaders.
>>
>
> I have a Lenovo Yoga 900 which presents this problem and has the same bootloader / firmware information as Kai-Heng already posted:
>
> [ 5.992426] Bluetooth: Core ver 2.22
> [ 5.992438] Bluetooth: HCI device and connection manager initialized
> [ 5.992442] Bluetooth: HCI socket layer initialized
> [ 5.992444] Bluetooth: L2CAP socket layer initialized
> [ 5.992450] Bluetooth: SCO socket layer initialized
> [ 6.004941] Bluetooth: hci0: Bootloader revision 0.0 build 2 week 52 2014
> [ 6.010922] Bluetooth: hci0: Device revision is 5
> [ 6.010923] Bluetooth: hci0: Secure boot is enabled
> [ 6.010924] Bluetooth: hci0: OTP lock is enabled
> [ 6.010925] Bluetooth: hci0: API lock is enabled
> [ 6.010926] Bluetooth: hci0: Debug lock is disabled
> [ 6.010927] Bluetooth: hci0: Minimum firmware build 1 week 10 2014
> [ 6.014253] bluetooth hci0: firmware: direct-loading firmware intel/ibt-11-5.sfi
> [ 6.014256] Bluetooth: hci0: Found device firmware: intel/ibt-11-5.sfi
> [ 6.613961] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
> [ 6.613966] Bluetooth: BNEP filters: protocol multicast
> [ 6.613974] Bluetooth: BNEP socket layer initialized
> [ 6.983804] Bluetooth: hci0: Failed to send firmware data (-38)
>
> And the following product id and revision, from usb-devices:
>
> T: Bus=01 Lev=01 Prnt=01 Port=06 Cnt=02 Dev#= 3 Spd=12 MxCh= 0
> D: Ver= 2.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
> P: Vendor=8087 ProdID=0a2b Rev=00.01
> C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
> I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
>
> I understand the drawbacks with the approach presented here and lack of clear explanation of the problem, but I can confirm these patches work around the problem on my machine. Is there any extra info or test result I can provide to help debug this? I can also dedicate time to help write a different solution if some guidance is provided.
>
> Kai-Heng, did you end up filling a Bugzilla entry for this?
>
> Please CC-me on the replies as I'm not receiving emails from linux-bluetooth or linux-wireless anymore.
our hardware teams from the Bluetooth and WiFi side really need to look at this. An inter-dependency between the firmware loading of two otherwise independent drivers is really not what I want to see upstream. However I have no idea which boot loaders are affected or if this is something that might be even possible to be fixed in operational firmware. If you can create a binary btmon trace file with the error happening and getting really every single message from the boot we might get a bit further to understand where it goes wrong.
Regards
Marcel
Hello Marcel,
On Fri, Nov 9, 2018 at 4:36 PM João Paulo Rechi Vita <[email protected]> wrote:
>
> Hello Marcel,
>
> On Thu, Nov 8, 2018 at 11:49 PM Marcel Holtmann <[email protected]> wrote:
> >
> > our hardware teams from the Bluetooth and WiFi side really need to look at this.
Were you able to get attention from the hardware teams with the logs
I've provided? Are there any news or an idea of when / if we can
expect this to be fixed in firmware? If not, do you have suggestions
for an alternative solution?
Thanks,
--
João Paulo Rechi Vita
http://about.me/jprvita
Hello Marcel,
On Wed, Dec 5, 2018 at 11:27 AM João Paulo Rechi Vita <[email protected]> wrote:
>
> Hello Marcel,
>
> On Fri, Nov 9, 2018 at 4:36 PM João Paulo Rechi Vita <[email protected]> wrote:
> >
> > Hello Marcel,
> >
> > On Thu, Nov 8, 2018 at 11:49 PM Marcel Holtmann <[email protected]> wrote:
> > >
> > > our hardware teams from the Bluetooth and WiFi side really need to look at this.
>
> Were you able to get attention from the hardware teams with the logs
> I've provided? Are there any news or an idea of when / if we can
> expect this to be fixed in firmware? If not, do you have suggestions
> for an alternative solution?
>
Sorry to bother you again with this, but I'd really like to figure out
some way forward here. Did you get any feedback from the hardware
teams? Otherwise, I understand having an inter-dependency between the
wifi and bt kernel modules is not desirable, so do you have any
suggestion on how to solve this without adding this dependency?
--
João Paulo Rechi Vita
http://about.me/jprvita
Hello,
> > > >
> > > > our hardware teams from the Bluetooth and WiFi side really need to look at this.
> >
> > Were you able to get attention from the hardware teams with the logs
> > I've provided? Are there any news or an idea of when / if we can
> > expect this to be fixed in firmware? If not, do you have suggestions
> > for an alternative solution?
> >
>
> Sorry to bother you again with this, but I'd really like to figure out
> some way forward here. Did you get any feedback from the hardware
> teams? Otherwise, I understand having an inter-dependency between the
> wifi and bt kernel modules is not desirable, so do you have any
> suggestion on how to solve this without adding this dependency?
>
Have you tried the update the BT firmware with what is now available in
mainline linux-firmware.git?
I heard that this problem has now been resolved. After you update the
BT firmware, you need a full power cycle.
On Wed, Jan 9, 2019 at 10:39 AM Emmanuel Grumbach <[email protected]> wrote:
>
> Hello,
>
> > > > >
> > > > > our hardware teams from the Bluetooth and WiFi side really need to look at this.
> > >
> > > Were you able to get attention from the hardware teams with the logs
> > > I've provided? Are there any news or an idea of when / if we can
> > > expect this to be fixed in firmware? If not, do you have suggestions
> > > for an alternative solution?
> > >
> >
> > Sorry to bother you again with this, but I'd really like to figure out
> > some way forward here. Did you get any feedback from the hardware
> > teams? Otherwise, I understand having an inter-dependency between the
> > wifi and bt kernel modules is not desirable, so do you have any
> > suggestion on how to solve this without adding this dependency?
> >
>
> Have you tried the update the BT firmware with what is now available in
> mainline linux-firmware.git?
> I heard that this problem has now been resolved. After you update the
> BT firmware, you need a full power cycle.
Thanks for the reply. The latest firmware files I see upstream are
from commit c34a52ab7d, which are the same I had tested with
previously. I'm still able to hit the problem, but after the firmware
failed to load the Bluetooth adapter got disconnected from the USB bus
and then re-connected. Since the iwlwifi firmware loading routine had
already finished at this point, the Bluetooth firmware loaded
successfully. I had seen this behavior a few times in my previous
test, but not always (for example that behavior did not trigger on the
test I had previously shared logs for). So, maybe that is the fix that
has been implemented in the firmware? And perhaps some other changes
in the kernel where preventing that behavior from triggering all the
time? I'm pasting logs bellow where both modules where blacklisted and
manually loaded with "modprobe iwlwifi & modprobe btusb":
Jan 09 16:54:24 endless kernel: Bluetooth: Core ver 2.22
Jan 09 16:54:24 endless kernel: NET: Registered protocol family 31
Jan 09 16:54:24 endless kernel: Bluetooth: HCI device and connection
manager initialized
Jan 09 16:54:24 endless kernel: Bluetooth: HCI socket layer initialized
Jan 09 16:54:24 endless kernel: Bluetooth: L2CAP socket layer initialized
Jan 09 16:54:24 endless kernel: Bluetooth: SCO socket layer initialized
Jan 09 16:54:24 endless kernel: cfg80211: Loading compiled-in X.509
certificates for regulatory database
Jan 09 16:54:24 endless kernel: cfg80211: Loaded X.509 cert 'sforshee:
00b28ddf47aef9cea7'
Jan 09 16:54:24 endless kernel: platform regulatory.0: Direct firmware
load for regulatory.db failed with error -2
Jan 09 16:54:24 endless kernel: cfg80211: failed to load regulatory.db
Jan 09 16:54:24 endless kernel: usbcore: registered new interface driver btusb
Jan 09 16:54:24 endless kernel: Bluetooth: hci0: Bootloader revision
0.0 build 2 week 52 2014
Jan 09 16:54:24 endless kernel: Bluetooth: hci0: Device revision is 5
Jan 09 16:54:24 endless kernel: Bluetooth: hci0: Secure boot is enabled
Jan 09 16:54:24 endless kernel: Bluetooth: hci0: OTP lock is enabled
Jan 09 16:54:24 endless kernel: Bluetooth: hci0: API lock is enabled
Jan 09 16:54:24 endless kernel: Bluetooth: hci0: Debug lock is disabled
Jan 09 16:54:24 endless kernel: Bluetooth: hci0: Minimum firmware
build 1 week 10 2014
Jan 09 16:54:24 endless kernel: Intel(R) Wireless WiFi driver for Linux
Jan 09 16:54:24 endless kernel: Copyright(c) 2003- 2015 Intel Corporation
Jan 09 16:54:24 endless kernel: Bluetooth: hci0: Found device
firmware: intel/ibt-11-5.sfi
Jan 09 16:54:25 endless kernel: iwlwifi 0000:01:00.0: loaded firmware
version 36.7596afd4.0 op_mode iwlmvm
Jan 09 16:54:25 endless kernel: iwlwifi 0000:01:00.0: Detected
Intel(R) Dual Band Wireless AC 8260, REV=0x208
Jan 09 16:54:25 endless kernel: Bluetooth: BNEP (Ethernet Emulation) ver 1.3
Jan 09 16:54:25 endless kernel: Bluetooth: BNEP filters: protocol multicast
Jan 09 16:54:25 endless kernel: Bluetooth: BNEP socket layer initialized
Jan 09 16:54:25 endless kernel: Bluetooth: hci0: Failed to send
firmware data (-38)
Jan 09 16:54:25 endless kernel: iwlwifi 0000:01:00.0: base HW address:
a4:34:d9:81:bf:a5
Jan 09 16:54:25 endless kernel: ieee80211 phy0: Selected rate control
algorithm 'iwl-mvm-rs'
Jan 09 16:54:25 endless kernel: thermal thermal_zone6: failed to read
out thermal zone (-61)
Jan 09 16:54:25 endless kernel: iwlwifi 0000:01:00.0 wlp1s0: renamed from wlan0
Jan 09 16:54:25 endless kernel: IPv6: ADDRCONF(NETDEV_UP): wlp1s0:
link is not ready
Jan 09 16:54:25 endless kernel: IPv6: ADDRCONF(NETDEV_UP): wlp1s0:
link is not ready
Jan 09 16:54:25 endless kernel: IPv6: ADDRCONF(NETDEV_UP): wlp1s0:
link is not ready
Jan 09 16:54:31 endless kernel: usb 1-7: USB disconnect, device number 3
Jan 09 16:54:32 endless kernel: usb 1-7: new full-speed USB device
number 7 using xhci_hcd
Jan 09 16:54:32 endless kernel: usb 1-7: New USB device found,
idVendor=8087, idProduct=0a2b, bcdDevice= 0.01
Jan 09 16:54:32 endless kernel: usb 1-7: New USB device strings:
Mfr=0, Product=0, SerialNumber=0
Jan 09 16:54:32 endless kernel: Bluetooth: hci0: Bootloader revision
0.0 build 2 week 52 2014
Jan 09 16:54:32 endless kernel: Bluetooth: hci0: Device revision is 5
Jan 09 16:54:32 endless kernel: Bluetooth: hci0: Secure boot is enabled
Jan 09 16:54:32 endless kernel: Bluetooth: hci0: OTP lock is enabled
Jan 09 16:54:32 endless kernel: Bluetooth: hci0: API lock is enabled
Jan 09 16:54:32 endless kernel: Bluetooth: hci0: Debug lock is disabled
Jan 09 16:54:32 endless kernel: Bluetooth: hci0: Minimum firmware
build 1 week 10 2014
Jan 09 16:54:32 endless kernel: Bluetooth: hci0: Found device
firmware: intel/ibt-11-5.sfi
Jan 09 16:54:34 endless kernel: Bluetooth: hci0: Waiting for firmware
download to complete
Jan 09 16:54:34 endless kernel: Bluetooth: hci0: Firmware loaded in
1820173 usecs
Jan 09 16:54:34 endless kernel: Bluetooth: hci0: Waiting for device to boot
Jan 09 16:54:34 endless kernel: Bluetooth: hci0: Device booted in 11761 usecs
Jan 09 16:54:34 endless kernel: Bluetooth: hci0: Found Intel DDC
parameters: intel/ibt-11-5.ddc
Jan 09 16:54:34 endless kernel: Bluetooth: hci0: Applying Intel DDC
parameters completed
Jan 09 16:54:34 endless kernel: Bluetooth: RFCOMM TTY layer initialized
Jan 09 16:54:34 endless kernel: Bluetooth: RFCOMM socket layer initialized
Jan 09 16:54:34 endless kernel: Bluetooth: RFCOMM ver 1.11
--
João Paulo Rechi Vita
http://about.me/jprvita