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

On Thu, Dec 11, 2008 at 07:08:55PM +0000, Robert Watson wrote:
> 
> 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 _at_127.0.0.1 ." or some other activity that 
> triggers a UDP packet to be sent.

I just booted r185942 and it seems to work fine, so I guess it could
have been some stale obj file or something.

sorry for the noise