freebsd stable - Jan 2017 - panics collections on FreeBSD 11.0-RC1 RC2 PRERELEASE RELEASE STABLE

On 27.01.2017 14:58, Ivan Klymenko wrote:
> On Fri, 27 Jan 2017 13:46:30 +0300
> "Andrey V. Elsukov" <bu7cher at yandex.ru> wrote:
>
>> On 27.01.2017 01:33, Ivan Klymenko wrote:
>>> The reason most panics served as tuning Netisr:
>>> net.isr.numthreads=4
>>> net.isr.maxthreads=4
>>> net.isr.bindthreads=1
>>>
>>> Apparently, this subsystem at some moment  had been broken.
>>
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211836
>>
>
> Yes you are right.
> But the problem still remains unsolved.
>
> I just removed these settings.
I didn't done the merge of the patch into stable/11 and releng/11.0, 
because Adrian said it is not good enough and he will rework it better :)

-- 
WBR, Andrey V. Elsukov

On Fri, 27 Jan 2017 15:01:18 +0300
"Andrey V. Elsukov" <ae at FreeBSD.org> wrote:
> On 27.01.2017 14:58, Ivan Klymenko wrote:
> > On Fri, 27 Jan 2017 13:46:30 +0300
> > "Andrey V. Elsukov" <bu7cher at yandex.ru> wrote:
> >  
> >> On 27.01.2017 01:33, Ivan Klymenko wrote:  
> >>> The reason most panics served as tuning Netisr:
> >>> net.isr.numthreads=4
> >>> net.isr.maxthreads=4
> >>> net.isr.bindthreads=1
> >>>
> >>> Apparently, this subsystem at some moment  had been broken.  
> >>
> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211836
> >>  
> >
> > Yes you are right.
> > But the problem still remains unsolved.
> >
> > I just removed these settings.  
> 
> I didn't done the merge of the patch into stable/11 and releng/11.0, 
> because Adrian said it is not good enough and he will rework it
> better :)
> 
Thank you for your hard work and efforts.

On Fri, 27 Jan 2017 15:01:18 +0300
"Andrey V. Elsukov" <ae at FreeBSD.org> wrote:
> On 27.01.2017 14:58, Ivan Klymenko wrote:
> > On Fri, 27 Jan 2017 13:46:30 +0300
> > "Andrey V. Elsukov" <bu7cher at yandex.ru> wrote:
> >  
> >> On 27.01.2017 01:33, Ivan Klymenko wrote:  
> >>> The reason most panics served as tuning Netisr:
> >>> net.isr.numthreads=4
> >>> net.isr.maxthreads=4
> >>> net.isr.bindthreads=1
> >>>
> >>> Apparently, this subsystem at some moment  had been broken.  
> >>
> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211836
> >>  
> >
> > Yes you are right.
> > But the problem still remains unsolved.
> >
> > I just removed these settings.  
> 
> I didn't done the merge of the patch into stable/11 and releng/11.0, 
> because Adrian said it is not good enough and he will rework it
> better :)
> 

Jan 27 16:17:07 ns kernel: Fatal trap 12: page fault while in kernel mode
Jan 27 16:17:07 ns kernel: cpuid = 2; apic id = 02
Jan 27 16:17:07 ns kernel: fault virtual address        = 0x8
Jan 27 16:17:07 ns kernel: fault code           = supervisor read data, page not
present
Jan 27 16:17:07 ns kernel: instruction pointer  = 0x20:0xffffffff80b8e170
Jan 27 16:17:07 ns kernel: stack pointer                =
0x28:0xfffffe083b7fc550
Jan 27 16:17:07 ns kernel: frame pointer                =
0x28:0xfffffe083b7fc580
Jan 27 16:17:07 ns kernel: code segment         = base 0x0, limit 0xfffff, type
0x1b
Jan 27 16:17:07 ns kernel: = DPL 0, pres 1, long 1, def32 0, gran 1
Jan 27 16:17:07 ns kernel: processor eflags     = interrupt enabled, resume,
IOPL = 0
Jan 27 16:17:07 ns kernel: current process              = 12 (swi5: fast taskq)
Jan 27 16:17:07 ns kernel: trap number          = 12
Jan 27 16:17:07 ns kernel: panic: page fault
Jan 27 16:17:07 ns kernel: cpuid = 2
Jan 27 16:17:07 ns kernel: KDB: stack backtrace:
Jan 27 16:17:07 ns kernel: #0 0xffffffff80b3ec47 at kdb_backtrace+0x67
Jan 27 16:17:07 ns kernel: #1 0xffffffff80af3a46 at vpanic+0x186
Jan 27 16:17:07 ns kernel: #2 0xffffffff80af38b3 at panic+0x43
Jan 27 16:17:07 ns kernel: #3 0xffffffff8102de30 at trap_fatal+0x320
Jan 27 16:17:07 ns kernel: #4 0xffffffff8102dffc at trap_pfault+0x1bc
Jan 27 16:17:07 ns kernel: #5 0xffffffff8102d6ab at trap+0x27b
Jan 27 16:17:07 ns kernel: #6 0xffffffff8100fd81 at calltrap+0x8
Jan 27 16:17:07 ns kernel: #7 0xffffffff80d2ec9e at tcp_do_segment+0x12ae
Jan 27 16:17:07 ns kernel: #8 0xffffffff80d2d282 at tcp_input+0x14d2
Jan 27 16:17:07 ns kernel: #9 0xffffffff80c94402 at ip_input+0x192
Jan 27 16:17:07 ns kernel: #10 0xffffffff80c2a58d at netisr_dispatch_src+0xad
Jan 27 16:17:07 ns kernel: #11 0xffffffff80c12589 at ether_demux+0x149
Jan 27 16:17:07 ns kernel: #12 0xffffffff82b6971c at
vboxNetFltFreeBSDinput+0x27c
Jan 27 16:17:07 ns kernel: #13 0xffffffff80b520da at taskqueue_run_locked+0x14a
Jan 27 16:17:07 ns kernel: #14 0xffffffff80b51ecf at taskqueue_run+0xbf
Jan 27 16:17:07 ns kernel: #15 0xffffffff80aad3cf at
intr_event_execute_handlers+0x20f
Jan 27 16:17:07 ns kernel: #16 0xffffffff80aad636 at ithread_loop+0xc6
Jan 27 16:17:07 ns kernel: #17 0xffffffff80aa9e75 at fork_exit+0x85
Jan 27 16:17:07 ns kernel: Uptime: 16h19m23s
Jan 27 16:17:07 ns kernel: Dumping 7744 out of 32688
MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%


Alas - I was wrong.
The problem remains urgent.

The panic occurs when a network owncloud service activity in a jail.
I will write again: this problem appears while using jails and VirtualBox.
With switched off the jails - the problem is not reproduced.

I am looking forward the merge of the patch into stable/11 and releng/11.0.

This is a critical issue for me.