Date: Wed, 10 Dec 2008 22:58:14 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Roman Divacky <rdivacky@FreeBSD.org> Cc: current@FreeBSD.org Subject: Re: [PANIC]: rw_lock panic in in_pcballoc() in r185864 Message-ID: <alpine.BSF.1.10.0812102253220.36829@fledge.watson.org> In-Reply-To: <20081210214248.GA69246@freebsd.org> References: <20081210164345.GA32188@freebsd.org> <alpine.BSF.1.10.0812101916570.34589@fledge.watson.org> <20081210214248.GA69246@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.1.10.0812102253220.36829>