Re: SVN commit 259045 breaks -CURRENT

----- 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?

    Regards
    Steve

================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. 

In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337
or return the E.mail to postmaster_at_multiplay.co.uk.