Date: Sun, 15 Dec 2013 14:25:01 +0100 From: Stefan Esser <se@freebsd.org> To: Konstantin Belousov <kostikbel@gmail.com>, Steve Kargl <sgk@troutmask.apl.washington.edu> Cc: freebsd-current@freebsd.org Subject: Re: SVN commit 259045 breaks -CURRENT Message-ID: <52ADADAD.1010108@freebsd.org> In-Reply-To: <20131215054722.GI59496@kib.kiev.ua> References: <52ACD12A.5020906@freebsd.org> <20131214215904.GA24545@troutmask.apl.washington.edu> <52ACD783.7030203@freebsd.org> <20131214221627.GA24637@troutmask.apl.washington.edu> <20131215054722.GI59496@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Regards, STefan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?52ADADAD.1010108>