Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #90688 > unrolled thread

Bug#1124605: bugs.debian.org: ThinkPad 16s fails to suspend because of mt7925e

Back to article view | Back to linux.debian.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#1124605: bugs.debian.org: ThinkPad 16s fails to suspend because of mt7925e Salvatore Bonaccorso <carnil@debian.org> - 2026-01-03 22:10 +0100
    Bug#1124605: bugs.debian.org: ThinkPad 16s fails to suspend because of mt7925e Luboš Bouček <boucek.lubos@protonmail.com> - 2026-01-04 02:00 +0100
      Bug#1124605: bugs.debian.org: ThinkPad 16s fails to suspend because of mt7925e Salvatore Bonaccorso <carnil@debian.org> - 2026-01-04 06:40 +0100
        Bug#1124605: bugs.debian.org: ThinkPad 16s fails to suspend because of mt7925e Luboš Bouček <boucek.lubos@protonmail.com> - 2026-01-04 10:50 +0100

#90688 — Bug#1124605: bugs.debian.org: ThinkPad 16s fails to suspend because of mt7925e

Control: tags -1 + moreinfo

Hi,

On Sat, Jan 03, 2026 at 08:02:18PM +0100, Lubos Boucek wrote:
> Package: bugs.debian.org
> Severity: normal
> X-Debbugs-Cc: boucek.lubos@protonmail.com
> 
> Hello,
> 
> I am reporting a problem in a fresh install of Debian 13 on ThinkPad P16s Gen 4
> with AMD Ryzen AI 9 HX PRO 370 w/ Radeon 890M:
> 
> $ uname -r
> 6.12.57+deb13-amd64
> 
> Any attempt to suspend the laptop is unsuccessful, after a short black screen
> the laptop immediately wakes again. After disabling each item in
> /proc/acpi/wakeup to no avail, I checked dmesg to find these error messages:
> 
> [ 7008.878186] mt7925e 0000:c2:00.0: Message 00020007 (seq 10) timeout
> [ 7008.878214] mt7925e 0000:c2:00.0: PM: pci_pm_suspend(): mt7925_pci_suspend
> [mt7925e] returns -110
> [ 7008.878226] mt7925e 0000:c2:00.0: PM: dpm_run_callback(): pci_pm_suspend
> returns -110
> [ 7008.878236] mt7925e 0000:c2:00.0: PM: failed to suspend async: error -110
> [ 7008.878319] PM: Some devices failed to suspend, or early wake event detected
> 
> Unloading the module mt7925e indeed resolved the issue.

There were some bugfixes for mt7925 driver around 6.14-rc1. Can you
please test at least the version in backports (6.17.13-1~bpo13+1) to
see if you can observe the problem with this kernel as well?

Regards,
Salvatore

[toc] | [next] | [standalone]

#90690

With this kernel:

$ uname -r
6.17.13+deb13-amd64

The laptop seems to suspend correctly, thanks!

Lubos Boucek


On Saturday, January 3rd, 2026 at 22:02, Salvatore Bonaccorso <carnil@debian.org> wrote:

> 
> 
> Control: tags -1 + moreinfo
> 
> Hi,
> 
> On Sat, Jan 03, 2026 at 08:02:18PM +0100, Lubos Boucek wrote:
> 
> > Package: bugs.debian.org
> > Severity: normal
> > X-Debbugs-Cc: boucek.lubos@protonmail.com
> > 
> > Hello,
> > 
> > I am reporting a problem in a fresh install of Debian 13 on ThinkPad P16s Gen 4
> > with AMD Ryzen AI 9 HX PRO 370 w/ Radeon 890M:
> > 
> > $ uname -r
> > 6.12.57+deb13-amd64
> > 
> > Any attempt to suspend the laptop is unsuccessful, after a short black screen
> > the laptop immediately wakes again. After disabling each item in
> > /proc/acpi/wakeup to no avail, I checked dmesg to find these error messages:
> > 
> > [ 7008.878186] mt7925e 0000:c2:00.0: Message 00020007 (seq 10) timeout
> > [ 7008.878214] mt7925e 0000:c2:00.0: PM: pci_pm_suspend(): mt7925_pci_suspend
> > [mt7925e] returns -110
> > [ 7008.878226] mt7925e 0000:c2:00.0: PM: dpm_run_callback(): pci_pm_suspend
> > returns -110
> > [ 7008.878236] mt7925e 0000:c2:00.0: PM: failed to suspend async: error -110
> > [ 7008.878319] PM: Some devices failed to suspend, or early wake event detected
> > 
> > Unloading the module mt7925e indeed resolved the issue.
> 
> 
> There were some bugfixes for mt7925 driver around 6.14-rc1. Can you
> please test at least the version in backports (6.17.13-1~bpo13+1) to
> see if you can observe the problem with this kernel as well?
> 
> Regards,
> Salvatore

