lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <9ae25475-e8f4-4ee1-8022-7621fbe8ebc6@unibo.it>
Date: Mon, 13 Jan 2025 23:18:13 +0100
From: Sergio Callegari <sergio.callegari@...bo.it>
To: Linux regressions mailing list <regressions@...ts.linux.dev>,
 Takashi Iwai <tiwai@...e.de>
Cc: "luiz.dentz@...il.com" <luiz.dentz@...il.com>,
 "marcel@...tmann.org" <marcel@...tmann.org>,
 "linux-mediatek@...ts.infradead.org" <linux-mediatek@...ts.infradead.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "linux-bluetooth@...r.kernel.org" <linux-bluetooth@...r.kernel.org>,
 Deren Wu (武德仁) <Deren.Wu@...iatek.com>,
 "johan.hedberg@...il.com" <johan.hedberg@...il.com>,
 Steve Lee (李視誠) <steve.lee@...iatek.com>,
 "marc.payne@...sys.co.uk" <marc.payne@...sys.co.uk>,
 Sean Wang <Sean.Wang@...iatek.com>, Aaron Hou (侯俊仰)
 <Aaron.Hou@...iatek.com>, Chris Lu (陸稚泓)
 <Chris.Lu@...iatek.com>, Hao Qin (秦浩)
 <Hao.Qin@...iatek.com>
Subject: Re: [PATCH] Bluetooth: btmtk: Remove resetting mt7921 before
 downloading the fw

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@suse.de/
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@mediatek.com/
 >> 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


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