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

   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 postmas...@multiplay.co.uk.

_______________________________________________
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"

Reply via email to