[toc] | [prev] | [next] | [standalone]

#90692

Control: tags -1 + moreinfo

Hi 

On Sun, Jan 04, 2026 at 12:49:13AM +0000, Luboš Bouček wrote:
> With this kernel:
> 
> $ uname -r
> 6.17.13+deb13-amd64
> 
> The laptop seems to suspend correctly, thanks!

Ok that are great news.

Can you do further debugging on this issue? I see three major steps,
each in case of debugging "success".

- narrow down more the affected range of Debian versions where the
  issue got fixed.
- Bisect the upstream changes to identify a fixing commit
- Check if the commit can be backported to 6.12.y and resolving the
  issue.

I will outline only the first two first. So between 6.12.57-1 and
6.17.13-1 there are a couple of linux uploads happened:

6.17.13-1
6.17.13-1~bpo13+1
6.17.12-1
6.17.11-1
6.17.10-1
6.17.9-1
6.17.8-1
6.17.8-1~bpo13+1
6.17.7-2
6.17.7-1
6.17.6-1
6.17.5-1~exp1
6.17.2-1~exp1
6.16.12-2
6.16.12-1
6.16.12-1~bpo13+1
6.16.11-1
6.16.10-1
6.16.9-1
6.16.8-1
6.16.7-1
6.16.6-1
6.16.5-1
6.16.3-1
6.16.3-1~bpo13+1
6.16.1-1~exp1
6.16-1~exp1
6.16~rc7-1~exp1
6.15.6-1~exp1
6.15.5-1~exp1
6.15.4-1~exp1
6.15.3-1~exp1
6.15.2-1~exp1
6.15.1-1~exp1
6.15-1~exp1
6.15~rc7-1~exp1
6.14.6-1~exp1
6.14.5-1~exp1
6.14.3-1~exp1
6.13.11-1~exp1
6.13.10-1~exp1
6.13.9-1~exp1
6.13.8-1~exp1
6.13.7-1~exp1
6.13.6-1~exp1
6.13.5-1~exp1
6.13.4-1~exp1
6.13.3-1~exp1
6.13.2-1~exp1
6.13~rc7-1~exp1
6.13~rc6-1~exp1
6.12.63-1
6.12.57-1

From https://snapshot.debian.org/ you can fetch earlier and seen
uploads.so by querying
https://snapshot.debian.org/package/linux-signed-amd64/ you can get
earlier linux-image packages. 

The idea would be to now do a "manual" bisect of those changes
identifying at least a major version range where things changes.

Assume you found that, by first searching and testing the major
version bumps that 6.13~rc7-1~exp1 exposes the problem but
6.14.3-1~exp1 will not anymore.

The next step would be to test the equivalent upstream versions and
check that this still holds true and then start the bisection. This
can be done as follows, again remember with the hypotetical above
versions (adapt as needed), and it would involve compiling and testing
a few kernels:

    git clone https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
    cd linux-stable
    git checkout v6.14.3
    cp /boot/config-$(uname -r) .config
    yes '' | make localmodconfig
    make savedefconfig
    mv defconfig arch/x86/configs/my_defconfig

    # test 6.14.3 to ensure this is "good"
    make my_defconfig
    make -j $(nproc) bindeb-pkg
    ... install the resulting .deb package and confirm problem does not exist

    # test 6.13~rc7 to ensure this is "bad"
    git checkout v6.13-rc7
    make my_defconfig
    make -j $(nproc) bindeb-pkg
    ... install the resulting .deb package and confirm problem exists

With that confirmed, the bisection can start:

    git bisect start --term-new=fixed --term-old=broken
    git bisect fixed v6.14.3
    git bisect broken v6.13-rc7

In each bisection step git checks out a state between the oldest
known-bad and the newest known-good commit. In each step test using:

    make my_defconfig
    make -j $(nproc) bindeb-pkg
    ... install, try to boot / verify if problem exists

and if the problem is hit run:

    git bisect broken

and if the problem doesn't trigger run:

    git bisect fixed

. Please pay attention to always select the just built kernel for
booting, it won't always be the default kernel picked up by grub.

Iterate until git announces to have identified the first 'fixed'
commit.

Then provide the output of

    git bisect log

In the course of the bisection you might have to uninstall previous
kernels again to not exhaust the disk space in /boot. Also in the end
uninstall all self-built kernels again.

Can you please do this bisect?

Regards,
Salvatore

[toc] | [prev] | [next] | [standalone]

#90693

I am going to try this but it will take some time. I will let you know if I encounter any issues.

Lubos


On Sunday, January 4th, 2026 at 06:35, Salvatore Bonaccorso <carnil@debian.org> wrote:

