Date: Tue, 23 Feb 2016 21:30:45 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-amd64@FreeBSD.org Subject: [Bug 207446] Hang bringing up vtnet(4) on >8 cpu GCE VMs Message-ID: <bug-207446-6@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207446 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 Severity: Affects Only Me Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: wac@google.com CC: freebsd-amd64@FreeBSD.org CC: freebsd-amd64@FreeBSD.org Created attachment 167336 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D167336&action= =3Dedit patch to sys/dev/virtio/network/if_vtnetvar.h FreeBSD on Google Compute Engine currently requires "hw.vtnet.mq_disable=3D= 1" on virtual machines of more than 8 CPUs to avoid a hang when bringing up the v= tnet interface. I have prepared a patch which raises the VTNET_MAX_QUEUE_PAIRS to 64 which solves this hang on GCE VMs with 64 or fewer CPUs.=20 With this patch, the release engineer should be able to remove the hw.vtnet.mq_disable line from the /boot/loader.conf that is placed in images intended for Google Compute Engine and users should see the benefits of multiqueue as a result. The current limit of 8 is in CURRENT as well as earlier release branches (e= .g. stable/10). --=20 You are receiving this mail because: You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-207446-6>