Package Details: linux-amd-znver2-docs 5.18.v.9-1

Git Clone URL: https://aur.archlinux.org/linux-amd-znver2.git (read-only, click to copy)
Package Base: linux-amd-znver2
Description: Linux kernel aimed at the znver2 AMD Ryzen CPU based hardware
Upstream URL: https://www.kernel.org/
Licenses: GPL2
Submitter: eggz
Maintainer: eggz (NhaMeh)
Last Packager: eggz
Votes: 12
Popularity: 0.146222
First Submitted: 2020-10-26 18:04 (UTC)
Last Updated: 2022-07-02 18:48 (UTC)

Pinned Comments

eggz commented on 2020-10-26 18:15 (UTC)

Tired of compiling? Use this binary repo instead! Add this at the end of /etc/pacman.conf :

[linuxkernels]
Server = http://nhameh.ovh/$repo/$arch
SigLevel = Optional TrustAll

Latest Comments

eggz commented on 2022-06-17 08:52 (UTC)

That driver assumes that the display hardware has been initialized by the firmware or bootloader before the kernel boots.I am sorry, but I will not enforce this on all the kernel users. It looks like a really bad idea to do.

rvlobato commented on 2022-06-16 17:09 (UTC)

Hi @eggz, thanks for maintaining the package. I do not know if I'm misunderstanding. I was looking on https://wiki.archlinux.org/title/NVIDIA#Custom_kernel, and it says that the kernel should have CONFIG_DRM_SIMPLEDRM=y, looking in config seems that it is no enable. Likewise, I have nvidia-dkms, however never saw anything strange.

eggz commented on 2022-06-01 08:21 (UTC)

@evorster Yeah, intel BT certainly has some problems in the latest kernel releases, This is true. I personally dont use intel BT so I have absolutely no experience with it.

A possible work around could be this:

rmmod btusb
rmmod btintel
modprobe btintel
modprobe btusb

If it doesnt make things better, you better contact some intel bluetooth kernel dev and ask them what the hell they are doing up there lately :)

evorster commented on 2022-06-01 00:09 (UTC)

Using linux-amd-znver2-5.17.v.8-1-x86_64 I see the error described in this thread:

https://bbs.archlinux.org/viewtopic.php?id=264380

When I downgrade to linux-amd-znver2-docs-5.16.v.16-1-x86_64 The problem goes away.

kremix commented on 2022-04-13 22:24 (UTC)

@eggz works beautifully, much appreciated. however btusb is not being loaded for some reason. works on other kernels. Thanks.

eggz commented on 2022-04-12 23:03 (UTC)

Ok, can you try it now kremix?

kremix commented on 2022-04-12 22:16 (UTC)

hello. Is there any chance to add MEDIATEK MT7921 802.11ax driver? On stock kernel or even CK, wifi card works. not here sadly. thanks a lot

eggz commented on 2022-03-25 21:04 (UTC)

@macgeneral thank you for bringing this to my attention. its added now.

macgeneral commented on 2022-03-25 18:57 (UTC)

Hey,

Thank you again for maintaining this package.

Would it be possible to change the config.x86_64 file to

# CONFIG_RTW89_8852AE is not set
CONFIG_RTW89_8852AE=m

to support Realtek's 8852AE WiFi driver which was included with 5.16? Unfortunately the rtw89-dkms-git package / driver breaks with 5.16/17 and I lose my WiFi functionality on my Thinkpad X13.

ScradOwO commented on 2022-03-23 15:34 (UTC) (edited on 2022-03-23 15:34 (UTC) by ScradOwO)

@eggz thanks for the quick response and the builds!

eggz commented on 2022-03-22 18:47 (UTC)

@scradowo Thanks for pointing that out. I had it enabled but somehow in the final build it got turned off again. Another build is coming right up.

ScradOwO commented on 2022-03-22 17:51 (UTC) (edited on 2022-03-22 17:59 (UTC) by ScradOwO)

Is the amd-pstate scaling driver not enabled? edit: just checked your config, yeah it is indeed not enabled, would you consider enabling it in your future updates?

eggz commented on 2022-01-27 12:54 (UTC)

I seem to be having problems with the latest kernel when I reboot a system. Poweroff is fine. I have never seen a kernelupdate with this many commits, going through them seems like hell. As of now I have no idea where this issue comes from.

eggz commented on 2022-01-12 07:27 (UTC)

No problem mate!

Yeah I still don't really get what you are talking about, but that sounds like a system/user-specific option which I'm not keen on implementing anyway (if I'm not mistaken -- I'm afraid I'm not really following anyway).

dedguy21 commented on 2022-01-12 02:49 (UTC) (edited on 2022-01-12 03:06 (UTC) by dedguy21)

I'm sorry wasn't trying to be offensive, I really was just wondering.

But I think you are not understanding what I'm talking about.

Every kernel that is compiled has the possibility of excluding modules, this would be the first one where I just didn't see the option in the pkgbuild.

Modprobed-db provides this functionality for 99.9% of the custom kernels on arch to make that an easy process for the end user:

make LSMOD=$HOME/.config/modprobed.db localmodconfig ---remove all the modules not present in the modprobed.db database

Again, usually that option is available and I didn't see it in the pkgbuild, thought I was missing something.

You already provide a compiled package for download, I guess if it's no benefit to compiling that's just what I'll do.

But if you can't remove the excess modules during compile, why compile at all?

Again just wondering...

eggz commented on 2022-01-11 23:38 (UTC) (edited on 2022-01-11 23:39 (UTC) by eggz)

And where exactly do you want that "option" to be? I think I get the main idea of what you are trying to say but I'm not really sure. This kernel comes with a config and patches that I deem best for znver2, and its static. If you want to change the buildproces to something dynamic towards your system and preferences, I am unsure what you need this kernel for ... ?

dedguy21 commented on 2022-01-11 20:17 (UTC)

Hi, Just wondering

Am I missing where the option to build this with only ldconfig (only using the modules that are loaded with modprobed-db)?

There are a lot of modules I'm trying not to include in the build

PeerK commented on 2021-10-10 14:39 (UTC)

Thank you very much: As you see, I am not an expert ;) I changed makepkg.conf .

