https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207446
Mark Linimon changed:
What|Removed |Added
CC|freebsd-amd64@FreeBSD.org |
--
You are
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207446
--- Comment #10 from Andy Carrel ---
The patch boots and functions successfully when applied to a releng/10.3 kernel
on GCE, which fixes the problems I was observing originally. It also does the
right thing with
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207446
--- Comment #9 from Andy Carrel ---
I definitely prefer the requested vs. max terminology in your patch.
Ultimately we just need to make sure that the initialization here...
> 891 if (sc->vtnet_flags &
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207446
Steven Hartland changed:
What|Removed |Added
CC|
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207446
Mark Linimon changed:
What|Removed |Added
Keywords||patch
--
You
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207446
--- Comment #6 from Andy Carrel ---
After further investigation it looks like the driver is accidentally using
driver's vtnet_max_vq_pairs*2 + 1 for the control virtqueue instead of device's
max_virtqueue_pairs*2 + 1.
I'm
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207446
--- Comment #5 from Bryan Venteicher ---
(In reply to Jon Olson from comment #4)
The issue appears that GCE doesn't work when the guest driver requests fewer
than device's advertised max number of queue pairs. The
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207446
Glen Barber changed:
What|Removed |Added
Assignee|g...@freebsd.org |r...@freebsd.org
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207446
Glen Barber changed:
What|Removed |Added
Assignee|r...@freebsd.org
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207446
Bug ID: 207446
Summary: Hang bringing up vtnet(4) on >8 cpu GCE VMs
Product: Base System
Version: 10.3-BETA2
Hardware: amd64
OS: Any
Status: New
10 matches
Mail list logo