[PANIC]: rw_lock panic in in_pcballoc() in r185864

[Robert Watson]

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