Re: SIOCGIFADDR broken on 9.0-RC1?

On 2011-11-15 18:10:01 (+0100), GR free...@gomor.org wrote: more insights since my last post. Here is a small code to trigger the bug (end of email). When you run it on 9.0-RC1, it gets an alias address instead of the main inet address: % ./get-ip re0 inet: 192.168.2.10 # Main

Build error in bin/sh/jobs.c if DEBUG=2

While chasing down an odd issue with alignment faults I activated debugging in bin/sh. bin/sh/Makefile has a commented out line (# DEBUG_FLAGS+= -g -DDEBUG=2 -fno-inline) to do this so that's what I did. This fails to compile in bin/sh/jobs.c in vforkexecshell(). The debug TRACE() tries to print

OpenRD-CL support

Hi, Based on the work from arm/156814 I've got a working config and device tree for the OpenRD-CL. It successfully boots over NFS, both network interfaces as well as the cesa (crypto accelerator) work. The patch: diff --git a/sys/arm/conf/OPENRD-CL b/sys/arm/conf/OPENRD-CL new file mode 100644

Re: zfs kernel panic, known incompatibilities with clang CPUTYPE/COPTFLAGS?

On 2013-06-14 23:07:02 (+0200), Alexander Leidinger alexan...@leidinger.net wrote: The bt in the minidump is useless, but I made a bt directly in the kernel debugger: ---snip--- Fatal trap 12: page fault while in kernel mode cpuid = 2; apic id = 02 fault virtual address = 0x0 fault code

Re: zfs kernel panic, known incompatibilities with clang CPUTYPE/COPTFLAGS?

On 2013-06-24 22:08:01 (+0200), Alexander Leidinger alexan...@leidinger.net wrote: On Mon, 24 Jun 2013 12:15:18 +0200 Kristof Provost kris...@sigsegv.be wrote: For what it's worth, I'm running into exactly the same problem. (amd64, stable/9). I have no custom settings in /etc/make.conf

Re: zfs kernel panic, known incompatibilities with clang CPUTYPE/COPTFLAGS?

On 2013-06-29 18:49:16 (+0200), Martin Matuska m...@freebsd.org wrote: This was an obvious error by me - I forgot to register zfs_ioc_jail and zfs_ioc_unjail using the new functions. Amazing noone noticed this by now until it got merged down to stable/8. In addition, I see no need to log

Re: New Marvell SATA driver for testing

On 2010-04-28 15:44:29 (+0300), Alexander Motin m...@freebsd.org wrote: I'm glad to present new driver (mvs) for several series of Marvell SATA controllers (PCI-X, PCIe and SoC-integrated), to work with CAM ATA infrastructure. Driver supports following Marvell chips: ... 88SX6042,

Re: New Marvell SATA driver for testing

On 2010-05-04 08:11:09 (+0300), Alexander Motin m...@freebsd.org wrote: Kristof Provost wrote: I've done a quick test on my Orion (88F5182) based device. It seems to be working fine. It detects a SATA hard disk, reads/writes, ... I wasn't able to mount a filesystem from the disk

Re: [OpenRD Ultimate] e1000phy(88E1149/88E1121) has a initialize issue

On 2010-06-13 23:37:23 (+0900), Norikatsu Shigemura n...@freebsd.org wrote: Hi yongari! I have a OpenRD Ultimate, which has two GbE ports - if_mge(4). But I couldn't use mge1 like following. So I tried to investigate. - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Re: [OpenRD Ultimate] e1000phy(88E1149/88E1121) has a initialize issue

On 2010-06-20 21:03:51 (+0900), Norikatsu Shigemura n...@freebsd.org wrote: On Sun, 13 Jun 2010 22:13:31 +0200 Kristof Provost kris...@sigsegv.be wrote: I have a OpenRD Ultimate, which has two GbE ports - if_mge(4). But I couldn't use mge1 like following. So I tried to investigate

[PATCH] minstat: default width is terminal width, not 74

The man page states that: '-w widthWidth of ASCII-art plot in characters, default is 74.' This is not entirely correct. The mini-help is more accurate: '-w : width of graph/test output (default 74 or terminal width)' In other words: the man page fails to explain that ministat will default to

Re: pf crash on -current

On 2015-02-23 17:23:55 (-0800), Davide Italiano dav...@freebsd.org wrote: On Mon, Feb 23, 2015 at 5:17 PM, Allan Jude allanj...@freebsd.org wrote: Upgraded my router today, because it was approaching the 24 uptime days of doom Now, it likes to die on me, a lot The bt you posted

Re: pf crash on -current

On 2015-02-24 08:05:47 (+0100), Kristof Provost kris...@sigsegv.be wrote: On 2015-02-23 17:23:55 (-0800), Davide Italiano dav...@freebsd.org wrote: The bt you posted suggest this could be stack overflow, probably due to infinite recursion. Also, as a wild guess, just looking

sysctl -a panic on VIMAGE kernels

Hi, I’ve run into a reproducible panic on a VIMAGE kernel with ‘sysctl -a’. Relevant backtrace bits: #8 0x80e7dd28 in trap (frame=0xfe01f16b26a0) at /usr/src/sys/amd64/amd64/trap.c:426 #9 0x80e5e6a2 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:235 #10

Re: sysctl -a panic on VIMAGE kernels

On 2015-08-09 13:36:35 (+0300), Gleb Smirnoff gleb...@freebsd.org wrote: On Sun, Aug 09, 2015 at 12:28:22PM +0200, Kristof Provost wrote: K The following fixes it for me: K K diff --git a/sys/netinet/tcp_reass.c b/sys/netinet/tcp_reass.c K index 77d8940..3913ef3 100644 K --- a/sys/netinet

Re: pf NAT and VNET Jails

On 2015-11-09 21:47:01 (-0500), Shawn Webb wrote: > I found the problem: it seems that the new Intel Haswell graphics > support (which I've been running with) is at odds somehow with pf NAT. > Removing Haswell graphics support means working pf NAT. > That's ... very

Re: pf NAT and VNET Jails

> On 02 Nov 2015, at 14:47, Shawn Webb wrote: > > On Sunday, 01 November 2015 07:16:34 AM Julian Elischer wrote: >> On 11/1/15 2:50 AM, Shawn Webb wrote: >>> I'm at r290228 on amd64. I'm not sure which revision I was on last when it >>> last worked, but it seems VNET

Re: r289932 causes pf reversion - breaks rules with broadcast destination

On 2015-11-04 20:31:35 (-0500), Tom Uffner wrote: > Commit r289932 causes pf rules with broadcast destinations (and some but not > all rules after them in pf.conf) to be silently ignored. This is bad. > Thanks for the report. What version did you test exactly? There was an

Re: pf NAT and VNET Jails

> On 02 Nov 2015, at 15:07, Shawn Webb <shawn.w...@hardenedbsd.org> wrote: > > On Monday, 02 November 2015 02:59:03 PM Kristof Provost wrote: >> >> Can you add your pf.conf too? >> >> I’ll try upgrading my machine to something beyond 290228 to see if I c

Re: pf NAT and VNET Jails

> On 05 Nov 2015, at 17:25, Shawn Webb wrote: > I've figured it out. I've removed all rules and went with a barebones config. > > Right now, the laptop I'm using for NAT has an outbound interface of wlan0 > with an IP of 129.6.251.181 (from DHCP). The following line

Re: r289932 causes pf reversion - breaks rules with broadcast destination

> On 05 Nov 2015, at 18:39, Tom Uffner wrote: > > Tom Uffner wrote: >> Commit r289932 causes pf rules with broadcast destinations (and some but not >> all rules after them in pf.conf) to be silently ignored. This is bad. > >> I do not understand the pf code well enough to see

Re: Panic with PF on current.

> On 06 Nov 2015, at 01:12, Daniel Dettlaff wrote: > I have interesting verbose output with backtrace (not panic) from one of my > VMs: http://s.verknowsys.com/f0d457ce9420399baaf531012c33eb81.png > It’s triggered by autostarting jail on bridged vlan interface (no VNET >

Re: r289932 causes pf reversion - breaks rules with broadcast destination

On 2015-11-05 12:39:22 (-0500), Tom Uffner wrote: > So, if my rule was "working" due to false positive in a comparison that has > now been fixed, how many other address comparisons were affected by this > error? > > There are 36 occurrences of PF_ANEQ in pf.c and 2 in

Re: forwarding didn't work if wlan0 is member of a bridge

On 2015-12-23 08:08:29 (-0700), Sergey Manucharian wrote: > I believe this is related to the fact that wifi adapter cannot have more > that one MAC address. And that becomes true when it's a member of a > bridge. There exist some tricky ways to overcome that though. > That's

Re: IPV6 TCP6 Slow Connect

> On 12 Feb 2016, at 10:18, Larry Rosenman <l...@lerctr.org> wrote: > > On 2016-02-11 20:50, Larry Rosenman wrote: >> On 2016-02-11 14:40, Larry Rosenman wrote: >>> On 2016-02-11 14:25, Kristof Provost wrote: >>> On 11 Feb 2016, at 21:23, Larry Rosenman

Re: IPV6 TCP6 Slow Connect

> On 12 Feb 2016, at 15:29, Larry Rosenman wrote: > > On 2016-02-12 08:13, Larry Rosenman wrote: >> >> sysctl net.inet.tcp.rfc1323=0 >> makes it work > Shouldn't the stack do the right thing here? For the record, the other side > is also FreeBSD (10.2-STABLE). > Yes, but

Re: IPV6 TCP6 Slow Connect

> On 12 Feb 2016, at 15:33, Larry Rosenman <l...@lerctr.org> wrote: > > On 2016-02-12 08:31, Kristof Provost wrote: >>> On 12 Feb 2016, at 15:29, Larry Rosenman <l...@lerctr.org> wrote: >>> On 2016-02-12 08:13, Larry Rosenman wrote: >>>&g

Re: IPV6 TCP6 Slow Connect

> On 11 Feb 2016, at 21:23, Larry Rosenman wrote: > > From which system(s) perspective do you want the packet captures? > (Firewall, FreeBSD, Windows)? I wouldn’t expect it to make much of a difference in this case. Let’s start with whatever is easiest. Regards, Kristof

Re: IPV6 TCP6 Slow Connect

On 2016-02-10 20:38:02 (-0600), Larry Rosenman wrote: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206904 > > I've also posted lots of info to freebsd-net, and not gotten any > response. > > Summary: > > Cable Modem-> EM0 on a pfSense Firewall (FreeBSD 10.1, pfSense

Re: VNET branch destiny

On 10 Apr 2017, at 12:10, peter.b...@bsd4all.org wrote: There have been issues with pf if I recall correctly. I currently have issues with stable, pf and vnet. There is an issue with pf table entries when an interface is moved to a different vnet. Does anyone no if there is a specific fix for

Re: Attn: CI/Jenkins people; Run bhyve instance for testing pf

On 20 Jul 2017, at 18:24, Nikos Vassiliadis wrote: It would be great if you use vnet jails for that. I am not sure regarding the per-vnet pf functionality but I have seen many bug fixes hitting the tree since last year. You can ask on freebsd-virtualizat...@freebsd.org or freebsd...@freebsd.org

zfs recv panic

Hi, I have a reproducible panic on CURRENT (r318136) doing (jupiter) # zfs send -R -v zroot/var@before-kernel-2017-04-26 | nc dual 1234 (dual) # nc -l 1234 | zfs recv -v -F tank/jupiter/var For clarity, the receiving machine is CURRENT r318136, the sending machine is running a somewhat older

Re: zfs recv panic

On 16 May 2017, at 19:58, Andriy Gapon wrote: On 16/05/2017 16:49, Kristof Provost wrote: On 16 May 2017, at 15:41, Andriy Gapon wrote: On 10/05/2017 12:37, Kristof Provost wrote: I have a reproducible panic on CURRENT (r318136) doing (jupiter) # zfs send -R -v zroot/var@before-kernel-2017-04

Re: zfs recv panic

On 16 May 2017, at 15:41, Andriy Gapon wrote: On 10/05/2017 12:37, Kristof Provost wrote: I have a reproducible panic on CURRENT (r318136) doing (jupiter) # zfs send -R -v zroot/var@before-kernel-2017-04-26 | nc dual 1234 (dual) # nc -l 1234 | zfs recv -v -F tank/jupiter/var For clarity

Re: VNET jail and dhclient

On 10 Oct 2017, at 23:10, Oleg Ginzburg wrote: What is your FreeBSD version? This problem reproduced on FreeBSD 12 only. /var/empty is exist and trivial test: I’m running r324317 on CURRENT, yes. What arguments are you calling dhclient with? Clearly there’s a difference between what you’re

Re: VNET jail and dhclient

On 16 Nov 2017, at 14:04, KOT MATPOCKuH wrote: > Hello, all! > > I'm got same problem... > Can you show how you call dhclient? What FreeBSD version are you running? What’s the output of `sysctl kern.chroot_allow_open_directories`? Regards, Kristof ___

RFC: mallocarray()

Hi, I’d like to make it easier to avoid integer overflow issues in the kernel. It’d be a lot nicer to have a malloc function figure this out for us, so I’d like mallocarray(). https://reviews.freebsd.org/D13766 Are there any objections to this? Regards, Kristof

Re: ifnet use after free

On 25 Aug 2018, at 0:26, Matthew Macy wrote: On Fri, Aug 24, 2018 at 15:25 Shawn Webb wrote: Hey All, Somewhere in the last month or so, a use after free was introduced. I don't have the time right now to bisect the commits and figure out which commit introduced the breakage. Attached is

Re: [CURRENT, ezjail] rc, rc.subr and other rc. scripts gone: ezjail fails on 12-ALPHA

On 25 Aug 2018, at 9:06, O. Hartmann wrote: I'm using ezjail-admin from ports (most recent tree, up to date as of today, at Revision: 478001, FreeBSD is FreeBSD 12.0-ALPHA3 #455 r338309: Sat Aug 25 07:10:45 CEST 2018 amd64, the jails sources are at revision 338309). Updates of the jail's base

Re: ifnet use after free

On 25 Aug 2018, at 0:47, Kristof Provost wrote: On 25 Aug 2018, at 0:26, Matthew Macy wrote: On Fri, Aug 24, 2018 at 15:25 Shawn Webb wrote: Hey All, Somewhere in the last month or so, a use after free was introduced. I don't have the time right now to bisect the commits and figure

Re: ifnet use after free

memguard on the memory type in question is extremely useful in catching use after free. -M On Sat, Aug 25, 2018 at 05:51 Kristof Provost wrote: On 25 Aug 2018, at 0:47, Kristof Provost wrote: On 25 Aug 2018, at 0:26, Matthew Macy wrote: On Fri, Aug 24, 2018 at 15:25 Shawn Webb wrote: Hey All

Re: buildworld fails: fatal error: 'netpfil/pf/pf.h' file not found

On 9 Apr 2018, at 13:10, Vladimir Zakharov wrote: On Mon, Apr 09, 2018, Kristof Provost wrote: On 9 Apr 2018, at 10:50, Vladimir Zakharov wrote: For several days buildworld fails for me with the following error. Cleaning and rebuilding didn't help. ===> tests/sys/netpfil

Re: buildworld fails: fatal error: 'netpfil/pf/pf.h' file not found

On 9 Apr 2018, at 10:50, Vladimir Zakharov wrote: For several days buildworld fails for me with the following error. Cleaning and rebuilding didn't help. ===> tests/sys/netpfil/pf/ioctl (all) --- validation --- (cd /usr/src/tests/sys/netpfil/pf/ioctl && DEPENDFILE=.depend.validation

Re: vnet & firewalls in 12.0

On 18 Oct 2018, at 11:33, Ernie Luzar wrote: Wanting to get a head start on using 12.0 and vnet jails with in jail firewall. 1. Will Vimage be compiled as a module in the 12.0 kernel and be included in the base system release? vimage is a kernel option, not a module. It affects the entire

Re: 12.0-BETA1 vnet with pf firewall

> On 28 Oct 2018, at 12:56, Ernie Luzar wrote: > > Bjoern A. Zeeb wrote: >>> On 28 Oct 2018, at 15:31, Ernie Luzar wrote: >>> Tested with host running ipfilter and vnet running pf. Tried loading pf >>> from host console or from vnet console using kldload pf.ko command and get >>> this error

Re: 12.0-BETA1 vnet with pf firewall

On 28 Oct 2018, at 14:39, Rodney W. Grimes wrote: Bjoern A. Zeeb wrote: On 28 Oct 2018, at 15:31, Ernie Luzar wrote: Tested with host running ipfilter and vnet running pf. Tried loading pf from host console or from vnet console using kldload pf.ko command and get this error message;

Re: 12.0-BETA1 vnet with pf firewall

On 29 Oct 2018, at 4:41, Kristof Provost wrote: So we panic because we dereference a NULL pointer in strncmp(), which happens because nprogtab = 13 but ef->progtab[12] has NULL pointers. It’s not clear to me why that happens, but it’s something to go on. I do wonder if this isn’t a

Re: 12.0-BETA1 vnet with pf firewall

On 30 Oct 2018, at 14:29, Bjoern A. Zeeb wrote: On 30 Oct 2018, at 12:23, Kristof Provost wrote: I’m not too familiar with this part of the vnet code, but it looks to me like we’ve got more per-vnet variables that was originally anticipated, so we may need to just increase the allocated space

Re: Bad DHCP Checksums over VLANs

On 16 Sep 2018, at 23:05, Eric van Gyzen wrote: On 9/15/18 1:06 AM, Kurt Jaeger wrote: Can you disable all the options of the NIC ? ifconfig igb0 -rxcsum -txcsum -wol -tso4 -vlanmtu -vlanhwtag -vlanhwcsum -vlanhwtso Try to disable everything that can be disabled, e.g. LRO etc. Disabling

Re: Networking panic on 12 - found the cause

On 2019-02-12 13:54:21 (-0600), Eric van Gyzen wrote: > I see the same behavior on head (and stable/12). > > (kgdb) f > #16 0x80ce5331 in ether_output_frame (ifp=0xf80003672800, > m=0xf8000c88b100) at /usr/src/sys/net/if_ethersubr.c:468 > 468 switch

Re: FreeBSD CI Weekly Report 2019-06-09

On 15 Jun 2019, at 11:35, Kristof Provost wrote: On 12 Jun 2019, at 16:49, Li-Wen Hsu wrote: * https://ci.freebsd.org/job/FreeBSD-head-i386-test/ * Same as amd64: * sys.netinet.socket_afinet.socket_afinet_bind_zero * Others: * sys.netpfil.pf.forward.v6

Re: FreeBSD CI Weekly Report 2019-06-09

On 12 Jun 2019, at 16:49, Li-Wen Hsu wrote: * https://ci.freebsd.org/job/FreeBSD-head-i386-test/ * Same as amd64: * sys.netinet.socket_afinet.socket_afinet_bind_zero * Others: * sys.netpfil.pf.forward.v6 * sys.netpfil.pf.forward.v4 *

Re: Panic with r346530 [Re: svn commit: r346530 - in head/sys: netinet netinet6]

On 22 Apr 2019, at 12:25, Enji Cooper wrote: Either the sys/netinet/ or sys/netipsec/ tests triggered the panic. Not sure which right now. That looks to be happening during a vnet jail teardown, so it’s likely the sys/netipsec or sys/netpfil/pf tests. I’ve done a quick test with the pf

Re: kyua test

On 31 Jan 2020, at 7:34, Clay Daniels wrote: I've started running kyua test when I load the weekly current snapshot, and I'm a little confused about if I should run kyua test as user or root. In order to make the /usr/ports/devel/kyua port you need to be root and I have just been doing the

Re: llvm 10 libomp build error

On 12 Mar 2020, at 16:58, Ronald Klop wrote: Hi, Clean build after svn update gives: cc: error: no such file or directory: '/data/src/freebsd-current/contrib/llvm-pr oject/openmp/runtime/src/thirdparty/ittnotify/ittnotify_static.c' cc: error: no input files *** [ittnotify_static.pico] Error

Bridge project update (Week of April 6th)

not to be able to MFC these changes back to 12, but that may be possible after all. There is an experimental patch set for stable/12 here: https://people.freebsd.org/~kp/if_bridge/stable_12/ Best regards, Kristof Provost ___ freebsd-current@freebsd.org

Bridge project update (Week of April 14th)

. Best regards, Kristof Provost ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

CFT: if_bridge performance improvements

Hi, Thanks to support from The FreeBSD Foundation I’ve been able to work on improving the throughput of if_bridge. It changes the (data path) locking to use the NET_EPOCH infrastructure. Benchmarking shows substantial improvements (x5 in test setups). This work is ready for wider testing

Re: FreeBSD CI Weekly Report 2020-04-12

On 15 Apr 2020, at 0:37, Li-Wen Hsu wrote: (Please send the followup to freebsd-testing@ and note Reply-To is set.) FreeBSD CI Weekly Report 2020-04-12 === Here is a summary of the FreeBSD Continuous Integration results for the period from 2020-04-06 to

Re: FreeBSD CI Weekly Report 2020-04-12

On 15 Apr 2020, at 15:34, Kristof Provost wrote: On 15 Apr 2020, at 0:37, Li-Wen Hsu wrote: (Please send the followup to freebsd-testing@ and note Reply-To is set.) FreeBSD CI Weekly Report 2020-04-12 === Here is a summary of the FreeBSD Continuous Integration

Re: CFT: if_bridge performance improvements

On 16 Apr 2020, at 8:34, Pavel Timofeev wrote: Hi! Thank you for your work! Do you know if epair suffers from the same issue as tap? I’ve not tested it, but I believe that epair scales significantly better than tap. It has a per-cpu mutex (or more accurately, a mutex in each of its per-cpu

bridge project update (Week of March 9th)

Hi, As this is the first status report sent to a wider audience I’ll try to give a bit of background information. I’m working on a performance improvement project for if_bridge. Right now it’s a big bottleneck for a number of different scenarios (e.g. for VNET jail or VM hosts). if_bridge

Bridge project update (Week of March 30th)

svg I’ll give D245250 another week or two for reviews. It’s a relatively small patch, considering, but it’s complex and important. I also intend to add another test case for a cleanup issue that’s since been fixed in D245250. Best regards, Kristof Prov

Bridge project update (Week of March 23rd)

Hi, This week I got a prototype patch running, along the ideas discussed last week. Essentially, we keep the BRIDGE_LOCK for any add/delete of interfaces or rt entries, but use CK_LIST and epoch in the data path. This is a relatively straightforward change, and currently passes the regression

Re: CFT: if_bridge performance improvements

On 22 Apr 2020, at 18:15, Xin Li wrote: On 4/22/20 01:45, Kristof Provost wrote: On 22 Apr 2020, at 10:20, Xin Li wrote: Hi, On 4/14/20 02:51, Kristof Provost wrote: Hi, Thanks to support from The FreeBSD Foundation I’ve been able to work on improving the throughput of if_bridge

Bridge project update (Week of April 21st)

a bit more testing in CURRENT first. The Foundation wrote about this project here: https://www.freebsdfoundation.org/blog/500-if_bridge-performance-improvement/ There will be an in-depth article on this work in the upcoming May/June issue of FreeBSD Journal. Best regards, Kristof Provost

Re: CFT: if_bridge performance improvements

On 22 Apr 2020, at 10:20, Xin Li wrote: Hi, On 4/14/20 02:51, Kristof Provost wrote: Hi, Thanks to support from The FreeBSD Foundation I’ve been able to work on improving the throughput of if_bridge. It changes the (data path) locking to use the NET_EPOCH infrastructure. Benchmarking

Re: FreeBSD CI Weekly Report 2020-04-12

On 15 Apr 2020, at 16:49, Olivier Cochard-Labbé wrote: On Wed, Apr 15, 2020 at 4:10 PM Kristof Provost wrote: The problem appears to be that /usr/local/lib/python3.7/site-packages/scapy/arch/unix.py is misparsing the `netstat -rnW` output. Shouldn't scapy use the libxo output

Bridge project update (Week of March 16th)

to approach the epoch-ification now, and hope to have a functional prototype in a few weeks. Best regards, Kristof Provost ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail

Re: Plans for git

On 3 Sep 2020, at 19:56, Chris wrote: Why was the intention to switch NOT announced as such MUCH sooner? There was discussion about a possible switch to git on the freebsd-git mailing list as early as February 2017: https://lists.freebsd.org/pipermail/freebsd-git/2017-February/92.html

Re: bridge/igb panic: sleepq_add: td 0xfffffe01bbce5300 to sleep on wchan 0xffffffff8157d9a0 with sleeping prohibited

On 11 Sep 2020, at 19:06, Gleb Smirnoff wrote: > Kristof, > > can you please take a look? IMHO, the problem is that with r360345 > the bridge_ioctl() is fully covered by epoch. IMHO, should be either > more fine grained covered, or use internal locking, because some of > the code downstream

Re: iflib/bridge kernel panic

On 28 Sep 2020, at 12:45, Alexander Leidinger wrote: Quoting Kristof Provost (from Sun, 27 Sep 2020 17:51:32 +0200): Here’s an early version of a task queue based approach: http://people.freebsd.org/~kp/0001-bridge-Cope-with-if_ioctl-s-that-sleep.patch That still needs to be cleaned up

Re: iflib/bridge kernel panic

On 28 Sep 2020, at 16:44, Alexander Leidinger wrote: Quoting Kristof Provost (from Mon, 28 Sep 2020 13:53:16 +0200): On 28 Sep 2020, at 12:45, Alexander Leidinger wrote: Quoting Kristof Provost (from Sun, 27 Sep 2020 17:51:32 +0200): Here’s an early version of a task queue based

Re: iflib/bridge kernel panic

On 23 Sep 2020, at 19:37, xto...@hotmail.com wrote: > Kristof Provost wrote: >> On 21 Sep 2020, at 2:52, Shawn Webb wrote: >>>> From latest HEAD on a Dell Precision 7550 laptop: >>> >>> https://gist.github.com/lattera/a0803f31f58bcf8ead51ac1ebbc447e2 &g

Re: iflib/bridge kernel panic

On 21 Sep 2020, at 14:16, Shawn Webb wrote: On Mon, Sep 21, 2020 at 09:57:40AM +0200, Kristof Provost wrote: On 21 Sep 2020, at 2:52, Shawn Webb wrote: From latest HEAD on a Dell Precision 7550 laptop: https://gist.github.com/lattera/a0803f31f58bcf8ead51ac1ebbc447e2 The last working boot

Re: iflib/bridge kernel panic

On 30 Sep 2020, at 13:52, Alexander Leidinger wrote: Quoting Kristof Provost (from Tue, 29 Sep 2020 23:20:44 +0200): On 28 Sep 2020, at 16:44, Alexander Leidinger wrote: Quoting Kristof Provost (from Mon, 28 Sep 2020 13:53:16 +0200): On 28 Sep 2020, at 12:45, Alexander Leidinger wrote

Re: iflib/bridge kernel panic

On 21 Sep 2020, at 2:52, Shawn Webb wrote: >> From latest HEAD on a Dell Precision 7550 laptop: > > https://gist.github.com/lattera/a0803f31f58bcf8ead51ac1ebbc447e2 > > The last working boot environment was 14 Aug 2020. If I get some time to > bisect commits, I'll try to figure out the culprit. >

Re: somewhat reproducable vimage panic

On 23 Jul 2020, at 11:00, Bjoern A. Zeeb wrote: On 23 Jul 2020, at 8:09, Kristof Provost wrote: On 23 Jul 2020, at 9:19, Kristof Provost wrote: On 23 Jul 2020, at 0:15, John-Mark Gurney wrote: So, it's pretty easy to trigger, just attach a couple USB ethernet adapters, in my case, they were

Re: somewhat reproducable vimage panic

On 23 Jul 2020, at 0:15, John-Mark Gurney wrote: > So, it's pretty easy to trigger, just attach a couple USB ethernet > adapters, in my case, they were ure, but likely any two spare ethernet > interfaces will work, and wire them back to back.. > I’ve been able to trigger it using epair as well:

Re: somewhat reproducable vimage panic

On 23 Jul 2020, at 9:19, Kristof Provost wrote: On 23 Jul 2020, at 0:15, John-Mark Gurney wrote: So, it's pretty easy to trigger, just attach a couple USB ethernet adapters, in my case, they were ure, but likely any two spare ethernet interfaces will work, and wire them back to back.. I’ve

Re: git and the loss of revision numbers

On 29 Dec 2020, at 4:33, monochrome wrote: sry forgot details: source tree @ ead01bfe8 git -C /usr/src checkout gf20c0e331 error: pathspec 'gf20c0e331' did not match any file(s) known to git what is the 'g' for? That would have been a typo, I think. git -C /usr/src checkout f20c0e331 M

Re: firewall choice

On 27 Nov 2020, at 9:29, tech-lists wrote: What's the "best" [1] choice for firewalling these days, in the list's opinion? There's pf, ipf and ipfw. Which is the one being most recently developed/updated? I'm used to using pf, have done for over a decade. But OpenBSD's pf has diverged a lot

Re: HEADS UP: FreeBSD src repo transitioning to git this weekend

On 22 Dec 2020, at 22:06, bob prohaska wrote: > On Tue, Dec 22, 2020 at 09:34:25PM +0100, Ronald Klop wrote: >> >> what does "pkg install git" do for you? NB: I use "pkg install git-lite". >> Prevents about 1000 dependencies. >> > > That seems to have worked. It reported something about package

Re: HEADS UP: FreeBSD src repo transitioning to git this weekend

On 22 Dec 2020, at 22:50, Mark Millard wrote: On 2020-Dec-22, at 13:31, Mark Millard wrote: Clone https://git.FreeBSD.org/src.git anon...@git.freebsd.org:src.git g...@gitrepo.freebsd.org:src.git Hmm. It turns out that the last 2 are links on that page and the links expand out to:

Re: Enabling AESNI by default

On 31 Dec 2020, at 23:09, Rodney W. Grimes wrote: Its for ever dead code on a large number of machines that do not have the hardware for it. I know that is a decreasing set, but imho it would be better to somehow ONLY load the module if you had CPU support for it. The down side is that

Re: libifconfig_sfp.h does not compile for me

On 11 Mar 2021, at 9:51, Ronald Klop wrote: Hi, This https://cgit.freebsd.org/src/tree/lib/libifconfig/libifconfig_sfp.h includes libifconfig_sfp_tables.h which does not exist. My build fails on this. I cleaned /lib/libifconfig and /sbin/ifconfig, but no succes. The last change in these

Re: ifa leak on VNET teardown

On 13 Feb 2021, at 21:58, Alexander V. Chernikov wrote: It turns out we're leaking some ifas for loopback interfaces on VNET teardown: There’s a recent bug about this as well: 253998. The problem’s been around for a long time though. The pf tests trigger it from time to time, although it

Re: Interface counter inaccurate

On 15 Feb 2021, at 22:09, Daniel Ponte wrote: I've noticed that since upgrading to stable/13-n244514-18097ee2fb7c from 12.2-STABLE, throughput on my WAN interface (the box runs pf) is incorrectly showing double in systat -if, as well as in vnstat and pftop from ports. The LAN interface does

Re: Interface counter inaccurate

On 16 Feb 2021, at 0:58, Daniel Ponte wrote: On Mon, Feb 15, 2021 at 10:25:47PM +0100, Kristof Provost wrote: On 15 Feb 2021, at 22:09, Daniel Ponte wrote: I've noticed that since upgrading to stable/13-n244514-18097ee2fb7c from 12.2-STABLE, throughput on my WAN interface (the box runs pf

Re: WITHOUT_PF breaks buildworld

On 22 Dec 2021, at 8:21, Konrad Sewiłło-Jopek wrote: > Hi, > > I think the reason is somewhere in tools/build/test-includes: > > --- net/if_pfsync.o --- > In file included from net/if_pfsync.c:1: > In file included from > [...]freebsd/arm64.aarch64/tmp/usr/include/net/if_pfsync.h:56: >

Re: HEADS-UP: ASLR for 64-bit executables enabled by default on main

> On 18 Nov 2021, at 11:43, Marcin Wojtas wrote: > czw., 18 lis 2021 o 19:07 Li-Wen Hsu napisał(a): >> >>> On Wed, Nov 17, 2021 at 6:30 AM Marcin Wojtas wrote: >>> >>> As of b014e0f15bc7 the ASLR (Address Space Layout >>> Randomization) feature becomes enabled for the all 64-bit >>>

Re: Kernel panic for if_epair

On 16 Feb 2022, at 11:31, qroxana wrote: > It's running 14.0-CURRENT armv7 main-n252983-d21e71efce39 > > Kernel page fault with the following non-sleepable locks held: > exclusive sleep mutex epairidx (epairidx) r = 0 (0xe2fe9160) locked @ > /usr/src/sys/net/if_epair.c:165 > stack backtrace: > #0

Re: test-includes breaks buildworld when WITHOUT_PF is set in src.conf

On 9 Feb 2022, at 10:57, Gary Jennejohn wrote: > test-includes uses pf.h when checking usage of pfvar.h. > > But, these lines in include/Makefile remove pf.h when WITHOUT_PF is > set in src.conf: > > .if ${MK_PF} != "no" > INCSGROUPS+= PF > .endif > > This breaks buildworld. The error message:

Re: netinet & netpfil tests failing

On 18 Jan 2022, at 3:07, Gleb Smirnoff wrote: > * Another factor - scapy. The python scapy library would emit warning to > stderr > if it sees interface without any IP address. This happens right at 'import > scapy'. > The test suite considers a test failed if it has something on stderr,

Re: git: 8d49fd7331bc - main - pf: remove DIOCGETRULE and DIOCGETSTATUS : net/py-libdnet and net/scapy now broken, kyua test suite damaged

Hi Mark, On 14 Sep 2023, at 7:37, Mark Millard wrote: > This change leads the port net/py-libdnet to be broken: > > --- fw-pf.lo --- > fw-pf.c:212:22: error: use of undeclared identifier 'DIOCGETRULE' > if (ioctl(fw->fd, DIOCGETRULE, ) == 0 && > ^ > fw-pf.c:252:22: error: use of undeclared

Re: git: 8d49fd7331bc - main - pf: remove DIOCGETRULE and DIOCGETSTATUS : net/py-libdnet and net/scapy now broken, kyua test suite damaged

On 14 Sep 2023, at 15:34, Mark Millard wrote: > [I've cc'd a couple of folks that have dealt with fixing > breakage in the past.] > I’ve submitted a fix for libdnet in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273899 because it blocks net/scapy, which we rely on for tests. I do not plan

Re: panic in cypto code

On 5 Oct 2023, at 19:34, Steve Kargl wrote: > On Thu, Oct 05, 2023 at 06:05:37PM +0200, Kristof Provost wrote: >> Hi Steve, >> >> On 5 Oct 2023, at 17:36, Steve Kargl wrote: >>> In case anyone else is using openvpn. >>> >>> % pkg info openvp

Re: panic in cypto code

> On 6 Oct 2023, at 08:46, Steve Kargl > wrote: > > On Thu, Oct 05, 2023 at 03:11:02PM -0700, Steve Kargl wrote: >> >> I'll ping you off list when it's available. >> > > Well, this is interesting. I cannot upload the files to > a location from which I can then put them up on freefall.

Re: epair/vbridge: no IPv6 traffic egress until first IPv6 packet flows in

On 10 Oct 2023, at 19:26, FreeBSD User wrote: > Hello, > > at first: observation is below, marked [OBSERVATION]. > > Running recent CURRENT (FreeBSD 15.0-CURRENT #26 main-n265831-3523f0677ef: > Mon Oct 9 14:00:42 > CEST 2023 amd64), I've configured a bridge (bridge0), the hosts's interface >

Re: panic in cypto code

Hi Steve, On 5 Oct 2023, at 17:36, Steve Kargl wrote: > In case anyone else is using openvpn. > > % pkg info openvpn > openvpn-2.6.6 > Name : openvpn > Version: 2.6.6 > Installed on : Tue Sep 19 08:48:55 2023 PDT > Origin : security/openvpn > Architecture :

  1   2   >