Re: panics collections on FreeBSD 11.0-RC1 RC2 PRERELEASE RELEASE STABLE
On Fri, 27 Jan 2017 19:16:04 +0300 "Andrey V. Elsukov" 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:0x80b8e170 Jan 27 16:17:07 ns kernel: stack > > pointer= 0x28:0xfe083b7fc550 Jan 27 16:17:07 ns > > kernel: frame pointer= 0x28:0xfe083b7fc580 Jan > > 27 16:17:07 ns kernel: code segment = base 0x0, limit > > 0xf, 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 0x80b3ec47 at kdb_backtrace+0x67 Jan 27 16:17:07 > > ns kernel: #1 0x80af3a46 at vpanic+0x186 Jan 27 16:17:07 ns > > kernel: #2 0x80af38b3 at panic+0x43 Jan 27 16:17:07 ns > > kernel: #3 0x8102de30 at trap_fatal+0x320 Jan 27 16:17:07 > > ns kernel: #4 0x8102dffc at trap_pfault+0x1bc Jan 27 > > 16:17:07 ns kernel: #5 0x8102d6ab at trap+0x27b Jan 27 > > 16:17:07 ns kernel: #6 0x8100fd81 at calltrap+0x8 Jan 27 > > 16:17:07 ns kernel: #7 0x80d2ec9e at tcp_do_segment+0x12ae > > Jan 27 16:17:07 ns kernel: #8 0x80d2d282 at > > tcp_input+0x14d2 Jan 27 16:17:07 ns kernel: #9 0x80c94402 > > at ip_input+0x192 Jan 27 16:17:07 ns kernel: #10 0x80c2a58d > > at netisr_dispatch_src+0xad Jan 27 16:17:07 ns kernel: #11 > > 0x80c12589 at ether_demux+0x149 Jan 27 16:17:07 ns kernel: > > #12 0x82b6971c at vboxNetFltFreeBSDinput+0x27c Jan 27 > > 16:17:07 ns kernel: #13 0x80b520da at > > taskqueue_run_locked+0x14a Jan 27 16:17:07 ns kernel: #14 > > 0x80b51ecf at taskqueue_run+0xbf Jan 27 16:17:07 ns kernel: > > #15 0x80aad3cf at intr_event_execute_handlers+0x20f Jan 27 > > 16:17:07 ns kernel: #16 0x80aad636 at ithread_loop+0xc6 Jan > > 27 16:17:07 ns kernel: #17 0x80aa9e75 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. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: panics collections on FreeBSD 11.0-RC1 RC2 PRERELEASE RELEASE STABLE
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:0x80b8e170 Jan 27 16:17:07 ns kernel: stack pointer= 0x28:0xfe083b7fc550 Jan 27 16:17:07 ns kernel: frame pointer= 0x28:0xfe083b7fc580 Jan 27 16:17:07 ns kernel: code segment = base 0x0, limit 0xf, 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 0x80b3ec47 at kdb_backtrace+0x67 Jan 27 16:17:07 ns kernel: #1 0x80af3a46 at vpanic+0x186 Jan 27 16:17:07 ns kernel: #2 0x80af38b3 at panic+0x43 Jan 27 16:17:07 ns kernel: #3 0x8102de30 at trap_fatal+0x320 Jan 27 16:17:07 ns kernel: #4 0x8102dffc at trap_pfault+0x1bc Jan 27 16:17:07 ns kernel: #5 0x8102d6ab at trap+0x27b Jan 27 16:17:07 ns kernel: #6 0x8100fd81 at calltrap+0x8 Jan 27 16:17:07 ns kernel: #7 0x80d2ec9e at tcp_do_segment+0x12ae Jan 27 16:17:07 ns kernel: #8 0x80d2d282 at tcp_input+0x14d2 Jan 27 16:17:07 ns kernel: #9 0x80c94402 at ip_input+0x192 Jan 27 16:17:07 ns kernel: #10 0x80c2a58d at netisr_dispatch_src+0xad Jan 27 16:17:07 ns kernel: #11 0x80c12589 at ether_demux+0x149 Jan 27 16:17:07 ns kernel: #12 0x82b6971c at vboxNetFltFreeBSDinput+0x27c Jan 27 16:17:07 ns kernel: #13 0x80b520da at taskqueue_run_locked+0x14a Jan 27 16:17:07 ns kernel: #14 0x80b51ecf at taskqueue_run+0xbf Jan 27 16:17:07 ns kernel: #15 0x80aad3cf at intr_event_execute_handlers+0x20f Jan 27 16:17:07 ns kernel: #16 0x80aad636 at ithread_loop+0xc6 Jan 27 16:17:07 ns kernel: #17 0x80aa9e75 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-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: panics collections on FreeBSD 11.0-RC1 RC2 PRERELEASE RELEASE STABLE
On Fri, 27 Jan 2017 15:01:18 +0300 "Andrey V. Elsukov" wrote: > On 27.01.2017 14:58, Ivan Klymenko wrote: > > On Fri, 27 Jan 2017 13:46:30 +0300 > > "Andrey V. Elsukov" 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:0x80b8e170 Jan 27 16:17:07 ns kernel: stack pointer= 0x28:0xfe083b7fc550 Jan 27 16:17:07 ns kernel: frame pointer= 0x28:0xfe083b7fc580 Jan 27 16:17:07 ns kernel: code segment = base 0x0, limit 0xf, 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 0x80b3ec47 at kdb_backtrace+0x67 Jan 27 16:17:07 ns kernel: #1 0x80af3a46 at vpanic+0x186 Jan 27 16:17:07 ns kernel: #2 0x80af38b3 at panic+0x43 Jan 27 16:17:07 ns kernel: #3 0x8102de30 at trap_fatal+0x320 Jan 27 16:17:07 ns kernel: #4 0x8102dffc at trap_pfault+0x1bc Jan 27 16:17:07 ns kernel: #5 0x8102d6ab at trap+0x27b Jan 27 16:17:07 ns kernel: #6 0x8100fd81 at calltrap+0x8 Jan 27 16:17:07 ns kernel: #7 0x80d2ec9e at tcp_do_segment+0x12ae Jan 27 16:17:07 ns kernel: #8 0x80d2d282 at tcp_input+0x14d2 Jan 27 16:17:07 ns kernel: #9 0x80c94402 at ip_input+0x192 Jan 27 16:17:07 ns kernel: #10 0x80c2a58d at netisr_dispatch_src+0xad Jan 27 16:17:07 ns kernel: #11 0x80c12589 at ether_demux+0x149 Jan 27 16:17:07 ns kernel: #12 0x82b6971c at vboxNetFltFreeBSDinput+0x27c Jan 27 16:17:07 ns kernel: #13 0x80b520da at taskqueue_run_locked+0x14a Jan 27 16:17:07 ns kernel: #14 0x80b51ecf at taskqueue_run+0xbf Jan 27 16:17:07 ns kernel: #15 0x80aad3cf at intr_event_execute_handlers+0x20f Jan 27 16:17:07 ns kernel: #16 0x80aad636 at ithread_loop+0xc6 Jan 27 16:17:07 ns kernel: #17 0x80aa9e75 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. ___ freebsd-stable@freebsd.org mailing list https://lis
Re: reset not working like 70% of the time
On Wed, 25 Jan 2017 15:24:55 +0500 "Eugene M. Zheganin" wrote: > I'm seeing all of these in my konsole terminal window while working with Does it also happen if you use another terminal emulator insted of konsole? -- Torfinn Ingolfsen ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: [SOLVED] panics collections on FreeBSD 11.0-RC1 RC2 PRERELEASE RELEASE STABLE
On Fri, 27 Jan 2017 15:01:18 +0300 "Andrey V. Elsukov" wrote: > On 27.01.2017 14:58, Ivan Klymenko wrote: > > On Fri, 27 Jan 2017 13:46:30 +0300 > > "Andrey V. Elsukov" 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 :) > Thank you for your hard work and efforts. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: [SOLVED] panics collections on FreeBSD 11.0-RC1 RC2 PRERELEASE RELEASE STABLE
On 27.01.2017 14:58, Ivan Klymenko wrote: On Fri, 27 Jan 2017 13:46:30 +0300 "Andrey V. Elsukov" 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 :) -- WBR, Andrey V. Elsukov ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: [SOLVED] panics collections on FreeBSD 11.0-RC1 RC2 PRERELEASE RELEASE STABLE
On Fri, 27 Jan 2017 13:46:30 +0300 "Andrey V. Elsukov" 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. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: [SOLVED] panics collections on FreeBSD 11.0-RC1 RC2 PRERELEASE RELEASE STABLE
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 -- WBR, Andrey V. Elsukov ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
