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

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

Bug#1100153: linux: hangs on resume from suspend or hibernation with 6.12-6.13 on ThinkPad X1 Carbon Gen 10

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#1100153: linux: hangs on resume from suspend or hibernation with 6.12-6.13 on ThinkPad X1 Carbon Gen 10 Salvatore Bonaccorso <carnil@debian.org> - 2025-03-12 07:40 +0100
    Bug#1100153: linux: hangs on resume from suspend or hibernation with 6.12-6.13 on ThinkPad X1 Carbon Gen 10 "brian m. carlson" <sandals@crustytoothpaste.net> - 2025-03-13 23:20 +0100
      Bug#1100153: linux: hangs on resume from suspend or hibernation with 6.12-6.13 on ThinkPad X1 Carbon Gen 10 Salvatore Bonaccorso <carnil@debian.org> - 2025-03-15 16:20 +0100
    Bug#1100153: linux: hangs on resume from suspend or hibernation with 6.12-6.13 on ThinkPad X1 Carbon Gen 10 Salvatore Bonaccorso <carnil@debian.org> - 2025-03-15 16:20 +0100
      Bug#1100153: linux: hangs on resume from suspend or hibernation with 6.12-6.13 on ThinkPad X1 Carbon Gen 10 "brian m. carlson" <sandals@crustytoothpaste.net> - 2025-03-15 23:40 +0100
        Bug#1100153: linux: hangs on resume from suspend or hibernation with 6.12-6.13 on ThinkPad X1 Carbon Gen 10 Salvatore Bonaccorso <carnil@debian.org> - 2025-04-24 15:10 +0200

#86426 — Bug#1100153: linux: hangs on resume from suspend or hibernation with 6.12-6.13 on ThinkPad X1 Carbon Gen 10

Control: tags -1 + moreinfo

Hi Brian,

On Tue, Mar 11, 2025 at 10:15:38PM +0000, brian m. carlson wrote:
> Package: src:linux
> Version: 6.13.6-1~exp1
> Severity: important
> 
> I have been using Debian unstable on this machine for over two years
> with MATE.  In 6.10, resume worked successfully, and so did hibernation
> (I have turned off secure boot for that reason).  Since upgrading to
> 6.12, both suspend and hibernate fail to resume: they both display the
> background of my desktop, but the keyboard, mouse, and trackpoint are
> unusable and unresponsive.  I tried 6.13 to see if it was fixed, and it
> was not.
> 
> I will note that I usually run this machine plugged into a CalDigit TS3
> Plus dock such that I use two external monitors and the machine is run
> in clamshell mode with the internal display off.  If I suspend or
> hibernate in such a state, it still hangs on resume, but without the
> desktop background showing.
> 
> I'll mention that I'm up to date on the firmware updates, so that
> doesn't fix it.  Also, switching between S3 and whatever the non-S3
> (Windows-supported) option is in the firmware setup doesn't matter, and
> it fails both ways.  I've also noticed that memory encryption being
> enabled or disabled doesn't seem to affect it, either.
> 
> I don't believe this is a MATE bug because it has worked for some time
> with MATE, so I assume this is a kernel bug.  I have traditionally
> rebooted only infrequently and mostly suspended or hibernated, so it's
> hard for me to say when this first started happening.  I'm filing this
> because it is annoying (I need to use my dock for my work machine during
> the day and want to switch back at night, so I now have to reboot) and
> because it will also affect trixie and anyone using it, and ThinkPad X1
> Carbons are a popular Linux laptop.

So it's obviously okay that you fill this report and understand it's
annoying. But we likely need your help here :)

So you know it worked with 6.10 but latest in 6.12 not, can you first
identify by fetching the old linux-images (use the snapshots.d.o
service) to pinpoint the Debian revision ranges where the regression
is introduced?

What is that range? Could you next bisect. Assuming we get even a
result within one stable series, this would be great, because then
next I would like to ask if you can bisect the respective upstream
changes to the breaking commits (still works if the issue is
introduced on major version change, then bisect might take longer).

Can you do that and report back around which change the hehaviour
regressed?

Regards,
Salvatore

[toc] | [next] | [standalone]

#86436

[Multipart message — attachments visible in raw view] — view raw

On 2025-03-12 at 06:34:43, Salvatore Bonaccorso wrote:
> So you know it worked with 6.10 but latest in 6.12 not, can you first
> identify by fetching the old linux-images (use the snapshots.d.o
> service) to pinpoint the Debian revision ranges where the regression
> is introduced?

