RE: Hyper-V networking: problem after upgrade to 10.2
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 guest, and is the order determined at boot time. Something completely different: maybe you can point me to an explanation of these messages when I boot: calcru: runtime went backwards from 1672 usec to 845 usec for pid 144 (adjkerntz) calcru: runtime went backwards from 5 usec to 2 usec for pid 7 (pagezero) calcru: runtime went backwards from 126 usec to 63 usec for pid 4 (sctp_iterator) calcru: runtime went backwards from 6920 usec to 3743 usec for pid 3 (fdc0) calcru: runtime went backwards from 33080 usec to 16732 usec for pid 13 (geom) calcru: runtime went backwards from 12117 usec to 6318 usec for pid 1 (init) calcru: runtime went backwards from 155335 usec to 104098 usec for pid 0 (kernel) I happens since I virtualized the server. Again, I thank you very much for the help. And, of course, especially for the fix! With kind regards, Jac Van: Dexuan Cui [mailto:de...@microsoft.com] Verzonden: donderdag 4 februari 2016 7:01 Aan: Jac Backus; Sephe Qiao (Wicresoft); Kylie Liang; 'freebsd-virtualization@freebsd.org'; BSD Integration Components for Hyper-V Onderwerp: RE: Hyper-V networking: problem after upgrade to 10.2 Hi Jac, The easiest way to get the fixes is just using the latest stable/10 branch as I mentioned in another mail. Alternatively, if you want to use your local 10.2 source code in /usr/src/ + the fixes only, please read the below: I put the 10.2-specific fixes onto my github branch "decui/10.2/fix_mac_order" (please see the top 2 patches) : https://github.com/dcui/freebsd/commits/decui/10.2/fix_mac_order (I resolved a small code conflict) I verified the 2 patches could be cleanly applied to a clean installation of 10.2 VM: [root@decui-bsd102 /usr/src]# pwd /usr/src [root@decui-bsd102 /usr/src]# wget https://github.com/dcui/freebsd/commit/b706b383da285376554bcb69f44c4cc10270de24.patch --2016-02-04 13:37:04-- https://github.com/dcui/freebsd/commit/b706b383da285376554bcb69f44c4cc10270de24.patch Resolving github.com (github.com)... 192.30.252.131 Connecting to github.com (github.com)|192.30.252.131|:443... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/plain] Saving to: 'b706b383da285376554bcb69f44c4cc10270de24.patch.1' b706b383da285376554bcb69f44c4cc10270de24.pa [ <=> ] 7.13K --.-KB/s in 0.006s 2016-02-04 13:37:05 (1.22 MB/s) - 'b706b383da285376554bcb69f44c4cc10270de24.patch.1' saved [7297] [root@decui-bsd102 /usr/src]# patch -sp1 < b706b383da285376554bcb69f44c4cc10270de24.patch [root@decui-bsd102 /usr/src]# wget https://github.com/dcui/freebsd/commit/2bff041dbed26b5da88c4be72b4701bbf6c460cd.patch --2016-02-04 13:37:26-- https://github.com/dcui/freebsd/commit/2bff041dbed26b5da88c4be72b4701bbf6c460cd.patch Resolving github.com (github.com)... 192.30.252.129 Connecting to github.com (github.com)|192.30.252.129|:443... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/plain] Saving to: '2bff041dbed26b5da88c4be72b4701bbf6c460cd.patch.1' 2bff041dbed26b5da88c4be72b4701bbf6c460cd.pa [ <=> ] 4.22K --.-KB/s in 0.003s 2016-02-04 13:37:27 (1.31 MB/s) - '2bff041dbed26b5da88c4be72b4701bbf6c460cd.patch.1' saved [4323] [root@decui-bsd102 /usr/src]# patch -sp1 < 2bff041dbed26b5da88c4be72b4701bbf6c460cd.patch [root@decui-bsd102 /usr/src]# If the related files in your /usr/src/sys/dev/hyperv/ were messed up by the previous failed patch commands, you can replace the files with the version here (https://github.com/dcui/freebsd/tree/decui/10.2/fix_mac_order/sys/dev/hyperv. You can use the "Raw" format functionality to get the related URLs of the files and use 'wget' to get them): sys/dev/hyperv/include/hyperv.h sys/dev/hyperv/vmbus/hv_channel_mgmt.c sys/dev/hyperv/vmbus/hv_vmbus_drv_freebsd.c sys/dev/hyperv/vmbus/hv_vmbus_priv.h Please let me know if this will work for you. Thanks, -- Dexuan From: Jac Backus [mailto:j.bac...@bugworks.com] Sent: Thursday, February 4, 2016 7:18 To: Dexuan Cui mailto:de...@microsoft.com>>; Sephe Qiao (Wicresoft) mailto:v-yan...@microsoft.com>>; Kylie Liang mailto:kyl...@microsoft.com>>; 'freebsd-virtualization@freebsd.org' mailto:freebsd-virtualization@freebsd.org>>; BSD Integration Components for Hyper-V mailto:bs...@microsoft.com>> Subject: RE: Hyper-V networking: problem after upgrade to 10.2 Hello Dexuan, The first patch gives no messages. When trying the second: 112 # patch -sp1 < 1e469c559048fe6ec3641da3bb21ab87215c6506.patch 1 out of 7 hunks failed--saving rejects to sys/
RE: Hyper-V networking: problem after upgrade to 10.2
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., supposing the VM has 2 NICs (NIC1 with MAC1 and NIC2 with
MAC2), 2 kernel threads (FreeBSD's taskqueues) are created to register the NICs
concurrently; if sometimes NIC1 is registered first, NIC1 will be "hn0"and
sometimes if NIC2 is registered first, NIC2 will be "hn0"...
My fixes make sure the proper serialization, so now we can make sure NIC1 is
always registered before NIC2.
About another issue ("calcru: runtime went backwards"), I made a fix recently:
https://reviews.freebsd.org/D5174. Please try it.
I'm trying to push this fix to the Head branch.
Thanks,
-- Dexuan
From: Jac Backus [mailto:j.bac...@bugworks.com]
Sent: Friday, February 5, 2016 15:55
To: Dexuan Cui ; Sephe Qiao (Wicresoft)
; Kylie Liang ;
'freebsd-virtualization@freebsd.org' ; BSD
Integration Components for Hyper-V
Subject: RE: Hyper-V networking: problem after upgrade to 10.2
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 guest,
and is the order determined at boot time.
Something completely different: maybe you can point me to an explanation of
these messages when I boot:
calcru: runtime went backwards from 1672 usec to 845 usec for pid 144
(adjkerntz)
calcru: runtime went backwards from 5 usec to 2 usec for pid 7 (pagezero)
calcru: runtime went backwards from 126 usec to 63 usec for pid 4
(sctp_iterator)
calcru: runtime went backwards from 6920 usec to 3743 usec for pid 3 (fdc0)
calcru: runtime went backwards from 33080 usec to 16732 usec for pid 13 (geom)
calcru: runtime went backwards from 12117 usec to 6318 usec for pid 1 (init)
calcru: runtime went backwards from 155335 usec to 104098 usec for pid 0
(kernel)
I happens since I virtualized the server.
Again, I thank you very much for the help. And, of course, especially for the
fix!
With kind regards,
Jac
Van: Dexuan Cui [mailto:de...@microsoft.com]
Verzonden: donderdag 4 februari 2016 7:01
Aan: Jac Backus; Sephe Qiao (Wicresoft); Kylie Liang;
'freebsd-virtualization@freebsd.org'; BSD Integration Components for Hyper-V
Onderwerp: RE: Hyper-V networking: problem after upgrade to 10.2
Hi Jac,
The easiest way to get the fixes is just using the latest stable/10 branch as I
mentioned in another mail.
Alternatively, if you want to use your local 10.2 source code in /usr/src/ +
the fixes only, please read the below:
I put the 10.2-specific fixes onto my github branch "decui/10.2/fix_mac_order"
(please see the top 2 patches) :
https://github.com/dcui/freebsd/commits/decui/10.2/fix_mac_order (I resolved a
small code conflict)
I verified the 2 patches could be cleanly applied to a clean installation of
10.2 VM:
[root@decui-bsd102 /usr/src]# pwd
/usr/src
[root@decui-bsd102 /usr/src]# wget
https://github.com/dcui/freebsd/commit/b706b383da285376554bcb69f44c4cc10270de24.patch
--2016-02-04 13:37:04--
https://github.com/dcui/freebsd/commit/b706b383da285376554bcb69f44c4cc10270de24.patch
Resolving github.com (github.com)... 192.30.252.131
Connecting to github.com (github.com)|192.30.252.131|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/plain]
Saving to: 'b706b383da285376554bcb69f44c4cc10270de24.patch.1'
b706b383da285376554bcb69f44c4cc10270de24.pa [ <=>
] 7.13K --.-KB/s
in 0.006s
2016-02-04 13:37:05 (1.22 MB/s) -
'b706b383da285376554bcb69f44c4cc10270de24.patch.1' saved [7297]
[root@decui-bsd102 /usr/src]# patch -sp1 <
b706b383da285376554bcb69f44c4cc10270de24.patch
[root@decui-bsd102 /usr/src]# wget
https://github.com/dcui/freebsd/commit/2bff041dbed26b5da88c4be72b4701bbf6c460cd.patch
--2016-02-04 13:37:26--
https://github.com/dcui/freebsd/commit/2bff041dbed26b5da88c4be72b4701bbf6c460cd.patch
Resolving github.com (github.com)... 192.30.252.129
Connecting to github.com (github.com)|192.30.252.129|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/plain]
Saving to: '2bff041dbed26b5da88c4be72b4701bbf6c460cd.patch.1'
2bff041dbed26b5da88c4be72b4701bbf6c460cd.pa [ <=>
] 4.22K --.-KB/s
in 0.003s
2016-02-04 13:37:27 (1.31 MB/s) -
'2bff041dbed26b5da88c4be72b4701bbf6c460cd.patch.1' saved [4323]
[root@decui-bsd102 /usr/src]# patch -sp1 <
2bff041dbed26b5da88c4be72b4701bbf6c460cd.patch
[root@decui-bsd102 /usr/src]#
If the related files in your /usr/sr
[Differential] [Accepted] D5185: tcp/lro: Allow network drivers to set the limit for TCP ACK/data segment aggregation limit
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, network, adrian, delphij, royger, decui_microsoft.com, honzhan_microsoft.com, howard0su_gmail.com, hselasky, np, transport, gallatin Cc: freebsd-virtualization-list, freebsd-net-list ___ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
[Differential] [Accepted] D5185: tcp/lro: Allow network drivers to set the limit for TCP ACK/data segment aggregation limit
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_microsoft.com, howard0su_gmail.com, hselasky, np, transport, gallatin, adrian, network Cc: freebsd-virtualization-list, freebsd-net-list ___ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
[Differential] [Commented On] D5185: tcp/lro: Allow network drivers to set the limit for TCP ACK/data segment aggregation limit
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.freebsd.org/settings/panel/emailpreferences/ To: sepherosa_gmail.com, delphij, royger, decui_microsoft.com, honzhan_microsoft.com, howard0su_gmail.com, hselasky, np, transport, gallatin, adrian, network Cc: freebsd-virtualization-list, freebsd-net-list ___ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
[Differential] [Commented On] D5185: tcp/lro: Allow network drivers to set the limit for TCP ACK/data segment aggregation limit
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 any drawbacks to change these two fields into unsigned int? If not, I would change them into unsigned int after Chinese New Year :) 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_microsoft.com, howard0su_gmail.com, hselasky, np, transport, gallatin, adrian, network Cc: freebsd-virtualization-list, freebsd-net-list ___ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
