Am 15.12.2013 17:27, schrieb Steven Hartland: > > ----- Original Message ----- From: "Stefan Esser" <s...@freebsd.org> > To: "Konstantin Belousov" <kostik...@gmail.com>; "Steve Kargl" > <s...@troutmask.apl.washington.edu> > Cc: <freebsd-current@freebsd.org> > Sent: Sunday, December 15, 2013 1:25 PM > Subject: Re: SVN commit 259045 breaks -CURRENT > > >> Am 15.12.2013 06:47, schrieb Konstantin Belousov: >>> On Sat, Dec 14, 2013 at 02:16:27PM -0800, Steve Kargl wrote: >>>> On Sat, Dec 14, 2013 at 11:11:15PM +0100, Stefan Esser wrote: >>>>> Am 14.12.2013 22:59, schrieb Steve Kargl: >>>>>> On Sat, Dec 14, 2013 at 10:44:10PM +0100, Stefan Esser >>>>>> wrote: >>>>>>> >>>>>>> 2) SSH logins are very slow, many seconds of delay between >>>>>>> connect and password prompt, several seconds after password >>>>>>> entry until a command prompt appears (normally >>>>>>> instantaneous) >>>>>>> >>>>>> >>>>>> Ah, so that explains the behavior I'm see. Just updated a >>>>>> circa Aug 3rd i386 FreeBSD to top-of-tree. My ssh logins to >>>>>> my work system take 30+ seconds now. :( >>>>> >>>>> You may want to test the attached patch, which reverts the >>>>> above mentioned commit. >>>>> >>>> >>>> I probably won't get to it until tomorrow, because I had started a >>>> dog-food system purge including re-installing all ports. The laptop >>>> takes a bit a time to recompile everything. >>>> >>> >>> Are you all running i386, compiled with gcc ? >> >> I'm on -CURRENT, CLANG, amd64. But since the problem has also been >> reported for i386 compiled with GCC, there seems to be some problem >> in common kernel code, that has been uncovered by your change, >> >> BTW: I remember seeing two wait channels being reported when I type >> ^T during multi-user startup (sa-spamd, which needs 140 seconds with >> the broken kernel: >> >> nanosleep >> kqueue (I do not remember whether this name is exact or abbreviated) >> >> I've been assuming that the problem might actually be in nanosleep(), >> since this is a timing related function and we are seeing huge >> delays, but eventually the delayed action succeeds. >> >> But a kernel with only kern_conf.c compiled with -fno-strict-overflow >> did not show the delays. I do not have time for further tests, today. > > Delay in ssh login for ~30 is typical if its failing to resolve > the connecting IP. The update didn't break your resolver in anyway > did it?
No, I see a delay of some 3 to 5 seconds between start of the client and password prompt and another delay of 3 to 10 seconds after password entry and login prompt. There is no observable delay with a non-broken kernel. It was not me who reported 30s+ delays for SSH logins. And the delays exist even if connecting to the local SMTP port (e.g. a telnet localhost 25 takes a few seconds to establish the connection). (I had to disable VerifyHostKeyDNS in my SSH client, to prevent a 30s delay on outgoing connections. But this is completely unrelated.) Regards, STefan _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
