Re: [Asterisk-bsd] Asterisk13 coredump on freebsd 11.1
On Thu, Sep 28, 2017 at 01:17:24AM +0200, Hans Petter Selasky wrote:
> Hi,
>
> I just upgraded and hit these SEGFAULTs too. First of all you need to
> install GDB 8.0 from ports to get the right backtrace (important). This
> leads straight into LibUnwind in libgcc:
>
> (gdb) bt
> #0 uw_frame_state_for (context=context@entry=0x7fffdf3bbe20,
> fs=fs@entry=0x7fffdf3bbb70)
> at /wrkdirs/usr/ports/lang/gcc6/work/gcc-6.4.0/libgcc/unwind-dw2.c:1249
> #1 0x000802cc8ffb in _Unwind_ForcedUnwind_Phase2
> (exc=exc@entry=0x804427230,
> context=context@entry=0x7fffdf3bbe20) at
> /wrkdirs/usr/ports/lang/gcc6/work/gcc-6.4.0/libgcc/unwind.inc:155
> #2 0x000802cc9334 in _Unwind_ForcedUnwind (exc=0x804427230,
> stop=0x8024d5450 ,
> stop_argument=) at
> /wrkdirs/usr/ports/lang/gcc6/work/gcc-6.4.0/libgcc/unwind.inc:207
> #3 0x0008024d52b3 in _Unwind_ForcedUnwind (ex=,
> stop_func=0x7fffdf3bb948, stop_arg=0x804427000)
> at /usr/img/freebsd.11/lib/libthr/thread/thr_exit.c:106
> #4 thread_unwind () at /usr/img/freebsd.11/lib/libthr/thread/thr_exit.c:172
> #5 _pthread_exit_mask (status=, mask=)
> at /usr/img/freebsd.11/lib/libthr/thread/thr_exit.c:257
> #6 0x0008024d50db in _pthread_exit (status=0x804427000) at
> /usr/img/freebsd.11/lib/libthr/thread/thr_exit.c:206
> #7 0x0008024c7c0d in thread_start (curthread=0x804427000)
> at /usr/img/freebsd.11/lib/libthr/thread/thr_create.c:289
> #8 0x7fffdf34 in ?? ()
> Backtrace stopped: Cannot access memory at address 0x7fffdf3bc000
>
> libgcc uses this format which is OK:
>
> (gdb) ptype struct _Unwind_Context
> type = struct _Unwind_Context {
> _Unwind_Context_Reg_Val reg[18];
> void *cfa;
> void *ra;
> void *lsda;
> struct dwarf_eh_bases bases;
> _Unwind_Word flags;
> _Unwind_Word version;
> _Unwind_Word args_size;
> char by_value[18];
> }
>
> > x86_64_freebsd_fallback_frame_state
> > (struct _Unwind_Context *context, _Unwind_FrameState *fs)
> > {
> > struct sigframe *sf;
> > long new_cfa;
> >
> > /* Prior to FreeBSD 9, the signal trampoline was located immediately
> > before the ps_strings. To support non-executable stacks on AMD64,
> > the sigtramp was moved to a shared page for FreeBSD 9. Unfortunately
> > this means looking frame patterns again (sys/amd64/amd64/sigtramp.S)
> > rather than using the robust and convenient KERN_PS_STRINGS trick.
> >
> > : lea 0x10(%rsp),%rdi
> > : pushq $0x0
> > : mov $0x1a1,%rax
> > : syscall
> >
> > If we can't find this pattern, we're at the end of the stack.
> > */
> >
> > if (!( *(unsigned int *)(context->ra) == 0x247c8d48
> fault is triggered by this read access on the stack
> > && *(unsigned int *)(context->ra + 4) == 0x48006a10
> > && *(unsigned int *)(context->ra + 8) == 0x01a1c0c7
> > && *(unsigned int *)(context->ra + 12) == 0x050f ))
> > return _URC_END_OF_STACK;
> >
>
> The code in question is trying to access the return address of the
> caller on the stack which apparently I think is caught by the recently
> added MAP_GUARD feature:
>
> https://svnweb.freebsd.org/changeset/base/320763
>
> I think this feature can be disabled by setting:
> sysctl security.bsd.stack_guard_page=0
>
> And then restart Asterisk. Not sure if it helps, currently testing.
> This my best guess why Asterisk started segfaulting when upgrading to 11.1.
See this thread on current
https://lists.freebsd.org/pipermail/freebsd-current/2017-August/066855.html
which contained at least two variants of the supposed improvements.
___
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: Bind9 + TCP_FASTOPEN => no rndc
On Wed, Sep 27, 2017 at 09:17:29PM +, Dimitry Andric wrote:
> On 27 Sep 2017, at 19:35, Christopher Sean Hilton wrote:
> >
> > I'm trying to configure bind 9.11 as a nameserver on FreeBSD
> > 11-STABLE. When the bind9 port compile it enables TCP_FASTOPEN but the
> > changes haven't yet been baked into the GENERIC Kernel. I can't find a
> > way to disable the use of TCP_FASTOPEN in bind at startup. Is the only
> > way to fix this problem to build a new kernel with TCP_FASTOPEN
> > enabled?
>
> It looks like bind enables use of TCP_FASTOPEN whenever its configure
> script finds the define in the system headers. But it does not check
> whether the functionality actually works with setsockopt.
>
> In any case, the message is harmless noise, as any errors are ignored:
>
> #if defined(ISC_PLATFORM_HAVETFO) && defined(TCP_FASTOPEN)
> #ifdef __APPLE__
> backlog = 1;
> #else
> backlog = backlog / 2;
> if (backlog == 0)
> backlog = 1;
> #endif
> if (setsockopt(sock->fd, IPPROTO_TCP, TCP_FASTOPEN,
>(void *)&backlog, sizeof(backlog)) < 0) {
> isc__strerror(errno, strbuf, sizeof(strbuf));
> UNEXPECTED_ERROR(__FILE__, __LINE__,
> "setsockopt(%d, TCP_FASTOPEN) failed with
> %s",
> sock->fd, strbuf);
> /* TCP_FASTOPEN is experimental so ignore failures */
> }
> #endif
>
Great,
I assumed that the FASTOPEN failure was related to the inablity to
open the rndc socket. I'll have to debug the rndc socket seperately.
Thanks for help!
-- Chris
--
Chris
__o "All I was trying to do was get home from work."
_`\<,_ -Rosa Parks
___(*)/_(*).___o..___..o...ooO..._
Christopher Sean Hilton[chris/at/vindaloo/dot/com]
___
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: Bind9 + TCP_FASTOPEN => no rndc
On Thu, Sep 28, 2017 at 02:20:47PM +, Christopher Sean Hilton wrote: > Great, > > I assumed that the FASTOPEN failure was related to the inablity to > open the rndc socket. I'll have to debug the rndc socket seperately. > > > Thanks for help! > This had nothing to do with FASTOPEN and everything to do with moving named from the base system to ports. The solution is to explicitly configure the location of the rndc.key file in named.conf. Otherwise named looks in the wrong directory to find it and then fails. Simple when you know what's wrong. -- Chris __o "All I was trying to do was get home from work." _`\<,_ -Rosa Parks ___(*)/_(*).___o..___..o...ooO..._ Christopher Sean Hilton[chris/at/vindaloo/dot/com] ___ 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"
[Solved] Bind9 + TCP_FASTOPEN => no rndc
On Thu, Sep 28, 2017 at 03:28:17PM +, Christopher Sean Hilton wrote: > On Thu, Sep 28, 2017 at 02:20:47PM +, Christopher Sean Hilton wrote: > > Great, > > > > I assumed that the FASTOPEN failure was related to the inablity to > > open the rndc socket. I'll have to debug the rndc socket seperately. > > > > > > Thanks for help! > > > Just a note for future readers to say that the fix from the previous message solved this problem. -- Chris __o "All I was trying to do was get home from work." _`\<,_ -Rosa Parks ___(*)/_(*).___o..___..o...ooO..._ Christopher Sean Hilton[chris/at/vindaloo/dot/com] ___ 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: 11.1 running on HyperV hn interface hangs
On Thu, 14 Sep 2017 09:54:56 +0800 Sepherosa Ziehau wrote: > If you have any updates on this, please let me know. There is still > time for 10.4. We are still playing around with this in the lab... Running similar setup as the customer Microsoft Windows Server 2012 R2 Datacentre (6.3.9600) Revision 16384 Hyper-V 2012 Two VM guests - 11.0-RELEASE - 11.1-p1 We can not get the Hyper-V hn interface to lock up like the customer can though. We can get the VMs to hang/stall regularly if the guests run ntpd - approx every 15 mins, but no real obvious pattern to it. Disabling ntpd fixes it. Paul. -- Paul Koch | Founder | CEO AKIPS Network Monitor | akips.com Brisbane, Australia ___ 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: 11.1 running on HyperV hn interface hangs
On Fri, Sep 29, 2017 at 12:36 PM, Paul Koch wrote: > On Thu, 14 Sep 2017 09:54:56 +0800 > Sepherosa Ziehau wrote: > >> If you have any updates on this, please let me know. There is still >> time for 10.4. > > We are still playing around with this in the lab... > > Running similar setup as the customer > Microsoft Windows Server 2012 R2 Datacentre (6.3.9600) Revision 16384 > Hyper-V 2012 > > Two VM guests > - 11.0-RELEASE > - 11.1-p1 > > We can not get the Hyper-V hn interface to lock up like the customer can > though. > > We can get the VMs to hang/stall regularly if the guests run ntpd - approx > every 15 mins, but no real obvious pattern to it. Disabling ntpd fixes it. Hmm, by ntpd I think you mean ntp client? You will have to disable timesync if you run ntp client: sysctl hw.hvtimesync.sample_thresh=-1 sysctl hw.hvtimesync.ignore_sync=1 They interfere w/ each other. Or do you mean the network hanging triggered by "RXBUF ack failed"? Thanks, sephe -- Tomorrow Will Never Die ___ 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: 11.1 running on HyperV hn interface hangs
On Fri, 29 Sep 2017 13:31:22 +0800 Sepherosa Ziehau wrote: > On Fri, Sep 29, 2017 at 12:36 PM, Paul Koch wrote: > > On Thu, 14 Sep 2017 09:54:56 +0800 > > Sepherosa Ziehau wrote: > > > >> If you have any updates on this, please let me know. There is still > >> time for 10.4. > > > > We are still playing around with this in the lab... > > > > Running similar setup as the customer > > Microsoft Windows Server 2012 R2 Datacentre (6.3.9600) Revision 16384 > > Hyper-V 2012 > > > > Two VM guests > > - 11.0-RELEASE > > - 11.1-p1 > > > > We can not get the Hyper-V hn interface to lock up like the customer can > > though. > > > > We can get the VMs to hang/stall regularly if the guests run ntpd - approx > > every 15 mins, but no real obvious pattern to it. Disabling ntpd fixes > > it. > > Hmm, by ntpd I think you mean ntp client? You will have to disable > timesync if you run ntp client: > sysctl hw.hvtimesync.sample_thresh=-1 > sysctl hw.hvtimesync.ignore_sync=1 > > They interfere w/ each other. > > Or do you mean the network hanging triggered by "RXBUF ack failed"? > > Thanks, > sephe Yes, ntp client running on the VM guest. After finding it was unstable, we concluded that there must be some type of interference. Best that we automatically force ntp off when our software detects it is running in Hyper-V. We haven't been able to trigger the hn to hang like our customer can with the RXBUF problem though. Different underlying hardware probably. Paul. -- Paul Koch | Founder | CEO AKIPS Network Monitor | akips.com Brisbane, Australia ___ 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"
