@apol1o Thanks a lot for the detailed answer. Glad to know hibernation is working well on your side. Maybe there is some hope for me too.
Just wanted to make sure that linux-clear 6.0 was working well, because it takes quite a while to compile for me. Will be trying again.
Did you compile linux-clear with the 35. Intel Alder Lake (MALDERLAKE) option too ?
Just to be sure, are you setting those via /etc/modprob.d/i915.conf-like configuration ? Because I did not see anything related to i915 in your kernel parameter line.
Yeah we’ll see how it goes tonight, last night on 5.19.10 when it woke up from sleep to go into hibernation it failed to actually go into hibernate or didn’t wake up correctly, I’m not sure. Anyway the battery was completely dead next morning.
Yes, doing the 35. Alder Lake build too, haven’t actually tried another one yet. How long does it take you?
I’m just about under 20min with my modified makepkg.conf, maybe take a loot below but MAKEFLAGS="-j$(getconf _NPROCESSORS_ONLN)" probably does the biggest difference.
makepkg.conf
#!/hint/bash
#
# /etc/makepkg.conf
#
#########################################################################
# SOURCE ACQUISITION
#########################################################################
#
#-- The download utilities that makepkg should use to acquire sources
# Format: 'protocol::agent'
DLAGENTS=('file::/usr/bin/curl -qgC - -o %o %u'
'ftp::/usr/bin/curl -qgfC - --ftp-pasv --retry 3 --retry-delay 3 -o %o %u'
'http::/usr/bin/curl -qgb "" -fLC - --retry 3 --retry-delay 3 -o %o %u'
'https::/usr/bin/curl -qgb "" -fLC - --retry 3 --retry-delay 3 -o %o %u'
'rsync::/usr/bin/rsync --no-motd -z %u %o'
'scp::/usr/bin/scp -C %u %o')
# Other common tools:
# /usr/bin/snarf
# /usr/bin/lftpget -c
# /usr/bin/wget
#-- The package required by makepkg to download VCS sources
# Format: 'protocol::package'
VCSCLIENTS=('bzr::bzr'
'fossil::fossil'
'git::git'
'hg::mercurial'
'svn::subversion')
#########################################################################
# ARCHITECTURE, COMPILE FLAGS
#########################################################################
#
CARCH="x86_64"
CHOST="x86_64-pc-linux-gnu"
#-- Compiler and Linker Flags
#CPPFLAGS=""
CFLAGS="-march=native -mtune=native -O2 -pipe -fstack-protector-strong --param=ssp-buffer-size=4 -fno-plt \
-Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security \
-fstack-clash-protection -fcf-protection"
CXXFLAGS="-march=native -mtune=native -O2 -pipe -fstack-protector-strong --param=ssp-buffer-size=4 -fno-plt"
LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now"
LTOFLAGS="-flto=auto"
RUSTFLAGS="-C opt-level=2 -C target-cpu=native"
#-- Make Flags: change this for DistCC/SMP systems
MAKEFLAGS="-j$(getconf _NPROCESSORS_ONLN) --quiet"
#-- Debugging flags
DEBUG_CFLAGS="-g"
DEBUG_CXXFLAGS="$DEBUG_CFLAGS"
#DEBUG_RUSTFLAGS="-C debuginfo=2"
#########################################################################
# BUILD ENVIRONMENT
#########################################################################
#
# Makepkg defaults: BUILDENV=(!distcc !color !ccache check !sign)
# A negated environment option will do the opposite of the comments below.
#
#-- distcc: Use the Distributed C/C++/ObjC compiler
#-- color: Colorize output messages
#-- ccache: Use ccache to cache compilation
#-- check: Run the check() function if present in the PKGBUILD
#-- sign: Generate PGP signature file
#
BUILDENV=(!distcc color ccache check !sign)
#
#-- If using DistCC, your MAKEFLAGS will also need modification. In addition,
#-- specify a space-delimited list of hosts running in the DistCC cluster.
#DISTCC_HOSTS=""
#
#-- Specify a directory for package building.
#BUILDDIR=/tmp/makepkg
#########################################################################
# GLOBAL PACKAGE OPTIONS
# These are default values for the options=() settings
#########################################################################
#
# Makepkg defaults: OPTIONS=(!strip docs libtool staticlibs emptydirs !zipman !purge !debug !lto)
# A negated option will do the opposite of the comments below.
#
#-- strip: Strip symbols from binaries/libraries
#-- docs: Save doc directories specified by DOC_DIRS
#-- libtool: Leave libtool (.la) files in packages
#-- staticlibs: Leave static library (.a) files in packages
#-- emptydirs: Leave empty directories in packages
#-- zipman: Compress manual (man and info) pages in MAN_DIRS with gzip
#-- purge: Remove files specified by PURGE_TARGETS
#-- debug: Add debugging flags as specified in DEBUG_* variables
#-- lto: Add compile flags for building with link time optimization
#
OPTIONS=(strip docs !libtool !staticlibs emptydirs zipman purge !debug !lto)
#-- File integrity checks to use. Valid: md5, sha1, sha224, sha256, sha384, sha512, b2
INTEGRITY_CHECK=(sha256)
#-- Options to be used when stripping binaries. See `man strip` for details.
STRIP_BINARIES="--strip-all"
#-- Options to be used when stripping shared libraries. See `man strip` for details.
STRIP_SHARED="--strip-unneeded"
#-- Options to be used when stripping static libraries. See `man strip` for details.
STRIP_STATIC="--strip-debug"
#-- Manual (man and info) directories to compress (if zipman is specified)
MAN_DIRS=({usr{,/local}{,/share},opt/*}/{man,info})
#-- Doc directories to remove (if !docs is specified)
DOC_DIRS=(usr/{,local/}{,share/}{doc,gtk-doc} opt/*/{doc,gtk-doc})
#-- Files to be removed from all packages (if purge is specified)
PURGE_TARGETS=(usr/{,share}/info/dir .packlist *.pod)
#-- Directory to store source code in for debug packages
DBGSRCDIR="/usr/src/debug"
#########################################################################
# PACKAGE OUTPUT
#########################################################################
#
# Default: put built package and cached source in build directory
#
#-- Destination: specify a fixed directory where all packages will be placed
#PKGDEST=/home/packages
#-- Source cache: specify a fixed directory where source files will be cached
#SRCDEST=/home/sources
#-- Source packages: specify a fixed directory where all src packages will be placed
#SRCPKGDEST=/home/srcpackages
#-- Log files: specify a fixed directory where all log files will be placed
#LOGDEST=/home/makepkglogs
#-- Packager: name/email of the person or organization building packages
#PACKAGER="John Doe <john@doe.com>"
#-- Specify a key to use for package signing
#GPGKEY=""
#########################################################################
# COMPRESSION DEFAULTS
#########################################################################
#
COMPRESSGZ=(pigz -c -f -n)
COMPRESSBZ2=(pbzip2 -c -f)
COMPRESSXZ=(xz -T "$(getconf _NPROCESSORS_ONLN)" -c -z --best -)
COMPRESSZ=(compress -c -f)
COMPRESSLRZ=(lrzip -9 -q)
COMPRESSLZ=(lzip -c -f)
COMPRESSZ=(compress -c -f)
COMPRESSZST=(zstd -c -z -q --threads=0 -)
COMPRESSLZ=(lzip -c -f)
COMPRESSLZ=(lzip -c -f)
#########################################################################
# EXTENSION DEFAULTS
#########################################################################
#
PKGEXT='.pkg.tar.zst'
SRCEXT='.src.tar.gz'
#########################################################################
# OTHER
#########################################################################
#
#-- Command used to run pacman as root, instead of trying sudo and su
#PACMAN_AUTH=()
Yes, indeed. I believe with early KMS you should include these options in /etc/modprobe.d/*.
Thanks a lot for the tip. I matched my makepkg.conf with yours, but it still takes around 2 to 3 hours to build.
Do you manually run makepkg -si in the same folder as the PKGBUILD file ? Maybe the make compilation parallelization gets overriden somewhere because I use paru -S linux-clear instead ?.
Compiled the linux-clear 6.0.0.1-clear and can confirm that PSR related issues on 5.19.11 are gone at least. /etc/modprob.d/i915.conf was set as follows:
Also did my best to match your kernel parameters, but systemctl hibernate still breaks on resume for me even on linux-clear.
Running systool -m i915 -av and diff-ing with yours gives a single difference:
Attributes:
...
refcnt = "20" # Yours is 24
but looking it up does not bring anything relevant to the refcnt field.
I will try to use the sd-encrypt partition unlocking method, instead of encrypt (currently using), which seems one of the main difference between our configs.
Worst case, I will try to install a fresh Arch install without encryption and test check whether hibernation works or not.
Will be reporting in about 3 days.
Thanks again for the assistance.
EDIT: @apol1o One more thing, do you happen to use any composer ?
So I was curious and gave linux-clear a try yesterday just to see if there was much of a performance gain. Boot times were a few seconds faster, and single-threaded Geekbench numbers were about 2% faster, but the big surprise to me was that the power consumption was much worse than both the Arch linux kernel and linux-mainline.
powerstat reported average idle power consumption was 0.5W higher (3.7W vs 3.2W), and playing a YouTube video was 16-18W (vs 11-12W on the other kernels) eyeballing with powertop.
I think linux-clear has some extremely aggressive battery performance settings since even though I made no changes to thermald or tlp setup, linux-clear basically maintained almost full performance on benchmark runs on battery, while linux and linux-mainline both go into a less aggressive profile that shaves off about 50% on ST and 30% on MT Geekbench scores when unplugged.
If anyone is planning to regularly use linux-clear I’d be sure to do some perf/power benchmarking to make sure it’s worth it for your use case.
My tests were w/ 6.0 on linux-mainline and linux-clear and the fixed 5.9.13 w/ linux.
I’m using yay, perhaps paru or even yay for that matter don’t use the system makepkg.conf by default. yay --save --makepkgconf /etc/makepkg.conf this will tell yay which makepkg.conf file to use. Maybe paru has something similar?
That’s too bad. Honestly, no idea where to go from here. Which bootloader do you use? And some kind of display/session manager like gdm?
Also don’t forget to change your boot paremeters. For example cryptdevice=UUID:mapperName is equivalent to rd.luks.name=UUID=mapperName with sd-encrypt.
Good luck!
I’m using sway when I’m on the go and mostly Gnome when docked. Just woke up and suspend-then-hibernate seems to have worked once more.
That idle consumption seems to be a bit high, which command (options) exactly are you using to measure it?
Did you compile linux-clear yourself or did you install linux-clear-bin?
For me it was slightly lower when idle but much lower when watching Youtube and stuff but there’s too many variables here to make a real comparison.
I feel like OOTB tlp doesn’t do much these days. I set the EPP to 225 when on battery for example. Took the value from another thread but seems to be a good middleground for me.
(CPU_ENERGY_PERF_POLICY_ON_BAT=225)
I am running linux-clear not linux-clear-bin so yes, it was a custom compile with MALDERLAKE.
Maybe I’ll play around w/ EPP and see w/ all the kernels since I’ve been pretty disappointed in general w/ how battery usage w/ YouTube playback, even in Firefox where I have full HW acceleration (it’s about 1-2W lower than Chrome, which doesn’t have working HW decode).
I am using endeavor with XFCE here, and it has driven me up a wall.
To keep it short:
No tip has extended the four hour battery life for me. Certain programs, such as Discord, endeavor easy package install, will not redraw and will display a frozen image until the window border is changed in any way. Certain icons for window borders and menus will be tiny for zero reason. Scaling in general is broken and doesn’t cooperate with me.
Can someone please, please tell me what I’m doing wrong? I’ve tried two days worth of troubleshooting and absolutely nothing has fixed all of those issues.
So I run Arch, not Endevour, but they are the same base. I’ve had really good luck reading the Arch Wiki to make most things work great. Lemme share a few things that might help… theres a Frame.work Arch wiki entry: Framework Arch Wiki Entry
The newest kernel, 5.19+, sometimes creates several video-related bugs/issues. I install both Linux and Linux-LTS kernels; if the kernel is ever creating bugs, or updates and creates new ones, you can just select the Linux-LTS in GRUB and it’ll squash those. The forum is currently reporting issues on 5.19.12, so this might help you; How to install Linux-LTS alongside Linux kernel
Remember, I’ve setup Arch from the ground up - so I don’t have experience using EndevourOS (on the frame, anyway)… I think you need to look at issues a different way. LIKE, are the video issues you mentioned because of the kernel? Etc…
One thing at a time, and many times where yer sniffing isn’t where the problem is. Sorry yer not loving Endevour on the frame. Heck; I installed Windows 11 just to see the difference. I’ve had the most luck with Fedora and Arch on the Frame, Linux side anyway. Hope you iron things out.
5.19.12 broke mine as described. Arch Linux LTS kernel temporarely fixed my system (could also have downgraded the kernel)
5.19.13 right now works great again. no display problems, just like before .12.
@CodeAsm I would really like to know how you have this setup and working. I cant for the life of me figure this out.
At the moment my screen locks up for about 10 seconds at a time and then is usable for about 10 seconds. This is where I’m currently at.
Framework 12th gen
Arch 5.19.13-arch1-1
i3-gaps for my window manager
Installed mesa, and my Xorg log contains:
[ 112.325] (II) LoadModule: “intel”
[ 112.326] (WW) Warning, couldn’t open module intel
[ 112.326] (EE) Failed to load module “intel” (module does not exist, 0)
[ 112.326] (II) LoadModule: “modesetting”
[ 112.326] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[ 112.328] (II) Module modesetting: vendor=“X.Org Foundation”
[ 112.328] compiled for 1.21.1.4, module version = 1.21.1
[ 112.328] Module class: X.Org Video Driver
[ 112.328] ABI class: X.Org Video Driver, version 25.2
[ 112.328] (II) LoadModule: “fbdev”
[ 112.328] (WW) Warning, couldn’t open module fbdev
[ 112.328] (EE) Failed to load module “fbdev” (module does not exist, 0)
[ 112.328] (II) LoadModule: “vesa”
[ 112.329] (WW) Warning, couldn’t open module vesa
[ 112.329] (EE) Failed to load module “vesa” (module does not exist, 0)
[ 112.329] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[ 112.351] (II) modeset(0): using drv /dev/dri/card0
[ 112.351] (II) modeset(0): Creating default Display subsection in Screen section
I have created the file /etc/modprobe.d/i915.conf and it contains:
options i916 enable_psr=0
options i915 enable_fbc=1
options i915 fastboot=1
options i915 enable_guc=2
I have also created /etc/modprobe.d/acpi.conf and it contains:
acpi_osi="!Windows 2020"
Hey there. I happen to have pretty much the same setup as you do.
Arch Xorg i3 wm (i3-gaps), no login manager.
12th i7 1260P Batch 2, 2 x 8 GiB and 1TB WN SN850.
Not sure if this is a typo, but shouldn’t it be i915 instead of i916 ?
If you had i916 in your .conf file, I would suggest trying again with and without PSR to check if it works.
The screen related problems I had with my 12th gen were mostly solved by disabling PSR, or upgrading to an ever more recent linux kernel (linux-clear==6.0.0.2 seems to work even with PSR enabled).
I experimented with this parameter, and I think you are better off just commenting out this line.
Just use default GuC and HuC setting for Arch.
Hi All. I’m trying to get an external monitor working with my Framework on Arch. I have a CalDigit TS3 Plus Thunderbolt 3 dock which has an Apple 27" display plugged into it. When I connect the dock to my Framework, the display is recognized and renders output. However, it remains stable for about 90 seconds and then does about 30 seconds of flashing on and off in 1 second intervals. Then this whole cycle repeats again.
I’m using KMS with Wayland (Hyprland) though I also tried Xorg with Awesome & Picom and had the same problems.
Any suggestions on where I can look to debug this? I’ve viewed the output of journalctl and dmesg while the issue is happening and nothing jumps out at me, though I may not know exactly what to look for.
The i916 wasnt a typo, but changing it to i915 didnt solve the issue either.
I downloaded linux-clear and installed it (took nearly 2 hours with the 1260 and 64gig of ram) Now I’m stuck I installed with archinstall because the screen flickering on the laptop didnt allow for me to use the laptop and the secondary monitor chops off the bottom 1/3rd of whats happening so the archinstall script was the only way to see what I was doing during the install, and the ??systemd?? bootloader is not liking the change to “linux-clear”
I’m at square 1 again.
I’ve had this frame.work laptop for 1 week today and have been struggling like crazy to get it working with arch… Installing Gentoo on a Thinkpad T61P in 2008 was easier. Installing arch on my T14 Gen1 AMD only took a day…
I’m damn near ready to throw this thing in the garbage.
Did you run mkinitcpio -p linux after changing that to recompile the kernel ?
EDIT: Not sure about systemd-boot usage, but with GRUB, it requires re-running the grub-mkconfig command to generate the appropriate boot entries for the newly added kernels too.
While it might help in your case, I think first and foremost you should focus on the 5.19.13 linux default kernel, as it is confirmed to work (personally, as well as other people in this thread).
Maybe try disabling the other fbc and fastboot options for i915 in the .conf file, and reboot again.
For later reference, in case you have to compile packages from source faster, you should edited your /etc/makepkg.conf, namely by changing the default line with MAKEPKG_FLAGS="-j2" to something like MAKEPKG_FLAGS="-j$(nproc --all)". This will make the computer use all the core for compilation, which should make it last around 10 to 20 minutes (I also did it yesterday on i7 1260P).
Once you get it working, it is a smooth and pleasant experience.
Maybe give it a try again with a fresher / cooler head
