From: Thorsten Leemhuis <email@example.com>
To: Paul Menzel <firstname.lastname@example.org>, Takashi Iwai <email@example.com>
Cc: Fernando Ramos <firstname.lastname@example.org>,
Johan Hedberg <email@example.com>,
Luiz Augusto von Dentz <firstname.lastname@example.org>,
Tedd Ho-Jeong An <email@example.com>,
Marcel Holtmann <firstname.lastname@example.org>
Subject: Re: [PATCH] Bluetooth: Apply initial command workaround for more Intel chips
Date: Thu, 20 Jan 2022 15:26:21 +0100 [thread overview]
Message-ID: <email@example.com> (raw)
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.
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
>>>> 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
>>>> 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
>>>> This does not make any sense... but then I found this  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
>> 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)  merged in the current Linux 5.17
> cycle this week fixed the issue?
> Kind regards,
next prev parent reply other threads:[~2022-01-20 14:26 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-02 16:22 [PATCH] Bluetooth: Apply initial command workaround for more Intel chips Takashi Iwai
2021-12-02 16:32 ` Paul Menzel
2021-12-02 16:47 ` Takashi Iwai
2021-12-02 16:58 ` Paul Menzel
2021-12-03 7:24 ` Takashi Iwai
2021-12-03 21:18 ` Marcel Holtmann
2021-12-04 11:20 ` Takashi Iwai
2021-12-05 10:33 ` Fernando Ramos
2021-12-07 16:14 ` Marcel Holtmann
2021-12-10 13:23 ` Takashi Iwai
2022-01-16 14:06 ` Paul Menzel
2022-01-20 14:26 ` Thorsten Leemhuis [this message]
2022-01-20 15:07 ` Marcel Holtmann
2022-01-20 15:13 ` Thorsten Leemhuis
2022-01-20 14:32 ` Takashi Iwai
2021-12-28 12:43 ` Thorsten Leemhuis
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).