Date: Thu, 11 Dec 2008 19:08:55 +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.0812111905560.43589@fledge.watson.org> In-Reply-To: <20081211174023.GA57297@freebsd.org> References: <20081210164345.GA32188@freebsd.org> <alpine.BSF.1.10.0812101916570.34589@fledge.watson.org> <20081210214248.GA69246@freebsd.org> <alpine.BSF.1.10.0812102253220.36829@fledge.watson.org> <20081211174023.GA57297@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 11 Dec 2008, Roman Divacky wrote: >>> 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. > > it's something between 185772 and 185864, dont you have any dhcp-enabled > machine? if so.. can you reproduce that? I have several boxes, real and virtual, using DHCP and very recent (tm) kernels and no sign of this panic. That's why I think there's something going on here that's a bit more subtle. For example, we'd really like to know what in the rw_wlock() call got tripped over as a NULL pointer... >> The other thing that would be helpful is a dump of *inp so that we can see >> what state inp_lock is in. > > I foolishly deleted the kernel matching the vmcore, I'll try to do that > tomorrow OK. Once you get the panic, I think the most interesting questions have to do with the contents of *inp, *inp->inp_lock.lock_object, etc. It might also be interesting to know whether any UDP use triggers the panic, or just DHCP. You can test this by booting to single-user, configuring lo0 manually, and then doing "dig @127.0.0.1 ." or some other activity that triggers a UDP packet to be sent. 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.0812111905560.43589>