[Bug 239351] [panic] spin lock held too long under heavy load (net/wireguard affected)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239351 --- Comment #10 from Evilham --- Created attachment 206050 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=206050&action=edit acttrace_patch_206036 I'm starting to be really glad I opened this bug instead of trying to debug it myself. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 239351] [panic] spin lock held too long under heavy load (net/wireguard affected)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239351 --- Comment #11 from Evilham --- Created attachment 206051 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=206051&action=edit tid_frame_patch206038 # echo -e "tid 100168\nframe 4\np other_cpus\n" | kgdb /boot/kernel/kernel vmcore.2 > tid_frame_patch20603 -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 239351] [panic] spin lock held too long under heavy load (net/wireguard affected)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239351 --- Comment #12 from Evilham --- Created attachment 206056 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=206056&action=edit panic_assertion_patch206036.tar.gz This panic occurred with 13.0-CURRENT r350275+d78b126a34dc(master) + patch206036 over night; the system was compiling some ports in poudriere for CURRENT. I was about to discard it as it being the same as the others, but noticed it has a different message, namely panic: Assertion error_ == 0 failed at /freebsd/src/sys/vm/vm_map.c:553 Attached is the dump, backtrace, acttrace and I managed to identify tid and frame but p other_cpus returned "No symbol "other_cpus" in current context.", which is probably normal since this is a totally different thing, but I thought I'd give it a try anyway. I hope this is useful. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 239351] [panic] spin lock held too long under heavy load (net/wireguard affected)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239351 Mark Johnston changed: What|Removed |Added Assignee|n...@freebsd.org |b...@freebsd.org --- Comment #13 from Mark Johnston --- These problems don't appear to be network-related. I'm not sure how the page daemon got stuck waiting for its TLB shootdown to complete. clang unfortunately optimizes away the variable which would show which CPU(s) we were waiting for. For the VOP_UNSET_TEXT panic, please try applying the attached patch; it should give more debugging info when the problem happens again. I think you can drop the patch I supplied in comment 5. Please also try applying the patch in https://reviews.freebsd.org/D20327 . It should allow you to boot without having to set hw.pci.mcfg=0. Finally, are you willing to share the vmcores with me so that I can take a closer look? -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 239417] ARP ping fails from the host to bridged vnet jails
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239417 --- Comment #4 from Eugene Grosbein --- Yury, had you a chance to try with IP address moved to the bridge? I'd suggest you create the bridge at startup and assign host's IP to it. Then add/remove members to the brige only. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 239443] Intel NIC vs ACPI sleep, network loses
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239443 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|n...@freebsd.org Keywords||IntelNetworking -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 239417] ARP ping fails from the host to bridged vnet jails
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239417 --- Comment #5 from Yuri Victorovich --- (In reply to Eugene Grosbein from comment #4) Hi Eugene, I am doing this in the context of the containerization application that I am working on, yet unannounced (https://github.com/yurivict/crate). It is already functional, but needs networking and configuration management bits to be added or fixed. It runs programs and services in jails, and connects them to network dynamically using firewall rules or bridges. The main mode of connectivity is the "blend" mode when it blends with the host IP address using epair(4) and firewall rules. This doesn't involve creation of IP addresses, and I have it working, except for some minor details. The secondary mode is the "lan" mode which creates a dedicated LAN IP address for each container. I asked this question originally for this mode. Your suggestion about moving the IP address to the bridge makes sense. The process looks a bit more invasive than I originally thought it would be, because it would involve altering the network settings, moving the IP to another interface for the life of container or all containers and then moving it back, as per your advise. I will try this. This is only needed to find a spare LAN IP to allocate, and is not needed for subsequent container operation. Also this "lan" mode isn't strictly necessary because the "blend" mode should satisfy most use cases. I just came up with it, and thought that it would be interesting to implement it too. Thank you for your help! Yuri -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 239417] ARP ping fails from the host to bridged vnet jails
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239417 Eugene Grosbein changed: What|Removed |Added Status|New |Closed Resolution|--- |Works As Intended --- Comment #6 from Eugene Grosbein --- Closing for now. Feel free to re-open if you find it's really kernel problem. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
