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/ >> >> 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. > > 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. > > 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? > > 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. I agree, but seems everybody else sees it differently or does not care enough to do anything about it. 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. >> 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. 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 >> On 01.11.24 08:11, Chris Lu (陸稚泓) wrote: >>> Hi Thorsten, >>> >>> On Wed, 2024-10-30 at 12:29 +0100, Thorsten Leemhuis wrote: >>>> External email : Please do not click links or open attachments until >>>> you have verified the sender or the content. >>>> >>>> >>>> On 30.10.24 12:03, Chris Lu (陸稚泓) wrote: >>>>> >>>>> Let me recap and update the status of this problem. >>>> >>>> Many thx! >>>> >>>>> Marc feedback that he has some problem with MT7921AUN usb module. >>>>> Originally, we thought it was caused by the change "Fixes: >>>>> ccfc8948d7e4d9 ("Bluetooth: btusb: mediatek: reset the controller >>>>> before downloading the fw")". The change is mainly for MT7922, we >>>>> found some problem with MT7921 on specific platform internally. As >>>>> a result, Hao sent another patch to remove MT7921 from that >>>>> rule(Bluetooth: btmtk: Remove resetting mt7921 before downloading >>>>> the fw). >>>>> >>>>> However, Marc also mentioned that BT is able to work if changing >>>>> back >>>>> to an old firmware bin. Based on the clue, we found it was caused >>>>> by a >>>>> firmware change that specific MT7921 model will not able to setup >>>>> successfully. (In fact, we didn't expect that MT7921AUN can be get >>>>> by >>>>> normal user.) >>>>> >>>>> Since we can't predict which model user use and Luiz also suggests >>>>> MediaTek to fix it if that model can work before, we have prepared >>>>> a >>>>> solution. I've verified the solution locally that MT7921AUN model >>>>> can >>>>> work normally on Ubuntu PC. It will be a firmware modification. We >>>>> plan >>>>> to submit new firmware with this modification in 2024 Nov. >>>> >>>> Great, but due to the kernel's "no regressions" rule this is mostly >>>> irrelevant, as the regression must be fixed in a way that does not >>>> require users to change their firmware. >>>> >>> >>> Marc's module(MT7921AUN) is not working is due to a change in specific >>> firmware uploaded last year and we plan to revert that in the next >>> firmware release. Since it's related to controller's behavior, it's >>> quite hard to cover in software side. >>> Additionally, MT7921AUN is an external usb dongle. MediaTek official PC >>> project doesn't use this type of MT7921 model. We uses another type for >>> PC projects that it can be guaranteed bluetooth works normally with any >>> firmware we upload to Kernel. As a result, we believe the impact is >>> minimal to general user. >>> >>>> So is any such solution in sight? Or should we just revert >>>> ccfc8948d7e4d9 and any related follow up patches for now? Or would >>>> that >>>> just cause regressions for other users? >>>> >>> >>> Actually, it's not related to ccfc8948d7e4d9 which make bluetooth can't >>> setup normally if using MT7921AUN model + mismatched firmware. We >>> thought it was the same issue in the beginning, but it's not eventually >>> after getting more and more clue/logs. >>> I think we can keep the change because it's necessary to the change >>> submitter-Hao's project. >>> >>> Chris Lu >>> >>>> Ciao, Thorsten >>>> >>>>> On Wed, 2024-10-30 at 10:21 +0100, Thorsten Leemhuis wrote: >>>>>> External email : Please do not click links or open attachments >>>>>> until >>>>>> you have verified the sender or the content. >>>>>> >>>>>> >>>>>> Hi, Thorsten here, the Linux kernel's regression tracker. Top- >>>>>> posting >>>>>> for once, to make this easily accessible to everyone. >>>>>> >>>>>> I'm a bit lost here, but maybe I'm missing something. >>>>>> >>>>>> Luiz, can you help out here? Is there a reason why this patch is >>>>>> not >>>>>> making any process? >>>>>> >>>>>> Chris Lu and/or Hao Qin: Can you maybe help out as well as well >>>>>> and >>>>>> help >>>>>> with resolving some open questions that might or might not be >>>>>> relevant >>>>>> (see below). >>>>>> >>>>>> From Takashi reply, the bugzilla ticket he linked to, and the >>>>>> mail >>>>>> from >>>>>> the MediaTek folks >>>>>> ( >>>>>> >>> https://lore.kernel.org/lkml/12a344e25b31ec00fe8b57814d43fcb166e71be5.camel@xxxxxxxxxxxx/ >>>>>> ) it from the outside looks like this patch should really be >>>>>> merged >>>>>> rather sooner that later as it fixes regressions for some people. >>>>>> Afaics it should get a "Fixes: ccfc8948d7e4d9 ("Bluetooth: btusb: >>>>>> mediatek: reset the controller before downloading the fw")" tag, >>>>>> as >>>>>> it's >>>>>> afaics that commit that causes the regression that is known since >>>>>> more >>>>>> than three months now >>>>>> (https://lore.kernel.org/all/ZsTh7Jyug7MbZsLE@xxxxxxxxxxxx/ ). >>>>>> >>>>>> But note, it seems it does not fix the regression completely >>>>>> according >>>>>> to Marc's testing. >>>>>> https://lore.kernel.org/all/ZuCB98DSdtKCgxaL@xxxxxxxxxxxx/ >>>>>> >>>>>> Marc: Is that still how things are with current mainline? >>>>>> >>>>>> Ciao, Thorsten >>>>>> >>>>>> >>>>>> On 22.10.24 12:56, Takashi Iwai wrote: >>>>>>> On Mon, 14 Oct 2024 11:29:40 +0200, >>>>>>> Linux regression tracking (Thorsten Leemhuis) wrote: >>>>>>>> >>>>>>>> On 20.09.24 08:27, Chris Lu (陸稚泓) wrote: >>>>>>>>> On Thu, 2024-09-19 at 23:25 +0100, marc.payne@xxxxxxxxxxxx >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> External email : Please do not click links or open >>>>>>>>>> attachments until >>>>>>>>>> you have verified the sender or the content. >>>>>>>>>> Hi Chris and Luiz, >>>>>>>>>> >>>>>>>>>> What were your thoughts on the findings in my email dated >>>>>>>>>> 18th >>>>>>>>>> September? >>>>>>>>> >>>>>>>>> Thanks for your suggestion. >>>>>>>>> >>>>>>>>> I've prepared the same environment (Kernel v6.11 + >>>>>>>>> MT7921AUN >>>>>>>>> dongle) to >>>>>>>>> reproduce the issue, collected necessary logs locally and >>>>>>>>> also >>>>>>>>> initiated an internal discussion to clarify the root cause >>>>>>>>> of >>>>>>>>> this >>>>>>>>> symptom. We'll review the changes between two firmware >>>>>>>>> (20230526/20231109) if it's a bug or not. >>>>>>>>> >>>>>>>>> It may take some time to investigate. I'll let you know if >>>>>>>>> there is any >>>>>>>>> progress. >>>>>>>> >>>>>>>> Just wondering: Chris Lu, and Marc, what's the status here? >>>>>>>> From >>>>>>>> here it >>>>>>>> looks like there was no progress to fix this regression for a >>>>>>>> while, but >>>>>>>> it's easy to miss something, that's why I ask. >>>>>>>> >>>>>>>> Ciao, Thorsten >>>>>>> >>>>>>> FWIW, the similar bug was reported for the recent 6.11.x kernel >>>>>>> on >>>>>>> openSUSE Tumbleweed, and this patch was confirmed to work >>>>>>> around >>>>>>> the >>>>>>> crash at boot: >>>>>>> >>>>>>> >>> https://urldefense.com/v3/__https://bugzilla.suse.com/show_bug.cgi?id=1231599__;!!CTRNKA9wMg0ARbw!jYyH2oubBEtIKXmKl9cI2rrmK-7kSdaiIJQ8xH4NZa5i5YCTQDHaoOxCBhMgdAAY6ROIPAoPwbOV-LNeMRJBlR6u-As$ >>>>>>> >>>>>>> It'd be great if you can go ahead and merge the proper fix to >>>>>>> the >>>>>>> upstream. >>>>>>> >>>>>>> Let me know if you have another patch to test. Then I can >>>>>>> create a >>>>>>> test kernel package and ask the bug reporter for testing. >>>>>>> >>>>>>> >>>>>>> thanks, >>>>>>> >>>>>>> Takashi >>>>>>> >>>>>> >>>>>> >>>>> >>>>> ************* MEDIATEK Confidentiality Notice ******************** >>>>> The information contained in this e-mail message (including any >>>>> attachments) may be confidential, proprietary, privileged, or >>>>> otherwise >>>>> exempt from disclosure under applicable laws. It is intended to be >>>>> conveyed only to the designated recipient(s). Any use, >>>>> dissemination, >>>>> distribution, printing, retaining or copying of this e-mail >>>>> (including its >>>>> attachments) by unintended recipient(s) is strictly prohibited and >>>>> may >>>>> be unlawful. If you are not an intended recipient of this e-mail, >>>>> or believe >>>>> that you have received this e-mail in error, please notify the >>>>> sender >>>>> immediately (by replying to this e-mail), delete any and all copies >>>>> of >>>>> this e-mail (including any attachments) from your system, and do >>>>> not >>>>> disclose the content of this e-mail to any other person. Thank you! >>>>> >>>> >>>> >>> >>> ************* MEDIATEK Confidentiality Notice >>> ******************** >>> The information contained in this e-mail message (including any >>> attachments) may be confidential, proprietary, privileged, or otherwise >>> exempt from disclosure under applicable laws. It is intended to be >>> conveyed only to the designated recipient(s). Any use, dissemination, >>> distribution, printing, retaining or copying of this e-mail (including its >>> attachments) by unintended recipient(s) is strictly prohibited and may >>> be unlawful. If you are not an intended recipient of this e-mail, or believe >>> >>> that you have received this e-mail in error, please notify the sender >>> immediately (by replying to this e-mail), delete any and all copies of >>> this e-mail (including any attachments) from your system, and do not >>> disclose the content of this e-mail to any other person. Thank you! >>> >> > >
