Re: SVN commit 259045 breaks -CURRENT

Am 15.12.2013 17:27, schrieb Steven Hartland:
> 
> ----- Original Message ----- From: "Stefan Esser" <se_at_freebsd.org>
> To: "Konstantin Belousov" <kostikbel_at_gmail.com>; "Steve Kargl"
> <sgk_at_troutmask.apl.washington.edu>
> Cc: <freebsd-current_at_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