Seem to help against ukbd irqs but the problem is still there. I now discovered how I can get the same behavior in i3 and X.
I did this in xfce4-terminal, don't know if it has to be that or not. Hold down CTRL (with USB keyboard), press any other key and let go, but hold down CTRL the whole time. Now interrupt storms start on CPU 0 timer.

Done

• Moved radix_tree_iter parts to gplv2 module in kms-drm repo
• Cleaned up style
• Fixed issues pointed out in comments

Thanks for the feedback. Will update the patch.

Improve Makefile. Fix portlint warnings.
Use anonymous shared memory instead of /tmp filesystem because posix_allocated won't work with ZFS.

In D13431#294379, @mat wrote:

What would be the reason behind disabling the SUID option ? (I wonder why the option is there exactly.)

Fix config sample file naming and update checksum.

Changed maintainer and fixed indent.

Does this need the wlc update from https://bugs.freebsd.org/224202 ?

Thanks for the feedback!
Sorry the previous patch was a bit old. I updated and fixed according to recommendations.

Add Sway to x11-wm Makefile

Update to Weston 3.0

• Minor fixes for IPv6
• Fixed a bug that caused non-wildcard IP address sockets to not function properly

• Add support for IPv6 (but not IPv4-mapped IPv6 addresses)
• Change to M_NOWAIT in lbgroup malloc to solve non-sleepable lock issue
• Removed some old printfs.

In D11003#259152, @j-nitrology.com wrote:

I believe we need to update cddl/lib/libdtrace/tcp.d with this change also:

Update libdtrace with changes to struct field names.

Fix build error.

Remove debug printing and clean up whitespace diffs. Applies cleanly to master branch as of 20170915.
Branch with this patch can be found here:
https://github.com/johalun/freebsd/tree/master-socket-loadbalancer

In D12140#253587, @kmacy wrote:

In D12140#252557, @johalun0_gmail.com wrote:

I did a clean world+kernel build on iflib/netmap_rx branch.

Running pkt-gen -i em1 -f rx on receiver and pkt-gen -i em1 -f tx on the sender results in crash on receiver.
(sender and receiver two different machines connected back to back on em1)

db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe03668b2510
vpanic() at vpanic+0x19c/frame 0xfffffe03668b2590
kassert_panic() at kassert_panic+0x126/frame 0xfffffe03668b2600
em_isc_rxd_pkt_get() at em_isc_rxd_pkt_get+0xf1/frame 0xfffffe03668b2670
iflib_netmap_rxsync() at iflib_netmap_rxsync+0x235/frame 0xfffffe03668b2770
netmap_poll() at netmap_poll+0x79c/frame 0xfffffe03668b2870
freebsd_netmap_poll() at freebsd_netmap_poll+0x32/frame 0xfffffe03668b28a0
devfs_poll_f() at devfs_poll_f+0x7f/frame 0xfffffe03668b2900
kern_poll() at kern_poll+0x4fc/frame 0xfffffe03668b2aa0
sys_poll() at sys_poll+0x50/frame 0xfffffe03668b2ac0
amd64_syscall() at amd64_syscall+0x79b/frame 0xfffffe03668b2bf0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe03668b2bf0
--- syscall (209, FreeBSD ELF64, sys_poll), rip = 0x800daf2aa, rsp = 0x7fffdfff9e78, rbp = 0x7fffdfff9eb0 ---
KDB: enter: panic
[ thread pid 828 tid 100177 ]
Stopped at      kdb_enter+0x3b: movq    $0,kdb_why

However, if I limit the rate of packets I like so
pkt-gen -i em1 -f rx on receiver and pkt-gen -i em1 -f tx -R 100 on the sender
the receiver stops receiving packets after ~600 packets or so (6 batches received), after that rate on receiver goes to zero but does not crash.

Breaking the process might result in crash:

cpuid = 2                 
time = 1504082223         
KDB: stack backtrace:     
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe02398c0730                           
vpanic() at vpanic+0x19c/frame 0xfffffe02398c07b0   
kassert_panic() at kassert_panic+0x126/frame 0xfffffe02398c0820                                          
iflib_fl_bufs_free() at iflib_fl_bufs_free+0x1c2/frame 0xfffffe02398c0870                                
iflib_stop() at iflib_stop+0x478/frame 0xfffffe02398c08c0                                                
iflib_netmap_register() at iflib_netmap_register+0x1a4/frame 0xfffffe02398c0900                          
netmap_hw_reg() at netmap_hw_reg+0x2c/frame 0xfffffe02398c0930                                           
netmap_do_unregif() at netmap_do_unregif+0x16a/frame 0xfffffe02398c0960                                  
netmap_priv_delete() at netmap_priv_delete+0x31/frame 0xfffffe02398c0980                                 
netmap_dtor() at netmap_dtor+0x2b/frame 0xfffffe02398c09a0                                               
devfs_destroy_cdevpriv() at devfs_destroy_cdevpriv+0x8b/frame 0xfffffe02398c09c0                         
devfs_close_f() at devfs_close_f+0x65/frame 0xfffffe02398c09f0                                           
closef() at closef+0x1f5/frame 0xfffffe02398c0a80   
closefp() at closefp+0x9f/frame 0xfffffe02398c0ac0  
amd64_syscall() at amd64_syscall+0x79b/frame 0xfffffe02398c0bf0                                          
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe02398c0bf0

