You cannot share devices from the same IOMMU group (safely) between VMs and/or the Proxmox host: https://pve.proxmox.com/wiki/PCI_Passthrough#Verify_IOMMU_isolation . Lots of PCI(e) passthrough threads about exactly this and IOMMU groups in...
Either you ask the Proxmox maintainers directly (this is the community forum and I doubt, that the actual developers will read here often), or you go ahead, check out the actual kernel source, through git, and do the diff yourself. Main question...
If you look closely, the original posting indeed said "intel_iommu = on" (mind the spaces, inbetween the setting and its value!). So, if the quote was actually what that person had set, then it is quite likely, that "intel_iommu" never was set to...
Get an external EFI-Shell binary (for example via "pbatard"'s github repos: https://github.com/pbatard/UEFI-Shell/releases), and put that onto a USB drive into the "/EFI/BOOT/" folder, renamed (the shell bianry) as "bootx64.efi".
See if you can...
Exakt was zu erwarten war.
Nochmal für's Verständnis:
Deine GPU hat ein Problem damit, wenn sie mitten im Betrieb resettet werden soll.
Das ist für ein Consumer-Device auch nicht wirklich Teil des Use-Case.
Nun kann man dafür Workarounds...
If you would've shown any kind of details of your issue, other than "...it simply doesn't show up in the VM..." then maybe someone might be able to help.
Questioning the helpfulness of others, however is certainly the way to go, if you provide no...
Anhand deiner Fehlermeldung ist das Problem vermutlich (ich kann auch nur grob raten, anhand der gelieferten Details) folgendes:
Du hast ein System aufgesetzt, das bei Kernel-Update automatisch versucht das "vendor-reset" Kernel-Modul zu bauen...
Wenn du schon das externe (nicht Proxmox integrierte) "vendor-reset" Repo nutzen willst, dann würde ich auch dort nachfragen was los ist:
https://github.com/gnif/vendor-reset
Ansonsten wäre es hier wohl gut aufgehoben...
It might be, that feature compatability between QEMU and kernel version "causes" this message. That means one side trying to use a feature that the other cannot deal with. Easy to try out, if you are right with your assumption.
Looking forward to...
The kernel version is irrelevant, if you answer none of the other questions.
Here is the exact code line where this is coming from:
https://github.com/qemu/qemu/blob/master/hw/vfio/region.c#L324
Same code is not included in QEMU 10.1...
And what exactly is the issue here? How often do you see this message? Why does it bother you?
As you might have already seen in your search, this start with kernels >v6.19.
However, from what I read, it is intended just to be that, a "warning"...
Manually boot to a UEFI shell and boot from their, if possible. You can get prebuilt shells online (e.g. here: https://github.com/pbatard/UEFI-Shell/releases ). And then you just need a medium and put the shell-binary on it, inside the directory...
OK, so you only have this issue with one out of 4 cards and only after it had previously worked?
If so, which OSes do the cards run? And specifically, did the "failing" one run a different OS than the rest?
It somehow sounds very much like a...
If you can tell us what connection the e1000e Ethernet driver should have to the Kernels ACPI subsystem and the handling of power states...
That message usually indicates, that the system registered an ACPI-interrupt from the power-button, that...
Didn't have much time to read the full thread, but from what I saw, the issue occurs on reboot, right?
If that is the case, then maybe try the kernel commandline parameter "reboot=pci". Just in case the NICs have issues with the standard Linux...