It seems that a few more Intel chips require the workaround for the
broken initial command. At least, per openSUSE Bugzilla reports,
8087:0a2a and 8087:0026 need BTUSB_INTEL_BROKEN_INITIAL_NCMD flag.
Fixes: 83f2dafe2a62 ("Bluetooth: btintel: Refactoring setup routine for legacy ROM sku")
Buglink: https://bugzilla.opensuse.org/show_bug.cgi?id=1193124
Signed-off-by: Takashi Iwai <[email protected]>
---
drivers/bluetooth/btusb.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 75c83768c257..b26989b2df23 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -359,14 +359,16 @@ static const struct usb_device_id blacklist_table[] = {
/* Intel Bluetooth devices */
{ USB_DEVICE(0x8087, 0x0025), .driver_info = BTUSB_INTEL_COMBINED },
- { USB_DEVICE(0x8087, 0x0026), .driver_info = BTUSB_INTEL_COMBINED },
+ { USB_DEVICE(0x8087, 0x0026), .driver_info = BTUSB_INTEL_COMBINED |
+ BTUSB_INTEL_BROKEN_INITIAL_NCMD },
{ USB_DEVICE(0x8087, 0x0029), .driver_info = BTUSB_INTEL_COMBINED },
{ USB_DEVICE(0x8087, 0x0032), .driver_info = BTUSB_INTEL_COMBINED },
{ USB_DEVICE(0x8087, 0x0033), .driver_info = BTUSB_INTEL_COMBINED },
{ USB_DEVICE(0x8087, 0x07da), .driver_info = BTUSB_CSR },
{ USB_DEVICE(0x8087, 0x07dc), .driver_info = BTUSB_INTEL_COMBINED |
BTUSB_INTEL_BROKEN_INITIAL_NCMD },
- { USB_DEVICE(0x8087, 0x0a2a), .driver_info = BTUSB_INTEL_COMBINED },
+ { USB_DEVICE(0x8087, 0x0a2a), .driver_info = BTUSB_INTEL_COMBINED |
+ BTUSB_INTEL_BROKEN_INITIAL_NCMD },
{ USB_DEVICE(0x8087, 0x0a2b), .driver_info = BTUSB_INTEL_COMBINED },
{ USB_DEVICE(0x8087, 0x0aa7), .driver_info = BTUSB_INTEL_COMBINED },
{ USB_DEVICE(0x8087, 0x0aaa), .driver_info = BTUSB_INTEL_COMBINED },
--
2.31.1
Dear Takashi,
Am 02.12.21 um 17:22 schrieb Takashi Iwai:
> It seems that a few more Intel chips require the workaround for the
> broken initial command. At least, per openSUSE Bugzilla reports,
> 8087:0a2a and 8087:0026 need BTUSB_INTEL_BROKEN_INITIAL_NCMD flag.
>
> Fixes: 83f2dafe2a62 ("Bluetooth: btintel: Refactoring setup routine for legacy ROM sku")
> Buglink: https://bugzilla.opensuse.org/show_bug.cgi?id=1193124
> Signed-off-by: Takashi Iwai <[email protected]>
>
[…]
I have a Dell Latitude E7250 with
Bus 001 Device 003: ID 8087:0a2a Intel Corp. Bluetooth wireless
interface
and Bluetooth seems to work fine minus some Linux warnings [1] and a
problem transferring greater than some bytes files with the Nokia N9 [2].
Linux 5.16-rc3, Dell Inc. Latitude E7250/0TVD2T, BIOS A19 01/23/2018:
```
$ sudo dmesg | grep -i bluet
[ 8.173417] calling bt_init+0x0/0xb3 [bluetooth] @ 301
[ 8.173439] Bluetooth: Core ver 2.22
[ 8.173463] NET: Registered PF_BLUETOOTH protocol family
[ 8.173464] Bluetooth: HCI device and connection manager initialized
[ 8.173467] Bluetooth: HCI socket layer initialized
[ 8.173470] Bluetooth: L2CAP socket layer initialized
[ 8.173473] Bluetooth: SCO socket layer initialized
[ 8.173475] initcall bt_init+0x0/0xb3 [bluetooth] returned 0 after 35
usecs
[ 8.216875] Bluetooth: hci0: Legacy ROM 2.5 revision 1.0 build 3 week
17 2014
[ 8.233515] bluetooth hci0: firmware: direct-loading firmware
intel/ibt-hw-37.8.10-fw-1.10.3.11.e.bseq
[ 8.233520] Bluetooth: hci0: Intel Bluetooth firmware file:
intel/ibt-hw-37.8.10-fw-1.10.3.11.e.bseq
[ 8.540884] Bluetooth: hci0: unexpected event for opcode 0xfc2f
[ 8.558942] Bluetooth: hci0: Intel BT fw patch 0x32 completed & activated
```
Kind regards,
Paul
[1]: https://bugzilla.kernel.org/show_bug.cgi?id=215189
[2]:
https://lore.kernel.org/linux-bluetooth/[email protected]/T/#t
On Thu, 02 Dec 2021 17:32:14 +0100,
Paul Menzel wrote:
>
> Dear Takashi,
>
>
> Am 02.12.21 um 17:22 schrieb Takashi Iwai:
> > It seems that a few more Intel chips require the workaround for the
> > broken initial command. At least, per openSUSE Bugzilla reports,
> > 8087:0a2a and 8087:0026 need BTUSB_INTEL_BROKEN_INITIAL_NCMD flag.
> >
> > Fixes: 83f2dafe2a62 ("Bluetooth: btintel: Refactoring setup routine for legacy ROM sku")
> > Buglink: https://bugzilla.opensuse.org/show_bug.cgi?id=1193124
> > Signed-off-by: Takashi Iwai <[email protected]>
> >
>
> […]
>
> I have a Dell Latitude E7250 with
>
> Bus 001 Device 003: ID 8087:0a2a Intel Corp. Bluetooth wireless
> interface
>
> and Bluetooth seems to work fine minus some Linux warnings [1] and a
> problem transferring greater than some bytes files with the Nokia N9
> [2].
>
> Linux 5.16-rc3, Dell Inc. Latitude E7250/0TVD2T, BIOS A19 01/23/2018:
>
> ```
> $ sudo dmesg | grep -i bluet
> [ 8.173417] calling bt_init+0x0/0xb3 [bluetooth] @ 301
> [ 8.173439] Bluetooth: Core ver 2.22
> [ 8.173463] NET: Registered PF_BLUETOOTH protocol family
> [ 8.173464] Bluetooth: HCI device and connection manager initialized
> [ 8.173467] Bluetooth: HCI socket layer initialized
> [ 8.173470] Bluetooth: L2CAP socket layer initialized
> [ 8.173473] Bluetooth: SCO socket layer initialized
> [ 8.173475] initcall bt_init+0x0/0xb3 [bluetooth] returned 0 after
> 35 usecs
> [ 8.216875] Bluetooth: hci0: Legacy ROM 2.5 revision 1.0 build 3
> week 17 2014
> [ 8.233515] bluetooth hci0: firmware: direct-loading firmware
> intel/ibt-hw-37.8.10-fw-1.10.3.11.e.bseq
> [ 8.233520] Bluetooth: hci0: Intel Bluetooth firmware file:
> intel/ibt-hw-37.8.10-fw-1.10.3.11.e.bseq
> [ 8.540884] Bluetooth: hci0: unexpected event for opcode 0xfc2f
> [ 8.558942] Bluetooth: hci0: Intel BT fw patch 0x32 completed & activated
> ```
Thanks, so this seems depending on the hardware, maybe a subtle
difference matters. As far as I read the code changes, the workaround
was applied in the past unconditionally, so it must be fairly safe
even if the chip works as is.
Or, for avoiding the unnecessarily application of the workaround,
should it be changed as a fallback after the failure at the first
try...?
Takashi
Dear Takashi,
Am 02.12.21 um 17:47 schrieb Takashi Iwai:
> On Thu, 02 Dec 2021 17:32:14 +0100, Paul Menzel wrote:
>> Am 02.12.21 um 17:22 schrieb Takashi Iwai:
>>> It seems that a few more Intel chips require the workaround for the
>>> broken initial command. At least, per openSUSE Bugzilla reports,
>>> 8087:0a2a and 8087:0026 need BTUSB_INTEL_BROKEN_INITIAL_NCMD flag.
>>>
>>> Fixes: 83f2dafe2a62 ("Bluetooth: btintel: Refactoring setup routine for legacy ROM sku")
>>> Buglink: https://bugzilla.opensuse.org/show_bug.cgi?id=1193124
>>> Signed-off-by: Takashi Iwai <[email protected]>
>>>
>>
>> […]
>>
>> I have a Dell Latitude E7250 with
>>
>> Bus 001 Device 003: ID 8087:0a2a Intel Corp. Bluetooth wireless interface
>>
>> and Bluetooth seems to work fine minus some Linux warnings [1] and a
>> problem transferring greater than some bytes files with the Nokia N9
>> [2].
>>
>> Linux 5.16-rc3, Dell Inc. Latitude E7250/0TVD2T, BIOS A19 01/23/2018:
>>
>> ```
>> $ sudo dmesg | grep -i bluet
>> [ 8.173417] calling bt_init+0x0/0xb3 [bluetooth] @ 301
>> [ 8.173439] Bluetooth: Core ver 2.22
>> [ 8.173463] NET: Registered PF_BLUETOOTH protocol family
>> [ 8.173464] Bluetooth: HCI device and connection manager initialized
>> [ 8.173467] Bluetooth: HCI socket layer initialized
>> [ 8.173470] Bluetooth: L2CAP socket layer initialized
>> [ 8.173473] Bluetooth: SCO socket layer initialized
>> [ 8.173475] initcall bt_init+0x0/0xb3 [bluetooth] returned 0 after 35 usecs
>> [ 8.216875] Bluetooth: hci0: Legacy ROM 2.5 revision 1.0 build 3 week 17 2014
>> [ 8.233515] bluetooth hci0: firmware: direct-loading firmware intel/ibt-hw-37.8.10-fw-1.10.3.11.e.bseq
>> [ 8.233520] Bluetooth: hci0: Intel Bluetooth firmware file: intel/ibt-hw-37.8.10-fw-1.10.3.11.e.bseq
>> [ 8.540884] Bluetooth: hci0: unexpected event for opcode 0xfc2f
>> [ 8.558942] Bluetooth: hci0: Intel BT fw patch 0x32 completed & activated
>> ```
>
> Thanks, so this seems depending on the hardware, maybe a subtle
> difference matters. As far as I read the code changes, the workaround
> was applied in the past unconditionally, so it must be fairly safe
> even if the chip works as is.
Maybe add that to the commit message?
> Or, for avoiding the unnecessarily application of the workaround,
> should it be changed as a fallback after the failure at the first
> try...?
Reading through the openSUSE Bugzilla issue, the failure is:
Bluetooth: hci0: Reading Intel version command failed (-110)
Bluetooth: hci0: command 0xfc05 tx timeout
I couldn’t find the report for 8087:0a2a in the issue. Can you check,
what firmware is used?
If the functionality of 5.14 is restored by your patch, then it should
work I guess. I didn’t use Bluetooth for file transfers in the past and
only for connecting to external speakers.
Kind regards,
Paul
On Thu, 02 Dec 2021 17:58:01 +0100,
Paul Menzel wrote:
>
> Dear Takashi,
>
>
> Am 02.12.21 um 17:47 schrieb Takashi Iwai:
> > On Thu, 02 Dec 2021 17:32:14 +0100, Paul Menzel wrote:
>
> >> Am 02.12.21 um 17:22 schrieb Takashi Iwai:
> >>> It seems that a few more Intel chips require the workaround for the
> >>> broken initial command. At least, per openSUSE Bugzilla reports,
> >>> 8087:0a2a and 8087:0026 need BTUSB_INTEL_BROKEN_INITIAL_NCMD flag.
> >>>
> >>> Fixes: 83f2dafe2a62 ("Bluetooth: btintel: Refactoring setup routine for legacy ROM sku")
> >>> Buglink: https://bugzilla.opensuse.org/show_bug.cgi?id=1193124
> >>> Signed-off-by: Takashi Iwai <[email protected]>
> >>>
> >>
> >> […]
> >>
> >> I have a Dell Latitude E7250 with
> >>
> >> Bus 001 Device 003: ID 8087:0a2a Intel Corp. Bluetooth wireless interface
> >>
> >> and Bluetooth seems to work fine minus some Linux warnings [1] and a
> >> problem transferring greater than some bytes files with the Nokia N9
> >> [2].
> >>
> >> Linux 5.16-rc3, Dell Inc. Latitude E7250/0TVD2T, BIOS A19 01/23/2018:
> >>
> >> ```
> >> $ sudo dmesg | grep -i bluet
> >> [ 8.173417] calling bt_init+0x0/0xb3 [bluetooth] @ 301
> >> [ 8.173439] Bluetooth: Core ver 2.22
> >> [ 8.173463] NET: Registered PF_BLUETOOTH protocol family
> >> [ 8.173464] Bluetooth: HCI device and connection manager initialized
> >> [ 8.173467] Bluetooth: HCI socket layer initialized
> >> [ 8.173470] Bluetooth: L2CAP socket layer initialized
> >> [ 8.173473] Bluetooth: SCO socket layer initialized
> >> [ 8.173475] initcall bt_init+0x0/0xb3 [bluetooth] returned 0 after 35 usecs
> >> [ 8.216875] Bluetooth: hci0: Legacy ROM 2.5 revision 1.0 build 3 week 17 2014
> >> [ 8.233515] bluetooth hci0: firmware: direct-loading firmware intel/ibt-hw-37.8.10-fw-1.10.3.11.e.bseq
> >> [ 8.233520] Bluetooth: hci0: Intel Bluetooth firmware file: intel/ibt-hw-37.8.10-fw-1.10.3.11.e.bseq
> >> [ 8.540884] Bluetooth: hci0: unexpected event for opcode 0xfc2f
> >> [ 8.558942] Bluetooth: hci0: Intel BT fw patch 0x32 completed & activated
> >> ```
> >
> > Thanks, so this seems depending on the hardware, maybe a subtle
> > difference matters. As far as I read the code changes, the workaround
> > was applied in the past unconditionally, so it must be fairly safe
> > even if the chip works as is.
>
> Maybe add that to the commit message?
Maybe, if the upstream agrees with that. More comments needed from
Intel, as it's a kind of black magic.
> > Or, for avoiding the unnecessarily application of the workaround,
> > should it be changed as a fallback after the failure at the first
> > try...?
>
> Reading through the openSUSE Bugzilla issue, the failure is:
>
> Bluetooth: hci0: Reading Intel version command failed (-110)
> Bluetooth: hci0: command 0xfc05 tx timeout
>
> I couldn’t find the report for 8087:0a2a in the issue.
There two different machines in the report.
> Can you check,
> what firmware is used?
It's the place before loading the firmware, so the firmware version
doesn't matter.
thanks,
Takashi
Hi Takashi,
>>>>> It seems that a few more Intel chips require the workaround for the
>>>>> broken initial command. At least, per openSUSE Bugzilla reports,
>>>>> 8087:0a2a and 8087:0026 need BTUSB_INTEL_BROKEN_INITIAL_NCMD flag.
>>>>>
>>>>> Fixes: 83f2dafe2a62 ("Bluetooth: btintel: Refactoring setup routine for legacy ROM sku")
>>>>> Buglink: https://bugzilla.opensuse.org/show_bug.cgi?id=1193124
>>>>> Signed-off-by: Takashi Iwai <[email protected]>
>>>>>
>>>>
>>>> […]
>>>>
>>>> I have a Dell Latitude E7250 with
>>>>
>>>> Bus 001 Device 003: ID 8087:0a2a Intel Corp. Bluetooth wireless interface
>>>>
>>>> and Bluetooth seems to work fine minus some Linux warnings [1] and a
>>>> problem transferring greater than some bytes files with the Nokia N9
>>>> [2].
>>>>
>>>> Linux 5.16-rc3, Dell Inc. Latitude E7250/0TVD2T, BIOS A19 01/23/2018:
>>>>
>>>> ```
>>>> $ sudo dmesg | grep -i bluet
>>>> [ 8.173417] calling bt_init+0x0/0xb3 [bluetooth] @ 301
>>>> [ 8.173439] Bluetooth: Core ver 2.22
>>>> [ 8.173463] NET: Registered PF_BLUETOOTH protocol family
>>>> [ 8.173464] Bluetooth: HCI device and connection manager initialized
>>>> [ 8.173467] Bluetooth: HCI socket layer initialized
>>>> [ 8.173470] Bluetooth: L2CAP socket layer initialized
>>>> [ 8.173473] Bluetooth: SCO socket layer initialized
>>>> [ 8.173475] initcall bt_init+0x0/0xb3 [bluetooth] returned 0 after 35 usecs
>>>> [ 8.216875] Bluetooth: hci0: Legacy ROM 2.5 revision 1.0 build 3 week 17 2014
>>>> [ 8.233515] bluetooth hci0: firmware: direct-loading firmware intel/ibt-hw-37.8.10-fw-1.10.3.11.e.bseq
>>>> [ 8.233520] Bluetooth: hci0: Intel Bluetooth firmware file: intel/ibt-hw-37.8.10-fw-1.10.3.11.e.bseq
>>>> [ 8.540884] Bluetooth: hci0: unexpected event for opcode 0xfc2f
>>>> [ 8.558942] Bluetooth: hci0: Intel BT fw patch 0x32 completed & activated
>>>> ```
>>>
>>> Thanks, so this seems depending on the hardware, maybe a subtle
>>> difference matters. As far as I read the code changes, the workaround
>>> was applied in the past unconditionally, so it must be fairly safe
>>> even if the chip works as is.
>>
>> Maybe add that to the commit message?
>
> Maybe, if the upstream agrees with that. More comments needed from
> Intel, as it's a kind of black magic.
>
>>> Or, for avoiding the unnecessarily application of the workaround,
>>> should it be changed as a fallback after the failure at the first
>>> try...?
>>
>> Reading through the openSUSE Bugzilla issue, the failure is:
>>
>> Bluetooth: hci0: Reading Intel version command failed (-110)
>> Bluetooth: hci0: command 0xfc05 tx timeout
>>
>> I couldn’t find the report for 8087:0a2a in the issue.
>
> There two different machines in the report.
>
>> Can you check,
>> what firmware is used?
>
> It's the place before loading the firmware, so the firmware version
> doesn't matter.
I want to apply this quirk to as little devices as possible. It is one of these quirks we have to hardcode per USB VID:PID since we can’t auto-detect which boot loader is faulty.
So before I blacklist them, we better get a good understand of which they are. Can you include a btmon trace for that part. You most likely have to blacklist btusb.ko, start btmon and then load btusb.ko manually. One with and one without the quirk. And add that to the commit message.
We then try to find that module internally. It must be some SKU that we didn’t have in our test rack.
Regards
Marcel
On Fri, 03 Dec 2021 22:18:06 +0100,
Marcel Holtmann wrote:
>
> Hi Takashi,
>
> >>>>> It seems that a few more Intel chips require the workaround for the
> >>>>> broken initial command. At least, per openSUSE Bugzilla reports,
> >>>>> 8087:0a2a and 8087:0026 need BTUSB_INTEL_BROKEN_INITIAL_NCMD flag.
> >>>>>
> >>>>> Fixes: 83f2dafe2a62 ("Bluetooth: btintel: Refactoring setup routine for legacy ROM sku")
> >>>>> Buglink: https://bugzilla.opensuse.org/show_bug.cgi?id=1193124
> >>>>> Signed-off-by: Takashi Iwai <[email protected]>
> >>>>>
> >>>>
> >>>> […]
> >>>>
> >>>> I have a Dell Latitude E7250 with
> >>>>
> >>>> Bus 001 Device 003: ID 8087:0a2a Intel Corp. Bluetooth wireless interface
> >>>>
> >>>> and Bluetooth seems to work fine minus some Linux warnings [1] and a
> >>>> problem transferring greater than some bytes files with the Nokia N9
> >>>> [2].
> >>>>
> >>>> Linux 5.16-rc3, Dell Inc. Latitude E7250/0TVD2T, BIOS A19 01/23/2018:
> >>>>
> >>>> ```
> >>>> $ sudo dmesg | grep -i bluet
> >>>> [ 8.173417] calling bt_init+0x0/0xb3 [bluetooth] @ 301
> >>>> [ 8.173439] Bluetooth: Core ver 2.22
> >>>> [ 8.173463] NET: Registered PF_BLUETOOTH protocol family
> >>>> [ 8.173464] Bluetooth: HCI device and connection manager initialized
> >>>> [ 8.173467] Bluetooth: HCI socket layer initialized
> >>>> [ 8.173470] Bluetooth: L2CAP socket layer initialized
> >>>> [ 8.173473] Bluetooth: SCO socket layer initialized
> >>>> [ 8.173475] initcall bt_init+0x0/0xb3 [bluetooth] returned 0 after 35 usecs
> >>>> [ 8.216875] Bluetooth: hci0: Legacy ROM 2.5 revision 1.0 build 3 week 17 2014
> >>>> [ 8.233515] bluetooth hci0: firmware: direct-loading firmware intel/ibt-hw-37.8.10-fw-1.10.3.11.e.bseq
> >>>> [ 8.233520] Bluetooth: hci0: Intel Bluetooth firmware file: intel/ibt-hw-37.8.10-fw-1.10.3.11.e.bseq
> >>>> [ 8.540884] Bluetooth: hci0: unexpected event for opcode 0xfc2f
> >>>> [ 8.558942] Bluetooth: hci0: Intel BT fw patch 0x32 completed & activated
> >>>> ```
> >>>
> >>> Thanks, so this seems depending on the hardware, maybe a subtle
> >>> difference matters. As far as I read the code changes, the workaround
> >>> was applied in the past unconditionally, so it must be fairly safe
> >>> even if the chip works as is.
> >>
> >> Maybe add that to the commit message?
> >
> > Maybe, if the upstream agrees with that. More comments needed from
> > Intel, as it's a kind of black magic.
> >
> >>> Or, for avoiding the unnecessarily application of the workaround,
> >>> should it be changed as a fallback after the failure at the first
> >>> try...?
> >>
> >> Reading through the openSUSE Bugzilla issue, the failure is:
> >>
> >> Bluetooth: hci0: Reading Intel version command failed (-110)
> >> Bluetooth: hci0: command 0xfc05 tx timeout
> >>
> >> I couldn’t find the report for 8087:0a2a in the issue.
> >
> > There two different machines in the report.
> >
> >> Can you check,
> >> what firmware is used?
> >
> > It's the place before loading the firmware, so the firmware version
> > doesn't matter.
>
> I want to apply this quirk to as little devices as possible. It is one of these quirks we have to hardcode per USB VID:PID since we can’t auto-detect which boot loader is faulty.
>
> So before I blacklist them, we better get a good understand of which they are. Can you include a btmon trace for that part. You most likely have to blacklist btusb.ko, start btmon and then load btusb.ko manually. One with and one without the quirk. And add that to the commit message.
One of the reporters uploaded the logs to the kernel.org bugzilla
https://bugzilla.kernel.org/show_bug.cgi?id=215167
(I forgot to add this URL to the patch description, although this
could be reached from openSUSE Bugzila entry.)
Let me know (or better to access to bugzilla above by yourself) if
anything else is required.
thanks,
Takashi
On 21/12/02 05:47PM, Takashi Iwai wrote:
> Thanks, so this seems depending on the hardware, maybe a subtle
> difference matters. As far as I read the code changes, the workaround
> was applied in the past unconditionally, so it must be fairly safe
> even if the chip works as is.
>
> Or, for avoiding the unnecessarily application of the workaround,
> should it be changed as a fallback after the failure at the first
> try...?
I don't know if this helps, but I started experiencing this same issue ("hci0:
command 0xfc05 tx timeout") yesterday after a kernel upgrade.
My controller is a different one:
8087:0025 Intel Corp. Wireless-AC 9260 Bluetooth Adapter
^^^^^^^^^
I tried with different (older) versions of the v5.15.x kernel but none worked.
Now, this is the interesting (?) part: today, when I switched on the computer
to keep testing, the bluetooth was *already* working once again.
I have reviewed my bash history to try to figure out what is it that I did, and
the only thing I see is that yesterday, before going to sleep, I did a full
poweroff instead of a reset (which is what I used yesterday to try different
kernels).
This does not make any sense... but then I found this [1] post from someone else
who experienced the same.
Is there any reasonable explanation for this? Could this be the reason why you
seem to have different results with the same controller (8087:0a2a)?
[1] https://bbs.archlinux.org/viewtopic.php?pid=2006188#p2006188
Hi Fernando,
>> Thanks, so this seems depending on the hardware, maybe a subtle
>> difference matters. As far as I read the code changes, the workaround
>> was applied in the past unconditionally, so it must be fairly safe
>> even if the chip works as is.
>>
>> Or, for avoiding the unnecessarily application of the workaround,
>> should it be changed as a fallback after the failure at the first
>> try...?
>
> I don't know if this helps, but I started experiencing this same issue ("hci0:
> command 0xfc05 tx timeout") yesterday after a kernel upgrade.
>
> My controller is a different one:
>
> 8087:0025 Intel Corp. Wireless-AC 9260 Bluetooth Adapter
> ^^^^^^^^^
>
> I tried with different (older) versions of the v5.15.x kernel but none worked.
>
> Now, this is the interesting (?) part: today, when I switched on the computer
> to keep testing, the bluetooth was *already* working once again.
>
> I have reviewed my bash history to try to figure out what is it that I did, and
> the only thing I see is that yesterday, before going to sleep, I did a full
> poweroff instead of a reset (which is what I used yesterday to try different
> kernels).
>
> This does not make any sense... but then I found this [1] post from someone else
> who experienced the same.
>
> Is there any reasonable explanation for this? Could this be the reason why you
> seem to have different results with the same controller (8087:0a2a)?
we trying to figure out what went wrong here. This should be really only an issue on the really early Intel hardware like Wilkens Peak. However it seems it slipped into later parts now as well. We are investigating what happened and see if this can be fixed via a firmware update or if we really have to mark this hardware as having a broken boot loader.
Regards
Marcel
On Tue, 07 Dec 2021 17:14:02 +0100,
Marcel Holtmann wrote:
>
> Hi Fernando,
>
> >> Thanks, so this seems depending on the hardware, maybe a subtle
> >> difference matters. As far as I read the code changes, the workaround
> >> was applied in the past unconditionally, so it must be fairly safe
> >> even if the chip works as is.
> >>
> >> Or, for avoiding the unnecessarily application of the workaround,
> >> should it be changed as a fallback after the failure at the first
> >> try...?
> >
> > I don't know if this helps, but I started experiencing this same issue ("hci0:
> > command 0xfc05 tx timeout") yesterday after a kernel upgrade.
> >
> > My controller is a different one:
> >
> > 8087:0025 Intel Corp. Wireless-AC 9260 Bluetooth Adapter
> > ^^^^^^^^^
> >
> > I tried with different (older) versions of the v5.15.x kernel but none worked.
> >
> > Now, this is the interesting (?) part: today, when I switched on the computer
> > to keep testing, the bluetooth was *already* working once again.
> >
> > I have reviewed my bash history to try to figure out what is it that I did, and
> > the only thing I see is that yesterday, before going to sleep, I did a full
> > poweroff instead of a reset (which is what I used yesterday to try different
> > kernels).
> >
> > This does not make any sense... but then I found this [1] post from someone else
> > who experienced the same.
> >
> > Is there any reasonable explanation for this? Could this be the reason why you
> > seem to have different results with the same controller (8087:0a2a)?
>
> we trying to figure out what went wrong here. This should be really only an issue on the really early Intel hardware like Wilkens Peak. However it seems it slipped into later parts now as well. We are investigating what happened and see if this can be fixed via a firmware update or if we really have to mark this hardware as having a broken boot loader.
The upstream bugzilla indicates that 8087:0aa7 seems hitting the same
problem:
https://bugzilla.kernel.org/show_bug.cgi?id=215167
OTOH, on openSUSE Bugzilla, there has been a report that applying the
workaround for 8087:0026 may cause another issue about the reset
error, so the entry for 8087:0026 should be dropped.
Takashi
Hi, this is your Linux kernel regression tracker speaking.
Hey bluetooth maintainers, what's the status here? It looks like the
issue was discussed quite a bit, but then nothing happened anymore. Or
am I missing something?
Other users seem to still run into the issue, see for example this report:
https://lore.kernel.org/all/[email protected]/
For the rest of the mail:
[TLDR: I'm adding this regression to regzbot, the Linux kernel
regression tracking bot; most text you find below is compiled from a few
templates paragraphs some of you might have seen already.]
On 02.12.21 17:22, Takashi Iwai wrote:
> It seems that a few more Intel chips require the workaround for the
> broken initial command. At least, per openSUSE Bugzilla reports,
> 8087:0a2a and 8087:0026 need BTUSB_INTEL_BROKEN_INITIAL_NCMD flag.
>
> Fixes: 83f2dafe2a62 ("Bluetooth: btintel: Refactoring setup routine for legacy ROM sku")
> Buglink: https://bugzilla.opensuse.org/show_bug.cgi?id=1193124
> Signed-off-by: Takashi Iwai <[email protected]>
>
> ---
> drivers/bluetooth/btusb.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> index 75c83768c257..b26989b2df23 100644
> --- a/drivers/bluetooth/btusb.c
> +++ b/drivers/bluetooth/btusb.c
> @@ -359,14 +359,16 @@ static const struct usb_device_id blacklist_table[] = {
>
> /* Intel Bluetooth devices */
> { USB_DEVICE(0x8087, 0x0025), .driver_info = BTUSB_INTEL_COMBINED },
> - { USB_DEVICE(0x8087, 0x0026), .driver_info = BTUSB_INTEL_COMBINED },
> + { USB_DEVICE(0x8087, 0x0026), .driver_info = BTUSB_INTEL_COMBINED |
> + BTUSB_INTEL_BROKEN_INITIAL_NCMD },
> { USB_DEVICE(0x8087, 0x0029), .driver_info = BTUSB_INTEL_COMBINED },
> { USB_DEVICE(0x8087, 0x0032), .driver_info = BTUSB_INTEL_COMBINED },
> { USB_DEVICE(0x8087, 0x0033), .driver_info = BTUSB_INTEL_COMBINED },
> { USB_DEVICE(0x8087, 0x07da), .driver_info = BTUSB_CSR },
> { USB_DEVICE(0x8087, 0x07dc), .driver_info = BTUSB_INTEL_COMBINED |
> BTUSB_INTEL_BROKEN_INITIAL_NCMD },
> - { USB_DEVICE(0x8087, 0x0a2a), .driver_info = BTUSB_INTEL_COMBINED },
> + { USB_DEVICE(0x8087, 0x0a2a), .driver_info = BTUSB_INTEL_COMBINED |
> + BTUSB_INTEL_BROKEN_INITIAL_NCMD },
> { USB_DEVICE(0x8087, 0x0a2b), .driver_info = BTUSB_INTEL_COMBINED },
> { USB_DEVICE(0x8087, 0x0aa7), .driver_info = BTUSB_INTEL_COMBINED },
> { USB_DEVICE(0x8087, 0x0aaa), .driver_info = BTUSB_INTEL_COMBINED },
Adding the regression mailing list to the list of recipients, as it
should be in the loop for all regressions, as explained here:
https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html
To be sure this issue doesn't fall through the cracks unnoticed, I'm
adding it to regzbot, my Linux kernel regression tracking bot:
#regzbot ^introduced 83f2dafe2a62
#regzbot title bluetooth: more Intel chips require the workaround for
the broken initial command
#regzbot link: https://bugzilla.kernel.org/show_bug.cgi?id=215167
#regzbot link: https://bugzilla.opensuse.org/show_bug.cgi?id=1193124
#regzbot ignore-activity
Reminder: when fixing the issue, please add a 'Link:' tag with the URL
to the report (the parent of this mail) using the kernel.org redirector,
as explained in 'Documentation/process/submitting-patches.rst'. Regzbot
then will automatically mark the regression as resolved once the fix
lands in the appropriate tree. For more details about regzbot see footer.
Sending this to everyone that got the initial report, to make all aware
of the tracking. I also hope that messages like this motivate people to
directly get at least the regression mailing list and ideally even
regzbot involved when dealing with regressions, as messages like this
wouldn't be needed then.
Don't worry, I'll send further messages wrt to this regression just to
the lists (with a tag in the subject so people can filter them away), as
long as they are intended just for regzbot. With a bit of luck no such
messages will be needed anyway.
Ciao, Thorsten (wearing his 'Linux kernel regression tracker' hat)
P.S.: As a Linux kernel regression tracker I'm getting a lot of reports
on my table. I can only look briefly into most of them. Unfortunately
therefore I sometimes will get things wrong or miss something important.
I hope that's not the case here; if you think it is, don't hesitate to
tell me about it in a public reply, that's in everyone's interest.
BTW, I have no personal interest in this issue, which is tracked using
regzbot, my Linux kernel regression tracking bot
(https://linux-regtracking.leemhuis.info/regzbot/). I'm only posting
this mail to get things rolling again and hence don't need to be CC on
all further activities wrt to this regression.
---
Additional information about regzbot:
If you want to know more about regzbot, check out its web-interface, the
getting start guide, and/or the references documentation:
https://linux-regtracking.leemhuis.info/regzbot/
https://gitlab.com/knurd42/regzbot/-/blob/main/docs/getting_started.md
https://gitlab.com/knurd42/regzbot/-/blob/main/docs/reference.md
The last two documents will explain how you can interact with regzbot
yourself if your want to.
Hint for reporters: when reporting a regression it's in your interest to
tell #regzbot about it in the report, as that will ensure the regression
gets on the radar of regzbot and the regression tracker. That's in your
interest, as they will make sure the report won't fall through the
cracks unnoticed.
Hint for developers: you normally don't need to care about regzbot once
it's involved. Fix the issue as you normally would, just remember to
include a 'Link:' tag to the report in the commit message, as explained
in Documentation/process/submitting-patches.rst
That aspect was recently was made more explicit in commit 1f57bd42b77c:
https://git.kernel.org/linus/1f57bd42b77c
Dear Takashi,
Am 10.12.21 um 14:23 schrieb Takashi Iwai:
> On Tue, 07 Dec 2021 17:14:02 +0100, Marcel Holtmann wrote:
>>>> Thanks, so this seems depending on the hardware, maybe a subtle
>>>> difference matters. As far as I read the code changes, the workaround
>>>> was applied in the past unconditionally, so it must be fairly safe
>>>> even if the chip works as is.
>>>>
>>>> Or, for avoiding the unnecessarily application of the workaround,
>>>> should it be changed as a fallback after the failure at the first
>>>> try...?
>>>
>>> I don't know if this helps, but I started experiencing this same issue ("hci0:
>>> command 0xfc05 tx timeout") yesterday after a kernel upgrade.
>>>
>>> My controller is a different one:
>>>
>>> 8087:0025 Intel Corp. Wireless-AC 9260 Bluetooth Adapter
>>> ^^^^^^^^^
>>>
>>> I tried with different (older) versions of the v5.15.x kernel but none worked.
>>>
>>> Now, this is the interesting (?) part: today, when I switched on the computer
>>> to keep testing, the bluetooth was *already* working once again.
>>>
>>> I have reviewed my bash history to try to figure out what is it that I did, and
>>> the only thing I see is that yesterday, before going to sleep, I did a full
>>> poweroff instead of a reset (which is what I used yesterday to try different
>>> kernels).
>>>
>>> This does not make any sense... but then I found this [1] post from someone else
>>> who experienced the same.
>>>
>>> Is there any reasonable explanation for this? Could this be the reason why you
>>> seem to have different results with the same controller (8087:0a2a)?
>>
>> we trying to figure out what went wrong here. This should be really only an
>> issue on the really early Intel hardware like Wilkens Peak. However it seems
>> it slipped into later parts now as well. We are investigating what happened >> and see if this can be fixed via a firmware update or if we really
have to
>> mark this hardware as having a broken boot loader.
>
> The upstream bugzilla indicates that 8087:0aa7 seems hitting the same
> problem:
> https://bugzilla.kernel.org/show_bug.cgi?id=215167
>
> OTOH, on openSUSE Bugzilla, there has been a report that applying the
> workaround for 8087:0026 may cause another issue about the reset
> error, so the entry for 8087:0026 should be dropped.
Can you confirm that commit 95655456e7ce (Bluetooth: btintel: Fix broken
LED quirk for legacy ROM devices) [1] merged in the current Linux 5.17
cycle this week fixed the issue?
Kind regards,
Paul
[1]:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=95655456e7cee858a23793f67025765b4c4c227b
Hi, this is your Linux kernel regression tracker speaking.
Top-posting for once, to make this easy accessible to everyone.
Could the bluetooth maintainers please provide a status update? I wonder
if it's time to bring this regression to Linus attention, as it seems to
be an issue that hits quite a few users -- and at the same takes quite a
long time to get fixed for a issue where a patch with a workaround was
already proposed one and a half months ago.
Ciao, Thorsten
On 16.01.22 15:06, Paul Menzel wrote:
>
> Dear Takashi,
>
>
> Am 10.12.21 um 14:23 schrieb Takashi Iwai:
>> On Tue, 07 Dec 2021 17:14:02 +0100, Marcel Holtmann wrote:
>
>>>>> Thanks, so this seems depending on the hardware, maybe a subtle
>>>>> difference matters. As far as I read the code changes, the workaround
>>>>> was applied in the past unconditionally, so it must be fairly safe
>>>>> even if the chip works as is.
>>>>>
>>>>> Or, for avoiding the unnecessarily application of the workaround,
>>>>> should it be changed as a fallback after the failure at the first
>>>>> try...?
>>>>
>>>> I don't know if this helps, but I started experiencing this same
>>>> issue ("hci0:
>>>> command 0xfc05 tx timeout") yesterday after a kernel upgrade.
>>>>
>>>> My controller is a different one:
>>>>
>>>> 8087:0025 Intel Corp. Wireless-AC 9260 Bluetooth Adapter
>>>> ^^^^^^^^^
>>>>
>>>> I tried with different (older) versions of the v5.15.x kernel but
>>>> none worked.
>>>>
>>>> Now, this is the interesting (?) part: today, when I switched on the
>>>> computer
>>>> to keep testing, the bluetooth was *already* working once again.
>>>>
>>>> I have reviewed my bash history to try to figure out what is it that
>>>> I did, and
>>>> the only thing I see is that yesterday, before going to sleep, I did
>>>> a full
>>>> poweroff instead of a reset (which is what I used yesterday to try
>>>> different
>>>> kernels).
>>>>
>>>> This does not make any sense... but then I found this [1] post from
>>>> someone else
>>>> who experienced the same.
>>>>
>>>> Is there any reasonable explanation for this? Could this be the
>>>> reason why you
>>>> seem to have different results with the same controller (8087:0a2a)?
>>>
>>> we trying to figure out what went wrong here. This should be really
>>> only an
>>> issue on the really early Intel hardware like Wilkens Peak. However
>>> it seems
>>> it slipped into later parts now as well. We are investigating what
>>> happened >> and see if this can be fixed via a firmware update or if
>>> we really
> have to
>>> mark this hardware as having a broken boot loader.
>>
>> The upstream bugzilla indicates that 8087:0aa7 seems hitting the same
>> problem:
>> https://bugzilla.kernel.org/show_bug.cgi?id=215167
>>
>> OTOH, on openSUSE Bugzilla, there has been a report that applying the
>> workaround for 8087:0026 may cause another issue about the reset
>> error, so the entry for 8087:0026 should be dropped.
>
> Can you confirm that commit 95655456e7ce (Bluetooth: btintel: Fix broken
> LED quirk for legacy ROM devices) [1] merged in the current Linux 5.17
> cycle this week fixed the issue?
>
>
> Kind regards,
>
> Paul
>
>
> [1]:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=95655456e7cee858a23793f67025765b4c4c227b
>
Hi Thorsten,
> Could the bluetooth maintainers please provide a status update? I wonder
> if it's time to bring this regression to Linus attention, as it seems to
> be an issue that hits quite a few users -- and at the same takes quite a
> long time to get fixed for a issue where a patch with a workaround was
> already proposed one and a half months ago.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=95655456e7cee858a23793f67025765b4c4c227b
Regards
Marcel