Yeah, I can do that.  It might be this weekend before I finish, but I
can pin it down to some versions.  I'll get started on a few tonight.

> What is that range? Could you next bisect. Assuming we get even a
> result within one stable series, this would be great, because then
> next I would like to ask if you can bisect the respective upstream
> changes to the breaking commits (still works if the issue is
> introduced on major version change, then bisect might take longer).

I am less sure that I can build and install a functional kernel by hand.
I have no problem bisecting a change (I contribute to Git, after all),
but I don't usually do custom kernel builds.  I'll see if I can coerce
the linux package to build a custom version from upstream.
-- 
brian m. carlson (they/them or he/him)
Toronto, Ontario, CA

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

#86454

Hi Brian,

On Thu, Mar 13, 2025 at 10:04:34PM +0000, brian m. carlson wrote:
> On 2025-03-12 at 06:34:43, Salvatore Bonaccorso wrote:
> > So you know it worked with 6.10 but latest in 6.12 not, can you first
> > identify by fetching the old linux-images (use the snapshots.d.o
> > service) to pinpoint the Debian revision ranges where the regression
> > is introduced?
> 
> Yeah, I can do that.  It might be this weekend before I finish, but I
> can pin it down to some versions.  I'll get started on a few tonight.

Thanks.

> > What is that range? Could you next bisect. Assuming we get even a
> > result within one stable series, this would be great, because then
> > next I would like to ask if you can bisect the respective upstream
> > changes to the breaking commits (still works if the issue is
> > introduced on major version change, then bisect might take longer).
> 
> I am less sure that I can build and install a functional kernel by hand.
> I have no problem bisecting a change (I contribute to Git, after all),
> but I don't usually do custom kernel builds.  I'll see if I can coerce
> the linux package to build a custom version from upstream.

The easiest thing would be to build up a deb package of the build and
so use the bindeb-pkg target to build a binary package.

Is the following helping?
https://wiki.debian.org/DebianKernel/GitBisect

Regards,
Salvatore

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

#86455

Hi Brian,

On Thu, Mar 13, 2025 at 11:04:26PM +0000, brian m. carlson wrote:
> On 2025-03-12 at 06:34:43, Salvatore Bonaccorso wrote:
> > What is that range? Could you next bisect. Assuming we get even a
> > result within one stable series, this would be great, because then
> > next I would like to ask if you can bisect the respective upstream
> > changes to the breaking commits (still works if the issue is
> > introduced on major version change, then bisect might take longer).
> 
> I've done some testing and I've found that 6.10.12 is the last good
> version and 6.11-rc4 is the first bad version.  The former resumes
> correctly from suspend and hibernate and the latter fails in both cases.
> I also tested suspend on 6.11.2 and 6.11.10 and they also failed.
> 
> In all cases, to test suspend, I booted the machine on the kernel in
> question, logged in, waited for Firefox (which is loaded as part of my
> session) to finish loading the snapshot.debian.org page, then suspended
> by closing the lid.  To test hibernate, I went to the MATE shutdown
> menu and chose "Hibernate" instead of closing the lid.  Resuming from
> hibernation was done by booting the default kernel (which is presently
> 6.13.6 from experimental), although of course that kernel is overwritten
> by the one from the hibernation.
> 
> One interesting detail which may or may not be relevant is that suspend
> on 6.11 takes much longer, around 5 to 10 seconds before the light on
> the lid begins to pulse.  It is much faster on 6.10.12.
> 
> I'm including all of the kernel logs from my tests today (and from
> intermediate boots to install new kernels) as a gzipped attachment
> (firewall logs excluded for privacy and because they aren't
> relevant to this matter).

Okay that is already great, thank you for the time.

Now the next would in this case be ideally to bisect mainline between
v6.10 and v6.11-rc4 to identify the commit. On each step to build a
deb package for the kernel are hilighted at:
https://wiki.debian.org/DebianKernel/GitBisect

This will be somehow time intensive until we get to the breaking
commit, but right now I see it as only way to see where it regressed
in upstream and to followup with them.

Does this help?

Regards,
Salvatore

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

#86457

[Multipart message — attachments visible in raw view] — view raw

On 2025-03-15 at 15:11:07, Salvatore Bonaccorso wrote:
> Okay that is already great, thank you for the time.
> 
> Now the next would in this case be ideally to bisect mainline between
> v6.10 and v6.11-rc4 to identify the commit. On each step to build a
> deb package for the kernel are hilighted at:
> https://wiki.debian.org/DebianKernel/GitBisect

