On 08/03/2021 10:33, Mitidzi Racerex wrote:
Please give a link to RC1 builds.
See the e-mail that was posted on the 6th, 'FreeBSD 13.0-RC1 Now Available'
Thanks
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/
From: Kyle Evans
Subject: Re: Waiting for bufdaemon
Date: Mon, 8 Mar 2021 11:07:23 -0600
> I've tried tracking down exactly what the problem is that causes the
> symptoms we're seeing, but no luck so far. I'm eyeballing the
> following patch which partially reverts kib's 84eaf2ccc6aa05 ("x86:
> s
Please give a link to RC1 builds.
___
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"
Oh,
I am afraid I have to correct myself once again.
I was expecting the change to take effect immediately,
however, after closing all connections to the system,
it indeed seems to have helped to remove TSO6.
Thanks for the quick fix.
However, I will keep an eye on it,
I will do more testing tom
Hi,
thanks for you fast reaction.
I was sceptical about this, since it contrary to my expectations indeed
does affect IPv4 as well, but I tried it anyway and the result is
NEGATIVE.
Removing TSO6 does not help with it, it still spills out crazy sized
Ethernet frames of ~4000 and so on.
On Mon, 2
Hi Lars,
Do you see the TSO6 option enabled on your vtnet interface? Do you
see normal packet sizes if you disable it with "ifconfig vtnet0
-tso6"? Does it actually fix your IPv6 issue?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd
It looks like vtnet driver ignored MTU setting on 13.0-RC1.
I see this on both, IPv4 and IPv6 ... however IPv4 works maybe because
DigitalOcean and Vultr do split those frames on KVM virt host, but
don't do this for IPv6 (I suppose).
Everything about this is strange but so far I have been able to
On Mon, 8 Mar 2021 at 17:00, John-Mark Gurney wrote:
>
> How is the program suppose to tell when the extension is "-e", or -e
> is a different option and not the argument to -I?
-i-e is an in-place edit with extension "-e"
-i -e is an in-place edit with no extension
__
Ed Maste wrote this message on Mon, Mar 08, 2021 at 15:13 -0500:
> A relatively minor but longstanding incompatibility between FreeBSD
> and many other systems is the way sed handles backup files for
> in-place editing -- sed's -I and -i options. GNU sed and other BSDs
> accept an optional argument
On Mon, 8 Mar 2021 at 15:55, Ian Lepore wrote:
>
> I also hate the idea of requiring no space between -I and its related
> value. That seems like a huge POLA violation compared to how virtually
> every other command's options and arguments work.
On the other hand, -i.ext with no space is compati
Ian Lepore wrote in
<8e9983a4243d158789029ec8b16837b35ca4451a.ca...@freebsd.org>:
|On Mon, 2021-03-08 at 15:13 -0500, Ed Maste wrote:
|> A relatively minor but longstanding incompatibility between FreeBSD
|> and many other systems is the way sed handles backup files for
|> in-place editing --
On Mon, 2021-03-08 at 15:13 -0500, Ed Maste wrote:
> A relatively minor but longstanding incompatibility between FreeBSD
> and many other systems is the way sed handles backup files for
> in-place editing -- sed's -I and -i options. GNU sed and other BSDs
> accept an optional argument: -I.bak will
On 2021-03-08 12:13, Ed Maste wrote:
A relatively minor but longstanding incompatibility between FreeBSD
and many other systems is the way sed handles backup files for
in-place editing -- sed's -I and -i options. GNU sed and other BSDs
accept an optional argument: -I.bak will save a backup file w
A relatively minor but longstanding incompatibility between FreeBSD
and many other systems is the way sed handles backup files for
in-place editing -- sed's -I and -i options. GNU sed and other BSDs
accept an optional argument: -I.bak will save a backup file with a
.bak extension, and -I with no ar
On Mon, 8 Mar 2021 at 12:07, Kyle Evans wrote:
>
> diff --git a/sys/x86/x86/tsc.c b/sys/x86/x86/tsc.c
> index 68fc57e6ea7..6f25360a67c 100644
> --- a/sys/x86/x86/tsc.c
> +++ b/sys/x86/x86/tsc.c
> @@ -501,7 +501,12 @@ test_tsc(int adj_max_count)
> uint64_t *data, *tsc;
> u_int i, si
Hey friends,
I am running this FreeBSD 13.0-RC1 and I am experiencing strange
Ethernet frame sizes, TCP sizes well above 2500 on an MTU of 1500.
Somehow it seems that this problem only applies on IPv6,
IPv4 works fine.
I have seen some strange network behaviour with TCP connections
randomly dropp
On Mon, Mar 8, 2021 at 10:51 AM Yasuhiro Kimura wrote:
>
> From: Yasuhiro Kimura
> Subject: Re: Waiting for bufdaemon
> Date: Tue, 09 Mar 2021 00:57:32 +0900 (JST)
>
> > But still one question remains. Why have the value of
> > kern.timecounter.hardware and kern.timecounter.tc.ACPI-fast.counter
>
From: Yasuhiro Kimura
Subject: Re: Waiting for bufdaemon
Date: Tue, 09 Mar 2021 00:57:32 +0900 (JST)
> But still one question remains. Why have the value of
> kern.timecounter.hardware and kern.timecounter.tc.ACPI-fast.counter
> changed by applying the patch? My understanding is that it only make
From: Konstantin Belousov
Subject: Re: Waiting for bufdaemon
Date: Mon, 8 Mar 2021 02:03:13 +0200
> On Sun, Mar 07, 2021 at 02:25:45PM -0600, Kyle Evans wrote:
>> I'm going to be pedantic here, but note that this isn't a tunable. You
>> cannot, AFAIK, influence the timecounter chosen with kenv; i
Hi,
netgraph fails on concurrent node rename as I raised in
https://github.com/genneko/freebsd-vimage-jails/issues/2.
In summary, it gives an error that reads:
"ng_ether_ifnet_arrival_event: can't re-name node vi0_v1" for each
interface.
Which is similar to bug reported in
https://bugs.freebsd.o
20 matches
Mail list logo