eggz commented on 2021-10-10 13:58 (UTC)

"Maybe the option "-j(Nr_of_cores-2)" as default might be a useful parameter?"

I dont control that variable, its provided by makepkg.conf, which is provided by core/pacman. I can only give you my experiences, and I had a situation where I had to do a "nr_of_cors+ 2+" -J flag.

I'm just glad you found your problem :-)

PeerK commented on 2021-10-10 13:16 (UTC) (edited on 2021-10-10 13:17 (UTC) by PeerK)

I have 8 cores, single threaded (4700U, laptop) and I tested the build process with -j4 and -j6, since I was still logged on.

Although I did not benchmark the processes precisely, -j6 built the kernel in a few minutes, while the default from the package was inacceptable long while the cores were sleeping ;-)

Maybe the option "-j(Nr_of_cores-2)" as default might be a useful parameter?

Thanks for the hint with -O3, I reset it to the default. Kind regards

eggz commented on 2021-10-10 10:35 (UTC)

how much cores you have and how many workers you pick? try adding 5 workers more than your threads and see what happens.

Be careful with choosing -O3, not all makefiles/packages support this and you might run into compatibility issues.

PeerK commented on 2021-10-10 10:26 (UTC)

For the last few kernel updates, the build process does not run on all availiable core.

Since this takes obviously much, much more time, I wondered if there is a technical reason, not to use on all the cores any more.

I am a noob, but I wonder, if "-j <no. of cores - 1>" in $MAKEFLAGS and "-O3" in $CFLAGS could speed up building the kernel.

Cheers,

s3rj1k commented on 2021-09-30 13:10 (UTC)

@eggz provides=linux description in wiki about reasons are quite full, but I wonder, what will happen if one would actually add this to a PKGBUILD, lets say separate one, specificaly tailored to replace existing default kernel, I mean like, would arch people take this AUR package down or it would just block a merge to community repo.

Would like to here a comment about that from Arch people.

eggz commented on 2021-09-30 04:39 (UTC)

sorry bkuri, I got told by arch linux staff not to do so. I find it annoying aswel.

https://aur.archlinux.org/pkgbase/linux-amd-znver2/?O=60&PP=10#comment-780129 https://aur.archlinux.org/pkgbase/linux-slim/?O=10&PP=10#comment-781913

bkuri commented on 2021-09-29 23:50 (UTC) (edited on 2021-09-29 23:59 (UTC) by bkuri)

@eggz Thanks for maintaining this package.

Would it be possible to add provides=linux to the PKGBUILD? I'm trying to remove the built-in manjaro kernel by using the following command mhwd-kernel -r linux510, but I'm receiving an error like "removing linux510 breaks dependency 'linux'".

Cheers!

s3rj1k commented on 2021-09-17 12:36 (UTC)

Yea, seems ok, yay AUR build cache was in the way, thanks

eggz commented on 2021-09-17 09:14 (UTC)

Yeah, thought so; it should have been fixed with the last commit yesterday? Otherwise I'm not following.

s3rj1k commented on 2021-09-17 08:39 (UTC)

@eggz latest change broke build at sha256sums check for renamed patch, sorry about stating that for the other kernel, got a bit mixed-up.

GJRodenburg commented on 2021-08-25 06:20 (UTC)

@eggz, just a quick note to say thanks for maintaining this 'flavour' of the kernel.

eggz commented on 2021-08-18 21:34 (UTC)

I added fscrypt support due to popular demand (I have had this question before), but I have my reservations over its security and performance. Luks seems to be a much better way to do this...

s3rj1k commented on 2021-08-18 12:43 (UTC)

please enable CONFIG_FS_ENCRYPTION build option

eggz commented on 2021-06-28 08:27 (UTC)

Linux Kernel 5.13 git development log:

      amdgpu:
       - Revert GFX9/10 doorbell fixes, we just end up trading one bug for
         another

Yeah, totaly didn't see that one coming ..

5.13 Coming up.

eggz commented on 2021-06-26 13:18 (UTC)

OK I reverted the "doorbell" (thats how they call it in the git...) commits to remove the idle bug. The AMDGPU team should really consider testing their commits before mainlining them ...

eggz commented on 2021-06-26 12:52 (UTC)

@GJRodenburg, as explained and proven by linux-slim, I have the fix. The question was if I should implement it. I guess thats a yes.

@DanEng Performance stays the same on all my systems, I got no idea about that.

DanEng1982 commented on 2021-06-26 10:31 (UTC) (edited on 2021-06-26 10:34 (UTC) by DanEng1982)

My experience is this since the latest kernel - same applies to 5.13-RC7-mainline tho: Geekbench gave me a multi-core score of some 7200-7600 in the past, since the last releases of the mentioned kernel versions I only get some 4100-4200 points on the same machine (Lenovo IdeaPad 5 15ARE05 with Ryzen 7 4800U and 16GB RAM), nothing else has changed. I am not saying that your kernel is at fault and to be fair and honest it doesn't feel slower at all, might even be just a glitch with Geekbench. But this is just my two cents.

GJRodenburg commented on 2021-06-26 10:04 (UTC)

@eggz I'm seeing the same GPU useage on a [AMD/ATI] Navi 10 [Radeon RX 5600 OEM/5600 XT / 5700/5700 XT] (rev c1). It was only on the znver2 kernel, but now has hopped over to the (new) 5.12.13-arch1-1 stock arch kernel. I have no fix, but just to give you another datapoint.

