as i said, e.g. sometimes a device passthrough needs to be passed through as 'pcie express' device which is only available on q35
for this the machine type should not make any difference
why not? AFAIR the card only supports bios not uefi because it's so old. could you try with a different vm just to test? that way we can rule out any guest specific problems
sadly i can't really help for the specific example as i don't have an arc 310 gpu here to test, but in general there are two drivers involved in linux
1. the kernel part driver (i.e. i915/xe for the intel arc)
2. the userland driver (mesa)
the kernel driver is baked into the kernel (most of...
one possiblitiy is to boot the host in "single user mode" (similar to https://pve.proxmox.com/wiki/Root_Password_Reset but without the password reset)
this should give a root shell where you can reconfigure your network config
hi,
what exactly do you mean with this? if a vm is shut off, the vm is not running, so the card is not 'bound' to the vm anymore
do you mean you want to rebind it to the 'nvidia' driver after a vm shutdown?
what do you mean here/where does it say this?
it could work, but the containers would...
could you try with seabios instead of ovmf ? did you install the os before passing through the gpu?
is there anything intesting in the journal during time of vm boot?
could you also try to boot some live linux iso to see if the boot disk is the problem?
yes bisecting with the zfs bits intact is indeed much harder, I never did it myself yet... If you still want to do that, I'd have to go investigate a bit and come back with a short guide on how to do that, but not sure when I have time for that sadly
yes, i wanted the output with the broken state. Since i could not reproduce it yet here, it would be good if anybody affected could post the info i requested, so we can properly fix it here (instead of just restoring the old "wrong" code where it works)
if somebody could try to apply the following patch: https://lore.proxmox.com/pve-devel/20241105092421.774448-2-d.csapak@proxmox.com/
it would be interesting which file_write has what exact error in the task log when starting & failing with 'cannot bind to vfio-pci'
@ozioh thanks for the output. This is super strange, since it seems that the device is already bound to the vfio-pci driver. could you confirm that this is the case also after the first reboot?
if not, is it bound to the vfio-driver after a failed start attempt?
das sollte potentiell mit dem 'export' feature vom tape backup job funktionieren, vorraussetzung ist dass der mail-slot auch als slot sichtbar und als export slot in der config markiert ist
thanks for trying to tackling this.
AFAIU you shouldn't need to change commits in the pve-kernel git itself, only in the submodule
if you don't need zfs, then you could also simply building the submodule itself
you'd need to copy a kernel config file to the submodule as '.config' , and then...
ok, so after looking through the changes, i could not see a commit that would stand out which could cause this (no kernel expert here though)
also i don't think we currently have any spare hardware here that matches with which we could try to reproduce that
if you're motivated though, you...
no i'm not and it may be entirely unrelated ;) it's just what i noticed is different.
it could also of course be some kernel change that does not produce any different dmesg output and this is just a red herring.
is that guest a linux or windows vm? is there any log output there that might...
mhmm can you post your vm config and `lspci -nnk` output ?
i find it weird that it cannot bind to vfio-pci, while that is AFAIK a requirement for it to work with passthrough in qemu...
could you maybe post the exact error you encountered when it failed? We did recently change some internals on how we detect errors, and it seems some things are not necessary, so i just want to make sure which parts we should take care of differently
ok, so after sorting out the diffs between the two boots, there are the following relevant differences (sans address/etc changes):
on the 6.8.12 is missing the following lines:
PCI: not using ECAM ([mem 0xf0000000-0xf7ffffff] not reserved)
PCI: Using configuration type 1...
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.