From owner-freebsd-current@FreeBSD.ORG Wed Dec 10 22:58:15 2008 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1BD0A1065675; Wed, 10 Dec 2008 22:58:15 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id E8AF78FC12; Wed, 10 Dec 2008 22:58:14 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTP id 89B4846B38; Wed, 10 Dec 2008 17:58:14 -0500 (EST) Date: Wed, 10 Dec 2008 22:58:14 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Roman Divacky In-Reply-To: <20081210214248.GA69246@freebsd.org> Message-ID: References: <20081210164345.GA32188@freebsd.org> <20081210214248.GA69246@freebsd.org> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@FreeBSD.org Subject: Re: [PANIC]: rw_lock panic in in_pcballoc() in r185864 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2008 22:58:15 -0000 On Wed, 10 Dec 2008, Roman Divacky wrote: > hm... I wondered how it could work before that.... anyway, I got this crash Well, nothing says it still works that way, that's just the theory :-). >> So, given that this code has worked for quite a long time for many people, >> this really raises two questions: (1) how reproduceable is this and at what >> point does it kick in during the boot/runtime, and (2) when did this start >> happening in terms of updating your source? > > ad (1): I get this on every boot when dhcp kicks in (it uses udp I believe) > ie. 100% reproducible > > ad (2): Mon Dec 8 23:02:27 CET 2008 kernel (svn up-dated at most 10 minutes > before that) works 100% ok > > I have the crash dump and the kernel at hand so I can do basically anything > you ask me to do :) anything I can provide? Well, to be honest, the easiest thing to do may be to play the binary search game to narrow down the point where the problem starts a bit more. There are a few kinds of things that might lead to this problem -- perhaps we (I?) mucked up initialization of the inpcb with recent changes, or a virtualization-related change tripped something up, or a locking/scheduler change or such. The other thing that would be helpful is a dump of *inp so that we can see what state inp_lock is in. Robert N M Watson Computer Laboratory University of Cambridge