Date: Fri, 27 Jan 2017 16:41:59 +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: <20170127164159.772de4f2@nonamehost> In-Reply-To: <1e7898cf-a746-4289-74a2-fd9571387ca0@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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 27 Jan 2017 15:01:18 +0300 "Andrey V. Elsukov" <ae@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@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170127164159.772de4f2>