panics collections on FreeBSD 11.0-RC1 RC2 PRERELEASE RELEASE STABLE

[Ivan Klymenko]

On Fri, 27 Jan 2017 19:16:04 +0300
"Andrey V. Elsukov" <ae at FreeBSD.org> wrote:

> On 27.01.2017 17:41, Ivan Klymenko wrote:
> >> 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.  
> 
> The panic in PR 211836 is in the netisr code, and they are depend
> from the number of configured netisr threads. Your panics looks
> different and it seems unrelated. It would be good if you fill the PR
> with the details (backtraces from core.txt.N, how your kernel differs
> from the GENERIC, what kernel modules you have loaded, etc).
> 

For some time my operating system now is not write
core.txt.N files after panics.
Now I do not know how to make it do so.
Previously, these files are created, but I have not changed anything
after that.
It is difficult to draw detailed PR.