> 
> 
> Control: tags -1 + moreinfo
> 
> Hi
> 
> On Sun, Jan 04, 2026 at 12:49:13AM +0000, Luboš Bouček wrote:
> 
> > With this kernel:
> > 
> > $ uname -r
> > 6.17.13+deb13-amd64
> > 
> > The laptop seems to suspend correctly, thanks!
> 
> 
> Ok that are great news.
> 
> Can you do further debugging on this issue? I see three major steps,
> each in case of debugging "success".
> 
> - narrow down more the affected range of Debian versions where the
> issue got fixed.
> - Bisect the upstream changes to identify a fixing commit
> - Check if the commit can be backported to 6.12.y and resolving the
> issue.
> 
> I will outline only the first two first. So between 6.12.57-1 and
> 6.17.13-1 there are a couple of linux uploads happened:
> 
> 6.17.13-1
> 6.17.13-1~bpo13+1
> 6.17.12-1
> 6.17.11-1
> 6.17.10-1
> 6.17.9-1
> 6.17.8-1
> 6.17.8-1~bpo13+1
> 6.17.7-2
> 6.17.7-1
> 6.17.6-1
> 6.17.5-1~exp1
> 6.17.2-1~exp1
> 6.16.12-2
> 6.16.12-1
> 6.16.12-1~bpo13+1
> 6.16.11-1
> 6.16.10-1
> 6.16.9-1
> 6.16.8-1
> 6.16.7-1
> 6.16.6-1
> 6.16.5-1
> 6.16.3-1
> 6.16.3-1~bpo13+1
> 6.16.1-1~exp1
> 6.16-1~exp1
> 6.16~rc7-1~exp1
> 6.15.6-1~exp1
> 6.15.5-1~exp1
> 6.15.4-1~exp1
> 6.15.3-1~exp1
> 6.15.2-1~exp1
> 6.15.1-1~exp1
> 6.15-1~exp1
> 6.15~rc7-1~exp1
> 6.14.6-1~exp1
> 6.14.5-1~exp1
> 6.14.3-1~exp1
> 6.13.11-1~exp1
> 6.13.10-1~exp1
> 6.13.9-1~exp1
> 6.13.8-1~exp1
> 6.13.7-1~exp1
> 6.13.6-1~exp1
> 6.13.5-1~exp1
> 6.13.4-1~exp1
> 6.13.3-1~exp1
> 6.13.2-1~exp1
> 6.13~rc7-1~exp1
> 6.13~rc6-1~exp1
> 6.12.63-1
> 6.12.57-1
> 
> From https://snapshot.debian.org/ you can fetch earlier and seen
> uploads.so by querying
> https://snapshot.debian.org/package/linux-signed-amd64/ you can get
> earlier linux-image packages.
> 
> The idea would be to now do a "manual" bisect of those changes
> identifying at least a major version range where things changes.
> 
> Assume you found that, by first searching and testing the major
> version bumps that 6.13~rc7-1~exp1 exposes the problem but
> 6.14.3-1~exp1 will not anymore.
> 
> The next step would be to test the equivalent upstream versions and
> check that this still holds true and then start the bisection. This
> can be done as follows, again remember with the hypotetical above
> versions (adapt as needed), and it would involve compiling and testing
> a few kernels:
> 
> git clone https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
> cd linux-stable
> git checkout v6.14.3
> cp /boot/config-$(uname -r) .config
> yes '' | make localmodconfig
> make savedefconfig
> mv defconfig arch/x86/configs/my_defconfig
> 
> # test 6.14.3 to ensure this is "good"
> make my_defconfig
> make -j $(nproc) bindeb-pkg
> ... install the resulting .deb package and confirm problem does not exist
> 
> # test 6.13~rc7 to ensure this is "bad"
> git checkout v6.13-rc7
> make my_defconfig
> make -j $(nproc) bindeb-pkg
> ... install the resulting .deb package and confirm problem exists
> 
> With that confirmed, the bisection can start:
> 
> git bisect start --term-new=fixed --term-old=broken
> git bisect fixed v6.14.3
> git bisect broken v6.13-rc7
> 
> In each bisection step git checks out a state between the oldest
> known-bad and the newest known-good commit. In each step test using:
> 
> make my_defconfig
> make -j $(nproc) bindeb-pkg
> ... install, try to boot / verify if problem exists
> 
> and if the problem is hit run:
> 
> git bisect broken
> 
> and if the problem doesn't trigger run:
> 
> git bisect fixed
> 
> . Please pay attention to always select the just built kernel for
> booting, it won't always be the default kernel picked up by grub.
> 
> Iterate until git announces to have identified the first 'fixed'
> commit.
> 
> Then provide the output of
> 
> git bisect log
> 
> In the course of the bisection you might have to uninstall previous
> kernels again to not exhaust the disk space in /boot. Also in the end
> uninstall all self-built kernels again.
> 
> Can you please do this bisect?
> 
> Regards,
> Salvatore

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web