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
