Still same issue with Firefox [Testing Update] 2022-08-03 - Glibc, GCC, LibreOffice, Firefox, MangoHud, KDE-git - #11 by omano
Yes, i can confirm that, also mentioned here:
Verified on GNOME.
The 5.17 kernel dropping combined with a nvidia update stopped me from updating. I manually removed the old kernel, installing the new one and reinstalling the nvidia package. Everything is working again now
1 Like
That kernel was marked EOL in the 2022-07-17 update …
Yes, that’s just why it is not recommended to compile the kernel yourself these days. Otherwise, it could happen that it’s already becoming EOL while you are still busy compiling 
That being said, I am just curious:
Currently, I am using the 5.19 kernel which is marked mainline at kernel.org. Is there already information on when kernel 5.19 will become EOL?
Would be nice if we have linux-rolling-stable and linux-rolling-lts additional as Packages.
no, because we don’t know what the next lts kernel is. it might be 5.19, it might not. that’s not on a firm schedule; we’ll know when they decide.
Longterm kernels are picked based on various factors – major new features, popular commercial distribution needs, device manufacturer demand, maintainer workload and availability, etc. You can roughly estimate when the new longterm version will become available based on how much time has elapsed since the last longterm version was chosen.
They used to exist, they have been removed, they will not add them back now after deciding to not have them in Manjaro. Refer to all the old threads about that (linux-lts and linux-latest packages)
suspend-to-ram is still broken 5.18.16 and 5.19.0
Have a Qemu VM for testing stuff so maybe its broken on Host as well.
Mh, what precisely is broken there? I use suspend-to-ram all the time, didn’t even give it a thought. My thinkpad woke up from suspension with 5.19.0 today too.
the resume does not work so the screen stays black after some time, the lookscreen comes up but recognize no keyboard input
Maybe it’s something with the combination of kernel, DM, WM and locking program. In my case it’s sway and swaylock and as I said, it’s fine, as well with kernel 5.18 as 5.19. But I think this should be discussed further in a seperate thread.
5.18.12 works tm
I’m also not having any problems - works fine for me.
You may check also 5.18.13 kernel and if that works, do a git-bisect between the last working kernel and the first broken, which you claim to be 5.18.14. You can follow this example repo on how to do it: GitHub - philmmanjaro/linux41: Manjaro Kernel 4.1
5.18.13 also effected:
git bisect bad v5.18.13
Status: warte auf gute(n) Commit(s), schlechter Commit bekannt
git bisect good v5.18.12
Binäre Suche: danach noch 113 Commits zum Testen übrig (ungefähr 7 Schritte)
[48fda9af1df971076416bace9bfbb5d6d89ba6c1] icmp: Fix a data-race around sysctl_icmp_echo_ignore_broadcasts.
A little similar problem:
https://bbs.archlinux.org/viewtopic.php?id=278350&p=2
Hmm, then some in .13 started the regression on your hardware. So you have to check the suggested commits, change those in the PKGBUILD by using the RC version of it and remove all our custom patches as needed. To test each build needs to perform the suspend cycle …
However Arch suggested 5.18.13 with 07186778cf645cc79e6913a28dadf445cd3e2439 reverted. Maybe give that a try, but I doubt it will fix your problem … So go ahead and do your own git-bisect round. You may also check the queue for possible fixes …
will check this, to much work for a shinny sunday 
The latest LTS does not have this problem, I will use this now until stable is ok
There is some maintaince for fbdev [GIT PULL] fbdev updates & fixes for v5.20-rc1 - Helge Deller in the pipline.
r8168 module is now available to download 