Date: Wed, 31 Jul 2019 15:27:41 +0000 From: bugzilla-noreply@freebsd.org To: virtualization@FreeBSD.org Subject: [Bug 239118] in ESXi: Panic in ether_output_frame Message-ID: <bug-239118-27103-UWoAAIqiBl@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-239118-27103@https.bugs.freebsd.org/bugzilla/> References: <bug-239118-27103@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D239118 --- Comment #7 from Marius Strobl <marius@FreeBSD.org> --- I'd say that with an INTx-type interrupt or a single MSI vector, i. e. all = the "legacy" interrupt support iflib is about, there's just no other way than to operate in combined RXTX mode (as opposed to multiple MSI-X vectors which c= an be associated to either RX or TX on a per-vector basis). Thus, - as actually already written in my private e-mail to pkelsey@ and the submitter on June 25th - I fully agree with markj@ analysis that vmxnet3_isc_txd_credits_update() currently isn't reentrant as well as with = his fix (I'd probably code it to be more in line with the index updating in vmxnet3_isc_rxd_available(), though). However, as I also already wrote in said e-mail, on top of that it isn't obvious to me that it's safe to update txc->vxcr_next and txc->vxcr_gen non-atomically/lockless since r343291 dropped the locking around these operations. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-239118-27103-UWoAAIqiBl>