Kernel version 6.13.0-rc4 not shutting down properly.

evorster · 2024-12-23 20:33:00

Hi there!

In testing some other things, I noticed something strange. This laptop shuts down properly when running linux, linux-lts and linux-g14 kernels.
Unfortunately, when running the linux-git kernel, currently at 6.13.0-rc4, it does not actually power down the system.
It reaches the point where it would shut down the system, and just hangs there with black screens.
Looking at the journal of that session, it definitely looks like it should have shut down. Below are the last few lines of the journal, and I am not seeing anything untoward.
I left the machine in this state for about ten minutes, but it only shut down when I held the power button down.

Dec 23 18:53:26 Evert.Strix systemd[1]: Finished System Power Off.
Dec 23 18:53:26 Evert.Strix systemd[1]: Reached target System Power Off.
Dec 23 18:53:26 Evert.Strix systemd[1]: Shutting down.
Dec 23 18:53:26 Evert.Strix systemd-shutdown[1]: Syncing filesystems and block devices.
Dec 23 18:53:26 Evert.Strix systemd-shutdown[1]: Sending SIGTERM to remaining processes...
Dec 23 18:53:26 Evert.Strix systemd-journald[575]: Received SIGTERM from PID 1 (systemd-shutdow).
Dec 23 18:53:26 Evert.Strix systemd-journald[575]: Journal stopped

Nothing changed between the runs with the various kernels, and I would just spin up the machine, log in and then shut it down and then boot with another kernel.
Systemctl shows no failed services.

What are a few things to try or to look at to see why it is not shutting down properly?

gromit · 2024-12-23 21:23:59

Does it work when you go back to rc3?

sudo pacman -U https://pkgbuild.com/\~gromit/linux-bisection-kernels/linux-mainline-6.13rc3-1-x86_64.pkg.tar.zst

Edit: Also is this an issue every time you shut down this system or just some times?

Last edited by gromit (2024-12-23 21:24:33)

evorster · 2024-12-24 05:55:12

Hi there, Gromit.
Unfortunately, mainline seems to have the same problem on this laptop.

It happens every single time.

Thanks for taking a look.
If you are interested, the full journal for the Mainline session is available here:
https://pastebin.com/w6sqAMhC

loqs · 2024-12-24 15:41:49

Linux mainline is Linus's tree. In AUR linux-mainline is pinned to the latest git tag while linux-git is not pinned and follows the HEAD of the master branch. What if you go back to 6.13-rc1?

sudo pacman -U  https://pkgbuild.com/\~gromit/linux-bisection-kernels/linux-mainline-6.13rc3-1-x86_64.pkg.tar.zst

Last edited by loqs (2024-12-24 15:42:00)

evorster · 2024-12-25 06:08:46

I filed a bug with the kernel, and surprise surprise, they asked for a bisect.
That takes a little while, and it's Christmas, so it will have to wait a while.

Another interesting data point, if it helps, is that this issue seems to occur only when the external monitor is plugged into the HDMI port of the laptop.
I recently got a USB-C to Displayport cable, and when using that, the issue is gone.

evorster · 2024-12-25 06:22:49

Hi Gromit.
The link you provided is for the rc3 mainline, but it was an easy fix to change it to rc1.
Testing it now.

evorster · 2024-12-25 06:39:50

Hi there, Gromit.
You saved me a couple of kernel builds there. It still happens with 6.13.rc1

evorster · 2024-12-25 07:24:56

Hi Gromit.
It's slightly off topic here, but when following the instructions to bisect the kernel, I run into a problem.

I'm using the mainline kernel version to do the bisect.
I picked 6.12.rc7 as the last good version, and 6.13.rc1 as the first bad one.

makepkg -efsi then builds 6.12.0-1-mainline-05806-g55ae3eef10ae

It fails at the end with this bit of code:

  ZSTD    /mnt/int/system/aur/linux-mainline/pkg/linux-mainline/usr/lib/modules/6.12.0-1-mainline-05806-g55ae3eef10ae/kernel/net/qrtr/qrtr-mhi.ko.zst
  DEPMOD  /mnt/int/system/aur/linux-mainline/pkg/linux-mainline/usr/lib/modules/6.12.0-1-mainline-05806-g55ae3eef10ae
Warning: 'make modules_install' requires /doesnt/exist. Please install it.
This is probably in the kmod package.
rm: cannot remove '/mnt/int/system/aur/linux-mainline/pkg/linux-mainline/usr/lib/modules/6.13.0-rc4-1-mainline/build': No such file or directory
==> ERROR: A failure occurred in package_linux-mainline().
    Aborting...
[evert@Evert linux-mainline]$ ls -lrt
total 194828
-rw-r--r-- 1 evert evert       483 Dec 24 13:17 merge-with-testing
-rw-r--r-- 1 evert evert       873 Dec 24 13:17 linux.install.pkg
-rw-r--r-- 1 evert evert       853 Dec 24 13:17 linux.install
-rw-r--r-- 1 evert evert    277770 Dec 24 13:17 config
-rw-r--r-- 1 evert evert      6934 Dec 24 13:17 PKGBUILD
drwxr-xr-x 1 evert evert       140 Dec 24 13:29 linux-mainline
-rw-r--r-- 1 evert evert 144838688 Dec 24 13:56 linux-mainline-6.13rc4-1-x86_64.pkg.tar.xz
-rw-r--r-- 1 evert evert  26320548 Dec 24 13:57 linux-mainline-headers-6.13rc4-1-x86_64.pkg.tar.xz
-rw-r--r-- 1 evert evert  28037852 Dec 24 13:57 linux-mainline-docs-6.13rc4-1-x86_64.pkg.tar.xz
drwxr-xr-x 1 evert evert        40 Dec 24 13:58 src
drwxr-xr-x 1 evert evert        28 Dec 25 09:09 pkg
[evert@Evert linux-mainline]$ pwd
/mnt/int/system/aur/linux-mainline
[evert@Evert linux-mainline]$

And, indeed that directory does not exist.

[evert@Evert modules]$ pwd
/mnt/int/system/aur/linux-mainline/pkg/linux-mainline/usr/lib/modules
[evert@Evert modules]$ ls
6.12.0-1-mainline-05806-g55ae3eef10ae  6.13.0-rc4-1-mainline
[evert@Evert modules]$

It would appear to me that the PKGBUILD for linux-mainline is not suitable for bisection builds as is.
What PKGBUILD do you use for your bisection builds?

loqs · 2024-12-25 07:38:04

Keep track of the bisection progress in src/linux-mainline

cd src/linux-mainline$ git bisect start
status: waiting for both good and bad commits
$ git bisect bad v6.13-rc1
status: waiting for good commit(s), bad commit known
$ git bisect good v6.12
Bisecting: 6011 revisions left to test after this (roughly 13 steps)
[071b34dcf71523a559b6c39f5d21a268a9531b50] Merge tag 'sound-6.13-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
$ git describe 
v6.12-6130-g071b34dcf715
cd ../..

Edit the PKGBUILD and change the source line to

  "$_srcname::git+https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git#commit=071b34dcf71523a559b6c39f5d21a268a9531b50"

Now either move src to src.bisect then run makepkg -si or install `devtools` and run `pkgctl build` both of these commands will run a full build including prepare which will setup the build as expected.

evorster · 2024-12-26 05:17:26

Hi there!

I'm following the instructions from https://wiki.archlinux.org/title/Bisect … s_with_Git

There, it mentions running makepkg -efsi
From what I understand, this purposefully disables the git updating of the source so that the bisect can do its thing.

If I read your comment right, you are suggesting to move the src directory away and do the bisect there, while allowing the PKGBUILD to checkout various versions in a fresh src directory?

Maybe this info should be added to the wiki?

evorster · 2024-12-26 05:20:05

One more question, should I do the same thing for linux-mainline-headers? My installed nvidia-550xx-dkms depends on them being the exact same version as the kernel.

evorster · 2024-12-26 05:31:47

As an update, both makepkg -si and pkgctl build fail when checking the sha256sums.
I'll tell the PKGBUILD to skip checking them for now, just a point of interest.

evorster · 2024-12-26 08:28:28

The bisecting is finally working for me.
I went with moving the src directory to src.bisect to give a stable source tree to run the bisecting command on.

After each bisection, I get a commit to try next, and that is plugged into the PKGBUILD of the linux-mainline to build that commit.

My worry of building the headers is moot, as it turns out that running makepkg -fsi installs the headers and documentation too.

Just to keep track of my progress, I am making copies of each PKGBUILD that I have tried, as well as dumping the first line of the journal for each boot into a text file to ensure that I am actually running the proper version of the kernel that I think I was running on each test.

This has been quite the fun learning experience, and definitely something I will use in the future, as I tend to run into kernel bugs quite often.

loqs · 2024-12-26 19:17:34

For reference the upstream bug report https://bugzilla.kernel.org/show_bug.cgi?id=219629

WorMzy · 2024-12-26 19:40:02

Mod note: moving to AUR Issues.

Arch Linux

#1 2024-12-23 20:33:00

Kernel version 6.13.0-rc4 not shutting down properly.

#2 2024-12-23 21:23:59

Re: Kernel version 6.13.0-rc4 not shutting down properly.

#3 2024-12-24 05:55:12

Re: Kernel version 6.13.0-rc4 not shutting down properly.

#4 2024-12-24 15:41:49

Re: Kernel version 6.13.0-rc4 not shutting down properly.

#5 2024-12-25 06:08:46

Re: Kernel version 6.13.0-rc4 not shutting down properly.

#6 2024-12-25 06:22:49

Re: Kernel version 6.13.0-rc4 not shutting down properly.

#7 2024-12-25 06:39:50

Re: Kernel version 6.13.0-rc4 not shutting down properly.

#8 2024-12-25 07:24:56

Re: Kernel version 6.13.0-rc4 not shutting down properly.

#9 2024-12-25 07:38:04

Re: Kernel version 6.13.0-rc4 not shutting down properly.

#10 2024-12-26 05:17:26

Re: Kernel version 6.13.0-rc4 not shutting down properly.

#11 2024-12-26 05:20:05

Re: Kernel version 6.13.0-rc4 not shutting down properly.

#12 2024-12-26 05:31:47

Re: Kernel version 6.13.0-rc4 not shutting down properly.

#13 2024-12-26 08:28:28

Re: Kernel version 6.13.0-rc4 not shutting down properly.

#14 2024-12-26 19:17:34

Re: Kernel version 6.13.0-rc4 not shutting down properly.

#15 2024-12-26 19:40:02

Re: Kernel version 6.13.0-rc4 not shutting down properly.

Board footer