eggz commented on 2021-06-24 11:37 (UTC)

FYI, With the current kernelrelease I have a problem with my SIENNA (6800 series) GPU. The idle usage is through the roof, for some reason the GPU is not clocking back. There seems to be something using it but I have no idea what. This is at the kernel level.

I have succesfully removed the problem on my linux-slim kernel by reverting the "doorbell" commits which seems to cause this high usage bug (in some way I do not understand)

I have searched around alot EVERYWHERE the last few days, and it seems to me I am the ONLY one with this problem (or a sienna gpu?), if there is a need for the fix on this kernel, let me know and I will make it so.

eggz commented on 2021-06-16 12:13 (UTC)

Concerning the previously applied suspend patch;

applying git patch ../suspend.patch
error: patch failed: drivers/usb/host/xhci-pci.c:59
error: drivers/usb/host/xhci-pci.c: patch does not apply
error: patch failed: drivers/usb/host/xhci.h:1892
error: drivers/usb/host/xhci.h: patch does not apply

These patches are no longer actual. I will not forceimplement them on a "fire for effect" basis, that will cause trouble. If there are new, up to date/correct patches available I will implement them.

I don't have time to codereview right now -- might be they got merged aswel.

eggz commented on 2021-06-08 15:21 (UTC)

Hey gofree thx for the heads up.

I implemented the 8 patches and everything seems ok. I do not have any znver2 based laptop in my possesion though, so I idea if it works or what the outcome is.

Thanks again!

gofree commented on 2021-06-08 13:13 (UTC) (edited on 2021-06-08 13:47 (UTC) by gofree)

Do you think you could include 8 patches from here

https://gitlab.freedesktop.org/drm/amd/-/issues/1230

specifically link for patches

https://gitlab.freedesktop.org/drm/amd/uploads/c6a4b5dc9ea91d49fd48e67bdcdf99e7/test-patches.tar.gz

TechXero commented on 2021-05-01 10:28 (UTC)

@eggz Well I am currently on 11.16 and once I install 12.02 I cannot do anything except hard reset once I give reboot command. How to do this ? Can you find me on Discord ? TechXero ~ DarkXero#5199

eggz commented on 2021-05-01 09:50 (UTC) (edited on 2021-05-01 09:50 (UTC) by eggz)

@techxero

I See. How strange, I have a 3900x right here so it shouldn't be that diffrent from your CPU, and rebooting works just fine, so I really don't know what to tell you. :-(

Your older kernel will work for many years to come, but I suspect by then you will have found what the real problem is...

I have looked upstream for you and there is no mention of a reboot issue with the latest kernel..

Can you give your journalctl output right before your computer freezes?

TechXero commented on 2021-05-01 08:43 (UTC) (edited on 2021-05-01 08:46 (UTC) by TechXero)

@eggz

Before restoring my system was rebooting fine. Now after formatting it and installing Arch fresh.

Rebooting not booting, meaning, when I type sudo reboot or reboot, or even select reboot from panel it goes through motions then freezes on black screen that has the 2 Kernel lines top left..

Keyboard is unresponsive I have to hard reset.. 5.11.16-amd-znver2 works great.. If I update same issue.. What could I be missing if older version works not new one ? If I was missing anything then even older version shouldn't work right ?

eggz commented on 2021-04-30 23:28 (UTC)

@techxero, so you did an arch fresh install, but it was working fine before upgrading the kernel? This sounds a bit confusing to me, when did you upgrade? before or after the fresh install?

I have this kernel running on a bunch of systems, all of them are working fine. I also haven't got any complaint yet for this kernel. I'll never say never, but for now all evidence points towards your install missing having another problem instead of the kernel having a problem.

At what point exactly do you have a black screen? After grub? After the rootswitch? What do you see on your screen after grub? If I had to take a wild guess guess with almost no info (low hitrate though), it seems like your created ramdisk image is completely failing you.

TechXero commented on 2021-04-30 17:57 (UTC) (edited on 2021-04-30 18:49 (UTC) by TechXero)

@eggz Thanks for this but recently had to do fresh install of Arch now when using this Kernel and I try rebooting it just hangs on black screen. I am on Ryzen 5 3600X so a ZEN2 CPU.. Was working fine before upgrading to 5.12..

Seems 5.12 isn't yet ready for release. 5.11.16 is last one that works. So am sticking to that setting update to ignore for now :(

Tried Repo and compiling same result :(

ThirstyShark commented on 2021-04-26 22:55 (UTC)

Yep, touchpad is working again with the latest changes. Thanks for your quick response! Interesting how the config is split.

eggz commented on 2021-04-26 21:48 (UTC) (edited on 2021-04-26 21:48 (UTC) by eggz)

Thank you for picking this up, it seems that they renamed that option to these lines:

+CONFIG_I2C_HID_ACPI=m
+CONFIG_I2C_HID_CORE=m

which would explain why I lost that config, since I always reuse the old config.

Can you please confirm these new options work? thanks!

ThirstyShark commented on 2021-04-26 20:28 (UTC) (edited on 2021-04-26 20:29 (UTC) by ThirstyShark)

Hi,

in the latest version i2c-hid is gone. Can you re-add it? it's needed for most laptop touchpads.

CONFIG_I2C_HID=m

dedguy21 commented on 2021-03-12 20:43 (UTC) (edited on 2021-03-12 21:03 (UTC) by dedguy21)

Actually never mind, something messed up and so I'll just stick to the PKGBUILD. Thanks


How do we force "make localmodconfig" on your PKGBUILD?

I have it set to "menuconfig" so I can force zstd compress, but now the kernel, it build every module and the kitchen sink, was searching and didn't see an option where you would expect to see one?

dedguy21 commented on 2021-03-12 20:31 (UTC)

Thanks for the thorough answer.

eggz commented on 2021-03-12 18:16 (UTC) (edited on 2021-03-13 10:56 (UTC) by eggz)

It sure does. This was enabled by default starting from version 5.0. It should be enabled anywhere. You can check if its working with these steps. (everybody loves some feedback)

1) add 'drm.debug=0x04' to your kernel parameters preferably in "/etc/default/grub", in the GRUB_CMDLINE_LINUX, like this: GRUB_CMDLINE_LINUX="drm.debug=0x04" and then run grub-mkconfig -o /boot/grub/grub.cfg

or directly in "/boot/grub/grub.cfg" at the 'linux /boot/vmlinuz-linux' line, something like this: linux /boot/vmlinuz-linux root=UUID=<uuid> rw drm.debug=0x04

2) monitor dmesg output for 'VRR'(variable refresh rate?) strings (when the DE starts or when doing something opengl);

