I had already done some quick testing of the previous version earlier, but today I rebased this patch onto the latest version and applied it to the 16.0-CURRENT sources to do some testing.

A branch on github is available here to ease merge: https://github.com/stormshield-acazuc/freebsd-src/tree/bnxt_csum

Test for temp record is included into https://reviews.freebsd.org/D53299

In D49459#1213490, @zarychtam_plan-b.pwste.edu.pl wrote:

Are the tests that hard to add, or perhaps can it be proceeded with further without them?

Are the tests that hard to add, or perhaps can it be proceeded with further without them?

Stuck on athn_usb_detach code or executes athn_usb_stop multiple times
I suspect this is due to the msleep on one threat and a wakeup on another, but I am not certain how to isolate the problem.

Abandoning because it's already fixed.

In D47410#1137166, @ziaee wrote:

Hey Damjan. Are you still interested in this? Your latest patch is just removing those blocks. Please squash your commits into one and try remaking the patch. If not, please close this. Thanks for your submission!

Thank you for this fix. Works fine with Netlink.

Current Problem: Running into a recursive mutex based on FreeBSD/OpenBSD mutex styles.

Working to update the athn_usb_init, currently working through the newstate handler.

In D49884#1137462, @imp wrote:

In D49884#1137457, @lwhsu wrote:

I think the current idea is avoiding directly import firmware file into repo. Perhaps we can separate the firmware out. The current approach is using firmware ports/pkg, before having that, we can just put it somewhere and ask people to grab it and put to the required place, for testing.

Or point them at the linux wireless firmware archive repo....

In D49884#1137457, @lwhsu wrote:

I think the current idea is avoiding directly import firmware file into repo. Perhaps we can separate the firmware out. The current approach is using firmware ports/pkg, before having that, we can just put it somewhere and ask people to grab it and put to the required place, for testing.

I think the current idea is avoiding directly import firmware file into repo. Perhaps we can separate the firmware out. The current approach is using firmware ports/pkg, before having that, we can just put it somewhere and ask people to grab it and put to the required place, for testing.

Hey Damjan. Are you still interested in this? Your latest patch is just removing those blocks. Please squash your commits into one and try remaking the patch. If not, please close this. Thanks for your submission!

In D49677#1132641, @tuexen wrote:

If I understand the patch correctly, it contains three components:

• the fix by replacing in_delayed_cksum(m) with in_delayed_cksum_o(m, ipofs) in ng_nat.c.
• adding protection code which logs a warning.
• refactoring the code to remove indentation by using goto send.

It might be useful to separate these three when committing the code.

If I understand the patch correctly, it contains three components:

• the fix by replacing in_delayed_cksum(m) with in_delayed_cksum_o(m, ipofs) in ng_nat.c.
• adding protection code which logs a warning.
• refactoring the code to remove indentation by using goto send.

It might be useful to separate these three when committing the code.

printf() -> log(). Fix type mismatch.

Fix error message.

Fix mismerge.

Thank you for working on this! Can we add tests here?

I vastly under appreciated that folks rely upon the ng_eiface not moving with the struct ifnet. Probably because I've been using them in jails for over a decade and only recently noticed myself.

In D49158#1121374, @zec wrote:

Your obsession with getting rid of the "flawed" if_vmove() is noted, but for the sake of other people who may have a different view, and who have applications relying on this very concept for 20+ years, please do not take that route.

In D49158#1121338, @glebius wrote:

I do not like the plan. The picture drawn shows that a netgraph node in one vnet is connected to a node in a different vnet. This is basically a violation of the idea of vnet. Virtualized stacks should communicate with each other via network protocols, not kernel pointers. The only legal exclusion is epair(4).