Sorry for getting one more message in this discussion, but the issue is
still biting.
On 11/11/2024 10:21, Linux regression tracking (Thorsten Leemhuis) wrote:
> On 02.11.24 11:04, Takashi Iwai wrote:
>> On Fri, 01 Nov 2024 15:22:13 +0100,
>> Thorsten Leemhuis wrote:
>>>
>>> Thx for the insights, but it feels like this is not the complete story.
>>> From Takashi's mail earlier in the thread it appears to me that
there is
>>> a regression that the patch at the start of the thread fixes:
>>> https://lore.kernel.org/all/87iktk4d9l.wl-tiwai@xxxxxxx/
To the best of my understanding the patch mentioned here is now in 6.11
and 6.12. However, it does not fix the regression from 6.10.
>>> So it appears to me (please correct me if I'm wrong, which I might be)
>>> there is some regression that must be fixed independently of any
>>> firmware changes; not sure, maybe it's a different regression that the
>>> one Marc saw.
The new firmware does not fix it either.
>> That's hard to judge, unfortunately. The only fact is that 6.11 and
>> 6.12-rc are still buggy and fail to boot due to the kernel Oops from
>> Mediatek BT stuff. The patch
>>
https://lore.kernel.org/all/20240822052310.25220-1-hao.qin@xxxxxxxxxxxx/
>> seems working around it, but it doesn't mean that this is the right
>> fix, either.
I understand this is also in current 6.11 and 6.12 that still hang on
resume from hibernate.
Unclear to me who can reproduce the bug. From reports it looks like it
should be relatively easy to reproduce. Framework laptops as well as
Asus ROG Zephyrus 14 2022 do show the issue.
>> My wild guess is that there are substantial problems at btmtk stuff
>> about the firmware management. It blocks unbinding if something goes
>> wrong, and this bug surfaced casually due to another change.
>>> I just don't know what's the best way forward to resolve the regresson.
>>> A revert of the culprit? The patch at the start of this thread?
>>> Something else?
The issue was not present in 6.10. Having an idea of what to revert
would ease testing from the users side.
>> Either a revert of the firmware or the patch that triggered the issue
>> would be helpful as a temporary workaround, yes. We need a quick
>> duct-tape coverage, then fix the fundamental failure.
The fact that 6.10 has gone EOL has already left all those on rolling
distros with no usable kernel unless one overrides the kernel from those
offered by distros. So, yes, having some duct-tape solution would
definitively help.
> I agree, but seems everybody else sees it differently or does not care
> enough to do anything about it.
Substituting an intel wifi card for the mediatek one is a relatively
cheap solution, but given that the issue seems a regression it is not
the expected one. Wonder if 6.10 was working /while being wrong too/ for
some weird combination of factors.
> Or is some firmware update that fixes things within reach by now?
> Assuming here that the firmware is the only problem here (not sure at
> all if that is the case), as users never should be expected to update
> the firmware to fix a regression caused by a kernel change.
The more recent firmware does not seem to fix the issue.
The issue has in fact worsened. Until not long ago it was enough to
rfkill bt to work around the issue. Now, this does not suffice and I
need to switch down the wifi too.
>>> Takashi, Luiz, can you help me out here? I guess I otherwise soon will
>>> have to involve higher level maintainers to sort this out (e.g. the
-net
>>> maintainers and/or Linus).
>> I can build a test kernel and ask the reporter for testing if once
>> something is provided, of course. Just ping me.
Is there any patch to try against 6.11 or 6.12 at this point?
> Hmmm. Given the above I wonder if it would be good if you could make the
> reporter test a kernel with the revert and see if that helps -- and if
> it does then consider submitting that (with Linus and the -net
> maintainers in CC) to see if that gets anybody into action.
>
> Ciao, Thorsten
Thanks for the attention,
Sergio