log search: dmesg | grep -e drm -e VRR realtime monitor: dmesg -w | grep -e drm -e VRR

You should see something like:

[  316.044970] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] VRR packet update: crtc=77 enabled=0 state=2
[  316.058560] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] VRR packet update: crtc=80 enabled=0 state=2
[  319.678906] [drm:drm_mode_addfb2 [drm]] [FB:132]
[  319.679766] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] VRR packet update: crtc=77 enabled=1 state=3
[  319.683630] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] VRR packet update: crtc=80 enabled=1 state=3
[  319.740178] [drm:drm_mode_addfb2 [drm]] [FB:140]
[  319.763956] [drm:drm_mode_addfb2 [drm]] [FB:141]
[  322.578440] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] VRR packet update: crtc=77 enabled=0 state=2
[  322.589016] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] VRR packet update: crtc=80 enabled=0 state=2
[  342.316459] [drm:drm_mode_addfb2 [drm]] [FB:131]
[  342.317336] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] VRR packet update: crtc=77 enabled=1 state=3
[  342.331751] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] VRR packet update: crtc=80 enabled=1 state=3
[  342.387385] [drm:drm_mode_addfb2 [drm]] [FB:132]
[  342.413740] [drm:drm_mode_addfb2 [drm]] [FB:133]
[  352.512071] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] VRR packet update: crtc=77 enabled=0 state=2
[  352.522602] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] VRR packet update: crtc=80 enabled=0 state=2
[  354.964177] [drm:drm_mode_addfb2 [drm]] [FB:137]
[  354.965248] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] VRR packet update: crtc=77 enabled=1 state=3
[  354.968819] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] VRR packet update: crtc=80 enabled=1 state=3
[  355.024555] [drm:drm_mode_addfb2 [drm]] [FB:132]
[  355.051308] [drm:drm_mode_addfb2 [drm]] [FB:141]

the VRR packet updates will show you that freesync is doing its thing.

ADDITION: you can even check out the monitor(s?) freesync range(s?) with this command: cat /sys/kernel/debug/dri/0/DP-*/vrr_range

Initial support was for a single monitor only, but my tests show now it should always be working, atleast when you are using OGL fullscreen on some monitor.

dedguy21 commented on 2021-03-12 15:14 (UTC)

Quick question, does this kernel come with freesync baked in and enabled?

eggz commented on 2021-02-26 10:15 (UTC)

5.11.2 still does not contain the upstream amdgpu fixes, but atleast they are spotted in the master tree of stable:

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=9c712c9c382ca69a955e3a384fc245ad8c42b005

Which leads me to believe they will finally be merged in 5.11.3

Until then, enjoy this prepatched kernel I guess..

macgeneral commented on 2021-02-23 15:29 (UTC) (edited on 2021-02-23 15:30 (UTC) by macgeneral)

Don't worry, there are no hard feelings - I hope I didn't sound rude :) As for the build pipeline: that's a valid point I didn't consider. It's just that your current PKGBUILD takes way longer than it could for everyone else (especially people with slow internet access).

I don't like binary builds (from the AUR) too much for critical things like the kernel, but I might give it a try.

Thank you for the fast response and for maintaining this project.

eggz commented on 2021-02-23 15:21 (UTC)

I'm Sorry, but that would break my entire build pipeline. I hope you don't take this personally..

You sound like a capable guy (since you don't want to use the binary repo), maybe you can, for example, "sed" my PKGBUILD to your likings before you fire the build? Shouldn't be that hard to automate that. I also love automation.

macgeneral commented on 2021-02-23 15:01 (UTC) (edited on 2021-02-23 15:16 (UTC) by macgeneral)

Could you please either change the retrieval of the source code to the tar archive like for examlpe the linux-clear package does or alternatively use something like git clone --depth 1 --branch $gitver https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git?

It's completely unnecessary to retrieve the complete git history of the kernel (it wastes a lot of space when being kept in the cache directory and takes forever to download on a clean build).

Compare your current PKGBUILD:

[..]
Receiving objects: 100% (9277799/9277799), 3.43 GiB | 8.04 MiB/s, done.
[..]
dev@vm:~$ du -hs ~/.cache/yay/linux-amd-znver2/linux
3,7G    ~/.cache/yay/linux-amd-znver2/linux

Using only the current/required state (--depth 1):

dev@vm:~$ git clone --depth 1 --branch v5.11.1 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
[..]
Receiving objects: 100% (75668/75668), 202.59 MiB | 6.19 MiB/s, done.
[..]
dev@vm:~$ du -hs linux
1,4G    linux

Using the tar-Archive instead:

dev@vm:~$ wget https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.11.1.tar.xz
[..]
linux-5.11.1.tar.xz 100%[===================>] 112,17M  9,14MB/s    in 13s     
[..]

So a https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-$gitver.tar.xz would be optimal ;)

