thr3ads.net - freebsd stable - panics collections on FreeBSD 11.0-RC1 RC2 PRERELEASE RELEASE STABLE [Jan 2017]

If this information is useful, please help other people find it:
Share via:

Ivan Klymenko

2017-Jan-27 14:41 UTC

panics collections on FreeBSD 11.0-RC1 RC2 PRERELEASE RELEASE STABLE

On Fri, 27 Jan 2017 15:01:18 +0300
"Andrey V. Elsukov" <ae at 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 at 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.

Andrey V. Elsukov

2017-Jan-27 16:16 UTC

head link

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: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 stable - Jan 2017 - panics collections on FreeBSD 11.0-RC1 RC2 PRERELEASE RELEASE STABLE

panics collections on FreeBSD 11.0-RC1 RC2 PRERELEASE RELEASE STABLE

panics collections on FreeBSD 11.0-RC1 RC2 PRERELEASE RELEASE STABLE