Arch Linux User Repository

A few things BEFORE building this package and/or commenting here:

READ THE WIKI AND UNDERSTAND HOW TO USE MAKEPKG AND EVERYTHING IT ENTAILS

If you do not read the wiki and ask a stupid question, you'll either get a stupid/terse response from me or you will be ignored. If this continues, this may require me to bring this up to a TU for account suspensions.

Remember, there's also search engines that you can also look up errors that you get related to makepkg.

WE WILL NOT MODIFY THE CONFIG FILE

This package's goal is to be as close to the Arch Linux linux package. Therefore, we use the config file from that package. We will not, unless under very special circumstances, modify the config file for any reason.

You can make changes yourself. You should be capable enough to make any changes you see fit without us making the changes on our end.

WE WILL NOT ADD X PATCH

This one has been more recent. The goal of this package is to add a MINIMAL patch set for IOMMU grouping and for VGA arbitration on Intel iGPUs. Under no circumstances will I backport patches that are not present in the linux repository on git.archlinux.org nor will I add a patch that adds a feature outside of the intended goal of this project.

If you absolutely feel that your patch is completely necessary, you MUST have ready a link to the appropriate discussion from the OFFICIAL LINUX KERNEL MAILING LISTS and/or from Arch Linux's Bug Tracker at bugs.archlinux.org. For the latter, they must be bugs present in the linux package in [core] and do NOT open a task on there if it is specific to this package (or any AUR package for that matter). I do not want to see links to reddit talking about some patch that you want to add.

If you want to add patches to your own build, that's completely fine.

DO NOT USE AN AUR HELPER THEN EXPECT US TO HELP

AUR helpers are unsupported and therefore we will not provide help to you unless you have verified it's not working with makepkg. I always make sure this package builds in a clean chroot before uploading here, so I know it builds on a clean and up to date Arch Linux system.

BINARY PACKAGES ARE PROVIDED FOR YOUR CONVENIENCE

Both maintainers of this package provide signed binary packages in unofficial pacman repositories maintained and signed by ourselves. If you do not want to compile this kernel yourself for whatever reason, feel free to make use of them.

• markzz's repository: https://wiki.archlinux.org/index.php/Unofficial_user_repositories#markzz
• slowbro's repository: https://wiki.archlinux.org/index.php/Unofficial_user_repositories#slowbro

Like markzz was, I'm providing updated builds in my (unofficial) user repository, if you don't want to build this yourself.

Info here: https://wiki.archlinux.org/index.php/Unofficial_user_repositories#slowbro

Signing key: 85186206

Details on importing a key for pacman are here.

with gcc 10 i have a compile error on virt/kvm/kvm main.c:2236

it seems upstream bug: https://bugzilla.kernel.org/show_bug.cgi?id=207173 should be fixed with 5.7 upstream mentioned there

commit: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=78a5255ffb6a1

adding that patch makes it compile again

I'm also providing builds of the linux-vfio kernel in my unofficial user repository :)

https://wiki.archlinux.org/index.php/Unofficial_user_repositories#disastrousaur

This repository is fully signed and updated daily

It wouldn't matter much anyways because I'm almost certain that X does not support hot plugging display devices. Heck, if you notice in the 0/6 patch, the submitter mentions that he restarts X when hot plugging, which is what I would expect.

The patch seems to be for people who are hotplugging PCI-e devices (which I would expect to be over Thunderbolt), which is something I would bet a vast majority of users do not attempt. I do not expect this patch would improve AMDGPU users' experiences while running a "normal" setup with just a AMD video device plugged directly into one of the available PCI-e slots inside their machines and not touching it while the machine is running (as is a very good idea to not touch an active device on a PCI-e slot/device that isn't specifically designed for hot plugging).

Also, it appears that the issues discussed in the earlier comments are related to certain AMD processors and not video devices.

I'll admit I don't know much in the ways of DRI or internal kernel workings. There's a patchset that has been penned by Andrey Grodzovsky, a Software Engineer at AMD, that purports to resolve some of these issues. For those using AMDGPU who are experiencing issues, I suggest you read his patch summary, and look into testing these patches on your system(s).

I hope that in the coming days/weeks more detailed information and better patches will be released; it looks like this, at the very least, has the attention of AMD.

https://lists.freedesktop.org/archives/dri-devel/2020-May/265386.html

QEMU5 update is breaking windows VM's on newer Ryzen processors. Apparently fix is to disable amd-stibp in the cpu flags or use earlier kernel for the moment. Various workarounds in the vfio discord.

I get the same error as purploid, AMD host GPU, passing down an Nvidia; last kernel update seems to have broken something because switching to LTS fixed it. I'm on x570 chipset if that matters

markzz: I am not. I am using AMDGPU for my host system and am passing an nvidia card to the guest VM. It's possible there was another change somewhere along the way but this issue popped up after upgrading from 5.6.8 to 5.6.10-1.

I am finding that the LTS kernel doesn't give me this issue. Now that I can boot the Windows guest, the only thing I can see in the minidump file is NTOSKRNL.exe crashing which doesn't give me much to go on and I haven't had any major updates on the guest VM in a while.

purploid: Are you using i915 VGA arbitration?

@slowbro thank you, but I have already set that option.

These GSOD/BSOD errors only started after I updated to this kernel. I switched to vfio-lts and it's working again.

I'll try the non-lts version in a few updates and see if that stabilizes things.

@purploid https://wiki.archlinux.org/index.php/PCI_passthrough_via_OVMF#Bluescreen_at_boot_since_Windows_10_1803