Date: Fri, 27 Jan 2017 18:40:20 +0200 From: Ivan Klymenko <fidaj@ukr.net> To: "Andrey V. Elsukov" <ae@FreeBSD.org> Cc: freebsd-bugs@freebsd.org, freebsd-stable@freebsd.org, hiren panchasara <hiren@strugglingcoder.info>, Adrian Chadd <adrian@FreeBSD.org> Subject: Re: panics collections on FreeBSD 11.0-RC1 RC2 PRERELEASE RELEASE STABLE Message-ID: <20170127184020.6c730b8e@nonamehost> In-Reply-To: <3be020a7-b68e-ad69-78b2-e16c3d6286ae@FreeBSD.org> References: <20161021220413.1d130f5c@nonamehost> <20161228095808.64d617de@nonamehost> <20161228174142.GB17818@strugglingcoder.info> <20161228195333.120e844f@nonamehost> <20161228175729.GC17818@strugglingcoder.info> <20170127003310.15c5a828@nonamehost> <478d912c-b9ed-44e0-6afb-c3f30cefec6b@yandex.ru> <20170127135859.30628eb7@nonamehost> <1e7898cf-a746-4289-74a2-fd9571387ca0@FreeBSD.org> <20170127164159.772de4f2@nonamehost> <3be020a7-b68e-ad69-78b2-e16c3d6286ae@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 27 Jan 2017 19:16:04 +0300 "Andrey V. Elsukov" <ae@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170127184020.6c730b8e>