[vfio-users] OVMF: Boots only first time after driver installation

[Alex Williamson]

On Wed, Jan 6, 2016 at 12:05 PM, S B <sb9sb0 at gmail.com> wrote:

> Thank you, I gziped the files, because they are really huge.
> 21734 is the first working boot.
> 21819 is the second boot, which does not work.
>

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.

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.

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:

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')
2) Boot the VM fully and shut it down, again report the same lspci output
3) Attempt to start the VM again, report the behavior, report anything new
in dmesg and again lspci output
4) Include the qemu commandline used for all of this as well

Thanks,
Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/vfio-users/attachments/20160106/963f4a00/attachment.htm>