You are not logged in.
I noticed this after an update, I tested going to the lts kernel (6.6) and the ram usage went back down, here are two screenshots comparing the two:
6.7
https://i.imgur.com/Ci7y11X.png
LTS
https://i.imgur.com/RtMZY5l.png
Looking at the processes the only difference I can see is that each task now uses more ram in 6.7. What changed?
Last edited by Samueru (2024-01-21 00:38:12)
Offline
Not to worry, I know that Arch developers dislike it when RAM is unused.
Only one thing is certain: nothing is certain.
Offline
What changed?
Newer kernels offer more features and those features will probably use more memory.
FWIW I like to use https://github.com/pixelb/ps_mem/ to analyse memory usage in detail.
And please replace those oversized images with URLs or thumbnail links. Or post the output of `free -h` or the content of /proc/meminfo instead, both will be more useful than screenshots of `htop`.
Jin, Jiyan, Azadî
Offline
Samueru wrote:What changed?
Newer kernels offer more features and those features will probably use more memory.
FWIW I like to use https://github.com/pixelb/ps_mem/ to analyse memory usage in detail.
And please replace those oversized images with URLs or thumbnail links. Or post the output of `free -h` or the content of /proc/meminfo instead, both will be more useful than screenshots of `htop`.
I used htop becasue not long ago there were changes to procps-ng that affects free that result in higher ram usage values than before, it was just that the calculation changed, nothing else changed so I wanted to avoid someone explaining that it is normal because of procps-ng had I used free -h instead of htop
EIther way here is the output of ps_mem and free -h on lts and 6.7:
6.7.arch3-1
ps_mem
Private + Shared = RAM used Program
240.0 KiB + 89.5 KiB = 329.5 KiB xinit
272.0 KiB + 69.5 KiB = 341.5 KiB dbus-run-session
444.0 KiB + 415.5 KiB = 859.5 KiB sh
1.1 MiB + 174.5 KiB = 1.2 MiB dbus-broker-launch
1.3 MiB + 58.5 KiB = 1.3 MiB dbus-broker
968.0 KiB + 481.5 KiB = 1.4 MiB startx
1.0 MiB + 545.5 KiB = 1.5 MiB systemd-hostnamed
1.1 MiB + 645.0 KiB = 1.8 MiB dbus-daemon (2)
1.3 MiB + 548.5 KiB = 1.8 MiB login
1.8 MiB + 139.5 KiB = 1.9 MiB (sd-pam)
1.5 MiB + 474.5 KiB = 1.9 MiB picom
1.4 MiB + 643.5 KiB = 2.1 MiB systemd-logind
812.0 KiB + 1.7 MiB = 2.5 MiB systemd-udevd
2.1 MiB + 555.5 KiB = 2.6 MiB systemd-journald
768.0 KiB + 2.6 MiB = 3.4 MiB udevadm (2)
1.1 MiB + 2.4 MiB = 3.5 MiB sudo (2)
3.0 MiB + 887.5 KiB = 3.9 MiB systemd-timesyncd
3.7 MiB + 1.3 MiB = 5.0 MiB zsh (2)
6.1 MiB + 787.5 KiB = 6.9 MiB pipewire-pulse
7.0 MiB + 427.5 KiB = 7.4 MiB at-spi2-registryd
8.5 MiB + 258.5 KiB = 8.8 MiB xss-lock
8.6 MiB + 265.5 KiB = 8.9 MiB xfconfd
8.5 MiB + 520.5 KiB = 9.0 MiB polkitd
5.5 MiB + 4.0 MiB = 9.5 MiB systemd (2)
9.7 MiB + 706.5 KiB = 10.4 MiB dunst
10.2 MiB + 652.5 KiB = 10.8 MiB gvfsd
11.1 MiB + 408.5 KiB = 11.5 MiB at-spi-bus-launcher
10.6 MiB + 1.5 MiB = 12.1 MiB pipewire
13.0 MiB + 374.5 KiB = 13.3 MiB gvfsd-fuse
16.7 MiB + 2.4 MiB = 19.1 MiB NetworkManager
21.5 MiB + 1.9 MiB = 23.4 MiB i3
25.5 MiB + 5.2 MiB = 30.7 MiB xfce4-terminal
19.5 MiB + 11.8 MiB = 31.3 MiB kdeconnectd
22.8 MiB + 11.1 MiB = 33.9 MiB kdeconnect-indicator
31.3 MiB + 3.1 MiB = 34.4 MiB wireplumber
30.7 MiB + 16.2 MiB = 46.9 MiB xfce-polkit
33.3 MiB + 17.2 MiB = 50.5 MiB xfce4-clipman
47.0 MiB + 7.9 MiB = 54.9 MiB polybar (3)
84.3 MiB + 14.9 MiB = 99.2 MiB Xorg
---------------------------------
570.2 MiB
=================================
free -h
total used free shared buff/cache available
Mem: 1.8Gi 958Mi 510Mi 20Mi 620Mi 887Mi
Swap: 5.4Gi 0B 5.4Gi
LTS:
~/ sudo ps_mem
[sudo] password for samuel:
Private + Shared = RAM used Program
240.0 KiB + 91.5 KiB = 331.5 KiB xinit
272.0 KiB + 73.5 KiB = 345.5 KiB dbus-run-session
444.0 KiB + 417.5 KiB = 861.5 KiB sh
1.0 MiB + 180.5 KiB = 1.2 MiB dbus-broker-launch
1.3 MiB + 59.5 KiB = 1.3 MiB dbus-broker
968.0 KiB + 483.5 KiB = 1.4 MiB startx
1.0 MiB + 417.5 KiB = 1.4 MiB at-spi2-registryd
1.0 MiB + 544.5 KiB = 1.5 MiB systemd-hostnamed
1.2 MiB + 415.5 KiB = 1.6 MiB at-spi-bus-launcher
1.2 MiB + 635.0 KiB = 1.8 MiB dbus-daemon (2)
1.3 MiB + 544.5 KiB = 1.8 MiB login
1.8 MiB + 139.5 KiB = 1.9 MiB (sd-pam)
1.5 MiB + 472.5 KiB = 1.9 MiB picom
1.1 MiB + 896.5 KiB = 1.9 MiB systemd-timesyncd
1.4 MiB + 647.5 KiB = 2.1 MiB systemd-logind
2.0 MiB + 555.5 KiB = 2.6 MiB systemd-journald
908.0 KiB + 1.7 MiB = 2.6 MiB systemd-udevd
2.6 MiB + 261.5 KiB = 2.8 MiB xss-lock
2.6 MiB + 265.5 KiB = 2.9 MiB xfconfd
2.1 MiB + 790.5 KiB = 2.9 MiB pipewire-pulse
2.5 MiB + 526.5 KiB = 3.0 MiB polkitd
1.2 MiB + 2.3 MiB = 3.5 MiB sudo (2)
856.0 KiB + 2.8 MiB = 3.6 MiB udevadm (2)
4.2 MiB + 654.5 KiB = 4.8 MiB gvfsd
3.7 MiB + 1.3 MiB = 5.0 MiB zsh (2)
5.0 MiB + 369.5 KiB = 5.3 MiB gvfsd-fuse
4.6 MiB + 1.4 MiB = 6.0 MiB pipewire
5.7 MiB + 722.5 KiB = 6.4 MiB dunst
5.4 MiB + 4.0 MiB = 9.4 MiB systemd (2)
10.7 MiB + 2.4 MiB = 13.0 MiB NetworkManager
19.5 MiB + 3.0 MiB = 22.5 MiB wireplumber
21.6 MiB + 1.8 MiB = 23.3 MiB i3
19.5 MiB + 5.2 MiB = 24.7 MiB xfce4-terminal
19.1 MiB + 7.9 MiB = 27.0 MiB polybar (3)
15.3 MiB + 11.9 MiB = 27.2 MiB kdeconnectd
18.8 MiB + 11.2 MiB = 30.0 MiB kdeconnect-indicator
14.7 MiB + 16.2 MiB = 31.0 MiB xfce-polkit
19.3 MiB + 17.3 MiB = 36.6 MiB xfce4-clipman
66.5 MiB + 15.0 MiB = 81.5 MiB Xorg
---------------------------------
399.1 MiB
=================================
~/ free -h
total used free shared buff/cache available
Mem: 1.8Gi 755Mi 713Mi 20Mi 620Mi 1.1Gi
Swap: 5.4Gi 0B 5.4Gi
Offline
https://gitlab.archlinux.org/archlinux/ … ote_157925 have you tried building 6.7 with 6.6's config? If the issue is not due to a change in the config you may need to bisect the kernel to identify the cause.
Offline
I would not say that this is a problem of the 6.7 kernel exclusively. This is a fact that has been observed in recent years: the kernel and programs consume more and more memory, without knowing exactly the reason or the benefits of it.
Having, for example, 16 GB of RAM in 2024 is not the same as having it in 2017. You can do less things now than before.
You can see for yourself: the latest Arch installation ISO, needs at least 784 MB of memory to be able to be launched correctly in VirtualBox. The April 2017 ISO (the first non-dual one) can be booted in VirtualBox with only 364 MB, that's less than half.
I think that in the optimization aspect, Linux and its ecosystem leaves much to be desired compared to the past.
Excuse my poor English.
Offline
https://gitlab.archlinux.org/archlinux/ … ote_157925 have you tried building 6.7 with 6.6's config? If the issue is not due to a change in the config you may need to bisect the kernel to identify the cause.
Oh that's my man Gaël, nice to see that he also noticed the issue as well. And yes it is true that it gets worse the more you use the PC, I was doing the regular stuff like using telegram and the web browser and noticed that my ram usage was above 5 GIB when it would use to be under 3 GiB for those tasks and began troubleshooting.
Offline
The biggest difference seems to be in GTK stuff, but eg. zsh and i3 are idem and xinit, sh and dbus-run-session even leaned down a bit.
Also this is not exactly the same as RAM demand creeping up over time.
Check
cat /proc/meminfo
after "losing" RAM, then isolate the rescue.target (that will kill all GUI, save volatile data before!) and re-check the meminfo.
Then allocate a lot of RAM
head -c 1500m /dev/zero | tail
and see what impact that has on the status quo.
Finally you can also try to allocate memory and see whether that takes more RAM on 6.7 or 6.6
cat <(head -c 500m /dev/zero) <(sleep 120) | tail
will hold 500MB for 2 minutes (if you need more time to draw the data, sleep longer)
You should also run this on the rescue.target to avoid interference from your DE
Do you have an AMD GPU?
Offline
have you tried building 6.7 with 6.6's config?
https://drive.google.com/file/d/1B_BF7D … sp=sharing linux-6.7.arch3-1.2-x86_64.pkg.tar.zst
https://drive.google.com/file/d/1VSiOG5 … sp=sharing linux-headers-6.7.arch3-1.2-x86_64.pkg.tar.zst
If the config is not the cause please try the first kernel from https://bbs.archlinux.org/viewtopic.php … 8#p2139898 if that has the issue please also try the second.
Offline
The biggest difference seems to be in GTK stuff, but eg. zsh and i3 are idem and xinit, sh and dbus-run-session even leaned down a bit.
Also this is not exactly the same as RAM demand creeping up over time.Check
cat /proc/meminfo
after "losing" RAM, then isolate the rescue.target (that will kill all GUI, save volatile data before!) and re-check the meminfo.
Then allocate a lot of RAMhead -c 1500m /dev/zero | tail
and see what impact that has on the status quo.
Finally you can also try to allocate memory and see whether that takes more RAM on 6.7 or 6.6
cat <(head -c 500m /dev/zero) <(sleep 120) | tail
will hold 500MB for 2 minutes (if you need more time to draw the data, sleep longer)
You should also run this on the rescue.target to avoid interference from your DEDo you have an AMD GPU?
Sorry I did not understand what you meant by isolating rescue.target and kill all GUI. Worth mentioning that I can log into tty since I use startx, I will compare the ram usage logging into tty2 which doesn't start the graphical session.
Other stuff like polybar and dunst doubled their ram usage, networkmanager and wireplumber also increased considerably for no apparent reason, and it looks like ps_mem doesn't take into account the usage of the kernel which by the looks of what htop and free -h report is also higher.
Yes I have an AMD GPU. RX 580 which also kernel 6.6 broke its power reporting as well.
loqs wrote:have you tried building 6.7 with 6.6's config?
https://drive.google.com/file/d/1B_BF7D … sp=sharing linux-6.7.arch3-1.2-x86_64.pkg.tar.zst
https://drive.google.com/file/d/1VSiOG5 … sp=sharing linux-headers-6.7.arch3-1.2-x86_64.pkg.tar.zst
If the config is not the cause please try the first kernel from https://bbs.archlinux.org/viewtopic.php … 8#p2139898 if that has the issue please also try the second.
Installed that kernel, nothing changed, however I did not install linux-headers, do I need them? My system doesn't have that package installed.
Offline
loqs wrote:have you tried building 6.7 with 6.6's config?
https://drive.google.com/file/d/1B_BF7D … sp=sharing linux-6.7.arch3-1.2-x86_64.pkg.tar.zst
https://drive.google.com/file/d/1VSiOG5 … sp=sharing linux-headers-6.7.arch3-1.2-x86_64.pkg.tar.zst
If the config is not the cause please try the first kernel from https://bbs.archlinux.org/viewtopic.php … 8#p2139898 if that has the issue please also try the second.
I tried the linux-mainline-6.7rc1-1-x86_64.pkg.tar.zst kernel and IT FIXED IT!
Private + Shared = RAM used Program
240.0 KiB + 88.5 KiB = 328.5 KiB xinit
272.0 KiB + 75.5 KiB = 347.5 KiB dbus-run-session
428.0 KiB + 369.5 KiB = 797.5 KiB sh
1.0 MiB + 178.5 KiB = 1.2 MiB dbus-broker-launch
1.2 MiB + 63.5 KiB = 1.3 MiB dbus-broker
912.0 KiB + 438.5 KiB = 1.3 MiB startx
1.0 MiB + 420.5 KiB = 1.4 MiB at-spi2-registryd
1.1 MiB + 394.5 KiB = 1.5 MiB at-spi-bus-launcher
1.2 MiB + 632.0 KiB = 1.8 MiB dbus-daemon (2)
1.3 MiB + 539.5 KiB = 1.8 MiB login
1.4 MiB + 503.5 KiB = 1.9 MiB picom
1.8 MiB + 146.5 KiB = 1.9 MiB (sd-pam)
1.4 MiB + 746.5 KiB = 2.2 MiB systemd-logind
2.0 MiB + 631.5 KiB = 2.6 MiB systemd-journald
936.0 KiB + 1.8 MiB = 2.7 MiB systemd-udevd
2.1 MiB + 780.5 KiB = 2.9 MiB pipewire-pulse
2.6 MiB + 267.5 KiB = 2.9 MiB xfconfd
1.1 MiB + 2.1 MiB = 3.2 MiB sudo (2)
3.0 MiB + 368.5 KiB = 3.3 MiB gvfsd-fuse
880.0 KiB + 2.7 MiB = 3.6 MiB udevadm (2)
3.0 MiB + 970.5 KiB = 4.0 MiB systemd-timesyncd
3.7 MiB + 685.5 KiB = 4.4 MiB dunst
4.2 MiB + 489.5 KiB = 4.7 MiB gvfsd
4.5 MiB + 278.5 KiB = 4.8 MiB xss-lock
3.7 MiB + 1.3 MiB = 5.0 MiB zsh (2)
4.6 MiB + 509.5 KiB = 5.1 MiB polkitd
4.6 MiB + 1.4 MiB = 6.0 MiB pipewire
5.3 MiB + 4.0 MiB = 9.3 MiB systemd (2)
12.5 MiB + 2.5 MiB = 15.0 MiB NetworkManager
18.3 MiB + 3.4 MiB = 21.7 MiB wireplumber
21.5 MiB + 1.6 MiB = 23.1 MiB i3
19.2 MiB + 5.3 MiB = 24.5 MiB xfce4-terminal
19.0 MiB + 6.9 MiB = 25.9 MiB polybar (3)
15.4 MiB + 11.9 MiB = 27.2 MiB kdeconnectd
18.9 MiB + 11.1 MiB = 30.1 MiB kdeconnect-indicator
16.7 MiB + 16.3 MiB = 33.0 MiB xfce-polkit
19.3 MiB + 17.2 MiB = 36.5 MiB xfce4-clipman
65.6 MiB + 15.0 MiB = 80.6 MiB Xorg
---------------------------------
399.9 MiB
=================================
Offline
If linux-mainline-6.7rc1-1-x86_64.pkg.tar.zst fixed it. Did linux-6.7.arch3-1.2-x86_64.pkg.tar.zst have the issue? If so please try the following kernel which is 6.7 without Arch's patches still with the config from 6.6:
https://drive.google.com/file/d/1WLHHc7 … sp=sharing linux-6.7.arch3-1.3-x86_64.pkg.tar.zst
https://drive.google.com/file/d/10Qx4sX … sp=sharing linux-headers-6.7.arch3-1.3-x86_64.pkg.tar.zst
Offline
If linux-mainline-6.7rc1-1-x86_64.pkg.tar.zst fixed it. Did linux-6.7.arch3-1.2-x86_64.pkg.tar.zst have the issue? If so please try the following kernel which is 6.7 without Arch's patches still with the config from 6.6:
https://drive.google.com/file/d/1WLHHc7 … sp=sharing linux-6.7.arch3-1.3-x86_64.pkg.tar.zst
https://drive.google.com/file/d/10Qx4sX … sp=sharing linux-headers-6.7.arch3-1.3-x86_64.pkg.tar.zst
Yes linux-6.7.arch3-1.2-x86_64.pkg.tar.zst had the issue, I said that in the message before trying the 6.7rc kernel sorry that I splited it into two replies.
Just booted into linux-6.7.arch3-1.3-x86_64.pkg.tar.zst the issue is back.
Last edited by Samueru (2024-01-21 19:35:01)
Offline
Ftr, 2nd link below.
Basically "systemctl isolate rescue.target", but typing that into some xfce terminal will immediately kill the GUI session.
There's an increasing pattern w/ AMDGPU itr, basicallly the RAM usage creeps up in likely GART/GTT (maybe it's now assigned to clients?) and is apparently only reclaimable in the rescue (perhaps multi-user?) target: https://bbs.archlinux.org/viewtopic.php … 6#p2144656
Ftr, polybar uses cairo, what gets it close to "gtk stuff" (itr)
But loqs is probably also already compiling bisection kernels, just can't help it
Offline
Ftr, 2nd link below.
Basically "systemctl isolate rescue.target", but typing that into some xfce terminal will immediately kill the GUI session.There's an increasing pattern w/ AMDGPU itr, basicallly the RAM usage creeps up in likely GART/GTT (maybe it's now assigned to clients?) and is apparently only reclaimable in the rescue (perhaps multi-user?) target: https://bbs.archlinux.org/viewtopic.php … 6#p2144656
Ftr, polybar uses cairo, what gets it close to "gtk stuff" (itr)But loqs is probably also already compiling bisection kernels, just can't help it
Seth my man you said 2nd link below but there is only one link? Either way I think I get it now.
I booted kernel 6.7.0-1.3 (has the issue) into tty2 and logged in (this prevents the graphical session from ever starting).
According to fastfetch (It runs automatically because it is on my zshrc) the ram usage is 558MiB.
free reports 535 MiB of ram used.
Then I ran systemctl isolate rescue.target which killed everything and asked me for my root password.
free -h now said that ram usage was 499 MiB
And dropping the caches lowered to 423 MiB.
Repeating the same steps on the LTS kernel (which does not have the issue) gave these results:
546 MiB of RAM used according to fastfetch.
530 MiB of RAM used according to free -h.
518 MiB after running systemctl isolate rescue.targe
which became 444 MiB after dropping the caches.
That's interesting, I should probably repeat the test after logging to a graphical session, because these results indicate that ram usage is lower on the kernel that has the issue lol
Is everything ok with the steps I'm doing?
Last edited by Samueru (2024-01-21 21:53:22)
Offline
There're 4 links in my signature.
According to fastfetch
Please use "cat /proc/meminfo" - every abstracting tool mushes relevant data into a single value, that's not really helpful.
I should probably repeat the test after logging to a graphical session
Yup, that was the idea
Edit: "dropping the caches" à la "echo 3 > /proc/sys/vm/drop_caches" is NOT goign to cut it if the RAM is "lost" in GART/GTT!
You have to reclaim it by allocating it.
Last edited by seth (2024-01-21 21:57:53)
Offline
There're 4 links in my signature.
According to fastfetch
Please use "cat /proc/meminfo" - every abstracting tool mushes relevant data into a single value, that's not really helpful.
I should probably repeat the test after logging to a graphical session
Yup, that was the idea
Edit: "dropping the caches" à la "echo 3 > /proc/sys/vm/drop_caches" is NOT goign to cut it if the RAM is "lost" in GART/GTT!
You have to reclaim it by allocating it.
Alright, I'm lost now.
Should I change from graphical.target to multi-user.target? (that is what the archwiki link is telling me to do)
Also if that was the idea it means all my steps were correct (besides not using meminfo) so I don't understand when you say that dropping caches won't work.
Offline
Not "echo 3 > /proc/sys/vm/drop_caches" but allocate the memory, https://bbs.archlinux.org/viewtopic.php … 6#p2145276
Sorry, isolation is actually in the paragraph above the direct link, https://wiki.archlinux.org/title/System … ent_target and the page also explains the targets in https://wiki.archlinux.org/title/Systemd#Targets - the direct link doesn't specifically address the multi-user.target but uses it as example on how to change the default target.
Offline
But loqs is probably also already compiling bisection kernels, just can't help it
Final sanity check kernel:
https://drive.google.com/file/d/1cg_cxg … sp=sharing linux-6.7rc1-1.1-x86_64.pkg.tar.zst
https://drive.google.com/file/d/1CRHucL … sp=sharing linux-headers-6.7rc1-1.1-x86_64.pkg.tar.zst
Assuming that is good:
$ git bisect bad v6.7
status: waiting for good commit(s), bad commit known
[stephen@arch ~/builds/linux-stable/src/linux]$ git bisect good v6.7-rc1
Bisecting: 1100 revisions left to test after this (roughly 10 steps)
[17894c2a7aa60a6da7495cc8500a53523e64c4b1] Merge tag 'trace-v6.7-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace
https://drive.google.com/file/d/1rvPlsx … sp=sharing linux-6.7rc4.r152.g17894c2a7aa6-1-x86_64.pkg.tar.zst
https://drive.google.com/file/d/1QXisXf … sp=sharing linux-headers-6.7rc4.r152.g17894c2a7aa6-1-x86_64.pkg.tar.zst
Offline
seth wrote:But loqs is probably also already compiling bisection kernels, just can't help it
Final sanity check kernel:
https://drive.google.com/file/d/1cg_cxg … sp=sharing linux-6.7rc1-1.1-x86_64.pkg.tar.zst
https://drive.google.com/file/d/1CRHucL … sp=sharing linux-headers-6.7rc1-1.1-x86_64.pkg.tar.zstAssuming that is good:
$ git bisect bad v6.7 status: waiting for good commit(s), bad commit known [stephen@arch ~/builds/linux-stable/src/linux]$ git bisect good v6.7-rc1 Bisecting: 1100 revisions left to test after this (roughly 10 steps) [17894c2a7aa60a6da7495cc8500a53523e64c4b1] Merge tag 'trace-v6.7-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace
https://drive.google.com/file/d/1rvPlsx … sp=sharing linux-6.7rc4.r152.g17894c2a7aa6-1-x86_64.pkg.tar.zst
https://drive.google.com/file/d/1QXisXf … sp=sharing linux-headers-6.7rc4.r152.g17894c2a7aa6-1-x86_64.pkg.tar.zst
linux-6.7rc1-1.1-x86_64.pkg.tar.zst is good. The issue is gone.
Should I now test linux-6.7rc4.r152.g17894c2a7aa6-1-x86_64.pkg.tar.zst?
Edit: Just went ahead and tested it as well, it is also good.
Last edited by Samueru (2024-01-21 23:23:47)
Offline
$ git bisect good
Bisecting: 545 revisions left to test after this (roughly 9 steps)
[6d04b70ea48b2d84ebf6cd9ad9b01ba50a58542e] Merge tag 'dmaengine-fix-6.7' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine
https://drive.google.com/file/d/1xayw-x … sp=sharing linux-6.7rc5.r261.g6d04b70ea48b-1-x86_64.pkg.tar.zst
https://drive.google.com/file/d/1XfuUQD … sp=sharing linux-headers-6.7rc5.r261.g6d04b70ea48b-1-x86_64.pkg.tar.zst
Offline
$ git bisect good Bisecting: 545 revisions left to test after this (roughly 9 steps) [6d04b70ea48b2d84ebf6cd9ad9b01ba50a58542e] Merge tag 'dmaengine-fix-6.7' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine
https://drive.google.com/file/d/1xayw-x … sp=sharing linux-6.7rc5.r261.g6d04b70ea48b-1-x86_64.pkg.tar.zst
https://drive.google.com/file/d/1XfuUQD … sp=sharing linux-headers-6.7rc5.r261.g6d04b70ea48b-1-x86_64.pkg.tar.zst
This one is good as well.
Offline
$ git bisect good
Bisecting: 277 revisions left to test after this (roughly 8 steps)
[fa655abe42c65e7e4ad52baf280dadfb571c110e] Merge tag 'input-for-v6.7-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
https://drive.google.com/file/d/1v1ftYg … sp=sharing linux-6.7rc6.r256.gfa655abe42c6-1-x86_64.pkg.tar.zst
https://drive.google.com/file/d/1Ubrfk- … sp=sharing linux-headers-6.7rc6.r256.gfa655abe42c6-1-x86_64.pkg.tar.zst
Offline
$ git bisect good Bisecting: 277 revisions left to test after this (roughly 8 steps) [fa655abe42c65e7e4ad52baf280dadfb571c110e] Merge tag 'input-for-v6.7-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
https://drive.google.com/file/d/1v1ftYg … sp=sharing linux-6.7rc6.r256.gfa655abe42c6-1-x86_64.pkg.tar.zst
https://drive.google.com/file/d/1Ubrfk- … sp=sharing linux-headers-6.7rc6.r256.gfa655abe42c6-1-x86_64.pkg.tar.zst
All good.
Offline
$ git bisect good
Bisecting: 142 revisions left to test after this (roughly 7 steps)
[5939a693dc6e6d6f293681017c70ff60c3723d43] Merge tag 'drm-fixes-2024-01-04' of git://anongit.freedesktop.org/drm/drm
https://drive.google.com/file/d/1Sk3hoA … sp=sharing linux-6.7rc8.r35.g5939a693dc6e-1-x86_64.pkg.tar.zst
https://drive.google.com/file/d/1Y94EK7 … sp=sharing linux-headers-6.7rc8.r35.g5939a693dc6e-1-x86_64.pkg.tar.zst
Offline