<div dir="ltr">Thanks. I'm an idiot. I just replied to the email directly after the subscription and wasn't paying attention. Thank you for correcting it.<div><br></div><div>I was originally running 3.13.0-86-generic upgraded to the 3.19 version to try before I posted this, but got the same results. I'll try a newer version of the kernel and see what happens.</div><div><br></div><div>Sorry to be dense but what do you mean by "retrain properly"? I assume you mean that once it fails to reset it just never recovers? </div><div><br></div><div>We have 2 other machines that I've never seen this problem with so what what you are saying makes sense. This system does have a slightly more specialized PCI bus to be able to stick 8 cards on a single bus (at least that is my understanding), so at this point, either I'm hitting a bug that is fixed in the kernel, or this PCI bus is not doing something that vfio-pci is expecting (would be my speculation).</div><div><br></div><div>I'll report back my findings tomorrow. </div><div><br></div><div>Thanks for the help.</div><div><br></div><div>-Kevin</div><div><br></div><div><br></div><div><br><div><br></div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 17, 2016 at 5:53 PM, Alex Williamson <span dir="ltr"><<a href="mailto:alex.williamson@redhat.com" target="_blank">alex.williamson@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">(generally a good idea to have a useful subject line)<br>
<br>
On Mon, 17 Oct 2016 16:26:15 -0500<br>
Kevin Vasko <<a href="mailto:kvasko@gmail.com">kvasko@gmail.com</a>> wrote:<br>
><br>
> Any suggestions on debugging a !!! Unknown header type 7f?<br>
><br>
<br>
This usually means that the device didn't come back from bus reset and<br>
re-reading the PCI config space where the device was just gives a -1<br>
response.  lspci tries to interpret that bogus data and gives results<br>
like you see.  You might try a newer kernel, we've probably fixed some<br>
things in the bus reset path since v3.19.  It looks like you continue<br>
to see the bogus data once it gets into this state, so it's probably<br>
not a "simple" device coming out of reset too slowly problem.  Possibly<br>
the PCIe link doesn't retrain properly sometimes after a bus reset.  If<br>
a new kernel doesn't help, I could give you instructions for performing<br>
a bus reset with setpci and you could test how reliably you can reset<br>
the device and read config space after.  Thanks,<br>
<br>
Alex<br>
</blockquote></div><br></div></div></div>