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