eggz commented on 2021-02-23 13:52 (UTC)

Looks like the amdgpu patches are still not mainlined, so... enjoy this patched kernel I guess? Can't really follow why it is so hard to merge these commits to stable.

eggz commented on 2021-02-23 09:25 (UTC) (edited on 2021-02-23 09:25 (UTC) by eggz)

Hey fellow AMD users, this is just a PSA; Be sure to check this thread out: https://www.reddit.com/r/Amd/comments/lnmet0/an_update_on_usb_connectivity_with_500_series/

As it turns out, I myself was/is also affected by those problems. But mostly the 'replug' happens so fast I don't even notice it. But my kernel log sure does! :

Feb 23 09:45:21 eggzpc kernel: usbcore: registered new interface driver usbfs
Feb 23 09:45:21 eggzpc kernel: usbcore: registered new interface driver hub
Feb 23 09:45:21 eggzpc kernel: usbcore: registered new device driver usb
Feb 23 09:45:21 eggzpc kernel: usb usb2: We don't know the algorithms for LPM for this host, disabling LPM.
Feb 23 09:45:21 eggzpc kernel: usb usb4: We don't know the algorithms for LPM for this host, disabling LPM.
Feb 23 09:45:21 eggzpc kernel: usb: port power management may be unreliable
Feb 23 09:45:21 eggzpc kernel: usb usb6: We don't know the algorithms for LPM for this host, disabling LPM.
Feb 23 09:45:21 eggzpc kernel: usb usb8: We don't know the algorithms for LPM for this host, disabling LPM.
Feb 23 09:45:21 eggzpc kernel: usb 1-3: new full-speed USB device number 2 using xhci_hcd
Feb 23 09:45:21 eggzpc kernel: usb 5-1: new full-speed USB device number 2 using xhci_hcd
Feb 23 09:45:21 eggzpc kernel: usb 3-4: new full-speed USB device number 2 using xhci_hcd
Feb 23 09:45:21 eggzpc kernel: usb 7-2: new full-speed USB device number 2 using xhci_hcd
Feb 23 09:45:21 eggzpc kernel: usb 3-4: config 1 has an invalid interface number: 2 but max is 1
Feb 23 09:45:21 eggzpc kernel: usb 3-4: config 1 has no interface number 1
Feb 23 09:45:21 eggzpc kernel: usb 5-1: not running at top speed; connect to a high speed hub
Feb 23 09:45:21 eggzpc kernel: usbcore: registered new interface driver usbhid

Lets hope AMD adresses them soon!

eggz commented on 2021-02-21 00:43 (UTC)

I'm sorry but i chose lzo compression since its much faster in compressing. You can always override it to the compression of your choice, but I'm not changing the default.

toxygen commented on 2021-02-21 00:40 (UTC)

since arch is moving to ztsd compression on mkinitcpio, should linux-amd-znver2.preset line 6 be changed to:

export COMPRESSION="ztsd"

?

i had no problems with changing it manually

eggz commented on 2021-02-19 16:34 (UTC)

Hey, smart maintainers actually just wait for upstream and do nothing. I'm not a smart maintainer. I am an impatient one. I think I'm going to leave it like that, take the big problem out, let upstream take care of the rest. (Unless it's still not fixed in 5.11.1, then I'll have another look)

Thank you so much for your feedback. Now I know it's worth implementing on all my kernels. It's hard to debug/fix for hardware you do not even have.

scruffidog commented on 2021-02-19 16:24 (UTC)

I think you targeted the right fiddly bits. I've performed the poweroff under a few different scenarios and they all seem to work correctly in that when I take it down, it stays down.

The weird trace and the "Renoir unsupported power profile" issues are still there. One step at a time.

eggz commented on 2021-02-19 07:56 (UTC)

@scruffidog I implemented a proposed shutdown patch for renoir hardware. It seems to work in most cases (but not all of them).

If you are able, please provide feedback to me, to see if it is worth implementing on all kernels (or its just better to wait for upstream if it doesnt work in most cases).

eggz commented on 2021-02-19 07:33 (UTC) (edited on 2021-02-19 07:39 (UTC) by eggz)

This is probably the new renoir modules that aren't working 100%. The vanilla arch kernel works because they never bother activating AMD modules and that might be the probable cause.

as mentioned before this is probably because of these modules (which vanilla doesnt activate)

CONFIG_AMD_SFH_HID=m
CONFIG_AMD_PMC=m

If the complaints still keep rolling in after 5.11.1, I am disabeling these modules ...

EDIT:

Looks like you are not the only one: https://bugzilla.kernel.org/show_bug.cgi?id=211799

scruffidog commented on 2021-02-19 04:32 (UTC) (edited on 2021-02-19 04:37 (UTC) by scruffidog)

something weird with this kernel: when I try to poweroff by doing "poweroff" or "systemctl poweroff" with this kernel, it always winds up rebooting. I thought I was going crazy until I reinstalled the standard linux-5.11.arch2-1 kernel where it then behaves normally. how do I even begin to debug this ?

I was trying to figure out other issues where I'm getting the following error mesgs:

