You are not logged in.
Hi,
With the help of the Wiki and reddit, I managed to get PCI passthrough via QEMU and libvirt working just fine from my Arch host to a Windows 10 Pro guest. I was pretty excited at how painless such a seemingly complex procedure was.
But, of course, I was too sanguine. Upon adding my sound card to my mobo, the host system refuses to boot, or even to bring up my dm-crypt prompt. I've tried removing the card, but same thing. All I get upon boot is the "starting version 234" message from systemd. When I enable debug mode in systemd-boot, I get the following as the last lines before the system hangs:
>VFIO - User Level meta-driver version: 0.3
>vfio-pci 0000:01:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=none
I can Ctrl+Alt+Delete a reboot, so it's not a complete system halt, but I can leave it up for an hour with no change. I can't Ctrl-C out of it, either, and it gives me no prompts whatsoever. I can't find a reference to this issue here, on reddit, or anywhere else online.
Anyone have any idea what's going on?
SPECS
* linux 4.12.10-1
* systemd 234.11-8
* libvirt 3.7.0-1
* qemu 2.10.0-1
* nvidia 384.69-2
* Intel i7-7700k @ 4.9
* GTX 1050 @ Stock (Host)
* GTX 1080 Ti @ 2.0 (Guest)
* 16 GB DDR4-3866
* 850 EVO 1TB
Offline
The intel i7-7700k normally comes wtih an intel integrated graphics chipset , and the address 0000:01:00.0 is often used by such devices.
Maybe bios/uefi firmware settings were changed when the sound card was added.
The system could be running fine, just displaying things on an ouput that's not connected to a monitor.
Can you connect over ssh ?
If not, verify whether integrated graphics related settings have changed and try reverting them.
(temp blacklisting vfio-pci or booting AL install iso might also help)
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Hey, thanks for the reply. Internet and power have been spotty during the hurricance. I managed to get it booting by booting the AL install USB, commenting out the VFIO modules, and regenerating the kernel. So, I now have a bootable system. Unfortunately, whenever I re-enable the VFIO modules, I get exactly the same error, despite the fact that the vendor device IDs for my Ti and its audio are the same as always. Any clue what could be causing a system that handled passthrough perfectly well to suddenly...stop?
Last edited by Fitzwilliam (2017-09-12 04:08:56)
Offline
A change in cgroups seems most likely.
Those could originate from a kernel change, or firmware (possibly triggered by the addition of the sound card) .
For now i suggest you create multiple options in your bootloader, you need atleast one option that boots without anything vfio related as a fallback choice.
Is this an uefi or bios system ?
post lspci -k .
Last edited by Lone_Wolf (2017-09-12 13:56:57)
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline