linux-kernel - Re: [REGRESSION] bluetooth: mt7921: Crash on Resume From Suspend And Hibernate

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <ad78ad62-ebd2-40d7-8a6d-623ae947584c@gmail.com>
Date: Thu, 5 Dec 2024 13:59:55 +0100
From: Sergio Callegari <sergio.callegari@...il.com>
To: jglotzer@...il.com
Cc: Aaron.Hou@...iatek.com, Chris.Lu@...iatek.com, Deren.Wu@...iatek.com,
 Hao.Qin@...iatek.com, Sean.Wang@...iatek.com, johan.hedberg@...il.com,
 linux-bluetooth@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-mediatek@...ts.infradead.org, luiz.dentz@...il.com,
 marc.payne@...sys.co.uk, marcel@...tmann.org, regressions@...mhuis.info,
 regressions@...ts.linux.dev, steve.lee@...iatek.com, tiwai@...e.de
Subject: Re: [REGRESSION] bluetooth: mt7921: Crash on Resume From Suspend And
 Hibernate

John Glotzer <jglotzer@...il.com> wrote

> In following the related email threads it seems that this particular email thread has
> not had any activity since 10/21/2024. Now the focus seems to be on firmware download which
> in my admittedly non-expert opinion seems to be not clearly related.

Since then, it has become apparent that

- The issue affects many laptops that fail to resume from hibernation 
with recent kernels. It is not just about wifi/bt mt7922 combos attached 
via USB, but also and most important those attached via PCIe, e.g.

MEDIATEK Corp. MT7922 802.11ax PCI Express Wireless Network Adapter

- The new firmware (241106...) does not seem to solve the issue on all 
the affected systems.

- it is relatively easy to script actions to kill BT before 
sleep/hibernation and unkill it after resume, but they are suboptimal. 
Users will typically set them up after multiple failures to resume, 
which often means after data loss.

Would it be possible to (at least temporarily) revert the changes 
occurred from 6.10 to 6.11 that triggered this problem?

Sergio