<div dir="ltr"><br>So, this time I mixed up arch linux guest with win8 guest.<br><br><br>lspci -vvvxxxx > lspci_1<br><br>/usr/bin/qemu-system-x86_64 <br> -enable-kvm -M pc-i440fx-2.4 -cpu host,kvm=off -smp 3,sockets=1,cores=3,threads=1 -m 4096 <br> -soundhw hda -serial none -parallel none -name Wingame -rtc base=localtime -redir tcp:22::22 -vga none -nographic -display none <br> -device vfio-pci,host=01:00.0,addr=09.0,multifunction=on <br> -device vfio-pci,host=01:00.1,addr=09.1 <br> -drive if=pflash,format=raw,readonly,file=/root/qemu/win8/OVMF_CODE-pure-efi.fd <br> -drive if=pflash,format=raw,file=/root/qemu/win8/my_vars.fd <br> -readconfig /root/qemu/config/ich9-ehci-uhci.cfg <br> -device usb-host,vendorid=0x0079,productid=0x0006 <br> -device usb-host,vendorid=0x045e,productid=0x028e <br> -device usb-host,vendorid=0x062a,productid=0x0252 <br> -device usb-host,vendorid=0x04f3,productid=0x0103 <br> -drive file=/root/qemu/arch.qcow2,id=win,format=qcow2,if=none <br> -device ide-hd,bus=ide.0,drive=win <br> -boot c<br><br>The arch linux guest is working fine.<br>The new dmesg output is in dmesg_cmd_1<br><br>lspci -vvvxxxx > lspci_2<br><br>/usr/bin/qemu-system-x86_64 <br> -enable-kvm -M pc-i440fx-2.4 -cpu host,kvm=off -smp 3,sockets=1,cores=3,threads=1 -m 4096 <br> -soundhw hda -serial none -parallel none -name Wingame -rtc base=localtime -vga none -nographic -display none <br> -device vfio-pci,host=01:00.0,addr=09.0,multifunction=on <br> -device vfio-pci,host=01:00.1,addr=09.1 <br> -drive if=pflash,format=raw,readonly,file=/root/qemu/win8/OVMF_CODE-pure-efi.fd <br> -drive if=pflash,format=raw,file=/root/qemu/win8/my_vars.fd <br> -readconfig /root/qemu/config/ich9-ehci-uhci.cfg <br> -device usb-host,vendorid=0x0079,productid=0x0006 <br> -device usb-host,vendorid=0x045e,productid=0x028e <br> -device usb-host,vendorid=0x062a,productid=0x0252 <br> -device usb-host,vendorid=0x04f3,productid=0x0103 <br> -drive file=/root/qemu/win8/win8.qcow2,id=win,format=qcow2,if=none <br> -device ide-hd,bus=ide.0,drive=win <br> -boot c<br><br>The win8 guest is working fine.<br>The new dmesg output is in dmesg_cmd_2<br><br>lspci -vvvxxxx > lspci_3<br><br>Now I start the first qemu command again. The screen stays off, I can ssh to the VM and shut it down. qemu outputs:<br>qemu-system-x86_64: vfio-pci: Unable to power on device, stuck in D3<br>qemu-system-x86_64: vfio-pci: Unable to power on device, stuck in D3<br>qemu-system-x86_64: vfio-pci: Unable to power on device, stuck in D3<br>qemu-system-x86_64: vfio-pci: Unable to power on device, stuck in D3<br>qemu-system-x86_64: vfio-pci: Cannot read device rom at 0000:01:00.0<br>Device option ROM contents are probably invalied (check dmesg).<br>Skip option ROM probe with rombar=0, or load from file with romfile=<br><br><br>The new dmesg output is in dmesg_cmd_3<br>lspci -vvvxxxx > lspci_4<br><br><br>I start the second qemu command again. The VM is not starting. qemu outputs<br>qemu-system-x86_64: -device vfio-pci,host=01:00.0,addr=09.0,multifunction=on: vfio: Error failed to setup INTx fd: Device or resource busy<br>qemu-system-x86_64: -device vfio-pci,host=01:00.0,addr=09.0,multifunction=on: Device initialization failed<br><br><br>The new dmesg output is in dmesg_cmd_4<br>lspci -vvvxxxx > lspci_5<br><br><br>If I start one of the commands again, the behavior stays the same.<br></div><div class="gmail_extra"><br><div class="gmail_quote">2016-01-06 22:31 GMT+01:00 Alex Williamson <span dir="ltr"><<a href="mailto:alex.l.williamson@gmail.com" target="_blank">alex.l.williamson@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Wed, Jan 6, 2016 at 12:05 PM, S B <span dir="ltr"><<a href="mailto:sb9sb0@gmail.com" target="_blank">sb9sb0@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Thank you, I gziped the files, because they are really huge.<br></div>21734 is the first working boot.<br></div>21819 is the second boot, which does not work.</div></blockquote><div><br></div></span><div>I think these are really only useful along with the trace-events file from your build tree, but if I knew you were just going to throw them up on the mailing list I would have discouraged it altogether. This kind of tracing is mostly useful if the person with the problem intends to do the debugging, so you can tell what point things happen, make changes and try something else. Imagine running strace on your browser and asking someone to tell you why a web page doesn't render properly from the logs, that's about the same degree of complexity.</div><div><br></div><div>Unfortunately you have a Tonga based GPU, which like Fiji, seems to have some sort of reset problem. We don't really know if the problem is with the hardware or something we're not accounting for when doing a bus reset. I'm talking with AMD about this, but I have no hardware, little time, and it's really not an "enable tracing and spot the problem" kind of issue.</div><div><br></div><div>Some of the errors you've reported seem like the card is dead from a PCI perspective, the stuck in D3 stuff, having capabilities of 0xff and 0xffff, INTx conflicts, etc. could you report the following:</div><div><br></div><div>1) Do a clean boot of the host, do not start the VM, and report the output of 'sudo lspci -vvvxxxx' (that's 3x 'v', not 'w')</div><div>2) Boot the VM fully and shut it down, again report the same lspci output</div><div>3) Attempt to start the VM again, report the behavior, report anything new in dmesg and again lspci output</div><div>4) Include the qemu commandline used for all of this as well</div><div><br></div><div>Thanks,</div><div>Alex</div></div></div></div> </blockquote></div><br></div>