[ 3.188408] ------------[ cut here ]------------ [ 3.188411] WARNING: CPU: 6 PID: 633 at net/wireless/nl80211.c:7652 nl80211_get_reg_do+0x22e/0x2a0 [cfg80211] [ 3.188482] Modules linked in: snd_hda_codec_realtek(+) iommu_v2 gpu_sched i2c_algo_bit drm_ttm_helper fjes(-) ccm snd_hda_codec_generic ttm algif_aead ledtrig_audio snd_hda_codec_hdmi cbc snd_hda_intel des_generic snd_acp3x_rn snd_intel_dspcfg libdes snd_soc_dmic drm_kms_helper snd_acp3x_pdm_dma snd_hda_codec hid_sensor_gyro_3d snd_soc_core hid_sensor_accel_3d hid_sensor_magn_3d hid_sensor_trigger industrialio_triggered_buffer kfifo_buf hid_sensor_iio_common snd_hda_core industrialio ac97_bus snd_pcm_dmaengine snd_hwdep snd_pcm cec snd_timer snd syscopyarea sysfillrect hid_sensor_hub sysimgblt snd_rn_pci_acp3x fb_sys_fops soundcore snd_pci_acp3x amd_sfh algif_skcipher cmac sha512_ssse3 sha512_generic md4 algif_hash af_alg joydev mousedev iwlmvm hid_multitouch mac80211 hid_generic libarc4 iwlwifi nls_iso8859_1 edac_mce_amd nls_cp437 hp_wmi(+) kvm_amd vfat fat cfg80211 sparse_keymap ccp wmi_bmof kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel tpm_crb k10temp evdev [ 3.188557] aesni_intel input_leds crypto_simd pcspkr tpm_tis led_class tpm_tis_core cryptd glue_helper rfkill tpm i2c_piix4 i2c_hid ucsi_acpi rng_core typec_ucsi typec thermal wmi video hid battery ac acpi_cpufreq pinctrl_amd button amd_pmc acpi_tad sch_fq_codel tcp_bbr drm pkcs8_key_parser msr fuse crypto_user ip_tables x_tables xfs libcrc32c crc32c_generic rtsx_pci_sdmmc mmc_core serio_raw atkbd libps2 xhci_pci xhci_hcd crc32c_intel nvme usbcore nvme_core usb_common t10_pi rtsx_pci i8042 serio [ 3.188613] CPU: 6 PID: 633 Comm: iwd Not tainted 5.11.0-AMD-znver2 #1 [ 3.188617] Hardware name: HP HP ENVY x360 Convertible 15m-ee0xxx/876F, BIOS F.15 11/12/2020 [ 3.188620] RIP: 0010:nl80211_get_reg_do+0x22e/0x2a0 [cfg80211] [ 3.188674] Code: 89 ef c7 44 24 0c 01 00 00 00 e8 3d 03 49 e1 85 c0 74 cc e9 ff fe ff ff 48 89 ef 48 89 04 24 e8 08 1e 6b e1 48 8b 04 24 eb 89 <0f> 0b 48 89 ef e8 f8 1d 6b e1 b8 ea ff ff ff e9 75 ff ff ff b8 97 [ 3.188678] RSP: 0018:ffffb79e41c7fb60 EFLAGS: 00010202 [ 3.188682] RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000 [ 3.188684] RDX: ffff95208e4c8008 RSI: 0000000000000000 RDI: ffff95208e4c8300 [ 3.188686] RBP: ffff9520841e6500 R08: 0000000000000004 R09: ffff952082c1f014 [ 3.188688] R10: 0000000000000020 R11: ffff95208d88b0c0 R12: ffffb79e41c7fbc0 [ 3.188690] R13: ffff952082c1f014 R14: 0000000000000000 R15: ffff95208e4c8300 [ 3.188693] FS: 000077440c5d2740(0000) GS:ffff952f4f780000(0000) knlGS:0000000000000000 [ 3.188696] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 3.188698] CR2: 000077440c55d4e0 CR3: 000000010d912000 CR4: 0000000000150ee0 [ 3.188701] Call Trace: [ 3.188707] genl_family_rcv_msg_doit+0xfd/0x160 [ 3.188721] genl_rcv_msg+0xf0/0x1e0 [ 3.188726] ? nl80211_vendor_cmd_dump+0x5e0/0x5e0 [cfg80211] [ 3.188778] ? nl80211_send_regdom.constprop.0+0x1b0/0x1b0 [cfg80211] [ 3.188832] ? genl_get_cmd+0xc0/0xc0 [ 3.188836] netlink_rcv_skb+0x5b/0x100 [ 3.188841] genl_rcv+0x24/0x40 [ 3.188844] netlink_unicast+0x23c/0x340 [ 3.188848] netlink_sendmsg+0x233/0x460 [ 3.188855] __sys_sendto+0x18e/0x1a0 [ 3.188864] __x64_sys_sendto+0x25/0x30 [ 3.188868] do_syscall_64+0x33/0x40 [ 3.188875] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 3.188882] RIP: 0033:0x77440c6d5680 [ 3.188886] Code: c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 1d 45 31 c9 45 31 c0 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 68 c3 0f 1f 80 00 00 00 00 55 48 83 ec 20 48 [ 3.188889] RSP: 002b:00007ffced034038 EFLAGS: 00000246 ORIG_RAX: 000000000000002c [ 3.188893] RAX: ffffffffffffffda RBX: 0000575a904e3c00 RCX: 000077440c6d5680 [ 3.188895] RDX: 000000000000001c RSI: 0000575a90503330 RDI: 0000000000000004 [ 3.188897] RBP: 0000575a90502ee0 R08: 0000000000000000 R09: 0000000000000000 [ 3.188899] R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffced0340b8 [ 3.188901] R13: 00007ffced0340b4 R14: 0000575a904ed890 R15: 0000000000000000 [ 3.188905] ---[ end trace e842f3efd640ead4 ]---

and further down:

amdgpu: Unsupported power profile mode 0 on RENOIR

This is on a HP Envy x360 with the 4700u.

eggz commented on 2021-02-18 12:53 (UTC)

I identified the AMDgpu troubles in the linux-next tree and "backported" the patch

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=85f4f00c1e88b2a5aced59cca7354631e8889dfb

Description:

This reverts commit 8866a67ab86cc0812e65c04f1ef02bcc41e24d68.

This breaks hotplug of HDMI on some systems, resulting in
a blank screen also causes failures for displays to light up
on other systems.

There are a bunch of other fixes in upstream (linux-next), but this one seems standalone and is compatible with the stable tree. I'm not going to put everything upstream inhere, this seems to be enough for me to supress all the AMDGPU errors.

I tested this on 2 machines already and it seems to have good results.

eggz commented on 2021-02-16 15:06 (UTC)

Nice man! Lemme know the results.

Just to be overly clear, set those options to

# CONFIG_AMD_SFH_HID is not set
# CONFIG_AMD_PMC is not set

Let me know that it fixes anything if you are able to. Good luck!

dedguy21 commented on 2021-02-16 15:02 (UTC)

@eggz

Thanks. I don't mind compiling as it was my main excuse in buying so many darn cores in the first place :)

eggz commented on 2021-02-16 08:56 (UTC) (edited on 2021-02-16 08:57 (UTC) by eggz)

@dedguy21

There were alot of renoir code additions in 5.11 (and I activated them), and I can only hope they were good. If they aren't, theres not much I can do about that. I don't even have renoir hardware :/

I also saw some AMDGPU problems on my vega based hardware on 5.11, but if your problems are CPUrelated, that sends even more chills up my spine ...

I hope they will fix it in 5.11.1 or later. I think it's best you keep checking on every release if things get better or not.

Another option is to disable the new RENOIR options and recompile the kernel:

CONFIG_AMD_SFH_HID=m
CONFIG_AMD_PMC=m

I think PMC is a strong contender in being a problematic new module explaining the troubles you have..

IF you're intrested in this last option but don't like to compile, I'll do it for you, just let me know. (since I don't have the hardware..)

dedguy21 commented on 2021-02-16 07:25 (UTC) (edited on 2021-02-16 07:29 (UTC) by dedguy21)

I have a Dell G5 SE 5505, ryzen 4900H renoir chip, plus radeon 5600M graphics. Any rate have been using this kernel since you split it away from linux-amd, and everything was working fine until this last 5.11-xx update. Performance was horrible, machine stuttered at everything, even booting took longer than usual.

Just an FYI, not sure if anyone else will have the issue, but I had to downgrade back to 5.10-16, that fixed my issues.

eggz commented on 2021-02-15 20:44 (UTC)

Your vbox modules are not ready for linux 5.11 . You will probably have to wait for an update for that module.

Also why is everyone using virtualbox for virtualisation on linux? Just use libvirtd/Qemu kvm ...? You know like ... with present in-tree kernel modules?

jogai commented on 2021-02-15 20:17 (UTC) (edited on 2021-02-15 20:18 (UTC) by jogai)

It fails with my dkms modules:

``

(3/3) Install DKMS modules

==> dkms install --no-depmod -m v4l2loopback -v 0.12.5 -k 5.11.0-AMD-znver2

==> dkms install --no-depmod -m v4l2loopback-dc -v 1.7.1 -k 5.11.0-AMD-znver2

==> dkms install --no-depmod -m vboxhost -v 6.1.18_OSE -k 5.11.0-AMD-znver2

Error! Bad return status for module build on kernel: 5.11.0-AMD-znver2 (x86_64)

Consult /var/lib/dkms/vboxhost/6.1.18_OSE/build/make.log for more information.

