panics collections on FreeBSD 11.0-RC1 RC2 PRERELEASE RELEASE STABLE

[Andrey V. Elsukov]

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).

-- 
WBR, Andrey V. Elsukov