igb0 interface works flawlessly at 1.4 Mpps so problem limited to em

@johan_duh.se I've fixed these two panics in my dev branch. Both em and igb work fine for me now. I'll update the patch as soon as you can confirm that you find no further issues.

I did a clean world+kernel build on iflib/netmap_rx branch.

em0@pci0:0:31:6:	class=0x020000 card=0x06db1028 chip=0x156f8086 rev=0x21 hdr=0x00
    device     = 'Ethernet Connection I219-LM'

Tested with netmap's pkt-gen

In D12101#251537, @kmacy wrote:

In D12101#251488, @erj wrote:

In D12101#251426, @johalun0_gmail.com wrote:

In D12101#251279, @johalun0_gmail.com wrote:

The busy waiting would cause 10% CPU usage on my system when no cable connected to em0 (traced to em_if_update_admin_status).
This patch also fixes this. I can no longer detect any unusual CPU usage.

Getting a lot of witness output. Like a few per second or so.

I think this revision depends on D11969. It changes the core lock from a mutex to an sx lock, which would allow sleeping while its held.

Actually the problem is that I didn't completely eliminate the use of mutexes in the OS independent code. Update forthcoming.

In D12101#251279, @johalun0_gmail.com wrote:

The busy waiting would cause 10% CPU usage on my system when no cable connected to em0 (traced to em_if_update_admin_status).
This patch also fixes this. I can no longer detect any unusual CPU usage.

The busy waiting would cause 10% CPU usage on my system when no cable connected to em0 (traced to em_if_update_admin_status).
This patch also fixes this. I can no longer detect any unusual CPU usage.

In D11003#242043, @sepherosa_gmail.com wrote:

In D11003#242017, @kevin.bowling_kev009.com wrote:

@sepherosa_gmail.com does this look good to you now?

Yep :)

socket inheritance
Allow socket inheritance between sockets with SO_REUSEPORT_LB option.
Inspired by https://github.com/DragonFlyBSD/DragonFlyBSD/commit/02ad2f0b874fb0a45eb69750219f79f5e8982272

In D11003#233702, @sepherosa_gmail.com wrote:

In D11003#233679, @johalun0_gmail.com wrote:

In D11003#232523, @sepherosa_gmail.com wrote:

And your implementation actually suffers the same issue as Linux: if any of the listen socket is closed, the sockets on the closed listen socket's accept queue are dropped; but well, that's may be acceptable, since I don't think Linux even fixed that.

Would implementing https://github.com/DragonFlyBSD/DragonFlyBSD/commit/02ad2f0b874fb0a45eb69750219f79f5e8982272 solve this?

Yep.

In D11003#232523, @sepherosa_gmail.com wrote:

And your implementation actually suffers the same issue as Linux: if any of the listen socket is closed, the sockets on the closed listen socket's accept queue are dropped; but well, that's may be acceptable, since I don't think Linux even fixed that.

Duplicate a couple of SO_REUSEPORT checks and do the same for SO_REUSEPORT_LB in 'in_pcb_bindsetup.c'.
Let SO_REUSEPORT_LB set SO_REUSEADDR to fix the "address in use" error earlier mentioned. Testing confirmed that the earlier "possible bug" is now fixed.

Removed graphics/wayland patches since it has already been updated to 1.13

Remove patch for file with only date change.
Cleaned up weston/Makefile

Reordered rows and clean up in weston/Makefile.

To illustrate, I just did a build with the WAYLAND option enabled to compare output from ldd.

Cleaned up weston/Makefile.
Removed xorg-server and gtk30 patches that didn't belong here.

It is not the size of libwayland-egl that was the concern, rather that I expect some amount of complaints about Mesa depending on graphics/wayland. Since Xorg depends on Mesa, that would mean Xorg pulls in Wayland even without Xwayland installed. Maybe I am being overly cautious here, but "Why does Mesa depend on LLVM from ports when the same version is provided by the base system?" is a regularly recurring question, sometimes in the form of a complaint. Let's take a poll during the call today to see what the group thinks the option's default state should be.

That is correct, those who wish to try Wayland will n6eed to build some ports with non-default options. The alternative is worse; making everyone using Xorg/Mesa install parts of Wayland regardless of their intent to use it. Unfortunately, we cannot just split off libwayland-egl.so into it's own package because the WAYLAND option also affects the build of gbm (part of the reason to combine the libs was to have a single WAYLAND option affecting both gbm and EGL). I cannot think of a better solution without support for flavors (which would allow packages for mesa-libs and mesa-libs+wayland) but am open to suggestions.

Changed libglapi dependency from port libglapi -> mesa-libs to conform to consolidated mesa-libs suggested in https://reviews.freebsd.org/D10448

• Can we have mesa-libs also generate libwayland-egl.so?

That is done when the WAYLAND option is enabled.

Hey! Nice work on this.
I have a couple of suggestions that to make way for Wayland.

I agree on both suggestions. Will test and see if works as expected.