On 12/11/17(Sun) 22:10, Stuart Henderson wrote:
> On 2017/11/12 22:48, Martin Pieuchot wrote:
> > On 12/11/17(Sun) 21:30, Stuart Henderson wrote:
> > > iked box, GENERIC.MP + WITNESS, -current as of Friday 10th:
> > 
> > Weird, did you tweak "kern.splassert" on this box?   Otherwise is looks
> > like a major corruption.
> 
> It would have kern.splassert=2. (I know this can cause problems
> sometimes, though this would be the first time in 5+ years I've bumped
> into it, most of my routers where I have serial console have this set).

Well the panic below correspond to a value of 0 or > 3.

> > > login: panic: kernel diagnostic assertion "_kernel_lock_held()" failed: 
> > > file "/src/cvs-openbsd/sys/kern/uipc_socket2.c", line 310
> > ^^^
> > Looks like one CPU is triggering this.
> > 
> > > splassert: soassertlocked: want 1 have 256
> > > 
> > > panic: spl assertion failure in soassertlocked
> > ^^^
> > That can't be coming from the same CPU..
> > 
> > 
> > 
> > 
> > > Starting stack trace...
> > > Faulted in traceback, aborting...
> > > panic(splassert: if_down: want 1 have 256
> > > panic: spl assertion failure in if_down) at
> > > Faulted in traceback, aborting...
> > > panicsplassert: if_down: want 1 have 256
> > > +0x133panic: spl assertion failure in if_down
> > > Faulted in traceback, aborting...
> > > 
> > > <repeated a few times>
> > > 
> > > It's stuck at this point, I can't enter ddb.
> > 
> > Are you running with WITNESS on purpose?  Can you reproduce such problem
> > without it?  I'm not saying it's WITNESS fault, but it's clear that
> > WITNESS kernels aren't ready for production yet.
> > 
> 
> I'm trying to get more information because it had either hanged or
> panicked previously (it didn't have serial connected at the time and
> the machine was needed so it had to be rebooted before I had chance
> to dig into it).

>From which snapshot was the kernel that hanged or panic'd?

Reply via email to