From owner-freebsd-stable@FreeBSD.ORG Thu Jan 14 12:23:09 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 85871106568F; Thu, 14 Jan 2010 12:23:09 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from constantine.ticketswitch.com (constantine.ticketswitch.com [IPv6:2002:57e0:1d4e:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id 4CA368FC18; Thu, 14 Jan 2010 12:23:09 +0000 (UTC) Received: from dilbert.rattatosk ([10.64.50.6] helo=dilbert.ticketswitch.com) by constantine.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NVOj3-000BX7-U7; Thu, 14 Jan 2010 12:22:57 +0000 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NVOj3-000BYo-TB; Thu, 14 Jan 2010 12:22:57 +0000 Date: Thu, 14 Jan 2010 12:22:57 +0000 Message-Id: To: attilio@freebsd.org, freebsd-stable@freebsd.org In-Reply-To: <3bbf2fe11001130112l26f7370dr2e282455a934a0b@mail.gmail.com> From: Pete French Cc: Subject: Re: [PATCH] Lockmgr deadlock on STABLE_8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2010 12:23:09 -0000 > http://www.freebsd.org/~attilio/lockmgr_fix8.diff > > I'm seeking for testers here. > Any report would be very much appreciated. I tested the patch on my machine which locks up, and I am afraid that it still locks, even with the patch applied. The last things on the console before the lock are. 1) A whole load of sshd errors for one of those flood attacks which try multiple usersnames. This is not unusual, all my systems with an external ssh port see this. 2) Four 'Watchdog timeout occurreed, resetting!" messages from if_bce.c. These are new - without your patch I did not get these. I have tried rnning this machine with WITNESS in the kernel, but it will not deadlock then. Without WiTNESS it will lock up in about twelve hours. I am going to try with just KDB and DDB to see if I can get it into a state where we can get some useful information out of it. I realsie, of course, that this might be utterly unrelated to the problem your patch is trying to address! cheers, -pete.