Has anyone tried the Manjaro kernel with the ACS patch on Arch Linux? (linux-acs-manjaro)
Search Criteria
Package Details: linux-vfio-headers 5.17.4.arch1-1
Git Clone URL: | https://aur.archlinux.org/linux-vfio.git (read-only, click to copy) |
---|---|
Package Base: | linux-vfio |
Description: | The Linux kernel and modules |
Upstream URL: | https://github.com/archlinux/linux/commits/v5.17.4-arch1 |
Keywords: | acs arbiter assignment gpu i915 kvm override passthrough pci qemu vfio vga |
Licenses: | GPL2 |
Submitter: | zman0900 |
Maintainer: | markzz (slowbro) |
Last Packager: | slowbro |
Votes: | 71 |
Popularity: | 0.75 |
First Submitted: | 2015-01-30 06:41 (UTC) |
Last Updated: | 2022-04-22 19:35 (UTC) |
Dependencies (15)
- pahole (pahole-git)
- bc (bc-gh) (make)
- cpio (cpio-git) (make)
- git (git-git, git-vfs, git-run-command-patch-git) (make)
- graphviz (make)
- imagemagick (graphicsmagick-imagemagick-compat, imagemagick-git, imagemagick-full-git, imagemagick-no-hdri, imagemagick-fftw, imagemagick-full) (make)
- kmod (kmod-git, kmod-minimal-git) (make)
- libelf (elfutils-git, libelf-minimal-git) (make)
- pahole (pahole-git) (make)
- perl (perl-git) (make)
- python-sphinx (python-sphinx-git, python-sphinx-2) (make)
- python-sphinx_rtd_theme (make)
- tar (tar-libarchive, tar-git, tar-parallel) (make)
- xmlto (xmlto-git) (make)
- xz (xz-git) (make)
Required by (4)
- zfs-linux-vfio (make)
- zfs-linux-vfio-git (make)
- zfs-linux-vfio-git-headers (make)
- zfs-linux-vfio-headers (make)
Sources (4)
Latest Comments
Jeka commented on 2022-07-04 11:01 (UTC) (edited on 2022-07-04 11:05 (UTC) by Jeka)
giostark commented on 2022-06-05 00:58 (UTC)
Maybe a tip for other noobs like me. Now the system update work with the gcc 12.1. Installing the pre-compiled kernel (done with gcc 11.2) or via helper (yay always search for gcc 11.2) result in error with the latest nvidia modules (that use the gcc 12.1). Solutions: 1) downgrade the gcc to the 11.2 (bleah solution) 2) (better solution) compile the kernel from the source without helpers using: makepkg -Crso Then: makepkg -ers Then: sudo pacman -U (3 packs generated before) Here the topic of the issue: https://bbs.archlinux.org/viewtopic.php?pid=2039309#p2039309
JuniorJPDJ commented on 2021-12-09 00:31 (UTC)
pssst, this version is 2 patches old now
Mine-turtle commented on 2021-10-27 05:45 (UTC) (edited on 2021-11-21 11:32 (UTC) by Mine-turtle)
HI, I'm unable to completely update my Manjaro for two update cycles now. These three are the last stragglers: linux-vfio, linux-vfio-docs, linux-vfio-headers.
This is all I get from pacman (gui) before update terminates:
Preparing...
Cloning linux-vfio build files...
Generating linux-vfio-docs information...
Failed to prepare transaction:
Failed to generate linux-vfio-docs information
Any advice?
hurrian commented on 2021-09-11 14:37 (UTC) (edited on 2021-09-12 06:49 (UTC) by hurrian)
Hello, I've noticed that this has been out of date for a while - I've updated the package to sync with the latest Arch vanilla kernel.
The ACS patch was successfully tested on a Gigabyte X570-UD, by passing through a chipset USB controller.
The i915 patch needed minor refactoring to build on 5.14, however I don't have any Intel hardware, so I am unable to test this patch.
Here's the link to my tree for 5.14.2-arch1-2: https://github.com/hurrian/linux-vfio/tree/5.14.2-arch1-2-vfio . I've also submitted this as a PR to @slowbro's repository.
Edit: The update to 5.14.2 has been merged.
daniel_shub commented on 2021-07-27 16:01 (UTC)
@slowbro how were you testing the package. Were you running it through a formal test suite of some sort or just seeing if passthrough was working?
slowbro commented on 2021-07-22 07:53 (UTC)
Hey all. I no longer have a machine that runs (or needs) this package, so I have no direct way to test it. Regardless, I will continue updating it. Please be sure to report any issues you run into.
JuniorJPDJ commented on 2021-07-11 13:31 (UTC)
Consider testing 5.13 ;D
JuniorJPDJ commented on 2021-07-11 04:46 (UTC)
I never actually played too much with github actions so I doubt I would be useful - I'm sorry ;/
Anyway - good idea! I'm not sure if it will be easy to test like that, but then someone will tell us here that it's broken ;V
slowbro commented on 2021-07-11 03:45 (UTC) (edited on 2021-07-11 04:12 (UTC) by slowbro)
Thank you - I don't have permission to do that, I don't think; however, since Arch is now using Github for their repo, I was considering using my Github account + GH Actions to so a similar thing. Admittedly, I am upgrading my PC very soon and likely will no longer need this package myself.. but I would like to continue to keep it available for others, as I know how helpful it can be.
I believe the default GH Actions disk space allowance well undershoots the size of the archlinux-linux repo, so I'll have to see about getting that working with a shallow clone. If you'd be willing to help, it would be appreciated! I was previously using this repository, and was planning on continuing there: https://github.com/slowbro/linux-vfio
Edit: by the way, I am in the process of building the latest package. I like to make sure it builds & boots before releasing it, so it will be ~20min.
JuniorJPDJ commented on 2021-07-11 00:04 (UTC)
Hey, I'm the guy flagging it out of date whole time.
Maybe you can just add me as co-maintainer, I'll update it instead of flagging and waiting ;)
I would be doing just dumb bumps for minor versions when new version of linux would become available in core repos.
slowbro commented on 2021-07-01 05:52 (UTC)
I'll get this updated ASAP, sorry! Been pulled in all directions lately.
JuniorJPDJ commented on 2021-06-28 23:27 (UTC)
Yup, official linux package seems to use github now: https://github.com/archlinux/svntogit-packages/blob/packages/linux/trunk/PKGBUILD
This is the repo it uses: https://github.com/archlinux/linux
jsutton commented on 2021-06-28 17:29 (UTC)
It looks like this package does not build at the moment.
==> Retrieving sources... -> Cloning archlinux-linux git repo... Cloning into bare repository '/home/jpsutton/.cache/yay/linux-vfio/archlinux-linux'... fatal: repository 'https://git.archlinux.org/linux.git/' not found
I suspect it has something to do with the deprecation of git.archlinux.org...
https://lists.archlinux.org/pipermail/arch-dev-public/2021-June/030466.html
daniel_shub commented on 2021-02-17 15:11 (UTC)
I did a little more digging and it looks like the problem is not this package, but rather that the linux package might be broken in the core repo (opps). It looks like the Arch Devs are on it and there is a 5.11 version of the linux package in testing with a patch for a recent upgrade to Sphinx. My guess is once the new version hits core and this package is updated, everything will be fine.
daniel_shub commented on 2021-02-16 20:37 (UTC)
I am having trouble building in a clean chroot.
cat: /etc/os-release: No such file or directory SPHINX htmldocs --> file:///build/linux-vfio/src/archlinux-linux/Documentation/output PARSE include/uapi/linux/dvb/audio.h PARSE include/uapi/linux/dvb/ca.h PARSE include/uapi/linux/dvb/dmx.h PARSE include/uapi/linux/dvb/frontend.h PARSE include/uapi/linux/dvb/net.h PARSE include/uapi/linux/dvb/video.h PARSE include/uapi/linux/videodev2.h PARSE include/uapi/linux/media.h PARSE include/uapi/linux/cec.h PARSE include/uapi/linux/lirc.h WARNING: The kernel documentation build process support for Sphinx v3.0 and above is brand new. Be prepared for possible issues in the generated output. /build/linux-vfio/src/archlinux-linux/Documentation/driver-api/usb/usb:158: ./drivers/usb/core/message.c:961: WARNING: Duplicate C declaration, also defined at driver-api/usb/gadget:759. Declaration is '.. c:function:: int usb_string (struct usb_device dev, int index, char buf, size_t size)'. /build/linux-vfio/src/archlinux-linux/Documentation/driver-api/usb/usb.rst:961: WARNING: Duplicate C declaration, also defined at driver-api/usb/gadget:759. Declaration is '.. c:struct:: usb_string'. /build/linux-vfio/src/archlinux-linux/Documentation/gpu/drm-kms:349: ./drivers/gpu/drm/drm_fourcc.c:312: WARNING: Duplicate C declaration, also defined at gpu/drm-kms:3. Declaration is '.. c:function:: const struct drm_format_info * drm_format_info (u32 format)'. /build/linux-vfio/src/archlinux-linux/Documentation/gpu/drm-kms:433: ./drivers/gpu/drm/drm_modeset_lock.c:338: WARNING: Duplicate C declaration, also defined at gpu/drm-kms:46. Declaration is '.. c:function:: int drm_modeset_lock (struct drm_modeset_lock lock, struct drm_modeset_acquire_ctx ctx)'. /build/linux-vfio/src/archlinux-linux/Documentation/gpu/drm-uapi:346: ./drivers/gpu/drm/drm_ioctl.c:919: WARNING: Duplicate C declaration, also defined at gpu/drm-uapi:70. Declaration is '.. c:function:: bool drm_ioctl_flags (unsigned int nr, unsigned int flags)'. /build/linux-vfio/src/archlinux-linux/Documentation/gpu/todo.rst:283: WARNING: Unexpected indentation. /build/linux-vfio/src/archlinux-linux/Documentation/gpu/todo.rst:284: WARNING: Block quote ends without a blank line; unexpected unindent. /build/linux-vfio/src/archlinux-linux/Documentation/driver-api/miscellaneous:48: ./drivers/pwm/core.c:667: WARNING: Duplicate C declaration, also defined at driver-api/miscellaneous:294. Declaration is '.. c:function:: int pwm_capture (struct pwm_device pwm, struct pwm_capture result, unsigned long timeout)'. /build/linux-vfio/src/archlinux-linux/Documentation/driver-api/80211/mac80211:109: ./include/net/mac80211.h:4719: WARNING: Duplicate C declaration, also defined at driver-api/80211/mac80211:1011. Declaration is '.. c:function:: void ieee80211_tx_status (struct ieee80211_hw hw, struct sk_buff *skb)'.
Exception occurred: File "/usr/lib/python3.9/site-packages/sphinx/builders/html/init.py", line 1039, in <lambda> ctx['css_files'].sort(key=lambda js: js.priority) AttributeError: 'str' object has no attribute 'priority' The full traceback has been saved in /tmp/sphinx-err-ct3buvc5.log, if you want to report the issue to the developers. Please also report this if it was a user error, so that a better error message can be provided next time. A bug report can be filed in the tracker at https://github.com/sphinx-doc/sphinx/issues. Thanks! make[1]: [Documentation/Makefile:91: htmldocs] Error 2 make: [Makefile:1665: htmldocs] Error 2 ==> ERROR: A failure occurred in build(). Aborting... ==> ERROR: Build failed, check /chroot/base-devel/dshub/build
giostark commented on 2020-12-28 13:54 (UTC)
@slowbro OT/ RTX4000 user here , but big thanks for your constant effort !!! :-) Happy holidays to both of you that help us to use this kernel ;-) /OT
slowbro commented on 2020-12-23 06:41 (UTC)
I have the patch & package prepped for 5.10.2 - waiting for it to come out of testing. There were significant changes to i915 in 5.10 - is anyone running 5.10.x already, on i915, and willing to test the linux-vfio package before 5.10 hits core?
derwhalfisch commented on 2020-12-09 07:58 (UTC)
5.9.11 has fixed the IOMMU groups problem for me, but I have had to include a patch to deal with an AMD reset bug.
peterh commented on 2020-12-04 07:11 (UTC)
5.9.11 fixed the problem also for me. Thanks.
spamad commented on 2020-12-02 19:17 (UTC)
I was having the same issue as peterh where the IOMMU grouping stopped working at 5.9.1 (I7-3770, Gigabyte Z77X-UD3H). After compiling 5.9.11, the issue is now resolved.
Zetein commented on 2020-11-30 04:35 (UTC)
An easy way to import the required gpg keys, if anyone is having problems with it as I was.
curl https://keybase.io/heftig/pgp_keys.asc | gpg --import
markzz commented on 2020-10-27 04:48 (UTC)
I can confirm there's an issue with it. I cannot get to investigating until this weekend though.
peterh commented on 2020-10-22 18:12 (UTC)
The IOMMU groups on my system (Z77, I7-3770) are broken if I'm using version linux-vfio 5.9.1.arch1-1. Any idea ?
slowbro commented on 2020-10-18 22:22 (UTC) (edited on 2020-10-18 22:22 (UTC) by slowbro)
5.9.1 is up now, but note that nvidia is only partially supported on 5.9.x; nvidia expects to have an update ready in november. this seems to only affect cuda and opencl.
https://forums.developer.nvidia.com/t/nvidia-driver-not-yet-supported-for-linux-kernel-5-9/157263
there are supposedly some patches available that workaround this issue; you'll need to find/apply those yourself if you need cuda/opencl on 5.9.x.
slowbro commented on 2020-09-30 18:47 (UTC)
Do you have any custom gpg configs or are you perhaps using an alternative keyring? I also am not able to reproduce the problem. Make sure your GPG keyring has all the listed signatures from your first post...
:: PGP keys need importing:
-> ABAF11C65A2970B130ABE3C479BE3E4300411886, required by: linux-vfio
-> 647F28654894E3BD457199BE38DBBDC86092693E, required by: linux-vfio
-> A2FF3A36AAA56654109064AB19802F8B0D70FC30, required by: linux-vfio
c3924754 commented on 2020-09-30 15:04 (UTC)
gpg --recv-keys 3B94A80E50A477C7
git clone https://aur.archlinux.org/linux-vfio.git
cd linux-vfio
makepkg -si
These steps do not work for me, without helpers. Even after having a clean repo/folder.
==> Verifying source file signatures with gpg...
archlinux-linux git repo ... SIGNATURE NOT FOUND
==> ERROR: One or more PGP signatures could not be verified!
TheUnknownZ commented on 2020-09-29 21:13 (UTC) (edited on 2020-09-29 21:14 (UTC) by TheUnknownZ)
gpg --recv-keys 3B94A80E50A477C7
git clone https://aur.archlinux.org/linux-vfio.git
cd linux-vfio
makepkg -si
Works here. I suggest reading the pinned comment as AUR helpers are not supported.
c3924754 commented on 2020-09-29 18:56 (UTC)
:: PGP keys need importing:
-> ABAF11C65A2970B130ABE3C479BE3E4300411886, required by: linux-vfio
-> 647F28654894E3BD457199BE38DBBDC86092693E, required by: linux-vfio
-> A2FF3A36AAA56654109064AB19802F8B0D70FC30, required by: linux-vfio
==> Import? [Y/n] y
:: Importing keys with gpg...
gpg: key 19802F8B0D70FC30: 6 duplicate signatures removed
gpg: key 19802F8B0D70FC30: 6 signatures reordered
gpg: key 19802F8B0D70FC30: public key "Jan Alexander Steffens (heftig) <jan.steffens@gmail.com>" imported
gpg: key 38DBBDC86092693E: public key "Greg Kroah-Hartman <gregkh@linuxfoundation.org>" imported
gpg: key 79BE3E4300411886: public key "Linus Torvalds <torvalds@kernel.org>" imported
gpg: Total number processed: 3
gpg: imported: 3
==> Making package: linux-vfio 5.8.12.arch1-1
==> Retrieving sources...
-> Cloning archlinux-linux git repo...
Cloning into bare repository '/home/user/.cache/yay/linux-vfio/archlinux-linux'...
remote: Enumerating objects: 19718, done.
remote: Counting objects: 100% (19718/19718), done.
remote: Compressing objects: 100% (9357/9357), done.
remote: Total 7741632 (delta 13062), reused 13650 (delta 10325), pack-reused 7721914
Receiving objects: 100% (7741632/7741632), 2.29 GiB | 6.63 MiB/s, done.
Resolving deltas: 100% (6468837/6468837), done.
-> Found config
-> Found add-acs-overrides.patch
-> Found i915-vga-arbiter.patch
-> Found sphinx-workaround.patch
==> Validating source files with sha256sums...
archlinux-linux ... Skipped
config ... Passed
add-acs-overrides.patch ... Passed
i915-vga-arbiter.patch ... Passed
sphinx-workaround.patch ... Passed
==> Verifying source file signatures with gpg...
archlinux-linux git repo ... SIGNATURE NOT FOUND
==> ERROR: One or more PGP signatures could not be verified!
error downloading sources: linux-vfio
Getting all of heftig's keys from KeyBase does not work either.
Suggestion gpg --recv-keys 3B94A80E50A477C7
also does not work.
What is going on here?
slowbro commented on 2020-06-10 03:15 (UTC)
Just threw 5.6.15 up, sorry for the delay. Note that heftig's GPG key was rotated recently, so you'll probably need to gpg --recv-keys 3B94A80E50A477C7
before building.
shaybox commented on 2020-06-10 02:44 (UTC)
5.6.10 Is no longer supported by kernel modules, and 5.7 is testing, at-least update to 5.6.13 for module support so the nvidia drivers work, the current patch-set works with 5.6.13 no change required.
plntyk commented on 2020-05-19 16:06 (UTC)
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
markzz commented on 2020-05-11 06:29 (UTC) (edited on 2020-05-11 06:31 (UTC) by markzz)
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.
slowbro commented on 2020-05-11 04:51 (UTC)
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
yankeedoodle commented on 2020-05-08 14:26 (UTC)
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.
meadovv commented on 2020-05-08 14:18 (UTC)
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
purploid commented on 2020-05-08 05:05 (UTC)
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.
markzz commented on 2020-05-08 00:49 (UTC)
purploid: Are you using i915 VGA arbitration?
purploid commented on 2020-05-07 23:09 (UTC)
@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.
slowbro commented on 2020-05-07 20:59 (UTC)
purploid commented on 2020-05-07 20:51 (UTC)
@markzz I am currently unable to boot my Windows VM with "KERNEL SECURITY CHECK FAILURE" Blue/Green Screen of Death.
I have attempted to boot into Windows Installer as well and I am seeing the same behaviour on a brand new ISO from MS.
markzz commented on 2020-05-06 21:23 (UTC)
Anyone who uses this PKGBUILD that actually uses the i915 VGA Arbitration patch, please let me know if you are currently having issues. It looks like to me that there's an issue in the current patch, but I do not personally use that part of this kernel.
I will be updating to 5.6.10.arch1-2 in the coming hours and would like to know if anyone can confirm my hunch.
markzz commented on 2020-05-06 20:28 (UTC)
Pushed commit 757f0700.
markzz commented on 2020-05-06 19:48 (UTC) (edited on 2020-05-06 20:02 (UTC) by markzz)
I'm trying to determine the cause now. I looked and saw that your package isn't built on a clean arch linux system (or chroot), so I'm doing some investigating.
EDIT: Since I didn't actually answer your question, it is a compiler error in the xen module, which is something neither patch touches directly in any way, so I'm poking around at what may be the issue that is related to that.
slowbro commented on 2020-05-06 19:33 (UTC)
What error do you get? I was able to build it last night and am running it now.
markzz commented on 2020-05-06 19:25 (UTC)
5.6.10.arch1-1 does not appear to build in a clean chroot.
markzz commented on 2020-05-01 15:52 (UTC)
daniel_shub: You're probably right, I added a pinned message. Heck, I wrote the patch that added that feature, I probably should use it. :-P
markzz commented on 2020-05-01 15:44 (UTC) (edited on 2020-05-01 16:06 (UTC) by markzz)
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
daniel_shub commented on 2020-05-01 14:33 (UTC)
@markzz first, let me start by saying thanks to you and slowbro for maintaining this package. Second, I think your decision to not deviate from the Arch Kernel except for the patches needed for VFIO/GPU pass through is the correct decision. The fact that the diff between this package and the linux package is so clean gave me a lot of confidence to install a custom kernel.
Finally, you may want to pin your message that says that the package will not deviate and if you want extra things to modify the PKGBUILD yourself.
markzz commented on 2020-05-01 07:00 (UTC)
lazerl0rd: As stated before further down the comments, no.
lazerl0rd commented on 2020-05-01 06:28 (UTC) (edited on 2020-05-01 06:29 (UTC) by lazerl0rd)
Could the following two patches be added:
https://clbin.com/OaR0H (for AMD Zen2)
https://github.com/ZestProjects/linux/commit/ac7e184bddfb559c29e9b97de11a0f496aad696e (for HP ProLiant Gen8 servers)
meshedpotato commented on 2020-04-27 16:25 (UTC)
Thanks @slowbro, you set me off the in the right direction - very very thanks ;) - my VMs are booting in 25 seconds now compared to 4 mins of total boot time prior to this flag.
markzz commented on 2020-04-26 23:37 (UTC)
I also do not consider grabbing patches from reddit as a good idea either. I would prefer that patch suggestions of any kind should also be accompanied by a Linux Kernel mail list thread OR an Arch Linux Flyspray link so there's discussion from those ends as well. Also, as a reminder, do not open Flyspray reports for upstream bugs.
NovaMoon commented on 2020-04-26 23:14 (UTC)
https://www.reddit.com/r/VFIO/comments/eba5mh/workaround_patch_for_passing_through_usb_and/ There is A bit more discussion around it but I understand. Its not needed to get passthrough working
markzz commented on 2020-04-26 21:18 (UTC)
I usually take a hard line stance of not adding any patches except those introduced by the linux package. The goal of this patch-set is not to be an all encompassing kernel for various VM related issues, but instead is just what is needed to do VFIO and GPU passthrough.
As I've said before, there's nothing stopping you from making changes to the PKGBUILD for your own build of the kernel with whatever patches you want.
slowbro commented on 2020-04-26 21:13 (UTC)
@NovaMoon do you have any links to more discussion/reports around that issue (vs just a link to a patch)?
NovaMoon commented on 2020-04-26 20:57 (UTC)
Hello Is it possible to add another patch to the kernel? this is describing the patch.
Zen2 CPU users experiencing FLR timeout errors in dmesg when passing the USB or Audio controllers can use this patch to bypass the issue. Typically the host will also crash shortly after. This issue affects all AM4 300/400/500 series boards when fitted with new Zen2 CPUs. The workaround is to disable FLR reset until AMD fixes it on their end via AGESA/BIOS update. Kernel patch: https://clbin.com/OaR0H
markzz commented on 2020-04-24 13:57 (UTC)
beetlejuice: This package will not deviate from the ARCH kernel's config. If you want to change the options when you go to build, you are free to do so.
beetlejuice commented on 2020-04-24 09:18 (UTC) (edited on 2020-04-24 09:21 (UTC) by beetlejuice)
CONFIG_PREEMPT_VOLUNTARY=yes
CONFIG_PREEMPT is not set
Should be default settings for this package. I don't like waiting 30 or more seconds and 100% CPU usage just to start OVMF bios. If there is a better solution for long boot time with OVMF please advice me.
slowbro commented on 2020-04-19 05:05 (UTC)
@meshedpotato, you can simply edit the 'config' file in the tar.gz you download from AUR. If you're currently using an AUR helper to install (i.e. yay) you would have to abandon that in favor of manually building it. There's plenty of docs on the wiki about how to build an AUR package, so I'll skip the details; but for your specific situation, you'd:
- Edit the 'config' file and change whatever parameters you want
- run
sha256sum config
and replace the value in the PKGBUILD - build the package
Best of luck!
meshedpotato commented on 2020-04-19 04:45 (UTC)
Hi Folks, any pointers on how i would be able to build with CONFIG_PREEMPT_VOLUNTARY=yes, the ACS patch has sorted out my IOMMU groups but I have large boot times.
I think I'm facing https://forums.unraid.net/topic/72172-unraid-os-version-653-available/
not sure where to start, Thank!
slowbro commented on 2020-04-10 02:00 (UTC)
the sphinx issue will be worked-around in 5.6.3, from upstream: link. building/testing now.
aknarts commented on 2020-04-09 07:31 (UTC) (edited on 2020-04-09 07:32 (UTC) by aknarts)
JuniorJPDJ: For the sphinx issue, another "fix" is to install python-sphinx-1 also fixes the issue, but might break other dependency so it is up to you which solution you chose. (It is an alternate dependency on the docs package)
markzz commented on 2020-04-08 17:12 (UTC)
Zauberfisch: I"m honestly going to unpin that comment as it should be expected that people read the wiki and know how to use makepkg before trying to build any packages.
JuniorJPDJ commented on 2020-04-08 14:01 (UTC)
If someone will have similar problem there's bug link to follow:
https://bugs.archlinux.org/task/66156
I temporary removed line make htmldocs
and removed $pkgbase-docs
from loop at the end of PKGBUILD so it compiles again.
JuniorJPDJ commented on 2020-04-08 13:51 (UTC)
I've very weird problem with compilation of this package:
Running Sphinx v3.0.0
Extension error:
Could not import extension cdomain (exception: cannot import name 'c_funcptr_sig_re' from 'sphinx.domains.c' (/usr/lib/python3.8/site-packages/sphinx/domains/c.py))
make[1]: *** [Documentation/Makefile:81: htmldocs] Error 2
make: *** [Makefile:1549: htmldocs] Error 2
Zauberfisch commented on 2020-04-08 04:29 (UTC)
@markzz: sorry. I wasn't actually asking, I know how to import a key or skip key checking. I just figured because there is a pinned comment for adding 2 of the 3 keys, it might be worth updating that message to include all 3 keys.
slowbro commented on 2020-04-08 04:18 (UTC) (edited on 2020-04-08 04:19 (UTC) by slowbro)
Not to dogpile, but I'd like to add "..or plug the error into google" :)
https://www.google.com/search?q=FAILED+unknown+public+key+A5E9288C4FA415FA
markzz commented on 2020-04-08 03:36 (UTC)
Zauberfish: Can you kindly read the wiki before being the 40,000th person to ask this?
Zauberfisch commented on 2020-04-08 03:20 (UTC)
I see the pinned comment saying I need to add 2 keys. But for me I still get an additional key error:
FAILED (unknown public key A5E9288C4FA415FA) ==> ERROR: One or more PGP signatures could not be verified!
seems the key for "Jan Alexander Steffens (heftig)" is also missing.
PrfStrwberry commented on 2020-04-04 22:31 (UTC)
@giostark seems I have to dig deeper. After booting the default arch kernel, the problem continues to exist.
giostark commented on 2020-04-04 16:36 (UTC) (edited on 2020-04-04 16:38 (UTC) by giostark)
@PrfStrwberry- I have a 7700K and differ for two instruction from your: Intel® vPro™ Platform Eligibility and Intel® Trusted Execution Technology. And to me the mitigations seems to work. In general mitigation come activate host side but is not mandatory that the guest will use them. Those security mitigations are for you really necessary? Are you using those for networking VMs. Seems not bios options are available in Asus firmware. Kernel side I'm a noob so I can't say a thing. Thanks slowbro and markzz for your work. Me too I could not make my stuffs without this kernel.
PrfStrwberry commented on 2020-04-04 14:29 (UTC) (edited on 2020-04-04 16:23 (UTC) by PrfStrwberry)
Hey thanks for keeping this package up to date. I could not do anything without it. I am using an i7 8700k with an ASUS Maximus X CODE. I just have a small problem, after compiling and installing everything. When I create a VM inside virt-manager, I cannot enable and apply the box at enable cpu flaw mitigations. After clicking and applying, the tickbox goes blank again. Any tips?
slowbro commented on 2020-03-28 19:10 (UTC)
ShayBox, it's unfortunately just the one little server on the west coast; it was probably busy with the binge watching I was doing on Plex last night. Should be okay now?
markzz commented on 2020-03-28 15:30 (UTC)
I'm going to set up my build system again and keep this package up to date as regards to this PKGBUILD to keep it up to date on my repository. The 5.5.13.arch1-1 is built and up on my repository.
markzz commented on 2020-03-28 04:41 (UTC)
This is my queue to actually use my work from home time and compile a new version of the package.
shaybox commented on 2020-03-28 01:54 (UTC)
slowbro your repo is running at a few hundred kbps
slowbro commented on 2020-03-27 18:23 (UTC)
Sorry for the update delay; I had made 5.5.10, but then forgot to push it. Then work-from-home happened and things have been cuh-ray-zee.
5.5.13 is up now. If anyone is using my repo, as an FYI, I have switched to zstd (.tar.zst).
I hope everyone is doing well.
slowbro commented on 2020-03-16 05:53 (UTC)
Got 5.5.9 out; note that this kernel is compiled w/ gcc 9.3.0; you may need to pacman -Syu
before building the new version (I'm not entirely sure since I did a roundabout way). Either way, the pre-compiled version is available on my repo.
osakasys commented on 2020-03-15 15:09 (UTC) (edited on 2020-03-15 15:10 (UTC) by osakasys)
And now my graphics card I've attached for use with VFIO isn't initializing correctly. Looking deeper it seems like this is a kernel issue, but I don't know the cause. Looking through dmesg
, I get this: pci-stub 0000:07:00.0: Invalid PCI ROM header signature: expecting 0xaa55, got 0xffff
and some message saying it couldn't turn on the device. Is anyone else having these problems? I'm building the LTS version of this kernel in the hopes it fixes my problems. I'll edit my post as I find more information.
EDIT: I should mention that it's not the card itself since I booted into Windows 10 briefly with it and it appears to work fine.
osakasys commented on 2020-03-14 18:51 (UTC)
Seems my build wasn't working. If I use slowbro's build it works fine.
markzz commented on 2020-03-14 18:31 (UTC)
Did you try the regular arch kernel? This patchset does not touch anything regarding disk mounts.
osakasys commented on 2020-03-14 14:51 (UTC) (edited on 2020-03-15 15:13 (UTC) by osakasys)
Getting an error when using fusermount
: fuse: missing mountpoint parameter
Everything I can find points to this being a kernel issue.
EDIT: This may be fixed in 5.6 due to this commit
EDIT2: This problem seems to have been fixed by using slowbro's build. I think my gcc and gcc-libs versions may have been to blame.
scootz commented on 2020-03-08 19:03 (UTC)
Thanks slowbro for providing the updated version. much appreciated.
markzz commented on 2020-02-27 01:59 (UTC)
When I get back to Michigan this weekend, I'll be making a build for my repository as well.
slowbro commented on 2020-02-26 23:21 (UTC) (edited on 2020-02-26 23:22 (UTC) by 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.
slowbro commented on 2020-02-23 00:52 (UTC)
Thanks, markzz. I just published a better version of 5.5.5 now, with updated kernel config - so if you already installed 5.5.5.arch1-1 from below, be sure to update to 5.5.5.arch1-2 from aur. Same kernel, just matches the 'linux' package's config.
I'll keep my eye out for upstream updates and try to get them released ASAP.
markzz commented on 2020-02-22 14:53 (UTC)
I have just added slowbro as a co-maintainer to assist me in keeping this up to date when I get into busy seasons like I have been trying to crawl out of. Sorry about the lack of updates and hopefully the two of us can keep this up to date more effectively than I can alone.
slowbro commented on 2020-02-22 08:23 (UTC)
Patches applied as-is for 5.5.5; untested.. https://github.com/slowbro/linux-vfio/tree/v5.5.5-arch1
shaybox commented on 2020-02-19 08:43 (UTC)
@slowbro I used your patches to update linux-zen-vfio :thumbsup:
slowbro commented on 2020-02-17 01:48 (UTC) (edited on 2020-02-17 02:08 (UTC) by slowbro)
Here's the two latest versions. 5.5.4 seems to work just as well as 5.5.3.
5.5.4.arch1-1: https://github.com/slowbro/linux-vfio/tree/v5.5.4-arch1
5.5.3.arch1-1: https://github.com/slowbro/linux-vfio/tree/v5.5.3-arch1
@glostark happy to help.
giostark commented on 2020-02-16 22:50 (UTC)
TNKS slowbro for the instructions. It worked as you stated. ;-) The kernel boot fine and my VM for work is finally on again.
slowbro commented on 2020-02-16 22:43 (UTC) (edited on 2020-02-16 22:49 (UTC) by slowbro)
Okay, the sha256sums are fixed: https://github.com/slowbro/linux-vfio/tree/v5.5.3-arch1
I just git push --force
'd because I am a bad person.
BTW: 5.5.4.arch1 built successfully, I'm testing a full makepkg now.
slowbro commented on 2020-02-16 21:56 (UTC)
Ah, whoops.. I had reorganized the patches to make the diffs smaller and forgot to re-hash. I'll fix that asap, but in the mean time you can update the sha256sum lines in the PKGBUILD. Just run 'sha256sum *.patch' to get the new ones. The sum array has the hashes in the same order as the sources array.
giostark commented on 2020-02-16 21:52 (UTC)
Thanks for you time and work... :-)
I receive this : ==> Validating source files with sha256sums... archlinux-linux ... Skipped config ... Passed add-acs-overrides.patch ... FAILED i915-vga-arbiter.patch ... FAILED ==> ERROR: One or more files did not pass the validity check!
Tried to delete the files and re-download , happen the same.
slowbro commented on 2020-02-16 21:09 (UTC) (edited on 2020-02-16 22:50 (UTC) by slowbro)
Alright, everything seems to be working on 5.5.3.arch1. I had switched to .3 because I noticed yesterday .4 was still in -testing.. but now .4 is out. This should just work with 5.5.4, you'll just need to change the PKGBUILD pkgver line. The patches apply cleanly. I'm compiling it now for 5.5.4 and will report back with results.
For now, enjoy 5.5.3.arch1: https://github.com/slowbro/linux-vfio/tree/v5.5.3-arch1
(Note: I make no guarantees, minimally tested,etc. My IOMMU groups are identical with this as they were with 5.3.7-arch1. I was able to boot my windows VM and it worked.)
alegru commented on 2020-02-16 13:57 (UTC)
I backported the changes to the linux-vfio-lts package, if someone wants to use it in the mean time
slowbro commented on 2020-02-15 20:31 (UTC)
I've been working on a PKGBUILD based on 5.5.4-arch1. I got the patches re-worked for all the recent intel_vga changes, and things seem good, I'll update later this weekend with a yay/nay.
arkaid commented on 2020-02-14 11:09 (UTC)
Does anybody know of a good tutorial on how to apply the patches by hand?
I usually rely on markzz to update the package, since I don't know how to do it myself, but I need to update the kernel soon.
shaybox commented on 2020-02-13 18:58 (UTC)
@aknarts This kernel is too out of date to work with most up to date dkms modules now.
aknarts commented on 2020-02-12 20:42 (UTC)
Anybody has an elegant solution to "incompatible gcc/plugin versions" when building dkms modules(namely nvidia-dkms)?
JuniorJPDJ commented on 2020-02-03 07:11 (UTC)
Don't worry. I'm just making sure you remember :D
markzz commented on 2020-02-03 06:10 (UTC)
I only forgot a little bit. I did some traveling over the last week and didn't have time to get to it. I will make every attempt to get to this in the next week, but sometimes life gets busy.
JuniorJPDJ commented on 2020-02-03 04:57 (UTC) (edited on 2020-02-03 04:57 (UTC) by JuniorJPDJ)
Next weekend just finished and new linux major version came. Do you remember about us? ;)
markzz commented on 2020-01-22 07:37 (UTC)
Yeah, that's on me. I'll put it on my TODO list for this weekend.
thearcherblog commented on 2020-01-22 06:05 (UTC)
Hello,
This package has been flagged out-of-date for some time... any news about updates?
Thanks a lot!
Zackptg5 commented on 2020-01-05 08:10 (UTC) (edited on 2020-01-05 08:12 (UTC) by Zackptg5)
Just thought I'd add this in here For those looking to compile for 5.4.6.2:
Change pkgver in PKGBUILD
Replace add-acs-override.patch with updated one listed in a previous comment
Modify i915-vga-arbiter.patch as follows:
-
For last diff, change all instances of intel_drv.h to display/intel_display.h
-
Change 1457 to 432 (line numbers beneath above)
Finally update sha256 as needed in PKGBUILD
NeoTheFox commented on 2019-12-14 16:05 (UTC)
So if anyone needs a newer patch it's here https://gitlab.com/Queuecumber/linux-acs-override/raw/master/workspaces/5.4/acso.patch
markzz commented on 2019-12-03 17:59 (UTC) (edited on 2019-12-03 18:01 (UTC) by markzz)
jklc: https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/linux
They are makedepends as well, you can remove them after building.
jklc commented on 2019-12-03 17:47 (UTC)
5.3.13(1ec4cb075348
) wants the following additional dependencies:
Packages (32) gd-2.2.5-2 ghostscript-9.50-2 giflib-5.2.1-1 gsfonts-20180524-2 gts-0.7.6-5 ijs-0.35-2 jbig2dec-0.17-1 libidn-1.35-2 liblqr-0.4.2-2 libpaper-1.1.24-11 libraqm-0.7.0-1 libwebp-1.0.3-1 openjpeg2-2.3.1-1 python-babel-2.7.0-3 python-docutils-0.14-4 python-imagesize-1.1.0-3 python-jinja-2.10.3-3 python-markupsafe-1.1.1-3 python-pygments-2.5.2-1 python-pytz-2019.3-3 python-snowballstemmer-2.0.0-3 python-sphinx-alabaster-theme-0.7.12-3 python-sphinxcontrib-applehelp-1.0.1-4 python-sphinxcontrib-devhelp-1.0.1-4 python-sphinxcontrib-htmlhelp-1.0.2-4 python-sphinxcontrib-jsmath-1.0.1-4 python-sphinxcontrib-qthelp-1.0.2-4 python-sphinxcontrib-serializinghtml-1.1.3-4 graphviz-2.42.3-1 imagemagick-7.0.9.7-1 python-sphinx-2.2.1-2 python-sphinx_rtd_theme-0.4.3-3
why?
jklc commented on 2019-10-29 01:07 (UTC)
It was a mce Hardware Error. I have since installed rasdaemon and updated the intel microcode to the latest(0xae). 5.3.7.arch1-1 has been running smoothly for the past 18 hours.
markzz commented on 2019-10-28 15:21 (UTC)
jklc: I cannot confirm this issue. The kernel appears to be working fine on my machine. The only difference I can think of is I do not use an Intel iGPU on the host.
jklc commented on 2019-10-27 22:06 (UTC)
Tried 5.3.7.arch1-1 on a Z390/9700k today with the lated -Syu pull. KVM/qemu Windows 10 guest with NVidia 2080Ti passthrough is running with some glitch and crashed the arch host within 60 minutes. Still investigating the cause. The last stable working version of linux-vfio for me has been 5.0.13-arch1-1 (f483bc1a95dc
)
markzz commented on 2019-09-21 04:19 (UTC)
I will not update this package until I have made the necessary modifications to all patches.
shaybox commented on 2019-09-21 04:02 (UTC)
Looks like the i915 vga patch is broken 5.3+, gonna have to be removed until someone produces a new modified patch to patch the patch
markzz commented on 2019-09-08 03:00 (UTC)
dszryan: put that in your makepkg.conf....................
dszryan commented on 2019-09-08 02:58 (UTC)
the build could do with: build() { cd $_srcname make -j $(($(cat /proc/cpuinfo | awk '/^processor/{print $3}' | wc -l) + 1)) bzImage modules }
to speed the build up, #jobs = #processors + 1
what do you think?
Youngsie97 commented on 2019-07-30 15:25 (UTC) (edited on 2019-07-30 15:25 (UTC) by Youngsie97)
Just wanted to comment to thank ironicbadger and also confirm their findings I was having issues in particular with discord and FF14(FFXIV) crashing and losing sound randomly rolling back to 4.19-20 via LTS package appears to have fixed these issues.
ironicbadger commented on 2019-07-22 04:02 (UTC)
I was running into some issues with 5.2.1 kernel today in a Windows 10 guest where 3d apps (such as Firefox, Chrome and Fusion 360) would just randomly quit.
According to my research I found the following on the VFIO discord
A new bug in kernel 5.2 is causing KMODE_EXPECTION_NOT_HANDLED and other anomalies for some people. A few folks reporting artifacting/crashing issues on 5.1 say that issue persists on 5.2 as well, but this is may be a different bug. Root cause of both issues remains unknown currently. Rollback to the last known good or LTS kernels.
I downgraded to 4.19.x via the linux-vfio-lts package and stability returned to my guest. Hope this helps someone out.
markzz commented on 2019-07-10 17:19 (UTC)
If this is a requirement for you, you will need to add this patch yourself when you build.
igno2k commented on 2019-07-10 11:00 (UTC)
Any chance to add the Agesa Patch? https://clbin.com/VCiYJ
Also see: https://forum.level1techs.com/t/attention-amd-vfio-users-do-not-update-your-bios/142685
giostark commented on 2019-05-09 15:58 (UTC) (edited on 2019-05-09 16:07 (UTC) by giostark)
I am getting the following build error:
Extension error:
Could not import extension kerneldoc (exception: cannot import name
'AutodocReporter' from 'sphinx.ext.autodoc' (/usr/lib/python3.7/site-packages/sphinx/ext/autodoc/__init__.py))
As the same here: https://aur.archlinux.org/packages/linux-rt-bfq/
Following those patch instructions I deleted some lines in the PKGBUILD and I'm now compiling.
markzz commented on 2019-04-25 18:43 (UTC)
PiMaker101: One of the goals of this package is to model it after the standard linux package in the official repositories. This includes configuration options. This does not, however, stop you from changing the config yourself when you build it though.
PiMaker101 commented on 2019-04-25 18:16 (UTC)
Tested with 5.0.9 by changing the git tag in the PKGBUILD, working fine, including testing with QEMU 4.0. Noteworthy though, that I had to disable building the doc package (removed htmldocs from make
), since there was a build error with sphinx.
By the way, I think it might be a good idea to change the default kernel config in this package to enable voluntary preemption (CONFIG_PREEMPT_VOLUNTARY=y
), since this fixes a bug with QEMU/OMVF boot times when configured with a lot of RAM/cores (see https://forums.unraid.net/topic/72172-unraid-os-version-653-available/). Personally using this configuration, have not noticed any side-effects or performance losses on the host so far.
Youngsie97 commented on 2019-03-24 10:56 (UTC)
Just wanted to say that In regards to jmandawg and markzz that I have been updating by just changing the versions for about a week now (starting with 5.0-1) with no unexpected behaviour or side effects. Although I should state I haven't done any deep testing outside of just running my normal vms etc.
markzz commented on 2019-03-24 04:26 (UTC) (edited on 2019-03-24 04:40 (UTC) by markzz)
jmandawg: You can certainly try just changing the PKGBUILD with no new patches, but I would bet on the fact that the current patches will not work. The issue is, it's on my list of things I have to get done, but that list has grown in the last few months to the point where I'm trying to catch up. No ETA at this moment.
EDIT: I take it all back, it looks like the patches did apply, so I'm running a build and will quickly test it tomorrow.
jmandawg commented on 2019-03-24 02:46 (UTC)
Thanks for the great work, 5.0.x coming anytime soon? Or is it safe to change the _srcver and rebuild?
NeoTheFox commented on 2018-12-12 20:10 (UTC)
The latest version (4.19.8-arch1-1-vfio) has build error due to patch:
drivers/pci/quirks.c:4617:28: error: ‘pci_acs_overrides’ undeclared here (not in a function); did you mean ‘pcie_acs_overrides’? { PCI_ANY_ID, PCI_ANY_ID, pci_acs_overrides }, ^~~~~~~~~~~~~~~~~ pcie_acs_overrides
markzz commented on 2018-12-12 16:30 (UTC)
I have pushed something that the patches apply, but I haven't tested the package itself.
markzz commented on 2018-12-12 14:09 (UTC) (edited on 2018-12-12 15:24 (UTC) by markzz)
whight: The vga arbiter patch does not apply in 4.19.x.
Applying: i915: Add module option to support VGA arbiter on HD devices (4.17)
error: patch failed: drivers/gpu/drm/i915/i915_params.c:133
error: drivers/gpu/drm/i915/i915_params.c: patch does not apply
error: patch failed: drivers/gpu/drm/i915/i915_params.h:58
error: drivers/gpu/drm/i915/i915_params.h: patch does not apply
error: patch failed: drivers/gpu/drm/i915/intel_display.c:15402
error: drivers/gpu/drm/i915/intel_display.c: patch does not apply
whight commented on 2018-12-12 08:36 (UTC)
You shouldn't have any troubles using the patch in your sources for 4.19.8. Built and tested it myself with linux from the core repo. If you'd like, I can help keep this maintained.
markzz commented on 2018-12-05 14:00 (UTC)
archqemu: I try to keep up to date with regards to whatever version is in [core]. The problem is, on version releases (e.g. 4.14 -> 4.15), I often have to rewrite the patches (this isn't normally a problem on patch releases like 4.16.7 -> 4.16.8). Because I'm both a full time student and work full time as a software engineer, I am sometimes unable to set aside enough time to update the patches and I get to it when I can. The semester is almost over at the time of this comment, so I should be able to set aside time for sure then, if not sooner.
archqemu commented on 2018-12-05 13:51 (UTC) (edited on 2018-12-05 13:51 (UTC) by archqemu)
okay cool, thanks for your quick reply!
I was just curious if there is any systematic release schedule related to the kernel releases.
markzz commented on 2018-12-05 10:14 (UTC)
archqemu: When it's done.
archqemu commented on 2018-12-05 10:07 (UTC) (edited on 2018-12-05 10:07 (UTC) by archqemu)
When can we expect an update of this package?
jmandawg commented on 2018-10-29 17:51 (UTC)
Awesome thanks markzz, I didn't know this, i'm still a bit of a noob (switched from debian) i'm going to try this for the next kernel update. Thanks again.
markzz commented on 2018-10-29 14:44 (UTC)
jmandawg: This is because when you boot this kernel without building the dkms module for it, it will of course not work. Because this is information any user of DKMS should know about, I don't see a reason to pin a comment about that.
I think this is something that you should read what the wiki states on DKMS because it actually lays out the steps to make sure the module is built for your kernel in use and does not require a reinstall of the nvidia-dkms package.
https://wiki.archlinux.org/index.php/Dynamic_Kernel_Module_Support
jmandawg commented on 2018-10-29 14:36 (UTC) (edited on 2018-10-29 14:37 (UTC) by jmandawg)
Someone should sticky the comment by (erylflynn commented on 2016-04-21 17:23 (edited on 2016-07-28 04:34 by erylflynn))
Installing this new kernel will break Xorg if you are using nvidia-dkms, but a re-install of nvidia-dkms fixes it.
Unfortunately there is no way to search the comments on here.
MurkyDepths commented on 2018-09-08 22:00 (UTC)
Sorry it took so long to reply, got busy with some other stuff.
I've done with and without AUR helpers. Pacaur seemed to work fine, without was a 70/30ish of it working or not. Over the course of some ten+ installs about 3 or 5 ended up working. Without doing anything different before the install.
Essentially, I have no idea what the problem is.
markzz commented on 2018-09-05 03:11 (UTC)
The -headers and -docs packages are not required to use the base package. The headers package are just that, headers for developers that need them. The docs package is also just that, documentation for the kernel and you don't need them to run the kernel.
If you are using an AUR helper, don't. They are not supported and I will not even entertain issues with packages built with them. Try building using makepkg alone and if that doesn't work, use a clean chroot (check the wiki).
If you really want to try a known good built package done in a clean chroot, you can try the package in my public repository. Again, check the wiki. I know for a fact that this PKGBUILD is known to work as I use it every day with no issue (and on an Nvidia card with the nouveau drivers).
MurkyDepths commented on 2018-09-04 18:20 (UTC)
When I install it asks if I want to install linux-vfio-headers and docs. They should be installed, but I don't even know. I'll go test that when I have time. If headers aren't installed that's likely the problem, if they are I'll get the version number. I'll also check dkms as you mentioned. And if anything doesn't really work, I'll try rebuilding it.
erylflynn commented on 2018-09-04 17:40 (UTC)
Only time I saw anything like this was when the kernel was built but the headers was not. I tried a new AUR tool and it only built the linux-vfio package, not linux-vfio-headers. Once I rebuilt everything making sure the headers installed it worked.
Check linux-vfio-headers installed version. Also "dkms status" to show if the module for your video drivers was built. If not force dkms to rebuild and see what happens.
MurkyDepths commented on 2018-09-04 17:32 (UTC)
I've searched as extensively as I could manage. Every time was a fresh install. With or without nvidia drivers. Blacklisting nouveau or nvidia, setting a default output card does nothing, binding the card with pci-stub and/or vfio-bind doesn't change anything. Different desktop managers changes nothing, reinstalling desktop managers and Xorg doesn't change anything. Haven't found anything special in the logs I've looked at or using dmesg(or whatever it's called, I can't recall). If there are any other drivers I need to worry about I don't know which ones they are.
Honestly I'm at my wits end, I'm far from a veteran but I'm at least a decently good user, but nothing special. Though searches on google and scouring wikis and forums I haven't found anything that solves it. I've found ones with similar problems to mine, but either with no solution or one that doesn't work for me.
Is there a way to log the installation process of linux-vfio? I've noticed some red text pop up here and there, but am not sure how to get my hands on it. Only thought of that during my writing of this. Usually, at the end, or close to it, there is usually a rather large red block of text, probably ten lines at the very least. I have no idea if these are errors or not, but if I can get my hands on that log it might help solving whatever problem is causing this. Whether that's a hardware issue or software I can't say.
markzz commented on 2018-09-03 16:25 (UTC) (edited on 2018-09-03 16:27 (UTC) by markzz)
MurkyDepths: Did you check the Wiki, the forums, Google?
I can tell you this kernel is working fine on at least my system. Check your drivers, check your logs, etc...
MurkyDepths commented on 2018-09-03 13:45 (UTC)
For some reason installing this now kills graphical boot and it’s stuck on a blackscreen with a blinking cursor. Non-graphical boot works fine though. Have you encountered this before? If so, do you know of a way to fix it?
MurkyDepths commented on 2018-08-30 15:42 (UTC)
Sorry, I'm like maybe day one on arch so I have little to no idea how AUR works properly. Though I'm learning, it doesn't stop me from being stupid.
markzz commented on 2018-08-30 14:59 (UTC)
The answer to that question is always "When it's done."
Also, seeing as this PKGBUILD is on 4.18.4 right now tells you something about your question...
MurkyDepths commented on 2018-08-30 14:23 (UTC) (edited on 2018-08-30 14:31 (UTC) by MurkyDepths)
Is the patch available to 4.18.*? If it isn't, how long do you think it'll be until it's updated?
markzz commented on 2018-08-25 19:24 (UTC)
jugs: Usually that's the case, but this time I'm just being slow.
jugs commented on 2018-08-25 00:12 (UTC)
Does the patch not work on 4.18?
codekoala commented on 2018-08-13 16:30 (UTC)
Looks like recompiling this package did the trick for me.
codekoala commented on 2018-08-13 15:33 (UTC)
I'm having problems with nvidia-dkms and this package:
==> dkms install nvidia/396.24 -k 4.17.3-1-vfio Error! Bad return status for module build on kernel: 4.17.3-1-vfio (x86_64) Consult /var/lib/dkms/nvidia/396.24/build/make.log for more information.
I'm not sure when the problems started happening, but it's probably started within the last week. Anyone else having issues with nvidia drivers failing to install for this kernel lately?
I'm trying to get operational again by trying combinations of different kernel and nvidia versions. Still no luck yet.
markzz commented on 2018-06-09 15:59 (UTC)
DocMAX: That line appears to be doing a job. Removing it would make me feel uneasy and without further information, I will not remove it.
You are free to do so when you build it though. The details of that reddit post also show that the person was using an Atom/Pentium/Celeron with a possible ACS cap and that line should absolutely not be removed.
If you want to discuss it with me further, I'd recommend turning to email and contacting me directly, especially if you have more information that will change my mind.
DocMAX commented on 2018-06-09 15:26 (UTC)
Could you remove the line described here?:
markzz commented on 2018-05-30 23:33 (UTC)
I'll add it soon then.
moffat commented on 2018-05-30 22:39 (UTC)
This patch was needed to enable ACS override on my machine using an i7-7260U
giostark commented on 2018-05-09 19:00 (UTC)
@Fleetscut ...damn TNX. Im a noob in linux so I was stuck thinking that was a nvidia problem. After the last gcc-8.1.0 I wasn't able to reinstall the nvidia-dkms module. By the way the virtual machine and the pci pass through worked fine, was only the host to have a 800x600 resolution ^_^ For the moment ill blacklist the new gcc.
Fleetscut commented on 2018-05-08 01:09 (UTC)
i cant seem to build this kernel with gcc-8.1.0. i keep getting a message that mv cannot stat the temp directory that is being used to build. happens no matter where i point the build directory. i had to downgrade to my last version of gcc to get it to work.
markzz commented on 2018-04-13 15:59 (UTC)
When you build this PKGBUILD, you will get the three packages. As for how pacaur or ANY other aur helper works, I cannot say.
mcardillo55 commented on 2018-04-13 07:16 (UTC)
Does the kernel need to be rebuilt to install linux-vfio-headers? For example, I run pacaur -S linux-vfio, it compiles and installs the kernel. Then I run pacaur -S linux-vfio-headers, it compiles the kernel again before installing the headers. Aren't the headers just extracted from the tarball?
Thanks
markzz commented on 2018-04-06 16:30 (UTC)
Dehir: What?
Dehir commented on 2018-04-06 15:18 (UTC)
IF there is every possible to get realtime kernel with vfio same time :P
markzz commented on 2018-03-08 21:25 (UTC)
If either of you can get a core dump, I can investigate, but I don't know what else to tell you because I do not have the same hardware as you.
c3924754 commented on 2018-03-08 21:19 (UTC)
I can also confirm that with 4.11.4+ I cannot start my VMs that have a dedicated GPU. Experiencing output very similar to @cinna .
markzz commented on 2018-02-10 01:51 (UTC)
cinna: None of those functions in the call trace are in the patches that this kernel provide. I would either file a bug with Arch or with upstream.
cinna commented on 2018-02-10 01:39 (UTC) (edited on 2018-02-10 01:41 (UTC) by cinna)
I'm having a similar issue as zatricky where a VM refuses to launch when I have a dedicated gpu attached. Here's a relevant dmesg when I attempt to launch it. As for my hardware I'm running a Ryzen processor with a dedicated GPU for my host and another for my VMs
https://gist.github.com/anonymous/650925d4d58f7fd689b951f99c5d35f5
markzz commented on 2018-02-09 19:46 (UTC) (edited on 2018-02-09 20:02 (UTC) by markzz)
zatricky: Are you using an Intel iGPU for the host? Also, some relevant dmesg output would be helpful.
zatricky commented on 2018-02-08 20:19 (UTC) (edited on 2018-02-08 20:24 (UTC) by zatricky)
Latest package 4.15.1-1 resulted in sporadic errors from libvirtd when attempting to launch VM with dedicated GPU: Feb 08 22:08:04 <hostname> libvirtd[612]: 2018-02-08 20:08:04.406+0000: 612: error : virNetSocketReadWire:1808 : End of file while reading data: Input/output error</hostname>
Other VMs (not using GPU) were functional. From the moment I attempted to start the dedicated-GPU VM, virsh commands would no longer complete and virt-manager would become unresponsive.
Downgraded to 4.14.11-1 - all is working again.
- Z68MA-G45 (MS-7676)
- i7 3770
- AMD Radeon R9 380
markzz commented on 2018-02-07 21:23 (UTC) (edited on 2018-02-08 03:42 (UTC) by markzz)
Sorry about the lack of updates (if only I had unlimited time). I am currently building and testing 4.15 and you can expect it by this coming Friday.
EDIT: It is up and I need i915 users to tell me if everything's okay.
fr3dx commented on 2018-01-24 12:06 (UTC) (edited on 2018-01-24 12:06 (UTC) by fr3dx)
Hiya, how can I use this kernel on Manjaro Linux? ty
markzz commented on 2017-12-14 06:10 (UTC)
(4.14.5+) Because Arch itself has dropped i686 support, I have removed i686 from the PKGBUILD and there is no config file either.
abrilevskiy commented on 2017-12-06 06:26 (UTC)
I use Nvidia cards and Intel hardware and in order to get it working - ACS patch is required. Therefore AGESA update will not eliminate for ACS.
cinna commented on 2017-12-05 17:29 (UTC)
The NPT patch is included in the kernel as of 4.13.3 for you AMD people. When the upcoming AGESA update releases we probably won't even need this ACS patch anymore either ^_^
Pinned Comments
markzz commented on 2020-05-01 15:44 (UTC) (edited on 2020-05-01 16:06 (UTC) by markzz)
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.
slowbro commented on 2020-02-26 23:21 (UTC) (edited on 2020-02-26 23:22 (UTC) by 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.