> On Thu, Apr 16, 2020 at 12:39 PM Kevin Oberman wrote:
>
> > So you some how had a sort core dump sitting in
> > /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir. The questions, how
> > did get there? I'd take a look at the date on the file and, it it is older
> > than the buildworld, just
On Thu, Apr 16, 2020 at 12:39 PM Kevin Oberman wrote:
> So you some how had a sort core dump sitting in
> /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir. The questions, how
> did get there? I'd take a look at the date on the file and, it it is older
> than the buildworld, just assume that
ai you some how had a sort core dump sitting in
/usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir. The questions, how
did get there? I'd take a look at the date on the file and, it it is older
than the buildworld, just assume that it was left-over garbage. In either
case, you can delete it and
I have a machine running FreeBSD head.
rev 13.0-CURRENT #11 r360008
This is a quite powerful machine, so i thought it was a good idea to let
that server do the build and for my virtualbox machine i can use the
powerful machine to do a installword over NFS.
But when i did the make
> On Apr 10, 2020, at 12:57 AM, Poul-Henning Kamp wrote:
>
>
> In message <9f03fb79-a0ad-3c11-9a50-bc7731882...@fastmail.com>, Yuri Pankov
> writes:
>> Trond Endrestøl wrote:
>>> On Thu, 9 Apr 2020 10:56+0200, Gary Jennejohn wrote:
>>>
OK, I figured it out.
I used to
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
вт, 14 апр. 2020 г., 12:51 Kristof Provost :
> 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
