On 2010-04-28 15:44:29 (+0300), Alexander Motin 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, 88SX7042 (includin
On 2010-05-04 08:11:09 (+0300), Alexander Motin 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 fr
On 2010-06-13 23:37:23 (+0900), Norikatsu Shigemura 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.
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
On 2010-06-20 21:03:51 (+0900), Norikatsu Shigemura wrote:
> On Sun, 13 Jun 2010 22:13:31 +0200
> Kristof Provost wrote:
> > > I have a OpenRD Ultimate, which has two GbE ports - if_mge(4). But
> > > I couldn't use mge1 like followin
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 the
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
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 f
uture
reference 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
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 vl
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 ke
> 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 m
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;
linker_
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 bit o
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
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 (pfil_run
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 tests
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
* sys.netpfil.pf.set_tos.
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
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
On 2015-02-23 17:23:55 (-0800), Davide Italiano wrote:
> On Mon, Feb 23, 2015 at 5:17 PM, Allan Jude 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 suggest this could be stack
On 2015-02-24 08:05:47 (+0100), Kristof Provost wrote:
> On 2015-02-23 17:23:55 (-0800), Davide Italiano wrote:
> > The bt you posted suggest this could be stack overflow, probably due
> > to infinite recursion.
> > Also, as a wild guess, just looking at the stacktrace, I th
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 0xfff
On 2015-08-09 13:36:35 (+0300), Gleb Smirnoff 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 10
> 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 jails aren't working anymore
> On 02 Nov 2015, at 15:07, Shawn Webb 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 can
>> reproduce it. It’s o
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 issue with r289932 t
> 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 why this change ca
> 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 works:
>
> nat on wlan0 from
> 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
> feature enabled)
>
Thi
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 if_pfsync.c
>
Most of them
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 strange.
I've built the drm-i
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 true, but that only a
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 2.2.6)
>
> 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
___
> On 12 Feb 2016, at 10:18, Larry Rosenman 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 wrote:
>>> Fr
> 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 it’s possible that th
> On 12 Feb 2016, at 15:33, Larry Rosenman wrote:
>
> On 2016-02-12 08:31, Kristof Provost wrote:
>>> 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
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
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
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, the
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
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
t
On 2011-11-15 18:10:01 (+0100), GR 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 address b
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 v
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
On 2013-06-14 23:07:02 (+0200), Alexander Leidinger
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 = su
On 2013-06-24 22:08:01 (+0200), Alexander Leidinger
wrote:
> On Mon, 24 Jun 2013 12:15:18 +0200
> Kristof Provost 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
&g
On 2013-06-29 18:49:16 (+0200), Martin Matuska 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 these operation
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, &pcr) == 0 &&
> ^
> fw-pf.c:252:22: error: use of undeclared ide
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
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 : FreeBSD:1
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
> 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. :(
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
> igb
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 do
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
___
f
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
_
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 NO_SUBDI
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/ne
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 tes
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 c
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 cu
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
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
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
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
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 now.
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 2020-0
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
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 outp
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 str
.
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"
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
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.
It
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
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:
`s
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..
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
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
Ed
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 (driv
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.
>
T
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
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
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, but
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
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
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 m
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 man
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:
https://cg
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
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 detectio
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 no
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 p
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 does
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 fil
> 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
>>> binaries
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:
> [...]freebsd
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, ev
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:
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
1 - 100 of 103 matches
Mail list logo
