Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755008AbYFFKDY (ORCPT ); Fri, 6 Jun 2008 06:03:24 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753323AbYFFKDK (ORCPT ); Fri, 6 Jun 2008 06:03:10 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1]:50722 "EHLO mail.cs.helsinki.fi" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753200AbYFFKDI (ORCPT ); Fri, 6 Jun 2008 06:03:08 -0400 Date: Fri, 6 Jun 2008 13:03:02 +0300 (EEST) From: "=?ISO-8859-1?Q?Ilpo_J=E4rvinen?=" X-X-Sender: ijjarvin@wrl-59.cs.helsinki.fi To: Patrick McManus cc: Ingo Molnar , David Miller , peterz@infradead.org, LKML , Netdev , rjw@sisk.pl, Andrew Morton , johnpol@2ka.mipt.ru Subject: Re: [fixed] [patch] Re: [bug] stuck localhost TCP connections, v2.6.26-rc3+ In-Reply-To: <1212708571.19522.10.camel@tng> Message-ID: References: <20080603094057.GA29480@elte.hu> <20080603.150344.145518113.davem@davemloft.net> <20080605142244.GA19216@elte.hu> <1212708571.19522.10.camel@tng> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-696208474-516156546-1212746582=:16829" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2339 Lines: 59 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---696208474-516156546-1212746582=:16829 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT On Thu, 5 Jun 2008, Patrick McManus wrote: > On Fri, 2008-06-06 at 00:13 +0300, Ilpo J?rvinen wrote: > > > > > I'm out of new ideas what could be still wrong (I got confused and > > lost > > track number of times while I tried to verify socket locking today and > > probably don't have more time for that now)... Unless somebody else > > (Patrick?) comes up with something quickly, > > Sorry, I don't see anything - it seems to boil down to the same code in > the DA and non-DA case as far as I can tell, but after a while all the > twisty passages seem to look alike. :-) This Ingo's testcase should anyway be quite "simple", I mean that distcc shouldn't do anything unexpected in a sense it shouldn't abort the flows by not sending data, close the listening socket or other things like that. > If Ingo confirms that the recv end was running the locking patch code, > it would be interesting to just confirm the sysreq+t looks the same as > before - it is possible the patch turned the race into a non-obvious > deadlock. ...Yes, but we want that from the receiver's host rather than from the sender end. Also checking that sender is still doing window probes once per 2min is probably worth of it though a change in that is quite unlikely. > I'm sure your smaller revert will make the problem go away just as the > larger one did, fwiw. I'd very much except it to. > The other odd thing is that Ingo did a lot of experimentation and was > only making this happen on localhost before (though I agree there is > nothing inherent about that lock and localhost) - isn't it odd that the > first trigger of it now is between two hosts? What do you make of that? ...No, it occurred couple of times in the past between host as well, nothing new in that. -- i. ---696208474-516156546-1212746582=:16829-- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/