Search results

For those after an automated docker (Cronjob'd) I chucked something together here which should be relatively straightforward to use. https://github.com/Aterfax/pbs-client-docker

Had a quick read of that earlier today, sounds like they silenced the repeated warnings rather than fixing a bug per se. Seems unclear if this is a red herring error warning or indicative of any real issues (probably worth you doing some iperf3 tests to see if you have any poor performance.)...

Had that happen sometimes and it be cleared by a reseat / wipe down of the PCIe pins with isopropyl alcohol. Give that a try and see if it clears up.

Have been using Linux 6.2.11-1-pve-relaxablermrr without issue since 8.0 came out. https://github.com/Aterfax/relax-intel-rmrr/releases Looking at testing and releasing the most recent autobuild today.

Have a look at: https://github.com/Aterfax/relax-intel-rmrr/discussions/38 There's no need to stop or pause the VMs while installing the debs (changes can only take effect after a reboot into the new kernel) and the installation of the debs should automatically run update-initramfs. I've never...

You could use the most recent signed and tested version which would indeed be a downgrade from your current version but should function fine (although you may need to pin the kernel version to be booted (https://pve.proxmox.com/wiki/Host_Bootloader#sysboot_kernel_pin). Alternatively you can use...

Also had this issue on Proxmox 7.2 . The mentioned earlier first mentioned script also fixes up getting the SMART data for a P420i on DL380p Gen 8.

This issue still appears to be present (I just 'enjoyed' fixing this.) root@proxmox:~# pveversion pve-manager/7.2-7/d0dd0e85 (running kernel: 5.15.39-3-pve) root@proxmox:~# grub-install --version grub-install.real (GRUB) 2.04-20

Unfortunately, not a scooby doo.

I've now finished tooling about with the README files to match the current setup.

I resolved the weirdness with the Docker build process, I forgot to copy the patches into the docker image! :rolleyes: As to broken builds: One possibility if people are not cloning the repo itself byte for byte and are copying and pasting certain files, they will almost certainly break the...

The build "system" is done so any releases will be appearing here in future: https://github.com/Aterfax/relax-intel-rmrr/releases I still need to untease what is breaking the patching in the Docker method but the current release was built on my Proxmox node and is working fine...

Ah well, I've kicked off a recompile which will take a bit but as I said I am running 5.15.35-1-pve-relaxablermrr and pass through is definitely working as I am passing a quadro card through to a VM! Let me know if you want me to upload the finished debs!

Hmm, that is odd since if you forked my repo it should have built the most recent kernel (the pve-kernel master branch) if you used build7.1-12.sh. I'd give it ago using that version first if you haven't. (Did you use build7.sh?) I should probably rename build7.1-12.sh to build_latest.sh...

Hmm, I did write this at 4 or 5 in the morning so there is a distinct chance I have made a mistake somewhere, but I did uninstall recompile and re-install as part of my testing and my current booted kernel is doing passthrough ok. Have a look and see if you've got the right kernel booted by...

I've now amended the build script to use sed rather than patch. Tested it once and it seems fine (I've not rebooted to check the patched kernel actually works, just compiled and installed it), so let me know if otherwise. Explanation in the README. https://github.com/Aterfax/relax-intel-rmrr...

sed is usually used for this and these are probably the sed commands you will need to patch the file: '/^static int iommu_skip_te_disable;.*/a static int intel_relaxable_rmrr = 0;' '/intel_iommu_tboot_noforce = 1;/a \\ \ } else if (!strncmp(str, "relax_rmrr", 10)) {\n\ \ \...

I have modified OrpheeGT's fork to support the latest kernel (5_15) here: https://github.com/Aterfax/relax-intel-rmrr I have 5.15.35-1-pve-relaxablermrr currently.

I haven't rebooted yet, will respond again if I do encounter that issue.

Admittedly I haven't had enough time to dig into this during the week but it looks like the second interfaces were failing to set their IPs correctly (doh) - forcing static IPs again on the command line and I have now got symmetric 9.4Gbit going between all devices. Thanks for the idea with...