==> Warning, `dkms install --no-depmod -m vboxhost -v 6.1.18_OSE -k 5.11.0-AMD-znver2' returned 10

==> depmod 5.11.0-AMD-znver2

``

drlobes commented on 2021-02-04 08:20 (UTC)

@eggz Yes its my first custom kernel install, all I did was install the aur package then restarted. Right now I saw that I have some updates to do and linux-amd-znver2 5.10.v.13-1 is also updating. I'll try the grub config after, thank you!

eggz commented on 2021-02-04 07:55 (UTC)

ehm.. did you run grub-mkconfig -o /boot/grub/grub.cfg ? and then pick the new kernel? Is this your first custom kernel install or not?

drlobes commented on 2021-02-04 07:44 (UTC)

Well it did install without any errors, but after restart uname -a still shows the kernel I normally have, is there anything else I need to do?

eggz commented on 2021-01-25 10:12 (UTC)

Even more triviatime: aur/linux-amd is currently standing by to be optimised for znver3 (RYZEN 5000 Desktop Series). For now, they are "equal". I will try to use linux-amd to always represent the "upstream" tech, so the latest architecture. Linux-amd will most likely continue working fine for ALL ryzen hardware though on the surface.

DanEng1982 commented on 2021-01-25 09:49 (UTC) (edited on 2021-01-25 09:50 (UTC) by DanEng1982)

znver2 is the name of the AMD Ryzen Zen2 microarchitecture meaning this is a highly optimized Kernel that, if you have an AMD Ryzen CPU, can be used for gaming, audio/video and things like that.

Moo-Crumpus commented on 2021-01-25 09:46 (UTC)

Just for the newbies asking stupid questions, like me: what is znver?

Kryesh commented on 2021-01-24 11:12 (UTC)

That was fast! I rebuilt the package it looks like it did the trick, awesome work

Thanks again for making and maintaining this build!

eggz commented on 2021-01-24 09:49 (UTC)

Kryesh, thanks to your clear indications, I found the problem.

The "order" you are withnessing with linux-zen (and not with my kernel) is because of the "/usr/share/libalpm/hooks/90-mkinitcpio-install.hook" pacman hook.

Apperantly, it expects the vmlinuz to be also (next to /boot obviously) written to /usr/lib/modules/*/vmlinuz. I adapted the packaging to do this, to respect this particular pacman hook.

For me, this extra copy seems to the trick (and the declaration of the "pkgbase" since this particular hook seems to need that).

Let me know the results.

eggz commented on 2021-01-24 02:03 (UTC)

hey there, thx for letting me know.

there are no real diffrences between my linux.install file and the (hidden, but still on the git of) linux-zen.install file, we both call depmod and then do a mkinicpio in that order.

please note that you are comparing an upgrade to a reinstall, though I do think you are still on to something here.

I'll take a look at this interesting topic when I have the time.

Thanks again.

Kryesh commented on 2021-01-24 01:11 (UTC) (edited on 2021-01-24 01:29 (UTC) by Kryesh)

Hi, Thanks for making this package!

I think I've found a minor ordering issue with the package installation, the initcpio image is generated before dkms modules are built. this means that if there is a dkms package included in the mkinicpio config the image fails to build. rerunning "sudo mkinitcpio -p linux-amd-znver2" after package installation builds the images correctly as the dkms processes have completed. In my case it's necessary as I need to include zfs-dkms.

From yay output:

--snip--
-> Running build hook: [zfs]
==> ERROR: module not found: `zavl'
==> ERROR: module not found: `znvpair'
==> ERROR: module not found: `zunicode'
==> ERROR: module not found: `zcommon'
==> ERROR: module not found: `zfs'
==> ERROR: module not found: `spl'
  -> Running build hook: [mdadm_udev]
Custom /etc/mdadm.conf file will be used in initramfs for assembling arrays.
==> Generating module dependencies
==> Creating zstd-compressed initcpio image: /boot/initramfs-linux-amd-znver2-fallback.img
==> WARNING: errors were encountered during the build. The image may not be complete.
(2/2) upgrading linux-amd-znver2-headers                  [###############################] 100%
:: Running post-transaction hooks...
(1/3) Arming ConditionNeedsUpdate...
(2/3) Updating module dependencies...
(3/3) Install DKMS modules
==> dkms install --no-depmod -m zfs -v 2.0.1 -k 5.10.10-AMD-znver2
==> dkms install --no-depmod -m ddcci -v 0.3.3 -k 5.10.10-AMD-znver2
==> depmod 5.10.10-AMD-znver2
--snip--

Example from the linux-zen package with correct ordering:

--snip--
:: Processing package changes...
(1/2) reinstalling linux-zen                                                                                                           [##################################################################################] 100%
(2/2) reinstalling linux-zen-headers                                                                                                   [##################################################################################] 100%
:: Running post-transaction hooks...
(1/5) Restoring Linux kernel modules...
++ uname -r
+ KVER=5.10.9-AMD-znver2
+ test -e /usr/lib/modules/backup/5.10.9-AMD-znver2
+ rm -rf /usr/lib/modules/backup
(2/5) Arming ConditionNeedsUpdate...
(3/5) Updating module dependencies...
(4/5) Install DKMS modules
==> dkms install --no-depmod -m zfs -v 2.0.1 -k 5.10.9-zen1-1-zen
==> dkms install --no-depmod -m ddcci -v 0.3.3 -k 5.10.9-zen1-1-zen
==> depmod 5.10.9-zen1-1-zen
(5/5) Updating linux initcpios...
==> Building image from preset: /etc/mkinitcpio.d/linux-zen.preset: 'default'
  -> -k /boot/vmlinuz-linux-zen -c /etc/mkinitcpio.conf -g /boot/initramfs-linux-zen.img
--snip--

I hope that makes sense, thanks!

DanEng1982 commented on 2021-01-01 12:17 (UTC)

Hey, I wish you a happy new year. I love your work and I was just wondering if you would be happy to upstream your updates to the Hefftor Linux Repo? If so, can you please contact me either via the Hefftor Linux Official Telegram group under nickname Able Archer or under daniel.engelthaler@gmail.com ? Thank you very much! Dan

hockeymikey commented on 2020-12-22 07:18 (UTC)

@eggz you're amazing! Working great

eggz commented on 2020-12-20 11:59 (UTC)

@hockeymikey

Great catch. I made the headerpackage more flexible, normally this shouldn't happen anymore in the future for other modules.

Thanks again. Let me know if the compile works now!

hockeymikey commented on 2020-12-20 08:06 (UTC)

Hey, dt-bindings is missing inside build/include (unsure what it exactly is) but need it for some compiling.

Scimmia commented on 2020-12-10 16:42 (UTC)

Please see the warning here: https://wiki.archlinux.org/index.php/Kernel/Arch_Build_System#Modifying_the_PKGBUILD

eggz commented on 2020-11-23 17:09 (UTC)

Oh gosh, I guess I never needed exfat for a while... Good catch arnaud!!

arnaud commented on 2020-11-23 16:25 (UTC)

Hi

Could you also add CONFIG_EXFAT_FS=m

Thanks

arnaud commented on 2020-11-14 19:28 (UTC)

Thank you so much for such reactivity!

Works like a charm.

eggz commented on 2020-11-14 18:01 (UTC)

Thank you for the feedback!! The module should be enabled now.

arnaud commented on 2020-11-14 16:25 (UTC)

Hi. Could you add CONFIG_HUAWEI_WMI=m to the config ?

If I understand well, It will allow this module to be built and available for the Huawei matebook 14 AMD 2020 laptops which have a R5 4600H or a R7 4800H AMD processor.

Thanks

eggz commented on 2020-10-31 11:25 (UTC)

I have added 'COMPRESSION="lzop"' in the mkinitcpio preset of this kernel. I find this balanced compression for the ramdisk alot faster for installing, and booting from it. Please check your preset file in /etc/mkinitcpio.d/ to make sure that this change is adopted (as there is probably a pacsave file created there instead).

eggz commented on 2020-10-26 18:15 (UTC)

Tired of compiling? Use this binary repo instead! Add this at the end of /etc/pacman.conf :

[linuxkernels]
Server = http://nhameh.ovh/$repo/$arch
SigLevel = Optional TrustAll