Hi all,
my inquiry concerns the "Building the Fedora Kernel" article (See https://fedoramagazine.org/building-fedora-kernel/, "Building the Fedora Kernel by Laura Abbot, 09/06/2019 stating that "Two common reasons to rebuild the kernel are to . . . add patches"; Also See https://docs.pagure.org/docs-fedora/building-custom-kernel.html).
Specifically, I would like to apply the below-listed PATCH to kernel 5.2.18-200.fc30.x86_64 to patch to resolve a Header Error Code 127 error received when attempting GPU pass-through on a 2700X Taichi Ultimate ( PATCH: https://clbin.com/VCiYJ, patch code listed at the end).
I am running the following Build: Motherboard: ASRock, X470 Taichi Ultimate BIOS Version: BIOS 3.3P CPU: AMD Ryzen 7 2700X HDDs: Host Linux: Samsung Electronics NVMe SSD Controller SM961/PM961, Windows(7/10) VMSamsung SSD 860 GPUs: Host Linux: PNY nVidia Quadro M2000, VM Pass-through: EVGA nVidia GeForce GTX 760; Linux: Fedora 30 Kernel: 5.2.18-200.fc30.x86_64).
I have been through several materials including (https://unix.stackexchange.com/questions/475128/is-there-a-quick-way-to-inst... describing how to get a particular build using koji; https://docs.fedoraproject.org/en-US/quick-docs/kernel/build-custom-kernel/ describing how to build the kernel via fedpkg and git; https://docs.fedoraproject.org/en-US/fedora/rawhide/system-administrators-gu... directed to upgrading the kernel; https://fedoraproject.org/wiki/Building_a_custom_kernel/Source_RPM describing how to build the kernel from RPMS using rpmdev-setuptree and koji; https://fedoraproject.org/wiki/Building_a_custom_kernel#Dependencies_for_bui... describing how to building the kernel via fedpkg and git; https://fedoramagazine.org/building-fedora-kernel/ describing how to build the kernel and listing two main reasons for doing so; https://docs.pagure.org/docs-fedora/building- custom-kernel.html crediting "Building the Fedora Kernel"; https://fedoramagazine.org/install-kernel-koji/ describing how to install a kernel from koji; https://github.com/AcidzDev/CentOS-header127/blob/master/CentOS-127patch.sh listing patch -p1 < pci.patch as the way to apply a patch to a kernel downloaded via wget from wget https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.3.1.tar.xz). I have also inquired at level1techs https://forum.level1techs.com/t/windows-10vm-gpu-passthrough-pci-header-erro... and the Fedora Forum https://forums.fedoraforum.org/showthread.php?322470-F30-how-to-apply-PATCH-....
At this point am somewhat overwhelemed with information and am unable to figure out how to properly apply this patch kernel 5.2.18-200.fc30.x86_64.
When attempting to compile and patch using koji (instructions at https://fedoraproject.org/wiki/Build...nel/Source_RPM), I am not sure how to apply the patch because there is only the kernel.spec and source which does not have any .c or .h files. Editing the kernel.spec file and copying the patch to ~/rpmbuild/SOURCES makes the build process fail. So I am kinda stuck here.
On the other hand, going the git and fedpkg route (https://docs.fedoraproject.org/en-US...custom-kernel/, https://fedoramagazine.org/building-fedora-kernel/; https://docs.pagure.org/docs-fedora/...om-kernel.html), I am not able to download a specific kernel version and always get a 5.3 kernel instead of the 5.2.18-200 that I am currently running. In fact, I tried it again yesterday and received the kernel-5.4.0-0.rc2.git2.1.fc30.x86_64.rpm.
It seems that the above-listed two ways are just two similar approaches to accomplishing the same task. Either way, I just cannot get the result I am looking for: a patched 5.2.18-200.fc30.x86_64 kernel with the ability to install NVIDIA drivers, do GPU pass-through and update later via "dnf update"
I must be missing something and any help is welcome.
The PATCH code is below PATCH: https://clbin.com/VCiYJ (patche code listed at the end)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index 766f5779db92..dc19079dad1b 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -52,6 +52,9 @@ unsigned int pci_pm_d3_delay;
static void pci_pme_list_scan(struct work_struct *work);
+static void pci_dev_save_and_disable(struct pci_dev *dev); +static void pci_dev_restore(struct pci_dev *dev); + static LIST_HEAD(pci_pme_list); static DEFINE_MUTEX(pci_pme_list_mutex); static DECLARE_DELAYED_WORK(pci_pme_work, pci_pme_list_scan); @@ -1379,15 +1382,7 @@ static void pci_restore_config_space(struct pci_dev *pdev) pci_restore_config_space_range(pdev, 4, 9, 10, false); pci_restore_config_space_range(pdev, 0, 3, 0, false); } else if (pdev->hdr_type == PCI_HEADER_TYPE_BRIDGE) { - pci_restore_config_space_range(pdev, 12, 15, 0, false); - - /* - * Force rewriting of prefetch registers to avoid S3 resume - * issues on Intel PCI bridges that occur when these - * registers are not explicitly written. - */ - pci_restore_config_space_range(pdev, 9, 11, 0, true); - pci_restore_config_space_range(pdev, 0, 8, 0, false); + pci_restore_config_space_range(pdev, 0, 15, 0, true); } else { pci_restore_config_space_range(pdev, 0, 15, 0, false); } @@ -4636,6 +4631,8 @@ void pci_reset_secondary_bus(struct pci_dev *dev) { u16 ctrl;
+ pci_dev_save_and_disable(dev); + pci_read_config_word(dev, PCI_BRIDGE_CONTROL, &ctrl); ctrl |= PCI_BRIDGE_CTL_BUS_RESET; pci_write_config_word(dev, PCI_BRIDGE_CONTROL, ctrl); @@ -4649,6 +4646,8 @@ void pci_reset_secondary_bus(struct pci_dev *dev) ctrl &= ~PCI_BRIDGE_CTL_BUS_RESET; pci_write_config_word(dev, PCI_BRIDGE_CONTROL, ctrl);
+ pci_dev_restore(dev); + /* * Trhfa for conventional PCI is 2^25 clock cycles. * Assuming a minimum 33MHz clock this results in a 1s
On Mon, 14 Oct 2019 15:45:00 -0000 "Kot Begemot" kbdeamon@gmail.com wrote:
source which does not have any .c or .h files. Editing the kernel.spec file and copying the patch to ~/rpmbuild/SOURCES makes the build process fail. So I am kinda stuck here.
How specifically does it fail? What are the error messages?
I regularly build and patch fedora kernels using the rpmbuild method, since I've been doing it for a long time. I am unfamiliar with the more modern method so cannot help with that.
I wrote my procedure as a reply to this list some time ago under "custom kernel build with patch".
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org...
When I create my personal patch, I have to create it locally for the kernel in git after I expand the source, or it won't be accepted. If your patch is not an official kernel patch, it won't apply for the same reason.
If you use secure boot with uefi, you will also have to remove the test signature from the custom kernel, and create a signing key and sign it with your key after install. I documented my procedure for that in a message on the user list, "How to sign a locally compiled kernel so it can be booted with UEFI."
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org/...
Hi Stan,
thank you so much!
I followed your guide and was able to complete my first kernel compile. That said, now I have developed a number of questions with respect to what I am trying to accomplish with these kernel compiles.
I would like to accomplish a number of things: 1. apply the patch to the kenel (which I am able to do now) while preserving the prioprietory NVIDIA driver installation. Is this possible or would I have to re-install and re-compile the drivers? 2. Can you tell me what will happen with respect to kernel updates post installation. Particularly as it relates to the NVIDIA drivers? Can I keep running dnf updates or would I have to prevent kernel updates some how? 3. After the compilation completes I find the following kernel-* files in /home/user0/rpmbuild/RPMS/x86_64 which is great. But is there any way to avoid compiling the "debug" versions? I am trying "rpmbuild -ba kernel.spec" at the moment.
[user0@f30vm1 x86_64]$ pwd && ls /home/user0/rpmbuild/RPMS/x86_64 kernel-5.2.18-200.f30localwithpcipatch.fc30.x86_64.rpm kernel-core-5.2.18-200.f30localwithpcipatch.fc30.x86_64.rpm kernel-debug-5.2.18-200.f30localwithpcipatch.fc30.x86_64.rpm kernel-debug-core-5.2.18-200.f30localwithpcipatch.fc30.x86_64.rpm kernel-debug-debuginfo-5.2.18-200.f30localwithpcipatch.fc30.x86_64.rpm kernel-debug-devel-5.2.18-200.f30localwithpcipatch.fc30.x86_64.rpm kernel-debuginfo-5.2.18-200.f30localwithpcipatch.fc30.x86_64.rpm kernel-debuginfo-common-x86_64-5.2.18-200.f30localwithpcipatch.fc30.x86_64.rpm kernel-debug-modules-5.2.18-200.f30localwithpcipatch.fc30.x86_64.rpm kernel-debug-modules-extra-5.2.18-200.f30localwithpcipatch.fc30.x86_64.rpm kernel-devel-5.2.18-200.f30localwithpcipatch.fc30.x86_64.rpm kernel-modules-5.2.18-200.f30localwithpcipatch.fc30.x86_64.rpm kernel-modules-extra-5.2.18-200.f30localwithpcipatch.fc30.x86_64.rpm
On Fri, 18 Oct 2019 18:26:01 -0000 "Kot Begemot" kbdeamon@gmail.com wrote:
I would like to accomplish a number of things:
- apply the patch to the kenel (which I am able to do now) while
preserving the prioprietory NVIDIA driver installation. Is this possible or would I have to re-install and re-compile the drivers?
I think if you use the akmod packages from rpmfusion, they will build the driver module at boot if it isn't there. I run a radeon, so I am not familiar with this. When I used to run nvidia, I couldn't use the rawhide kernels because rpmfusion hadn't created the necessary files (or maybe it was nvidia) because the kernels were development kernels. It might be possible to use the binary blob right from nvidia, but you would have to take care of all updating outside the package system.
Can you tell me what will happen with respect to kernel updates post installation. Particularly as it relates to the NVIDIA drivers? Can I keep running dnf updates or would I have to prevent kernel updates some how?
I prevent kernel updates so that my locally compiled kernel is always the default; the stock kernels don't have my patch in them. The -x option to dnf works, dnf -x kernel* update.
- After the compilation completes I find the following
kernel-* files in /home/user0/rpmbuild/RPMS/x86_64 which is great. But is there any way to avoid compiling the "debug" versions? I am trying "rpmbuild -ba kernel.spec" at the moment.
Edit the spec file, and turn off all the debug options; flip them from 1 to 0. These are just below the %define buildid .20191008 that you should be setting so your kernel is identified as a custom version. e.g. # kernel-debug %define with_debug %{?_without_debug: 0} %{?!_without_debug: 0}
On Fri, 18 Oct 2019 13:46:09 -0700 stan upaitag@zoho.com wrote:
On Fri, 18 Oct 2019 18:26:01 -0000 "Kot Begemot" kbdeamon@gmail.com wrote:
- After the compilation completes I find the following
kernel-* files in /home/user0/rpmbuild/RPMS/x86_64 which is great. But is there any way to avoid compiling the "debug" versions? I am trying "rpmbuild -ba kernel.spec" at the moment.
Edit the spec file, and turn off all the debug options; flip them from 1 to 0. These are just below the %define buildid .20191008 that you should be setting so your kernel is identified as a custom version. e.g. # kernel-debug %define with_debug %{?_without_debug: 0} %{?!_without_debug: 0}
PS
You can probably speed up your compile by replacing this line %define nobuildarches i386 with this one, if you are building for x86_64. %define nobuildarches i386 ppc64 s390x %{arm} %{power64} aarch64 ppc64le
and also disabling the cross-compile headers.
If you want to go even further, you could create a configuration file using make localmodconfig which will only build modules that you are actually using on the currently running system. Be sure that everything you need is there. It is a good idea to run make nconfig or make menuconfig after this to be sure that things look reasonable, and to remove things you are sure you don't need (file systems you don't use, etc.). This can get complex, so is a little deeper than the above two suggestions.
"I think if you use the akmod packages from rpmfusion, they will build the driver module at boot if it isn't there"
A bit lost here, would the rpm-fusion install and akmod install occur before or after the custom kernel compile?. . .
"It might be possible to use the binary blob right from nvidia, but you would have to take care of all updating outside the package system."
So if I go this route then I have to first compile the kernel with nouveau and then install NVIDIA?
In both of these instance, since the kernel.spec file controls what happens, is there a way to somehow generate or copy the kernel.spec file from the running kernel? I tried to find the kernel.spec file else where in the system but came up empty. I also see your answer below that refers to make localmodconfig . . . would this be the way to go?
One more thing, when I screw up the process and install a broken kernel by mistake is there anyway to remove it? I did dnf remove and regenerated the grub2-efi.cfg and ran dracut but I still see it in the boot menu.
On Sun, 20 Oct 2019 22:13:59 -0000 "Kot Begemot" kbdeamon@gmail.com wrote:
"I think if you use the akmod packages from rpmfusion, they will build the driver module at boot if it isn't there" A bit lost here, would the rpm-fusion install and akmod install occur before or after the custom kernel compile?. . .
Before. If you have run a production kernel, and are custom compiling that production kernel, you will probably already have the akmod installed. It would build the nvidia kernel module for your custom kernel the first time you boot your custom kernel. Asking on the rpmfusion users list is your best bet for clarification.
"It might be possible to use the binary blob right from nvidia, but you would have to take care of all updating outside the package system."
So if I go this route then I have to first compile the kernelwith nouveau and then install NVIDIA?
If there is a binary blob, I think you would have to set it up before you boot your new kernel, so it is ready when the kernel boots. It's been so long since I used an nvidia card, and I always used rpmfusion (or nouveau), so I'm not sure. Best go to the nvidia site and read their instructions for linux.
In both of these instance, since the kernel.spec file controls what happens, is there a way to somehow generate or copy the kernel.spec file from the running kernel? I tried to find the kernel.spec file else where in the system but came up empty. I also see your answer below that refers to make localmodconfig . . . would this be the way to go?
What you are looking for is the configuration options for the kernel, and they are under /boot in the files starting with config. I would say to go with localmodconfig, but you seem to be unfamiliar with this whole process, so I think you should wait a while, till you understand what you are doing better. It won't hurt anything, you'll just build a larger kernel than necessary. It's a good idea to have a look through the Documentation directory in the BUILD source before going there.
One more thing, when I screw up the process and install a broken kernel by mistake is there anyway to remove it? I did dnf remove and regenerated the grub2-efi.cfg and ran dracut but I still see it in the boot menu.
Run grub2-mkconfig -o grub.cfg in /boot/efi/EFI/fedora to fix that.
If the kernel is gone, you could also manually edit the grub.cfg file to remove it.
kernel@lists.fedoraproject.org
-
Kot Begemot -
stan