Re: console getty uses 1.5% of CPU
Poul-Henning Kamp writes: > I have two 12.2-R systems where the serial console is attached to a terminal > server. > > When there are no TCP connections to the terminal server, getty soaks up 1.5% > of the > CPU in the kernel (sleeping in "ttyin"), ktrace shows no system calls. > > When a TCP connection is made to the terminal server, which raises the > modem-handshake > on the DE-9 connector, the CPU usage stops. > > Anybody else seeing something like this ? Just checked, also happens on a similar box running 13.0-ALPHA3 -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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"
console getty uses 1.5% of CPU
I have two 12.2-R systems where the serial console is attached to a terminal server. When there are no TCP connections to the terminal server, getty soaks up 1.5% of the CPU in the kernel (sleeping in "ttyin"), ktrace shows no system calls. When a TCP connection is made to the terminal server, which raises the modem-handshake on the DE-9 connector, the CPU usage stops. Anybody else seeing something like this ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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"
Re: ZFS not mount at boot
On 05.04.21 18:17, Yuri Pankov wrote: - in /etc/rc.conf: zfs_enabled="YES" If this is exactly what you have in rc.conf, then it's the problem -- it should be "enable", not "enabled". This fixed the issue, thank you! -- xpetrl ___ 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"
Re: TCP Connection hang - MSS again
> On 6. Apr 2021, at 19:02, Rodney W. Grimes > wrote: > >> 06.04.2021 19:54, Rodney W. Grimes wrote: 05.04.2021 19:44, Rozhuk Ivan wrote: >>> As I understand, in some cases remote host does not reply with MSS >>> option, and host behind router continue use mss 8960, that dropped >>> by router. >> If the peer does not provide an MSS option, your local FreeBSD based >> host should use an MSS of net.inet.tcp.mssdflt bytes. The default is >> 536. So I don't think this should be a problem. > > Thats it! > Thanks, it was ~64k in mine config. This is also per-host setting, you know :-) It is generally bad idea using MTU over 1500 for an interface facing public network without -mtu 1500. You see, because TCP MSS affects only TCP and there is also UDP that happily produces oversized datagramms for DNS or RTP or NFS or tunneling like L2TP or OpenVPN etc. relying on IP fragmentation. I still recommend using -mtu 1500 in addition to mssdflt in your case. >>> >>> I do not recommend such a setting. That would defeat any jumbo frame usage >>> locally! >> >> Why? Default route should not be used for local delivery. > > Your right, but we are both making assumptions, I assumed that most > likely the only route on the system is the default route, and your > assuming that they are running with something more than a default > route. > >>> The gateway/router that is forwarding packets to the internet connection >>> needs its upstream interface mtu set properly, and configured to properly >>> return icmp need fragement messages on the interfaces towards the >>> internal network. >> >> This results in extra delays and retransmission during outgoing data >> transfer, not good. >> The mechanics is much more fragile than default route's mtu attribute. > > The delay should be pretty slight, the router is going to return an > icmp message, and if configured to do so frag the packets and > forward them on, no retransmission would occur as the DF flag > is not normally set unless explicitly requested. 1. Isn't a router either fragmenting a packet and forwarding the fragments or sending back an ICMP packet and dropping the packet? 2. Isn't FreeBSDs TCP implementation setting the DF bit, if net.inet.tcp.path_mtu_discovery is set to 1, which is the default. So it would take one RTT to the router For TCP to react and reduce the MSS. Best regards Michael > > It still makes no since to me to increase the interface MTU and then > crank it back down by using a route MTU. You might as well just leave > the MTU alone and not have 2 configurations items more or less doing > nothing. > > -- > Rod Grimes rgri...@freebsd.org > ___ > freebsd-...@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" ___ 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"
Re: Problem compiling libgit2
On 06/04/21 18:59, Filippo Moretti via freebsd-current wrote: After moving ports to git I had the following error while updating libgit2:===> Extracting for libgit2-1.1.0 => ===> Extracting for libgit2-1.1.0 => SHA256 Checksum OK for libgit2-1.1.0.tar.gz. ===> Patching for libgit2-1.1.0 sed: /usr/ports/devel/libgit2/work/libgit2-1.1.0/cmake/Modules/SelectHTTPSBackend.cmake: No such file or directory *** Error code 1 Stop. make[1]: stopped in /usr/ports/devel/libgit2 *** Error code 1 Stop. make: stopped in /usr/ports/devel/libgit2 my system:root@STING /usr/ports/devel/libgit2]# uname -a FreeBSD STING 14.0-CURRENT FreeBSD 14.0-CURRENT #23 main-n245729-51cc31088bf: Tue Mar 30 18:58:45 CEST 2021 root@STING:/usr/obj/usr/src/amd64.amd64/sys/STING amd64 It's been fixed, update your ports tree. -- Guido Falsi ___ 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"
Re: TCP Connection hang - MSS again
> 06.04.2021 19:54, Rodney W. Grimes wrote: > >> 05.04.2021 19:44, Rozhuk Ivan wrote: > >> > > As I understand, in some cases remote host does not reply with MSS > > option, and host behind router continue use mss 8960, that dropped > > by router. > If the peer does not provide an MSS option, your local FreeBSD based > host should use an MSS of net.inet.tcp.mssdflt bytes. The default is > 536. So I don't think this should be a problem. > >>> > >>> Thats it! > >>> Thanks, it was ~64k in mine config. > >> > >> This is also per-host setting, you know :-) > >> > >> It is generally bad idea using MTU over 1500 for an interface facing > >> public network > >> without -mtu 1500. You see, because TCP MSS affects only TCP and there is > >> also UDP > >> that happily produces oversized datagramms for DNS or RTP or NFS or > >> tunneling like L2TP or OpenVPN etc. > >> relying on IP fragmentation. > >> > >> I still recommend using -mtu 1500 in addition to mssdflt in your case. > > > > I do not recommend such a setting. That would defeat any jumbo frame usage > > locally! > > Why? Default route should not be used for local delivery. Your right, but we are both making assumptions, I assumed that most likely the only route on the system is the default route, and your assuming that they are running with something more than a default route. > > The gateway/router that is forwarding packets to the internet connection > > needs its upstream interface mtu set properly, and configured to properly > > return icmp need fragement messages on the interfaces towards the > > internal network. > > This results in extra delays and retransmission during outgoing data > transfer, not good. > The mechanics is much more fragile than default route's mtu attribute. The delay should be pretty slight, the router is going to return an icmp message, and if configured to do so frag the packets and forward them on, no retransmission would occur as the DF flag is not normally set unless explicitly requested. It still makes no since to me to increase the interface MTU and then crank it back down by using a route MTU. You might as well just leave the MTU alone and not have 2 configurations items more or less doing nothing. -- Rod Grimes rgri...@freebsd.org ___ 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"
Problem compiling libgit2
After moving ports to git I had the following error while updating libgit2:===> Extracting for libgit2-1.1.0 => ===> Extracting for libgit2-1.1.0 => SHA256 Checksum OK for libgit2-1.1.0.tar.gz. ===> Patching for libgit2-1.1.0 sed: /usr/ports/devel/libgit2/work/libgit2-1.1.0/cmake/Modules/SelectHTTPSBackend.cmake: No such file or directory *** Error code 1 Stop. make[1]: stopped in /usr/ports/devel/libgit2 *** Error code 1 Stop. make: stopped in /usr/ports/devel/libgit2 my system:root@STING /usr/ports/devel/libgit2]# uname -a FreeBSD STING 14.0-CURRENT FreeBSD 14.0-CURRENT #23 main-n245729-51cc31088bf: Tue Mar 30 18:58:45 CEST 2021 root@STING:/usr/obj/usr/src/amd64.amd64/sys/STING amd64 Filippo ___ 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"
Re: TCP Connection hang - MSS again
06.04.2021 19:54, Rodney W. Grimes wrote: >> 05.04.2021 19:44, Rozhuk Ivan wrote: >> > As I understand, in some cases remote host does not reply with MSS > option, and host behind router continue use mss 8960, that dropped > by router. If the peer does not provide an MSS option, your local FreeBSD based host should use an MSS of net.inet.tcp.mssdflt bytes. The default is 536. So I don't think this should be a problem. >>> >>> Thats it! >>> Thanks, it was ~64k in mine config. >> >> This is also per-host setting, you know :-) >> >> It is generally bad idea using MTU over 1500 for an interface facing public >> network >> without -mtu 1500. You see, because TCP MSS affects only TCP and there is >> also UDP >> that happily produces oversized datagramms for DNS or RTP or NFS or >> tunneling like L2TP or OpenVPN etc. >> relying on IP fragmentation. >> >> I still recommend using -mtu 1500 in addition to mssdflt in your case. > > I do not recommend such a setting. That would defeat any jumbo frame usage > locally! Why? Default route should not be used for local delivery. > The gateway/router that is forwarding packets to the internet connection > needs its upstream interface mtu set properly, and configured to properly > return icmp need fragement messages on the interfaces towards the > internal network. This results in extra delays and retransmission during outgoing data transfer, not good. The mechanics is much more fragile than default route's mtu attribute. ___ 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"
Re: TCP Connection hang - MSS again
> 05.04.2021 19:44, Rozhuk Ivan wrote: > > >>> As I understand, in some cases remote host does not reply with MSS > >>> option, and host behind router continue use mss 8960, that dropped > >>> by router. > >> If the peer does not provide an MSS option, your local FreeBSD based > >> host should use an MSS of net.inet.tcp.mssdflt bytes. The default is > >> 536. So I don't think this should be a problem. > > > > Thats it! > > Thanks, it was ~64k in mine config. > > This is also per-host setting, you know :-) > > It is generally bad idea using MTU over 1500 for an interface facing public > network > without -mtu 1500. You see, because TCP MSS affects only TCP and there is > also UDP > that happily produces oversized datagramms for DNS or RTP or NFS or tunneling > like L2TP or OpenVPN etc. > relying on IP fragmentation. > > I still recommend using -mtu 1500 in addition to mssdflt in your case. I do not recommend such a setting. That would defeat any jumbo frame usage locally! The gateway/router that is forwarding packets to the internet connection needs its upstream interface mtu set properly, and configured to properly return icmp need fragement messages on the interfaces towards the internal network. This leaking of jumbo frames to the Internet is almost always caused by blockage of icmp packets internal to a network, and doing that forces one to run on an mtu that is acceptable to the global Internet, a far from optimal situation. -- Rod Grimes rgri...@freebsd.org ___ 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"
Re: TCP Connection hang - MSS again
05.04.2021 19:44, Rozhuk Ivan wrote: >>> As I understand, in some cases remote host does not reply with MSS >>> option, and host behind router continue use mss 8960, that dropped >>> by router. >> If the peer does not provide an MSS option, your local FreeBSD based >> host should use an MSS of net.inet.tcp.mssdflt bytes. The default is >> 536. So I don't think this should be a problem. > > Thats it! > Thanks, it was ~64k in mine config. This is also per-host setting, you know :-) It is generally bad idea using MTU over 1500 for an interface facing public network without -mtu 1500. You see, because TCP MSS affects only TCP and there is also UDP that happily produces oversized datagramms for DNS or RTP or NFS or tunneling like L2TP or OpenVPN etc. relying on IP fragmentation. I still recommend using -mtu 1500 in addition to mssdflt in your case. ___ 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"