These directions were very helpful in compiling a kernel.
Unfortunately, it led to some unusual results.

The first step in the bisect was to try the merge base, which was 6.10,
which was bad, at which point Git refused to continue because the
problem had been fixed on the v6.10 branch.  So I thought I'd try
Debian's 6.9.2, which worked.  Then I tried upstream 6.9, which also
failed.  To verify, I tried upstream 6.9.2, which failed as well.

Note that I used `make oldddefconfig` with Debian's config to configure
the kernel, stepping back from v6.11-rc4, so it's nearly identical to
the Debian kernel (it's not signed and it doesn't have debug info, but
otherwise it should be pretty much the same.  In all cases, the tooling
is whatever's in Debian unstable at the moment.

My conclusion is thus that Debian includes some patch in the 6.9 and
6.10 series that fixes suspend and hibernate, but that patch is not
included in 6.11 and newer.

I will point out that I have a very similar ThinkPad X1 Carbon Gen 10
for work running Ubuntu 24.04 and their 6.8 kernel, and suspend and
resume do work there (the machine is using Secure Boot, so I cannot
speak to hibernation).  I can try booting off a live Ubuntu 24.10 image
(which contains a 6.11 kernel) or a daily build of Ubuntu 25.04 (which
contains a 6.14 kernel) and report back if you think that would be
helpful, say, in isolating an appropriate patch to apply.  I mention
this mostly because I know they do routine testing for things like
suspend and resume on some ThinkPads, so presumably things do work
there.

Of course, if you've come to a different conclusion or have other
suggestions about how to identify a cause, I'm all ears.
-- 
brian m. carlson (they/them or he/him)
Toronto, Ontario, CA

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

#86992

Hi Brian,

On Mon, Mar 31, 2025 at 05:47:16PM +0200, Uwe Kleine-König wrote:
> Hello brian,
> 
> On Sat, Mar 15, 2025 at 10:35:37PM +0000, brian m. carlson wrote:
> > On 2025-03-15 at 15:11:07, Salvatore Bonaccorso wrote:
> > > Okay that is already great, thank you for the time.
> > > 
> > > Now the next would in this case be ideally to bisect mainline between
> > > v6.10 and v6.11-rc4 to identify the commit. On each step to build a
> > > deb package for the kernel are hilighted at:
> > > https://wiki.debian.org/DebianKernel/GitBisect
> > 
> > These directions were very helpful in compiling a kernel.
> > Unfortunately, it led to some unusual results.
> > 
> > The first step in the bisect was to try the merge base, which was 6.10,
> > which was bad, at which point Git refused to continue because the
> > problem had been fixed on the v6.10 branch.
> 
> Can you try a vanilla 6.10.12 to confirm that there was a fix on the
> v6.10.x branch? If so, it would be interesting to know which commit
> fixed the issue for you. You can bisect that; I'd recommend something
> like
> 
> 	git bisect start --term-new=fine --term-old=broken v6.10.12 v6.10
> 
> to reduce the confusion.
> 
> > So I thought I'd try Debian's 6.9.2, which worked.  Then I tried
> > upstream 6.9, which also failed.  To verify, I tried upstream 6.9.2,
> > which failed as well.
> 
> Huh, this is surprising. Can you try to import the Debian patchstack
> from 6.9.2 onto 6.9.2 and bisect in that one to find the fixing commit?
> 
> > Note that I used `make oldddefconfig` with Debian's config to configure
> > the kernel, stepping back from v6.11-rc4, so it's nearly identical to
> > the Debian kernel (it's not signed and it doesn't have debug info, but
> > otherwise it should be pretty much the same.  In all cases, the tooling
> > is whatever's in Debian unstable at the moment.
> 
> Using `make oldddefconfig` is unstable when going up and down in the git
> history. A more suiteable approach is:
> 
> 	cp .config arch/x86/configs/brian_defconfig
> 
> and then use `make brian_defconfig` instead of `make oldconfig` in each
> step.
> 
> > My conclusion is thus that Debian includes some patch in the 6.9 and
> > 6.10 series that fixes suspend and hibernate, but that patch is not
> > included in 6.11 and newer.
> 
> I look forward to your test results. Your findings are really strange.

Did you had a chance to do further investigation here?

Regards,
Salvatore

[toc] | [prev] | [standalone]

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

csiph-web