[Bug 236724] igb(4): Interfaces fail to switch active to inactive state
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236724 Steven Hartland changed: What|Removed |Added CC||s...@freebsd.org --- Comment #36 from Steven Hartland --- Won't disabling MSI-X destroy the performance, if so feels like this might be worth an EN? -- You are receiving this mail because: You are on the CC list 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 236724] igb(4): Interfaces fail to switch active to inactive state
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236724 --- Comment #37 from Eirik Oeverby --- (In reply to Steven Hartland from comment #36) Strongly agree. -- You are receiving this mail because: You are on the CC list 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 219901] [Panic] [if_bridge] panic when destroying interface on bridge over time
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219901 O. Hartmann changed: What|Removed |Added CC||ohartm...@walstatt.org --- Comment #3 from O. Hartmann --- The problem is also still persistent in CURRENT (13.0-CURRENT FreeBSD 13.0-CURRENT #26 r356437: Tue Jan 7 07:19:34 CET 2020 amd64) and it can be reliably triggered by stopping vnet jails, where the epair is member of a bridge device. Also, these PRs seem to be related to this almost two years old bug: PR 238326 and probably this one year old bug PR 234985. Is anybody investigating this issue? It is also affecting 12.1-RELENG and 12-STABLE systems and it seems the larger the number of jails hosted is, the more likely is the failure . In our case, we crash one large server with a couple of Intel 350T2 NICs and ~ 10 -12 jails one EVERY shutdown of the system or stopping jails via "service jail stop" and it takes one or two attempts to crash the box by randomly select a jail and stop it via "service jail stop $name", $name is the jailname to be stopped. The only secure way to reboot the server is to issue "reboot". -- 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 234985] epair: Kernel panic when destroying epair interface of vnet jail after using ifconfig inside the jail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234985 O. Hartmann changed: What|Removed |Added CC||ohartm...@walstatt.org --- Comment #6 from O. Hartmann --- The problem is still persistent in recent CURRENT ( FreeBSD 13.0-CURRENT #26 r356437: Tue Jan 7 07:19:34 CET 2020 amd64). See also PR 238326 and PR 219901, a bug known since 2017. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list 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 240608] if_vmx(4): iflib - Panic with INVARIANTS: Memory modified after free (12.1-pre-QA)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240608 Andriy Gapon changed: What|Removed |Added CC||a...@freebsd.org, ||pkel...@freebsd.org --- Comment #8 from Andriy Gapon --- I am seeing the same problem with FreeBSD CURRENT as of r351653 (early September). As far as I can tell, jumbo frames are not used. The interface mtu is 1500 and there are no routes with non-default mtu. The interface driver is also vmxnet3. Unread portion of the kernel message buffer: panic: Memory modified after free 0xf8017f069800(2048) val=9d671660 @ 0xf8017f069800 cpuid = 0 time = 1578053135 KDB: stack backtrace: stack1 db_trace_self_wrapper+0x2b vpanic+0x1a4 panic+0x43 trash_ctor+0x49 mb_ctor_clust+0x18 uma_zalloc_arg+0xa4d m_cljget+0x8a _iflib_fl_refill+0x511 _task_fn_rx+0xc06 gtaskqueue_run_locked+0x139 gtaskqueue_thread_loop+0x88 fork_exit+0x84 fork_trampoline+0xe KDB: enter: panic __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 55 /usr/src/sys/amd64/include/pcpu_aux.h: No such file or directory. (kgdb) bt #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 #1 doadump (textdump=4620928) at /usr/src/sys/kern/kern_shutdown.c:467 #2 0x8039641c in db_fncall_generic (addr=, args=, rv=, nargs=) at /usr/src/sys/ddb/db_command.c:620 #3 db_fncall (dummy1=, dummy2=, dummy3=, dummy4=) at /usr/src/sys/ddb/db_command.c:668 #4 0x80395d39 in db_command (last_cmdp=, cmd_table=, dopager=0) at /usr/src/sys/ddb/db_command.c:492 #5 0x8039acd8 in db_script_exec (scriptname=, warnifnotfound=) at /usr/src/sys/ddb/db_script.c:304 #6 0x8039ab23 in db_script_kdbenter (eventname=) at /usr/src/sys/ddb/db_script.c:326 #7 0x80398d2a in db_trap (type=, code=) at /usr/src/sys/ddb/db_main.c:251 #8 0x807c90fc in kdb_trap (type=3, code=0, tf=) at /usr/src/sys/kern/subr_kdb.c:696 #9 0x80abe2d4 in trap (frame=0xfe468580) at /usr/src/sys/amd64/amd64/trap.c:621 #10 #11 kdb_enter (why=0x80bdbcb7 "panic", msg=0x80bdbcb7 "panic") at /usr/src/sys/kern/subr_kdb.c:483 #12 0x8077cff1 in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:987 #13 0x8077d073 in panic (fmt=0x8115abd0 "") at /usr/src/sys/kern/kern_shutdown.c:921 #14 0x80a0d399 in trash_ctor (mem=0x80, size=4621632, arg=, flags=) at /usr/src/sys/vm/uma_dbg.c:82 #15 0x8075ad68 in mb_ctor_clust (mem=0xf8017f069800, size=2048, arg=0x0, how=128) at /usr/src/sys/kern/kern_mbuf.c:738 #16 0x80a0783d in uma_zalloc_arg (zone=0xf8000289c000, udata=0x0, flags=) at /usr/src/sys/vm/uma_core.c:2441 #17 0x80759aca in m_cljget (m=0x0, how=1, size=2048) at /usr/src/sys/kern/kern_mbuf.c:1392 #18 0x808b5d71 in _iflib_fl_refill (ctx=0xf80002a4b000, fl=, count=) at /usr/src/sys/net/iflib.c:1986 #19 0x808b17d6 in __iflib_fl_refill_lt (ctx=, fl=0xf80002a42000, max=24) at /usr/src/sys/net/iflib.c:2079 #20 iflib_rxeof (rxq=0xf80002a32000, budget=24) at /usr/src/sys/net/iflib.c:2823 #21 _task_fn_rx (context=0xf80002a32000) at /usr/src/sys/net/iflib.c:3795 #22 0x807c72a9 in gtaskqueue_run_locked (queue=0xf800020a6100) at /usr/src/sys/kern/subr_gtaskqueue.c:377 #23 0x807c7028 in gtaskqueue_thread_loop (arg=) at /usr/src/sys/kern/subr_gtaskqueue.c:558 #24 0x8073ce34 in fork_exit (callout=0x807c6fa0 , arg=0xfe3f9008, frame=0xfe468ac0) at /usr/src/sys/kern/kern_fork.c:1048 -- You are receiving this mail because: You are on the CC list for the bug. 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 240608] if_vmx(4): iflib - Panic with INVARIANTS: Memory modified after free (12.1-pre-QA)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240608 --- Comment #9 from Andriy Gapon --- I have a crash dump and I can provide any data requested. I can also do some debugging myself if given some directions. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list 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"
IPv6, SLAAC, routing in iocage jail
Hi all, does anyone in this list have an idea if this behaviour is to be expected? I assume it is not in any way FreeNAS specific, of course. Might be an iocage artefact, though. https://www.ixsystems.com/community/threads/ipv6_cpe_wanif-not-quite-working-in-iocage-jail.81341/ Thanks and kind regards, Patrick -- punkt.de GmbH Patrick M. Hausen .infrastructure Kaiserallee 13a 76133 Karlsruhe Tel. +49 721 9109500 https://infrastructure.punkt.de i...@punkt.de AG Mannheim 108285 Geschäftsführer: Jürgen Egeling, Daniel Lienert, Fabian Stein ___ 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"
Re: IPv6, SLAAC, routing in iocage jail
On 8 Jan 2020, at 11:57, Patrick M. Hausen wrote: Hi all, does anyone in this list have an idea if this behaviour is to be expected? I assume it is not in any way FreeNAS specific, of course. Might be an iocage artefact, though. https://www.ixsystems.com/community/threads/ipv6_cpe_wanif-not-quite-working-in-iocage-jail.81341/ Try replacing the # KEYWORD: nojail with # KEYWORD: nojailvnet in /etc/rc.d/netoptions . I don’t know why its the one or other currently and if the other keyword is good for the entire file, but if this change helps you that can be sorted out. /bz ___ 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"
Re: IPv6, SLAAC, routing in iocage jail
Hi, > Am 08.01.2020 um 14:50 schrieb Bjoern A. Zeeb > : >> https://www.ixsystems.com/community/threads/ipv6_cpe_wanif-not-quite-working-in-iocage-jail.81341/ > > Try replacing the > > # KEYWORD: nojail > > with > > # KEYWORD: nojailvnet > > in /etc/rc.d/netoptions. Found and understood - I will give it a try later today and report back. May I remark that the semantics of "nojail" vs. "nojailvnet" are a *bit* confusing? Determine if booting in a jail, and add "nojail" (no jails allowed) or "nojailvnet" (only allow vnet-enabled jails) to the list of KEYWORDS to skip in rcorder(8). Shouldn't the latter be named "onlyjailvnet" or some such? Naming things ... ;-) Kind regards, Patrick -- punkt.de GmbH Patrick M. Hausen .infrastructure Kaiserallee 13a 76133 Karlsruhe Tel. +49 721 9109500 https://infrastructure.punkt.de i...@punkt.de AG Mannheim 108285 Geschäftsführer: Jürgen Egeling, Daniel Lienert, Fabian Stein ___ 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"
Re: IPv6, SLAAC, routing in iocage jail
On 8 Jan 2020, at 14:08, Patrick M. Hausen wrote: Hi, Am 08.01.2020 um 14:50 schrieb Bjoern A. Zeeb : https://www.ixsystems.com/community/threads/ipv6_cpe_wanif-not-quite-working-in-iocage-jail.81341/ Try replacing the # KEYWORD: nojail with # KEYWORD: nojailvnet in /etc/rc.d/netoptions. Found and understood - I will give it a try later today and report back. May I remark that the semantics of "nojail" vs. "nojailvnet" are a *bit* confusing? Determine if booting in a jail, and add "nojail" (no jails allowed) or "nojailvnet" (only allow vnet-enabled jails) to the list of KEYWORDS to skip in rcorder(8). Shouldn't the latter be named "onlyjailvnet" or some such? Naming things ... ;-) I have to say I had to look things up myself as I was confused. I’ve not been involved in these things before. /bz ___ 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"
Re: IPv6, SLAAC, routing in iocage jail
Hi! > Am 08.01.2020 um 14:50 schrieb Bjoern A. Zeeb > : > Try replacing the > > # KEYWORD: nojail > > with > > # KEYWORD: nojailvnet > > in /etc/rc.d/netoptions. Nailed it: default fe80::e228:6dff:fe6f:5b%epair0b UGepair0b I'll open a bug ticket for FreeBSD - no FreeNAS or iocage issue. Thanks! Patrick -- punkt.de GmbH Patrick M. Hausen .infrastructure Kaiserallee 13a 76133 Karlsruhe Tel. +49 721 9109500 https://infrastructure.punkt.de i...@punkt.de AG Mannheim 108285 Geschäftsführer: Jürgen Egeling, Daniel Lienert, Fabian Stein ___ 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"
Re: ssh command hang
On Tue, Jan 7, 2020 at 12:31 PM Bejiita78 . wrote: > has anyone ever noticed that locally a system may respond just fine, but > running a command like port make install or top would cause the ssh session > to hang indefinitely? I have not experienced this, but some detail might help. Version of FreeBSD, CPU (amd64, arm64, i386, etc.), base SSH or ports. If ports, build config. If you run "ssh -vvv" and "sshd -ddd", does that provide any clues? Have you looked at interface stats on either end for errors and/or drops? If it is reasonably repeatable, a BPF packet capture (probably just headers as the payload will be encrypted) using tcpdump. ssh is heavily used and this is the first report of this I have seen, making it likely that this is a local issue such as a firewall or network issue. I have had sessions up for days, often doing things like running top or building large ports with no problems. I do recall a time when my terminal emulator would occasionally freeze, but I have not seen it for quite a while. I use mate-terminal. This was a problem with the emulator, though, and also would lock up local operation as well as ssh sessions. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ 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"
Re: ssh command hang
Thank you sir I did set 1472 as mtu on rtr. Set it back to 1500. Bang. Back in business. Sent from my iPhone > On Jan 7, 2020, at 9:51 PM, Ryan Rawdon wrote: > > >> On Jan 7, 2020, at 3:30 PM, Bejiita78 . wrote: >> >> has anyone ever noticed that locally a system may respond just fine, but >> running a command like port make install or top would cause the ssh session >> to hang indefinitely? > > This is a common sign of a MTU mismatch on a network segment somewhere > between your client and the server (large segments/packets/frames go into a > black hole and nobody knows); or the path has a properly-configured reduced > MTU, but the server is sending the traffic with the Don’t Fragment bit set > (IP header); but the device in the path dropping it due to a smaller MTU is > not successfully having Packet Too Big ICMP errors get back to the server. > > If you perform a packet capture on the server, you will likely see it > retransmitting one or more segments over and over - but not see those > arriving to the client. > > The approach to diagnosing the point of the issue being introduced (MTU > mismatch, ICMP filtering, or the server not utilizing ICMP PTB responses > properly) depends largely on the network topology between your client and > server; and your ability to investigate or reproduce the symptoms in systems > along that path. > > There are plenty of other potential causes for this behavior, but this is the > first one I would investigate if experiencing this issue. Have there been > any network changes near your client or server that might have meddled with > MTU sizes or ICMP blocking? > ___ 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 230996] em/igb: Intel i210/i350: ifconfig: enabling "vlanhwtag" renders VLAN on i210/i350 NICs unusable
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230996 Jason Tubnor changed: What|Removed |Added CC||ja...@tubnor.net --- Comment #4 from Jason Tubnor --- This issue still exists in 12.1-p1 While vlanhwtagging doesn't need to be disabled if using the host in a vanilla config, once and igb interface is placed into a bridge as a vlan with a tap device for a bhyve guest, ingress of data to the guest comes to a halt under iperf3 testing. egress from the guest is not impacted and runs at full speed. When vlanhwtagging is disabled, forcing the host to perform the function, data ingress or egress of the guest runs at full speed. I'd like to enable vlanhwtagging as the CPU load put on the host is huge when transferring a single 1Gb/s stream of traffic from guests. -- 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"
