[PANIC]: rw_lock panic in in_pcballoc() in r185864
rwatson at FreeBSD.org
Thu Dec 11 19:08:55 UTC 2008
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
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
University of Cambridge
More information about the freebsd-current