Hi Rajil,
Is this specific to hardware or linux distribution ?
Possibly both.
The PCI device reset change that I mentioned earlier is
https://svnweb.freebsd.org/base?view=revision=306520
If you upgrade to 11-stable you should be able to pick it up and see
if it helps.
later,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203682
John Baldwin changed:
What|Removed |Added
CC||j...@freebsd.org
On Nov 7, 2016 2:01 PM, "Peter Grehan" wrote:
>
> Hi Rajil,
>
>
>>> I tried with the second onboard NIC and it worked the first time. iperf
>>> showed 10g speeds. After restarting the VM, i get an error for both
>>> NICs.
>
>
> What's the FreeBSD host version ? There was work
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203682
--- Comment #5 from John Baldwin ---
Note that the root issue is probably just that the spin on 'aps_ready' is
expensive to simulate on hypervisors. The vcpu is just going to run
continually until it gets preempted by
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203682
--- Comment #8 from John Baldwin ---
The problem with monitor/mwait is that it has to be emulated by the hypervisor
(you get a VM-exit for it), but that's actually hard to do because the
hypervisor can't tell when the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203682
--- Comment #7 from Marcel Moolenaar ---
(In reply to John Baldwin from comment #5)
Very possible. Maybe this theory be validated by using the monitor and mwait
instructions on recent CPUs?
--
You are receiving this
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203682
--- Comment #6 from Marcel Moolenaar ---
(In reply to John Baldwin from comment #4)
I can confirm that this solves/addresses the problem sufficiently.
A 4 core VM with the EFI frame buffer boots what appears to be
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210044
d...@rabson.org changed:
What|Removed |Added
Status|New |Closed
Resolution|---