Hello Dexuan,
I build a new kernel and the problem is gone.
I tried to understand your description of the patch. What I find remarkable is,
that there is apparently no fixed relation between the virtual nics defined in
Hyper-V (with a fixed mac address) and the devices, hn0, hn1, etc in the gue
Hi Jac,
Thanks for confirming the fixes!
Please let me explain the issue a little more. The issue exists in the VMBus
driver. Since the network driver depends on the VMBus driver, we have the issue.
The issue is: the VMBus doesn't guarantee the serialization of registering
multiple NICs, e.g., s
gallatin accepted this revision.
gallatin added a comment.
Thanks for addressing my concerns.. Does anybody else want to comment?
REVISION DETAIL
https://reviews.freebsd.org/D5185
EMAIL PREFERENCES
https://reviews.freebsd.org/settings/panel/emailpreferences/
To: sepherosa_gmail.com, net
adrian accepted this revision.
adrian added a comment.
Nice! Thanks for all this work!
REVISION DETAIL
https://reviews.freebsd.org/D5185
EMAIL PREFERENCES
https://reviews.freebsd.org/settings/panel/emailpreferences/
To: sepherosa_gmail.com, delphij, royger, decui_microsoft.com,
honzhan_
hselasky added inline comments.
INLINE COMMENTS
sys/netinet/tcp_lro.h:94 Might be worth set this limit to unsigned instead of
unsigned short. Technically we can LRO more than 64KBytes worth of data!
REVISION DETAIL
https://reviews.freebsd.org/D5185
EMAIL PREFERENCES
https://reviews.freebs
sepherosa_gmail.com added inline comments.
INLINE COMMENTS
sys/netinet/tcp_lro.h:94 My intention here is too keep the size of lro_ctrl
unchanged on amd64 (I think there is an implicit 4 bytes padding after
lro_mbuf_max :). But I am fine to change them into unsigned int.
Does anyone know
