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
_______________________________________________
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
