Re: ntpd segfaults on start
On Thu, Sep 05, 2019, Vladimir Zakharov wrote: > Hello! > > Accidentally it turned out that the ntpd does not start on boot. > Logs show that it core dumps: > 2019-09-05T08:38:43.588563+03:00 vzakharov ntpd 34934 - - ntpd 4.2.8p12-a > (1): Starting > 2019-09-05T08:38:43.588717+03:00 vzakharov kernel - - - Security policy > loaded: MAC/ntpd (mac_ntpd) > 2019-09-05T08:38:43.718356+03:00 vzakharov kernel - - - pid 35074 (ntpd), jid > 0, uid 123: exited on signal 11 > > Not sure how long does it happen. ktrace and gdb points to `setrlimit` > call. Clean rebuild has no effect. Does anyone have any idea what the > problem could be? Accidental insight after sending initial mail: I've disabled ASLR related sysctls, and now ntpd starts and runs again. # grep aslr /boot/loader.conf kern.elf32.aslr.enable=0 kern.elf64.aslr.enable=0 # service ntpd status ntpd is running as pid 30528. -- Regards, | "In theory there is no difference between theory Vladimir Zakharov | and practice. In practice there is."- Yogi Berra signature.asc Description: PGP signature
ntpd segfaults on start
Hello!
Accidentally it turned out that the ntpd does not start on boot.
Logs show that it core dumps:
2019-09-05T08:38:43.588563+03:00 vzakharov ntpd 34934 - - ntpd 4.2.8p12-a (1):
Starting
2019-09-05T08:38:43.588717+03:00 vzakharov kernel - - - Security policy loaded:
MAC/ntpd (mac_ntpd)
2019-09-05T08:38:43.718356+03:00 vzakharov kernel - - - pid 35074 (ntpd), jid
0, uid 123: exited on signal 11
Not sure how long does it happen. ktrace and gdb points to `setrlimit`
call. Clean rebuild has no effect. Does anyone have any idea what the
problem could be?
root@vzakharov:~ # uname -a
FreeBSD vzakharov 13.0-CURRENT FreeBSD 13.0-CURRENT r351834 GENERIC-NODEBUG
amd64
root@vzakharov:~ # ktrace -i sudo -u ntpd `which ntpd`
root@vzakharov:~ # kdump | tail -n 20
29735 ntpd CALL dup2(0,0x2)
29735 ntpd RET dup2 2
29735 ntpd CALL socket(PF_LOCAL,0x1002,0)
29735 ntpd RET socket 3
29735 ntpd CALL connect(0x3,0x7f924f98,0x6a)
29735 ntpd STRU struct sockaddr { AF_LOCAL, /var/run/logpriv }
29735 ntpd NAMI "/var/run/logpriv"
29735 ntpd RET connect -1 errno 13 Permission denied
29735 ntpd CALL connect(0x3,0x7f924f98,0x6a)
29735 ntpd STRU struct sockaddr { AF_LOCAL, /var/run/log }
29735 ntpd NAMI "/var/run/log"
29735 ntpd RET connect 0
29735 ntpd CALL setsid
29735 ntpd RET setsid 29735/0x7427
29735 ntpd CALL getrlimit(RLIMIT_STACK,0x7f9250a0)
29735 ntpd RET getrlimit 0
29735 ntpd CALL setrlimit(RLIMIT_STACK,0x7f9250a0)
29735 ntpd RET setrlimit 0
29735 ntpd PSIG SIGSEGV SIG_DFL code=SEGV_ACCERR
29735 ntpd NAMI "ntpd.core"
root@vzakharov:~ # ntpd
root@vzakharov:~ # gdb -c ntpd.core `which ntpd`
GNU gdb (GDB) 8.3 [GDB v8.3 for FreeBSD]
[...]
Reading symbols from /usr/sbin/ntpd...
Reading symbols from /usr/lib/debug//usr/sbin/ntpd.debug...
[New LWP 100946]
Core was generated by `ntpd'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 setrlimit () at setrlimit.S:4
4 RSYSCALL(setrlimit)
(gdb) bt
#0 setrlimit () at setrlimit.S:4
Backtrace stopped: Cannot access memory at address 0x7f3ce7c8
(gdb) quit
# cat /etc/src.conf
WITHOUT_ACCT=
WITHOUT_AMD=
WITHOUT_APM=
WITHOUT_ATM=
WITHOUT_AUTHPF=
WITHOUT_BLACKLIST=
WITHOUT_BLUETOOTH=
WITHOUT_BOOTPARAMD=
WITHOUT_BOOTPD=
WITHOUT_BSNMP=
WITHOUT_CCD=
WITHOUT_CROSS_COMPILER=
WITHOUT_CUSE=
WITHOUT_CXGBETOOL=
# WITHOUT_DEBUG_FILES=
WITHOUT_EE=
WITHOUT_FDT=
WITHOUT_FINGER=
WITHOUT_FLOPPY=
WITHOUT_FREEBSD_UPDATE=
WITHOUT_FTP=
WITHOUT_GDB=
WITHOUT_GNU_DIFF=
WITHOUT_GNU_GREP=
WITHOUT_GNU_GREP_COMPAT=
WITHOUT_GPIO=
WITHOUT_HAST=
WITHOUT_HTML=
WITHOUT_HYPERV=
WITHOUT_IPFILTER=
WITHOUT_ISCSI=
WITHOUT_KVM=
WITHOUT_LEGACY_CONSOLE=
WITHOUT_LIB32=
WITHOUT_LLVM_TARGET_ALL=
WITHOUT_LPR=
WITHOUT_MLX5TOOL=
WITHOUT_NDIS=
WITHOUT_NVME=
WITHOUT_PC_SYSINSTALL=
WITHOUT_PF=
WITHOUT_PMC=
WITHOUT_PPP=
WITHOUT_QUOTAS=
WITHOUT_RADIUS_SUPPORT=
WITHOUT_RBOOTD=
WITHOUT_SHAREDOCS=
WITHOUT_TALK=
WITHOUT_TELNET=
WITHOUT_TESTS=
WITHOUT_TFTP=
WITHOUT_TIMED=
WITH_BSD_GREP=
WITH_CCACHE_BUILD=
# WITH_CLANG_EXTRAS=
# WITH_CTF=
# WITH_RATELIMIT=
WITH_SORT_THREADS=
WITH_SVN=
BOOTSTRAP_ALL_TOOLS=
--
Regards, | "In theory there is no difference between theory
Vladimir Zakharov | and practice. In practice there is."- Yogi Berra
signature.asc
Description: PGP signature
Re: r350484 and ASLR enabled - init died (signal 6, exit 0)
On Mon, Aug 05, 2019, Konstantin Belousov wrote: > On Mon, Aug 05, 2019 at 08:10:43PM +0200, Trond Endrestøl wrote: > > On Mon, 5 Aug 2019 06:02-0700, David Wolfskill wrote: > > > > > On Mon, Aug 05, 2019 at 02:53:04PM +0200, Trond Endrestøl wrote: > > > > Hi, > > > > > > > > Has anyone else noticed the kernel being unable to spawn init lately? > > > > > > > > All I get is: > > > > > > > > init died (signal 6, exit 0) > > > > panic: Going nowhere without my init! > > > > > Try r350608. There was a mis-merge in the committed patch (more serious > part), and some limits were not applied, which I did not see in my > testing due to the mismatch between stock FreeBSD and my testing > environment. The issue persists still at r350713 on HP Probook after clean rebuild. root@# uname -a FreeBSD vzakharov 13.0-CURRENT FreeBSD 13.0-CURRENT r350713 GENERIC-NODEBUG amd64 root@# grep aslr /boot/loader.conf #kern.elf32.aslr.enable=1 #kern.elf64.aslr.enable=1 -- Regards, | "In theory there is no difference between theory Vladimir Zakharov | and practice. In practice there is."- Yogi Berra signature.asc Description: PGP signature
Re: Boot loader hangs after update to r349350
On Tue, Jun 25, 2019, Rebecca Cran wrote: > On 2019-06-25 13:57, Guido Falsi wrote: > > > > I'm having thee same issue. UEFI system, ZFS on root, two mirrored disks. > > > > Reverting 349349 fixes it. > > > Sorry, that was my commit. I'm debugging it now. Updating to r349447 fixed the issue for me. Thanks -- Regards, | "In theory there is no difference between theory Vladimir Zakharov | and practice. In practice there is."- Yogi Berra signature.asc Description: PGP signature
Re: Boot loader hangs after update to r349350
On Tue, Jun 25, 2019, Jan Beich wrote: > Vladimir Zakharov writes: > > > Hello > > > > After update from r349326 to r349350 boot loader hangs on string: > > Setting currdev to ada0p3: > > > > Laptop HP ProBook 430 G3. > > Do you boot from a ZFS pool on a GPT partition? If so how the pool is > configured: single disk, stripe, mirror or raidz? I do not use ZFS at all. # gpart show => 40 250069600 ada0 GPT (119G) 40 1600 1 efi (800K) 1640 16777216 2 freebsd-swap (8.0G) 16778856 31457280 3 freebsd-ufs (15G) 48236136 62914560 4 freebsd-ufs (30G) 50696 12582912 5 freebsd-ufs (6.0G) 123733608 125829120 6 freebsd-ufs (60G) 249562728 506912- free - (248M) > > Try reverting r349349. I'll try this. Thank you -- Regards, | "In theory there is no difference between theory Vladimir Zakharov | and practice. In practice there is."- Yogi Berra signature.asc Description: PGP signature
Boot loader hangs after update to r349350
Hello After update from r349326 to r349350 boot loader hangs on string: Setting currdev to ada0p3: Laptop HP ProBook 430 G3. -- Regards, | "In theory there is no difference between theory Vladimir Zakharov | and practice. In practice there is."- Yogi Berra signature.asc Description: PGP signature
Re: EFIRT on machines with pcid after r337773
On Wed, Aug 15, 2018, Konstantin Belousov wrote: > If you use UEFI boot, have EFIRT compiled in kernel (the case of > GENERIC) or pre-loaded as module, and efirt is not disabled by a tunable, > and the machine resets during kernel initialization, try this. > Patch fixed boot hanging for me on HP ProBook 430 G2. Thanks -- Regards, | "In theory there is no difference between theory Vladimir Zakharov | and practice. In practice there is."- Yogi Berra ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CURRENT from today throws lots of ACPI errors, lost HDMI detection
Hello! On Tue, Aug 14, 2018, Pete Wright wrote: > > On 8/14/18 6:13 PM, Kyle Evans wrote: > > On Tue, Aug 14, 2018 at 7:28 PM, Pete Wright wrote: > > > i also attempted to boot using UEFI but the system hangs very early in the > > > boot process. i have reverted to legacy mode for now so that i can work, > > > but am keen to test out any patches or do any other debugging that is > > > needed. > > Hi Pete, > > > > Where in the process does it hang with UEFI? I can't help much with > > any of your other problems, but I am curious about this one. =) > sure thing - the last several lines are: > > random: fast provider: "Intel Secure Key RNG" > kbd1 at kbdmux0 > netmap: loaded module > nexus0 > > at this point it hangs. let me know if you want me to try booting with > verbose output to dmesg or something. I've updated from r337734 and got the same here with HP Probook 430 G2. Setting efi.rt.disabled=1 in /boot/loader.conf fixed the problem for me. # uname -a FreeBSD vzakharov 12.0-ALPHA1 FreeBSD 12.0-ALPHA1 #24 r337829: Wed Aug 15 06:33:54 MSK 2018 root@vzakharov:/home/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 -- Regards, | "In theory there is no difference between theory Vladimir Zakharov | and practice. In practice there is."- Yogi Berra ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: buildworld fails: fatal error: 'netpfil/pf/pf.h' file not found
On Tue, Apr 10, 2018, Kristof Provost wrote: > On 9 Apr 2018, at 13:10, Vladimir Zakharov wrote: > > On Mon, Apr 09, 2018, Kristof Provost wrote: > > > On 9 Apr 2018, at 10:50, Vladimir Zakharov wrote: > > > > > > For several days buildworld fails for me with the following > > > error. Cleaning > > > and > > > rebuilding didn't help. > > > > > > ===> tests/sys/netpfil/pf/ioctl (all) > > > --- validation --- > > > (cd /usr/src/tests/sys/netpfil/pf/ioctl && > > > DEPENDFILE=.depend.validation > > > NO_SUBDIR=1 make -f /usr/src/tests/sys/netpfil/pf/ioctl/Makefile > > > _RECURSING_PROGS=t PROG=validation ) > > > Building > > > /home/obj/usr/src/amd64.amd64/tests/sys/netpfil/pf/ioctl/ > > > validation.o > > > --- validation.o --- > > > In file included from > > > /usr/src/tests/sys/netpfil/pf/ioctl/validation.c:35: > > > /home/obj/usr/src/amd64.amd64/tmp/usr/include/net/pfvar.h:49:10: > > > fatal > > > error: 'netpfil/pf/pf.h' file not found > > > #include > > > ^ > > It should be fully fixed as of r332358. > Thanks for the report. Works for me. Thanks. -- Regards, | "In theory there is no difference between theory Vladimir Zakharov | and practice. In practice there is."- Yogi Berra ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: buildworld fails: fatal error: 'netpfil/pf/pf.h' file not found
On Mon, Apr 09, 2018, Kristof Provost wrote:
> On 9 Apr 2018, at 10:50, Vladimir Zakharov wrote:
>
> For several days buildworld fails for me with the following error.
> Cleaning
> and
> rebuilding didn't help.
>
> ===> tests/sys/netpfil/pf/ioctl (all)
> --- validation ---
> (cd /usr/src/tests/sys/netpfil/pf/ioctl && DEPENDFILE=.depend.validation
> NO_SUBDIR=1 make -f /usr/src/tests/sys/netpfil/pf/ioctl/Makefile
> _RECURSING_PROGS=t PROG=validation )
> Building /home/obj/usr/src/amd64.amd64/tests/sys/netpfil/pf/ioctl/
> validation.o
> --- validation.o ---
> In file included from /usr/src/tests/sys/netpfil/pf/ioctl/validation.c:35:
> /home/obj/usr/src/amd64.amd64/tmp/usr/include/net/pfvar.h:49:10: fatal
> error: 'netpfil/pf/pf.h' file not found
> #include
> ^
> 1 error generated.
> *** [validation.o] Error code 1
>
> make[8]: stopped in /usr/src/tests/sys/netpfil/pf/ioctl
>
>
> My /etc/src.conf (I have PF switched off):
>
> Ah, that’s my fault. I didn’t consider people who’d switch off pf when I added
> the new ioctl tests.
>
> You can work around the issue by removing the new tests yourself, or by
> building pf in anyway (it won’t do anything unless you load the module and
> activate it).
>
> This should be a workaround for you until I can commit a better fix:
>
> diff --git a/tests/sys/netpfil/pf/Makefile b/tests/sys/netpfil/pf/Makefile
> index c055e6840bd..259e1275d9c 100644
> --- a/tests/sys/netpfil/pf/Makefile
> +++ b/tests/sys/netpfil/pf/Makefile
> @@ -3,7 +3,6 @@
> PACKAGE= tests
>
> TESTSDIR= ${TESTSBASE}/sys/netpfil/pf
> -TESTS_SUBDIRS+=ioctl
>
> ATF_TESTS_SH+= pass_block \
> forward \
Thanks. I've applied this fix for now and managed to update.
--
Regards, | "In theory there is no difference between theory
Vladimir Zakharov | and practice. In practice there is."- Yogi Berra
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
buildworld fails: fatal error: 'netpfil/pf/pf.h' file not found
Hello! For several days buildworld fails for me with the following error. Cleaning and rebuilding didn't help. ===> tests/sys/netpfil/pf/ioctl (all) --- validation --- (cd /usr/src/tests/sys/netpfil/pf/ioctl && DEPENDFILE=.depend.validation NO_SUBDIR=1 make -f /usr/src/tests/sys/netpfil/pf/ioctl/Makefile _RECURSING_PROGS=t PROG=validation ) Building /home/obj/usr/src/amd64.amd64/tests/sys/netpfil/pf/ioctl/validation.o --- validation.o --- In file included from /usr/src/tests/sys/netpfil/pf/ioctl/validation.c:35: /home/obj/usr/src/amd64.amd64/tmp/usr/include/net/pfvar.h:49:10: fatal error: 'netpfil/pf/pf.h' file not found #include ^ 1 error generated. *** [validation.o] Error code 1 make[8]: stopped in /usr/src/tests/sys/netpfil/pf/ioctl My /etc/src.conf (I have PF switched off): WITHOUT_ACCT= WITHOUT_AMD= WITHOUT_APM= WITHOUT_ATM= WITHOUT_AUTHPF= WITHOUT_BLACKLIST= WITHOUT_BLUETOOTH= WITHOUT_BOOTPARAMD= WITHOUT_BOOTPD= WITHOUT_BSNMP= WITHOUT_CCD= WITHOUT_CROSS_COMPILER= WITHOUT_CTM= WITHOUT_CUSE= WITHOUT_CXGBETOOL= # WITHOUT_DEBUG_FILES= WITHOUT_EE= WITHOUT_FDT= WITHOUT_FINGER= WITHOUT_FLOPPY= WITHOUT_FREEBSD_UPDATE= WITHOUT_FTP= WITHOUT_GDB= WITHOUT_GNU_GREP_COMPAT= WITHOUT_HAST= WITHOUT_HTML= WITHOUT_HYPERV= WITHOUT_IPFILTER= WITHOUT_ISCSI= WITHOUT_KVM= WITHOUT_LEGACY_CONSOLE= WITHOUT_LIB32= WITHOUT_LPR= WITHOUT_NDIS= WITHOUT_PC_SYSINSTALL= WITHOUT_PF= WITHOUT_PPP= WITHOUT_QUOTAS= WITHOUT_RADIUS_SUPPORT= WITHOUT_RBOOTD= WITHOUT_SHAREDOCS= WITHOUT_TALK= WITHOUT_TFTP= WITHOUT_TIMED= WITH_BSD_GREP= WITH_CCACHE_BUILD= # WITH_CLANG_EXTRAS= # WITH_CTF= # WITH_DTRACE_TESTS= WITH_SORT_THREADS= WITH_SVN= -- Regards, | "In theory there is no difference between theory Vladimir Zakharov | and practice. In practice there is."- Yogi Berra ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: buildkernel with PORTS_MODULES fails: Variable OBJTOP is recursive
On Tue, Feb 13, 2018, Bryan Drewery wrote:
> On 2/13/2018 1:48 AM, Vladimir Zakharov wrote:
> > On Mon, Feb 12, 2018, Bryan Drewery wrote:
> >> On 2/12/2018 6:54 AM, Vladimir Zakharov wrote:
> >>> Hello, Bryan!
> >>>
> >>> On Fri, Feb 09, 2018, Bryan Drewery wrote:
> >>>> On 2/1/2018 1:10 AM, Vladimir Zakharov wrote:
> >>>>> Hello!
> >>>>>
> >>>>> For some time (about a week) building and installing kernel fails with
> >>>>> the error "Variable OBJTOP is recursive." when going to build/install
> >>>>> module from ports.
> >>>>>
> >>>>> Last successful build was at r328426. Next build at r328527 failed and
> >>>>> still broken at r328649.
> >>>>>
> >>>>> Without PORTS_MODULES building and installing kernel succeeds. Another
> >>>>> workaround: ignore error and build/install module directly from ports.
> >>>>> ...
> >>>>
> >>>> For some reason I cannot recreate this issue.
> >>>
> >>> It seems, setting WITH_AUTO_OBJ in /etc/src-env.conf causes an error.
> >>> At least, removing it fixes build for me.
> >>>
> >>> Build successful with the following settings:
> >>> # cat /etc/src-env.conf
> >>> WITH_META_MODE=
> >>> #WITH_AUTO_OBJ=
> >>>
> >>
> >> Please try this patch (requires a buildkernel).
> >>
> >> https://people.freebsd.org/~bdrewery/patches/kernel-portsmodules.diff
> >>
> >
> > Fixed partly:
> > | buildkernel | installkernel |
> > r329196 | OK | FAIL(*) |
> > r329169 + patch | OK | OK|
> > r329196 + WITH_AUTO_OBJ | FAIL | |
> > r329169 + WITH_AUTO_OBJ + patch | FAIL | |
> >
> > (*) - same error "Variable OBJTOP is recursive".
> >
>
> Thanks, r329232 should fix it.
Not yet. 'installkernel' still fails (see below). Can be fixed either by
explicit setting WITHOUT_AUTO_OBJ in /etc/src-env.conf or by applying
previous patch (s/build/stage/ in kern.post.mk:89).
# svn info
Path: .
Working Copy Root Path: /usr/src
URL: https://svn.freebsd.org/base/head
Relative URL: ^/head
Repository Root: https://svn.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 329259
Node Kind: directory
Schedule: normal
Last Changed Author: eadler
Last Changed Rev: 329259
Last Changed Date: 2018-02-14 10:59:30 +0300 (Wed, 14 Feb 2018)
# cat /etc/src-env.conf
WITH_META_MODE=
#WITH_AUTO_OBJ=
# env | grep MAKE
MAKEOBJDIRPREFIX=/home/obj
# make -j 4 buildkernel && make installkernel
...
===> Ports module graphics/drm-next-kmod (all)
cd ${PORTSDIR:-/usr/ports}/graphics/drm-next-kmod; env -u CC -u CXX -u CPP
-u MAKESYSPATH -u MAKEOBJDIR MAKEFLAGS="-j 4 -J 15,16 -j 4 -J 15,16 -D
NO_MODULES_OBJ .MAKE.LEVEL.ENV=MAKELEVEL KERNEL=kernel TARGET=amd64
TARGET_ARCH=amd64" SYSDIR=/usr/src/sys
PATH=/home/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/home/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:/home/obj/usr/src/amd64.amd64/tmp/legacy/bin:/home/obj/usr/src/amd64.amd64/tmp/usr/sbin:/home/obj/usr/src/amd64.amd64/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
SRC_BASE=/usr/src OSVERSION=1200058
WRKDIRPREFIX=/home/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG make -B clean
build
===> Cleaning for drm-next-kmod-g20180117
===> License BSD2CLAUSE MIT GPLv2 accepted by the user
===> drm-next-kmod-g20180117 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by drm-next-kmod-g20180117 for building
===> Extracting for drm-next-kmod-g20180117
=> SHA256 Checksum OK for FreeBSDDesktop-kms-drm-g20180117-622fdd1_GH0.tar.gz.
===> Patching for drm-next-kmod-g20180117
===> drm-next-kmod-g20180117 depends on file: /usr/local/bin/ccache - found
===> Configuring for drm-next-kmod-g20180117
===> Building for drm-next-kmod-g20180117
[Creating objdir obj...]
...
--
>>> Kernel build for GENERIC-NODEBUG completed on Wed Feb 14 11:09:45 MSK 2018
--
--
>>> Installing kernel GENERIC-NODEBUG on Wed Feb 14 11:09:45 MSK 2018
--
...
kldxref /boot/kernel
===> Ports module graphics/drm-next-kmod (install)
cd ${PORTSDIR:-/usr/ports}/graphics
Re: buildkernel with PORTS_MODULES fails: Variable OBJTOP is recursive
On Mon, Feb 12, 2018, Bryan Drewery wrote: > On 2/12/2018 6:54 AM, Vladimir Zakharov wrote: > > Hello, Bryan! > > > > On Fri, Feb 09, 2018, Bryan Drewery wrote: > >> On 2/1/2018 1:10 AM, Vladimir Zakharov wrote: > >>> Hello! > >>> > >>> For some time (about a week) building and installing kernel fails with > >>> the error "Variable OBJTOP is recursive." when going to build/install > >>> module from ports. > >>> > >>> Last successful build was at r328426. Next build at r328527 failed and > >>> still broken at r328649. > >>> > >>> Without PORTS_MODULES building and installing kernel succeeds. Another > >>> workaround: ignore error and build/install module directly from ports. > >>> ... > >> > >> For some reason I cannot recreate this issue. > > > > It seems, setting WITH_AUTO_OBJ in /etc/src-env.conf causes an error. > > At least, removing it fixes build for me. > > > > Build successful with the following settings: > > # cat /etc/src-env.conf > > WITH_META_MODE= > > #WITH_AUTO_OBJ= > > > > Please try this patch (requires a buildkernel). > > https://people.freebsd.org/~bdrewery/patches/kernel-portsmodules.diff > Fixed partly: | buildkernel | installkernel | r329196 | OK | FAIL(*) | r329169 + patch | OK | OK | r329196 + WITH_AUTO_OBJ | FAIL | | r329169 + WITH_AUTO_OBJ + patch | FAIL | | (*) - same error "Variable OBJTOP is recursive". -- Regards, | "In theory there is no difference between theory Vladimir Zakharov | and practice. In practice there is."- Yogi Berra ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: buildkernel with PORTS_MODULES fails: Variable OBJTOP is recursive
Hello, Bryan!
On Fri, Feb 09, 2018, Bryan Drewery wrote:
> On 2/1/2018 1:10 AM, Vladimir Zakharov wrote:
> > Hello!
> >
> > For some time (about a week) building and installing kernel fails with
> > the error "Variable OBJTOP is recursive." when going to build/install
> > module from ports.
> >
> > Last successful build was at r328426. Next build at r328527 failed and
> > still broken at r328649.
> >
> > Without PORTS_MODULES building and installing kernel succeeds. Another
> > workaround: ignore error and build/install module directly from ports.
> >
> > # cat /etc/make.conf
> > MALLOC_PRODUCTION=yes
> > KERNCONF=GENERIC-NODEBUG GENERIC
> > #KERNCONF= GENERIC-NODEBUG
> > CPUTYPE?=native
> > #PORTS_MODULES = graphics/drm-next-kmod emulators/virtualbox-ose-kmod
> > PORTS_MODULES = graphics/drm-next-kmod
> >
> > DOC_LANG = en_US.ISO8859-1 ru_RU.KOI8-R
> >
> > WITH_DEBUG_PORTS = mail/neomutt
> >
> > WITH_CCACHE_BUILD=yes
> > CCACHE_DIR=/home/ccache
> >
> > #DEVELOPER=yes
> >
> > ...
> > Building /home/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG/kernel.full
> > --- kernel.full ---
> > linking kernel.full
> > ctfmerge -L VERSION -g -o kernel.full ...
> > text data bssdec hex filename
> > 22584632 1376209 474 28709729 0x1b61361 kernel.full
> > Building /home/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG/kernel.debug
> > Building /home/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG/kernel
> > --- all ---
> > ===> Ports module graphics/drm-next-kmod (all)
> > cd ${PORTSDIR:-/usr/ports}/graphics/drm-next-kmod; env -u CC -u CXX
> > -u CPP -u MAKESYSPATH MAKEFLAGS="-j 4 -J 15,16 -j 4 -J 15,16 -D
> > NO_MODULES_OBJ .MAKE.LEVEL.ENV=MAKELEVEL KERNEL=kernel TARGET=amd64
> > TARGET_ARCH=amd64" SYSDIR=/usr/src/sys
> > PATH=
> > SRC_BASE=/usr/src OSVERSION=1200056
> > WRKDIRPREFIX=/home/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG make -B
> > clean build
> > ===> Cleaning for drm-next-kmod-g20180117
> > ===> License BSD2CLAUSE MIT GPLv2 accepted by the user
> > ===> drm-next-kmod-g20180117 depends on file: /usr/local/sbin/pkg - found
> > ===> Fetching all distfiles required by drm-next-kmod-g20180117 for building
> > ===> Extracting for drm-next-kmod-g20180117
> > => SHA256 Checksum OK for
> > FreeBSDDesktop-kms-drm-g20180117-622fdd1_GH0.tar.gz.
> > ===> Patching for drm-next-kmod-g20180117
> > ===> drm-next-kmod-g20180117 depends on file: /usr/local/bin/ccache -
> > found
> > ===> Configuring for drm-next-kmod-g20180117
> > ===> Building for drm-next-kmod-g20180117
> > ===> drm (all)
> > Variable OBJTOP is recursive.
>
> For some reason I cannot recreate this issue.
It seems, setting WITH_AUTO_OBJ in /etc/src-env.conf causes an error.
At least, removing it fixes build for me.
Build successful with the following settings:
# cat /etc/src-env.conf
WITH_META_MODE=
#WITH_AUTO_OBJ=
# env | grep MAKE
MAKEOBJDIRPREFIX=/home/obj
# cat /etc/make.conf
MALLOC_PRODUCTION=yes
KERNCONF= GENERIC-NODEBUG
CPUTYPE?=native
PORTS_MODULES= graphics/drm-next-kmod
DOC_LANG = en_US.ISO8859-1 ru_RU.KOI8-R
WITH_DEBUG_PORTS = mail/neomutt
WITH_CCACHE_BUILD=yes
CCACHE_DIR=/home/ccache
DEVELOPER=yes
--
Regards, | "In theory there is no difference between theory
Vladimir Zakharov | and practice. In practice there is."- Yogi Berra
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: buildkernel with PORTS_MODULES fails: Variable OBJTOP is recursive
On Sun, Feb 04, 2018, O. Hartmann wrote: > Am Sat, 3 Feb 2018 11:17:06 +0100 > "O. Hartmann" <o.hartm...@walstatt.org> schrieb: > > > Am Sat, 3 Feb 2018 11:10:53 +0300 > > Vladimir Zakharov <zakharov...@gmail.com> schrieb: > > > > > Hello, Oliver! > > > > > > On Fri, Feb 02, 2018, O. Hartmann wrote: > > > > On Thu, 1 Feb 2018 12:10:30 +0300 > > > > Vladimir Zakharov <zakharov...@gmail.com> wrote: > > > > > > > > > Hello! > > > > > > > > > > For some time (about a week) building and installing kernel fails with > > > > > the error "Variable OBJTOP is recursive." when going to build/install > > > > > module from ports. > > > > > > > > > > Last successful build was at r328426. Next build at r328527 failed and > > > > > still broken at r328649. > > > > > > > > > > Without PORTS_MODULES building and installing kernel succeeds. Another > > > > > workaround: ignore error and build/install module directly from ports. > > > > > > > > > > > > > I have had the very same issue! > > > > > > > > You need to perform a "installworld" first (just comment out the > > > > PORTS_MODULES= > > > > parts of /etc/src.conf or /etc/make.conf, buildworld and buildkernel > > > > (maybe not > > > > a full buildworld, but I do not know the state of your source tree) and > > > > perform > > > > a regular installation of the world. It could be something easier by > > > > direkctly > > > > install-only the mk-portions, but recently, some changes to world > > > > (LLVM) made > > > > it worth anyway to buildworld. > > > > > > > > As recommended by others earlier on this list according to this > > > > subject, this > > > > procedure makes the problem go away. > > > > > > Thanks for your answer. Unfortunately, this didn't help. > > > > > > > You are correct! I made a mistake and had the portions still commented out. > > I'm very > > sorry. > > > > This remains a bug! > > > > This problem has been introduced with > > svn commit: r328489 - head/sys/conf > > The the appropriate list for reference. > Indeed, reverting r328489 fixes the problem. -- Regards, | "In theory there is no difference between theory Vladimir Zakharov | and practice. In practice there is."- Yogi Berra ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: buildkernel with PORTS_MODULES fails: Variable OBJTOP is recursive
Hello, Oliver! On Fri, Feb 02, 2018, O. Hartmann wrote: > On Thu, 1 Feb 2018 12:10:30 +0300 > Vladimir Zakharov <zakharov...@gmail.com> wrote: > > > Hello! > > > > For some time (about a week) building and installing kernel fails with > > the error "Variable OBJTOP is recursive." when going to build/install > > module from ports. > > > > Last successful build was at r328426. Next build at r328527 failed and > > still broken at r328649. > > > > Without PORTS_MODULES building and installing kernel succeeds. Another > > workaround: ignore error and build/install module directly from ports. > > > > I have had the very same issue! > > You need to perform a "installworld" first (just comment out the > PORTS_MODULES= > parts of /etc/src.conf or /etc/make.conf, buildworld and buildkernel (maybe > not > a full buildworld, but I do not know the state of your source tree) and > perform > a regular installation of the world. It could be something easier by > direkctly > install-only the mk-portions, but recently, some changes to world (LLVM) made > it worth anyway to buildworld. > > As recommended by others earlier on this list according to this subject, this > procedure makes the problem go away. Thanks for your answer. Unfortunately, this didn't help. -- Regards, | "In theory there is no difference between theory Vladimir Zakharov | and practice. In practice there is."- Yogi Berra ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
buildkernel with PORTS_MODULES fails: Variable OBJTOP is recursive
Hello!
For some time (about a week) building and installing kernel fails with
the error "Variable OBJTOP is recursive." when going to build/install
module from ports.
Last successful build was at r328426. Next build at r328527 failed and
still broken at r328649.
Without PORTS_MODULES building and installing kernel succeeds. Another
workaround: ignore error and build/install module directly from ports.
# cat /etc/make.conf
MALLOC_PRODUCTION=yes
KERNCONF=GENERIC-NODEBUG GENERIC
#KERNCONF= GENERIC-NODEBUG
CPUTYPE?=native
#PORTS_MODULES = graphics/drm-next-kmod emulators/virtualbox-ose-kmod
PORTS_MODULES = graphics/drm-next-kmod
DOC_LANG = en_US.ISO8859-1 ru_RU.KOI8-R
WITH_DEBUG_PORTS = mail/neomutt
WITH_CCACHE_BUILD=yes
CCACHE_DIR=/home/ccache
#DEVELOPER=yes
...
Building /home/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG/kernel.full
--- kernel.full ---
linking kernel.full
ctfmerge -L VERSION -g -o kernel.full ...
text data bssdec hex filename
22584632 1376209 474 28709729 0x1b61361 kernel.full
Building /home/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG/kernel.debug
Building /home/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG/kernel
--- all ---
===> Ports module graphics/drm-next-kmod (all)
cd ${PORTSDIR:-/usr/ports}/graphics/drm-next-kmod; env -u CC -u CXX
-u CPP -u MAKESYSPATH MAKEFLAGS="-j 4 -J 15,16 -j 4 -J 15,16 -D
NO_MODULES_OBJ .MAKE.LEVEL.ENV=MAKELEVEL KERNEL=kernel TARGET=amd64
TARGET_ARCH=amd64" SYSDIR=/usr/src/sys
PATH=
SRC_BASE=/usr/src OSVERSION=1200056
WRKDIRPREFIX=/home/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG make -B
clean build
===> Cleaning for drm-next-kmod-g20180117
===> License BSD2CLAUSE MIT GPLv2 accepted by the user
===> drm-next-kmod-g20180117 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by drm-next-kmod-g20180117 for building
===> Extracting for drm-next-kmod-g20180117
=> SHA256 Checksum OK for FreeBSDDesktop-kms-drm-g20180117-622fdd1_GH0.tar.gz.
===> Patching for drm-next-kmod-g20180117
===> drm-next-kmod-g20180117 depends on file: /usr/local/bin/ccache - found
===> Configuring for drm-next-kmod-g20180117
===> Building for drm-next-kmod-g20180117
===> drm (all)
Variable OBJTOP is recursive.
make[6]: stopped in
*** Error code 2
Stop.
make[5]: stopped in
===> Compilation failed unexpectedly.
Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
the maintainer.
*** Error code 1
Stop.
make[4]: stopped in /home/ports/graphics/drm-next-kmod
*** Error code 1
Stop.
make[3]: stopped in /home/ports/graphics/drm-next-kmod
*** [all] Error code 1
...
--
Regards, | "In theory there is no difference between theory
Vladimir Zakharov | and practice. In practice there is."- Yogi Berra
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: lldb unusable for regular user
On Tue, Sep 19, 2017, John Baldwin wrote: > On Monday, September 18, 2017 02:41:06 PM Vladimir Zakharov wrote: > > Hello! > > > > lldb coredumps for regular user, but works for root. > > > gdb `which lldb` lldb.core > > ... > > Reading symbols from /usr/bin/lldb...Reading symbols from > > /usr/lib/debug//usr/bin/lldb.debug...done. > > done. > > [New LWP 101610] > > [New LWP 100968] > > [New LWP 100126] > > [New LWP 101631] > > [New LWP 101637] > > [New LWP 101662] > > [New LWP 101672] > > [New LWP 100337] > > [New LWP 101593] > > Core was generated by `lldb ./test'. > > Program terminated with signal SIGSEGV, Segmentation fault. > > #0 x86_64_freebsd_fallback_frame_state (context=0x7fffddff6e20, > > context=0x7fffddff6e20, fs=0x7fffddff6b70) at ./md-unwind-support.h:60 > > 60 ./md-unwind-support.h: No such file or directory. > > [Current thread is 1 (LWP 101610)] > > (gdb) f > > #0 x86_64_freebsd_fallback_frame_state (context=0x7fffddff6e20, > > context=0x7fffddff6e20, fs=0x7fffddff6b70) at ./md-unwind-support.h:60 > > 60 in ./md-unwind-support.h > > (gdb) bt > > #0 x86_64_freebsd_fallback_frame_state (context=0x7fffddff6e20, > > context=0x7fffddff6e20, fs=0x7fffddff6b70) at ./md-unwind-support.h:60 > > #1 uw_frame_state_for (context=context@entry=0x7fffddff6e20, > > fs=fs@entry=0x7fffddff6b70) at > > /wrkdirs/usr/ports/lang/gcc6/work/gcc-6.4.0/libgcc/unwind-dw2.c:1249 > > #2 0x000804f6cffb in _Unwind_ForcedUnwind_Phase2 > > (exc=exc@entry=0x806b23230, context=context@entry=0x7fffddff6e20) at > > /wrkdirs/usr/ports/lang/gcc6/work/gcc-6.4.0/libgcc/unwind.inc:155 > > #3 0x000804f6d334 in _Unwind_ForcedUnwind (exc=0x806b23230, > > stop=0x804631760 , stop_argument=) at > > /wrkdirs/usr/ports/lang/gcc6/work/gcc-6.4.0/libgcc/unwind.inc:207 > > #4 0x0008046315c3 in _Unwind_ForcedUnwind (ex=, > > stop_func=0xe, stop_arg=0x806b23000) at > > /usr/src/lib/libthr/thread/thr_exit.c:106 > > #5 thread_unwind () at /usr/src/lib/libthr/thread/thr_exit.c:172 > > #6 _pthread_exit_mask (status=, mask=) at > > /usr/src/lib/libthr/thread/thr_exit.c:254 > > #7 0x0008046313eb in _pthread_exit (status=0x806b23000) at > > /usr/src/lib/libthr/thread/thr_exit.c:206 > > #8 0x000804623c0d in thread_start (curthread=0x806b23000) at > > /usr/src/lib/libthr/thread/thr_create.c:289 > > #9 0x7fffdddf7000 in ?? () > > Backtrace stopped: Cannot access memory at address 0x7fffddff7000 > > Your backtrace shows it crashed during thread exit inside of libthr, not in > lldb itself. Also, it seems you are using libgcc_s from external gcc rather > than the base system libgcc_s which is built from > contrib/llvm/projects/libunwind. If lldb dlopen'd some object that depends > on libgcc_s.so from ports gcc then that might explain this crash as it means > you are mixing two different unwind libraries. What does 'info sharedlibrary' > from gdb show? You're right, John. My environment had been polluted: $ env | grep gcc LIBRARY_PATH=/usr/local/lib/gcc6 LD_LIBRARY_PATH=/usr/local/lib/gcc6 I've deleted these variables, and lldb works now as expected. Thanks a lot -- Regards, | "In theory there is no difference between theory Vladimir Zakharov | and practice. In practice there is."- Yogi Berra ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
lldb unusable for regular user
Hello!
lldb coredumps for regular user, but works for root.
> uname -a
FreeBSD vzakharov 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r323675: Sun Sep 17
21:14:33 MSK 2017 root@vzakharov:/home/obj/usr/src/sys/GENERIC-NODEBUG
amd64
> cat test.c
#include
#include
int main()
{
printf("PID: %d\n", getpid());
sleep(10);
return 0;
}
> cc -O0 -g test.c -o test
> lldb ./test
(lldb) target create "./test"
Current executable set to './test' (x86_64).
(lldb) run
Process 37758 launching
Process 37758 launched: './test' (x86_64)
Segmentation fault (core dumped)
Exit 139
> sudo lldb ./test
(lldb) target create "./test"
Current executable set to './test' (x86_64).
(lldb) run
Process 37776 launching
Process 37776 launched: './test' (x86_64)
PID: 37776
Process 37776 exited with status = 0 (0x)
(lldb)
Postmortem by gdb:
> gdb ./test test.core
...
[New LWP 101456]
Core was generated by `./test'.
Program terminated with signal SIGTRAP, Trace/breakpoint trap.
#0 _start (ap=0x7fffe858, cleanup=0x800605910 ) at
/usr/src/lib/csu/amd64/crt1.c:50
50 {
(gdb) bt
#0 _start (ap=0x7fffe858, cleanup=0x800605910 ) at
/usr/src/lib/csu/amd64/crt1.c:50
(gdb) f
#0 _start (ap=0x7fffe858, cleanup=0x800605910 ) at
/usr/src/lib/csu/amd64/crt1.c:50
50 {
> gdb `which lldb` lldb.core
...
Reading symbols from /usr/bin/lldb...Reading symbols from
/usr/lib/debug//usr/bin/lldb.debug...done.
done.
[New LWP 101610]
[New LWP 100968]
[New LWP 100126]
[New LWP 101631]
[New LWP 101637]
[New LWP 101662]
[New LWP 101672]
[New LWP 100337]
[New LWP 101593]
Core was generated by `lldb ./test'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 x86_64_freebsd_fallback_frame_state (context=0x7fffddff6e20,
context=0x7fffddff6e20, fs=0x7fffddff6b70) at ./md-unwind-support.h:60
60 ./md-unwind-support.h: No such file or directory.
[Current thread is 1 (LWP 101610)]
(gdb) f
#0 x86_64_freebsd_fallback_frame_state (context=0x7fffddff6e20,
context=0x7fffddff6e20, fs=0x7fffddff6b70) at ./md-unwind-support.h:60
60 in ./md-unwind-support.h
(gdb) bt
#0 x86_64_freebsd_fallback_frame_state (context=0x7fffddff6e20,
context=0x7fffddff6e20, fs=0x7fffddff6b70) at ./md-unwind-support.h:60
#1 uw_frame_state_for (context=context@entry=0x7fffddff6e20,
fs=fs@entry=0x7fffddff6b70) at
/wrkdirs/usr/ports/lang/gcc6/work/gcc-6.4.0/libgcc/unwind-dw2.c:1249
#2 0x000804f6cffb in _Unwind_ForcedUnwind_Phase2
(exc=exc@entry=0x806b23230, context=context@entry=0x7fffddff6e20) at
/wrkdirs/usr/ports/lang/gcc6/work/gcc-6.4.0/libgcc/unwind.inc:155
#3 0x000804f6d334 in _Unwind_ForcedUnwind (exc=0x806b23230,
stop=0x804631760 , stop_argument=) at
/wrkdirs/usr/ports/lang/gcc6/work/gcc-6.4.0/libgcc/unwind.inc:207
#4 0x0008046315c3 in _Unwind_ForcedUnwind (ex=,
stop_func=0xe, stop_arg=0x806b23000) at
/usr/src/lib/libthr/thread/thr_exit.c:106
#5 thread_unwind () at /usr/src/lib/libthr/thread/thr_exit.c:172
#6 _pthread_exit_mask (status=, mask=) at
/usr/src/lib/libthr/thread/thr_exit.c:254
#7 0x0008046313eb in _pthread_exit (status=0x806b23000) at
/usr/src/lib/libthr/thread/thr_exit.c:206
#8 0x000804623c0d in thread_start (curthread=0x806b23000) at
/usr/src/lib/libthr/thread/thr_create.c:289
#9 0x7fffdddf7000 in ?? ()
Backtrace stopped: Cannot access memory at address 0x7fffddff7000
--
Regards, | "In theory there is no difference between theory
Vladimir Zakharov | and practice. In practice there is."- Yogi Berra
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SIGSEGV in /bin/sh after r322740 -> r322776 update
; 0x000800905300 <+2448>: jmpq 0x800904c93 <__malloc+803> 0x000800905305 <+2453>: mov%r11,-0x50(%rbp) 0x000800905309 <+2457>: xor%esi,%esi 0x00080090530b <+2459>: mov%rbx,%rdi 0x00080090530e <+2462>: callq 0x8009044b0 <__je_arena_choose_hard> 0x000800905313 <+2467>: mov%rax,-0x70(%rbp) 0x000800905317 <+2471>: cmpb $0x0,0x1(%rbx) 0x00080090531b <+2475>: je 0x8009053a9 <__malloc+2617> 0x000800905321 <+2481>: mov0x538(%rbx),%rax 0x000800905328 <+2488>: test %rax,%rax 0x00080090532b <+2491>: je 0x800905399 <__malloc+2601> 0x00080090532d <+2493>: cmp-0x70(%rbp),%rax 0x000800905331 <+2497>: je 0x8009053a9 <__malloc+2617> 0x000800905333 <+2499>: mov%rbx,%rdi 0x000800905336 <+2502>: mov-0x50(%rbp),%rsi 0x00080090533a <+2506>: mov-0x70(%rbp),%rdx 0x00080090533e <+2510>: callq 0x8008cc190 <__je_tcache_arena_reassociate> 0x000800905343 <+2515>: jmp0x8009053a9 <__malloc+2617> 0x000800905345 <+2517>: mov$0xa5,%esi 0x00080090534a <+2522>: jmp0x80090534e <__malloc+2526> 0x00080090534c <+2524>: xor%esi,%esi 0x00080090534e <+2526>: mov%r13,%rdi 0x000800905351 <+2529>: mov%r10,%rdx 0x000800905354 <+2532>: mov%r9,-0x60(%rbp) 0x000800905358 <+2536>: mov%r8d,%r12d 0x00080090535b <+2539>: mov%r10,-0x68(%rbp) 0x00080090535f <+2543>: mov%r11,%r15 0x000800905362 <+2546>: callq 0x800861424 <memset@plt> 0x000800905367 <+2551>: mov%r15,%r11 0x00080090536a <+2554>: mov-0x68(%rbp),%r10 0x00080090536e <+2558>: mov%r12d,%r8d 0x000800905371 <+2561>: mov-0x60(%rbp),%r9 0x000800905375 <+2565>: jmpq 0x800904c93 <__malloc+803> 0x00080090537a <+2570>: mov0x2e8167(%rip),%rdx# 0x800bed4e8 0x000800905381 <+2577>: xor%esi,%esi 0x000800905383 <+2579>: mov%rbx,%rdi 0x000800905386 <+2582>: mov%r9,%r14 0x000800905389 <+2585>: callq 0x800904160 <__je_arena_init> 0x00080090538e <+2590>: mov%r14,%r9 0x000800905391 <+2593>: mov%rax,%rsi 0x000800905394 <+2596>: jmpq 0x800904e24 <__malloc+1204> 0x000800905399 <+2601>: mov%rbx,%rdi 0x00080090539c <+2604>: mov-0x50(%rbp),%rsi 0x0008009053a0 <+2608>: mov-0x70(%rbp),%rdx 0x0008009053a4 <+2612>: callq 0x8008cc0b0 <__je_tcache_arena_associate> 0x0008009053a9 <+2617>: mov-0x70(%rbp),%rsi 0x0008009053ad <+2621>: test %rsi,%rsi 0x0008009053b0 <+2624>: mov-0x50(%rbp),%r11 0x0008009053b4 <+2628>: jne0x800904d00 <__malloc+912> 0x0008009053ba <+2634>: mov-0x60(%rbp),%r9 0x0008009053be <+2638>: mov-0x54(%rbp),%r8d 0x0008009053c2 <+2642>: jmpq 0x800904d34 <__malloc+964> 0x0008009053c7 <+2647>: mov%fs:0x0,%rax 0x0008009053d0 <+2656>: add0x2e83f9(%rip),%rax# 0x800bed7d0 0x0008009053d7 <+2663>: xor%esi,%esi 0x0008009053d9 <+2665>: mov%rax,%rdi 0x0008009053dc <+2668>: callq 0x8008cabc0 <__je_tsd_fetch_slow> 0x0008009053e1 <+2673>: mov%rax,%rbx 0x0008009053e4 <+2676>: jmpq 0x80090514f <__malloc+2015> 0x0008009053e9 <+2681>: mov0x2e83d0(%rip),%rax# 0x800bed7c0 0x0008009053f0 <+2688>: mov(%rax),%r12 0x0008009053f3 <+2691>: test %r12,%r12 0x0008009053f6 <+2694>: jne0x800905452 <__malloc+2786> 0x0008009053f8 <+2696>: mov0x2e80e9(%rip),%rdx# 0x800bed4e8 0x0008009053ff <+2703>: xor%esi,%esi 0x000800905401 <+2705>: mov%rbx,%rdi 0x000800905404 <+2708>: callq 0x800904160 <__je_arena_init> 0x000800905409 <+2713>: mov%rax,%r12 0x00080090540c <+2716>: jmp0x800905452 <__malloc+2786> 0x00080090540e <+2718>: xor%esi,%esi 0x000800905410 <+2720>: mov%rbx,%rdi 0x000800905413 <+2723>: callq 0x8009044b0 <__je_arena_choose_hard> 0x000800905418 <+2728>: mov%rax,%r12 0x00080090541b <+2731>: cmpb $0x0,0x1(%rbx) 0x00080090541f <+2735>: je 0x800905452 <__malloc+2786> 0x000800905421 <+2737>: mov0x538(%rbx),%rax 0x000800905428 <+2744>: test %rax,%rax 0x00080090542b <+2747>: je 0x800905443 <__malloc+2771> 0x00080090542d <+2749>: cmp%r12,%rax 0x000800905430 <+2752>: je 0x800905452 <__malloc+2786> 0x000800905432 <+2754>: mov%rbx,%rdi 0x000800905435 <+2757>: mov-0x50(%rbp),%rsi 0x000800905439 <+2761>: mov%r12,%rdx 0x00080090543c <+2764>: callq 0x8008cc190 <__je_tcache_arena_reassociate> 0x000800905441 <+2769>: jmp0x800905452 <__malloc+2786> 0x000800905443 <+2771>: mov%rbx,%rdi 0x000800905446 <+2774>: mov-0x50(%rbp),%rsi 0x00080090544a <+2778>: mov%r12,%rdx 0x00080090544d <+2781>: callq 0x8008cc0b0 <__je_tcache_arena_associate> 0x000800905452 <+2786>: test %r12,%r12 0x000800905455 <+2789>: mov%r14,%r9 0x000800905458 <+2792>: mov%r15d,%r8d 0x00080090545b <+2795>: jne0x800905262 <__malloc+2290> 0x000800905461 <+2801>: jmpq 0x800904d34 <__malloc+964> 0x000800905466 <+2806>: lea0xaef1f(%rip),%rdi# 0x8009b438c 0x00080090546d <+2813>: callq 0x8008dea20 <__je_malloc_write> 0x000800905472 <+2818>: callq 0x800861874 <abort@plt> 0x000800905477 <+2823>: callq 0x800861874 <abort@plt> End of assembler dump. -- Regards, | "In theory there is no difference between theory Vladimir Zakharov | and practice. In practice there is."- Yogi Berra ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ntpd dies soon after start
On Wed, Jun 14, 2017, Alan Somers wrote:
> On Wed, Jun 14, 2017 at 9:57 AM, Vladimir Zakharov
>
> This is by design. Your offset is so large (more than a year), that
> ntpd fails its basic sanity test. You need to do one of the
> following:
> 1) Manually set the time before starting ntpd for the first time
> 2) Invoke ntpd with the "-g" flag
> 3) Run ntpdate before running ntpd.
My offset was about 22 minutes only. Your receipt solved the problem.
Thanks
root@vzakharov:~ # date
Wed Jun 14 19:02:55 MSK 2017
root@vzakharov:~ # /usr/sbin/ntpd -q -c /etc/ntp.conf -p /var/run/ntpd.pid -f
/var/db/ntpd.drift
14 Jun 19:05:01 ntpd[14722]: ntpd 4.2.8p10-a (1): Starting
14 Jun 19:05:01 ntpd[14722]: Command line: /usr/sbin/ntpd -q -c /etc/ntp.conf
-p /var/run/ntpd.pid -f /var/db/ntpd.drift
14 Jun 19:05:01 ntpd[14722]: proto: precision = 0.065 usec (-24)
14 Jun 19:05:01 ntpd[14722]: leapsecond file
('/var/db/ntpd.leap-seconds.list'): good hash signature
14 Jun 19:05:01 ntpd[14722]: leapsecond file
('/var/db/ntpd.leap-seconds.list'): loaded, expire=2017-12-28T00:00:00Z
last=2017-01-01T00:00:00Z ofs=37
14 Jun 19:05:01 ntpd[14722]: Listen and drop on 0 v6wildcard [::]:123
14 Jun 19:05:01 ntpd[14722]: Listen and drop on 1 v4wildcard 0.0.0.0:123
14 Jun 19:05:01 ntpd[14722]: Listen normally on 2 re0 10.60.0.245:123
14 Jun 19:05:01 ntpd[14722]: Listen normally on 3 lo0 [::1]:123
14 Jun 19:05:01 ntpd[14722]: Listen normally on 4 lo0 [fe80::1%2]:123
14 Jun 19:05:01 ntpd[14722]: Listen normally on 5 lo0 127.0.0.1:123
14 Jun 19:05:01 ntpd[14722]: Listening on routing socket on fd #26 for
interface updates
14 Jun 19:05:02 ntpd[14722]: Soliciting pool server 192.36.143.130
14 Jun 19:05:03 ntpd[14722]: Soliciting pool server 195.122.241.236
14 Jun 19:05:04 ntpd[14722]: Soliciting pool server 91.207.136.55
14 Jun 19:05:05 ntpd[14722]: Soliciting pool server 194.190.168.1
root@vzakharov:~ # ntpdate 0.freebsd.pool.ntp.org
14 Jun 19:28:49 ntpdate[14740]: step time server 194.190.168.1 offset
1344.686561 sec
root@vzakharov:~ # date
Wed Jun 14 19:28:53 MSK 2017
--
Regards, | "In theory there is no difference between theory
Vladimir Zakharov | and practice. In practice there is."- Yogi Berra
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
ntpd dies soon after start
Hello!
I have ntpd enabled to start during boot. I see, that it starts. But
querying it after booting fails:
# ntpq -p
ntpq: read: Connection refused
After manual start, it works for several seconds and then dies.
root@vzakharov:~ # service ntpd start
Starting ntpd.
root@vzakharov:~ # ntpq -p
remote refid st t when poll reach delay offset jitter
==
0.freebsd.pool. .POOL. 16 p- 6400.0000.000 0.000
ftpshare1.corbi 89.109.251.212 u1 6411.489 1344688 0.000
root@vzakharov:~ # ntpq -p
remote refid st t when poll reach delay offset jitter
==
0.freebsd.pool. .POOL. 16 p- 6400.0000.000 0.000
ftpshare1.corbi 89.109.251.212 u1 6411.495 1344688 0.018
time.ooonet.ru 89.109.251.242 u1 641 25.201 1344687 0.000
nag.aleksdem.co 194.190.168.12 u1 6411.914 1344687 0.000
root@vzakharov:~ # ntpq -p
remote refid st t when poll reach delay offset jitter
==
0.freebsd.pool. .POOL. 16 p- 6400.0000.000 0.000
ground.corbina. 193.11.166.202 u2 6411.673 1344687 0.000
ftpshare1.corbi 193.11.166.202 u1 6411.532 1344688 0.018
time.ooonet.ru 89.109.251.242 u2 641 25.169 1344687 0.035
nag.aleksdem.co 194.190.168.12 u1 6412.740 1344686 0.311
root@vzakharov:~ # ntpq -p
ntpq: read: Connection refused
Cleaning, rebuilding and reinstalling world does not help.
# uname -a
FreeBSD vzakharov 12.0-CURRENT FreeBSD 12.0-CURRENT #87 r319940: Wed Jun 14
17:02:16 MSK 2017 root@vzakharov:/home/obj/usr/src/sys/GENERIC-NODEBUG
amd64
# truss -f /usr/sbin/ntpd -c /etc/ntp.conf -p /var/run/ntpd.pid -f
/var/db/ntpd.drift
... (closing descriptors is omitted)
14511: openat(AT_FDCWD,"/dev/null",O_RDONLY,00) = 0 (0x0)
14511: dup2(0,1) = 1 (0x1)
14511: dup2(0,2) = 2 (0x2)
14511: socket(PF_LOCAL,SOCK_DGRAM|SOCK_CLOEXEC,0) = 3 (0x3)
14511: connect(3,{ AF_UNIX "/var/run/logpriv" },106) = 0 (0x0)
14511: setsid() = 14511 (0x38af)
14511: getrlimit(RLIMIT_STACK,{ cur=536870912,max=536870912 }) = 0 (0x0)
14511: setrlimit(RLIMIT_STACK,{ cur=204800,max=536870912 }) = 0 (0x0)
14511: setrlimit(RLIMIT_MEMLOCK,{ cur=33554432,max=33554432 }) = 0 (0x0)
14511: sigprocmask(SIG_SETMASK,{
SIGHUP|SIGINT|SIGQUIT|SIGILL|SIGTRAP|SIGABRT|SIGEMT|SIGFPE|SIGKILL|SIGBUS|SIGSEGV|SIGSYS|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2
},{ }) = 0 (0x0)
14511: sigaction(SIGHUP,{ 0x80107afe0 SA_SIGINFO ss_t },{ SIG_DFL 0x0 ss_t }) =
0 (0x0)
14511: sigprocmask(SIG_SETMASK,{ },0x0) = 0 (0x0)
14511: sigprocmask(SIG_SETMASK,{
SIGHUP|SIGINT|SIGQUIT|SIGILL|SIGTRAP|SIGABRT|SIGEMT|SIGFPE|SIGKILL|SIGBUS|SIGSEGV|SIGSYS|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2
},{ }) = 0 (0x0)
14511: sigaction(SIGINT,{ 0x80107afe0 SA_SIGINFO ss_t },{ SIG_DFL SA_RESTART
ss_t }) = 0 (0x0)
14511: sigprocmask(SIG_SETMASK,{ },0x0) = 0 (0x0)
14511: sigprocmask(SIG_SETMASK,{
SIGHUP|SIGINT|SIGQUIT|SIGILL|SIGTRAP|SIGABRT|SIGEMT|SIGFPE|SIGKILL|SIGBUS|SIGSEGV|SIGSYS|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2
},{ }) = 0 (0x0)
14511: sigaction(SIGQUIT,{ 0x80107afe0 SA_SIGINFO ss_t },{ SIG_DFL SA_RESTART
ss_t }) = 0 (0x0)
14511: sigprocmask(SIG_SETMASK,{ },0x0) = 0 (0x0)
14511: sigprocmask(SIG_SETMASK,{
SIGHUP|SIGINT|SIGQUIT|SIGILL|SIGTRAP|SIGABRT|SIGEMT|SIGFPE|SIGKILL|SIGBUS|SIGSEGV|SIGSYS|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2
},{ }) = 0 (0x0)
14511: sigaction(SIGTERM,{ 0x80107afe0 SA_SIGINFO ss_t },{ SIG_DFL SA_RESTART
ss_t }) = 0 (0x0)
14511: sigprocmask(SIG_SETMASK,{ },0x0) = 0 (0x0)
14511: sigprocmask(SIG_SETMASK,{
SIGHUP|SIGINT|SIGQUIT|SIGILL|SIGTRAP|SIGABRT|SIGEMT|SIGFPE|SIGKILL|SIGBUS|SIGSEGV|SIGSYS|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2
},{ }) = 0 (0x0)
14511: sigaction(SIGBUS,{ 0x80107afe0 SA_SIGINFO ss_t },{ SIG_DFL 0x0 ss_t }) =
0 (0x0)
14511: sigprocmask(SIG_SETMASK,{ },0x0) = 0 (0x0)
14511: sigprocmask(SIG_SETMASK,{
Re: make buildworld broken at r317821 (libsysdecode)
On Fri, May 05, 2017, Kyle Evans wrote: >FYI- This has now been committed as r317842. Apologies for the >breakage, and thanks for the reports! Fixed for me after reinstalling usr.bin/grep. Thanks. -- Regards, | "In theory there is no difference between theory Vladimir Zakharov | and practice. In practice there is."- Yogi Berra ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: make buildworld broken at r317821 (libsysdecode)
On Fri, May 05, 2017, David Wolfskill wrote: > On Fri, May 05, 2017 at 07:05:14PM +0800, Alastair Hogge wrote: > > On Fri, 5 May 2017 12:31:41 PM Vladimir Zakharov wrote: > > > Hello! > > > > > > Cannot build world due to error in compiling lib/libsysdecode. Cleaning > > > (make clean, make cleandepend and wiping out ccache data) does not help. > > > > > > $ make -j 4 buildworld && make -j 4 buildkernel && make installkernel > > > ... > > > > [removed build log & host configs] > > > > I am having observing the same problem too. I updated to r317713 & > > rebooted > > the r317713 host, then I tried to build a release & it failed with the same > > errors. > > I'm trying to update from r317729. Previous update was from r317481. > > I had no issues updating from r317789 to r317824 on my build machine > (amd64). -- Regards, | "In theory there is no difference between theory Vladimir Zakharov | and practice. In practice there is."- Yogi Berra ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
make buildworld broken at r317821 (libsysdecode)
rib/smbfs/include -DHAVE_ICONV=1 -MD -MF.depend.nbns_rq.pico -MTnbns_rq.pico -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c /usr/src/contrib/smbfs/lib/smb/nbns_rq.c -o nbns_rq.pico --- all_subdir_lib/libsysdecode --- --- ioctl.o --- 1 error generated. *** [ioctl.o] Error code 1 make[5]: stopped in /usr/src/lib/libsysdecode 1 error make[5]: stopped in /usr/src/lib/libsysdecode *** [all_subdir_lib/libsysdecode] Error code 2 make[4]: stopped in /usr/src/lib --- all_subdir_lib/libstand --- A failure has been detected in another branch of the parallel make make[5]: stopped in /usr/src/lib/libstand *** [all_subdir_lib/libstand] Error code 2 make[4]: stopped in /usr/src/lib --- all_subdir_lib/libsmb --- A failure has been detected in another branch of the parallel make make[5]: stopped in /usr/src/lib/libsmb *** [all_subdir_lib/libsmb] Error code 2 make[4]: stopped in /usr/src/lib 3 errors make[4]: stopped in /usr/src/lib *** [lib__L] Error code 2 make[3]: stopped in /usr/src 1 error make[3]: stopped in /usr/src *** [libraries] Error code 2 make[2]: stopped in /usr/src 1 error make[2]: stopped in /usr/src *** [_libraries] Error code 2 make[1]: stopped in /usr/src 1 error make[1]: stopped in /usr/src *** [buildworld] Error code 2 make: stopped in /usr/src 1 error $ cat /etc/src.conf WITHOUT_ACCT= WITHOUT_AMD= WITHOUT_APM= WITHOUT_ATM= WITHOUT_AUTHPF= WITHOUT_BLUETOOTH= WITHOUT_BOOTPD= WITHOUT_BSNMP= WITHOUT_CCD= WITHOUT_CROSS_COMPILER= WITHOUT_CTM= WITHOUT_CUSE= WITHOUT_EE= WITHOUT_FDT= WITHOUT_FINGER= WITHOUT_FLOPPY= WITHOUT_FTP= WITHOUT_GDB= WITHOUT_GNU_GREP_COMPAT= WITHOUT_HAST= WITHOUT_HTML= WITHOUT_HYPERV= WITHOUT_IPFILTER= WITHOUT_ISCSI= WITHOUT_KVM= WITHOUT_LEGACY_CONSOLE= #WITHOUT_LIB32= WITHOUT_LPR= WITHOUT_NDIS= WITHOUT_PC_SYSINSTALL= WITHOUT_PPP= WITHOUT_QUOTAS= WITHOUT_RADIUS_SUPPORT= WITHOUT_RBOOTD= WITHOUT_RCMDS= WITHOUT_SHAREDOCS= # commented out for docproj to build # WITHOUT_SYSCONS= WITHOUT_TALK= WITHOUT_TFTP= WITHOUT_TIMED= # WITHOUT_ZFS= WITH_BSD_GREP= WITH_CCACHE_BUILD= WITH_CLANG_EXTRAS= # WITH_CTF= WITH_DTRACE_TESTS= WITH_SORT_THREADS= WITH_SVN= -- Regards, | "In theory there is no difference between theory Vladimir Zakharov | and practice. In practice there is."- Yogi Berra ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: dchlient does not autostart anymore?
On Fri, Mar 24, 2017, Jung-uk Kim wrote: > On 03/24/2017 11:20, Kirill Ponomarev wrote: > > On 03/24, Vladimir Zakharov wrote: > >> Hello! > >> > >> After upgrading from r315544 to r315880 network interface doesn't get IP > >> address using DHCP on boot anymore. > >> > >> $ grep re0 /etc/rc.conf | grep -v "^#" > >> ifconfig_re0="DHCP" > >> > >> "service netif restart" doesn't help either. Only manual dhclient > >> starting. > > > > Same issues here with today CURRENT, r315896. > > FYI, r315901 fixed the issue for me. For me too. Thanks. -- Regards, | "In theory there is no difference between theory Vladimir Zakharov | and practice. In practice there is."- Yogi Berra ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
dchlient does not autostart anymore?
Hello! After upgrading from r315544 to r315880 network interface doesn't get IP address using DHCP on boot anymore. $ grep re0 /etc/rc.conf | grep -v "^#" ifconfig_re0="DHCP" "service netif restart" doesn't help either. Only manual dhclient starting. -- Regards, | "In theory there is no difference between theory Vladimir Zakharov | and practice. In practice there is."- Yogi Berra ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
r313938 breaks portsnap
Hello After recent upgrade portsnap doesn't work anymore: # portsnap fetch update Looking up portsnap.FreeBSD.org mirrors... 6 mirrors found. Fetching snapshot tag from ec2-eu-west-1.portsnap.freebsd.org... done. Fetching snapshot metadata... done. Updating from Tue Feb 21 16:05:39 MSK 2017 to Tue Feb 21 16:59:30 MSK 2017. Fetching 5 metadata patches.lam: unable to limit stdio: Capabilities insufficient done. Applying metadata patches... done. Fetching 5 metadata files... lam: unable to limit stdio: Capabilities insufficient /usr/sbin/portsnap: cannot open 8c94d2c3f8fcea20eb1fd82021566c99c63a010e6b3702ee11e7a491795bcfb8.gz: No such file or directory metadata is corrupt. Reverting r313938 fixes the problem. -- Regards, | "In theory there is no difference between theory Vladimir Zakharov | and practice. In practice there is."- Yogi Berra ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
ACPI Error on HP ProBook 430 G2
Hello! Some time ago new ACPI messages appeared on console and in /var/log/messages. Like these: ACPI Error: Needed type [Reference], found [Processor] 0xf800043b8980 (20161117/exresop-111) ACPI Exception: AE_AML_OPERAND_TYPE, While resolving operands for [OpcodeName unavailable] (20161117/dswexec-498) ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.EC0.PPNT] (Node 0xf80004396640), AE_AML_OPERAND_TYPE (20161117/psparse-560) ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.EC0._Q04] (Node 0xf80004396c40), AE_AML_OPERAND_TYPE (20161117/psparse-560) acpi_ec0: evaluation of query method _Q04 failed: AE_AML_OPERAND_TYPE I'm sure that there were no such messages earlier. Suspend/resume works for me. But after disconnecting power line hw.acpi.acline still equals to 1. And powerd/powerdxx do not adjust CPU frequency anymore. System info: $ uname -a FreeBSD vzakharov 12.0-CURRENT FreeBSD 12.0-CURRENT #14 r310326M: Tue Dec 20 16:42:21 MSK 2016 root@vzakharov:/home/obj/usr/src/sys/GENERIC-NODEBUG amd64 dmesg: http://pastebin.com/cYD8cR0b hw.acpi: http://pastebin.com/Tht9B0FZ acpidump: http://vzakharov.ru/z2v-HPProBook430G2.asl PS. I'm not subscribed to freebsd-acpi. So keep me in CC, please. -- Regards, | "In theory there is no difference between theory Vladimir Zakharov | and practice. In practice there is."- Yogi Berra ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CURRENT: ipfw: problems with timeouts and worse network performance
On Fri, May 20, 2016, Jan Bramkamp wrote: > On 20/05/16 15:51, Vladimir Zakharov wrote: > > On Fri, May 20, 2016, Jan Bramkamp wrote: > >> On 20/05/16 14:54, Vladimir Zakharov wrote: > >>> Hello > >>> > >>> On Fri, May 20, 2016, O. Hartmann wrote: > >>>> I reported earlier about broken pipes in ssh sessions to remote hosts, > >>>> which occur on an erratic basis. i'm investigating this problem now and > >>>> it seems that it is also ipfw-related, but I'm not sure. This problem > >>>> is present since a couple of weeks now. > >>> > >>> Maybe this could help... > >>> > >>> I've also experienced problems with broken pipes in ssh sessions some > >>> time ago. Setting in sysctl.conf > >>> > >>> net.inet.ip.fw.dyn_ack_lifetime=3600 > >>> > >>> fixed problem for me. I didn't experiment with the value though. So, > >>> possibly, changing default value (300s) to 1 hour is overkill :). > >> > >> By default the OpenSSH SSH client is configured to use TCP keepalives. > >> Those should produce enough packets at a short enough interval to keep > >> the dynamic IPFW state established. > >> > >> Does your traffic pass through libalias? > > I guess not. How can I be sure? > > Libalias is used by ipfw and the old userland natd to implement IPv4 > NAT. It requires unmodified access to all packets including their > headers. LRO and TSO coalesce packets to reduce save CPU time but the > process is loses some of the information required by libalias. Unless > your ruleset uses ipfw in-kernel NAT or diverts traffic to natd you > don't have to worry about libalias. > > Use `kldstat -v | grep libalias` to check for libalias in the running > kernel and `pgrep natd` to search for running natd instances. Surely, I do not use NAT (and libalias): root@vzakharov:~ # kldstat -v | grep libalias root@vzakharov:~ # pgrep natd I use GENERIC-NODEBUG kernel (r300138) with ipfw module. And 'workstation' firewall type. -- Regards, | "In theory there is no difference between theory Vladimir Zakharov | and practice. In practice there is."- Yogi Berra ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CURRENT: ipfw: problems with timeouts and worse network performance
On Fri, May 20, 2016, Jan Bramkamp wrote: > On 20/05/16 14:54, Vladimir Zakharov wrote: > > Hello > > > > On Fri, May 20, 2016, O. Hartmann wrote: > >> I reported earlier about broken pipes in ssh sessions to remote hosts, > >> which occur on an erratic basis. i'm investigating this problem now and > >> it seems that it is also ipfw-related, but I'm not sure. This problem > >> is present since a couple of weeks now. > > > > Maybe this could help... > > > > I've also experienced problems with broken pipes in ssh sessions some > > time ago. Setting in sysctl.conf > > > > net.inet.ip.fw.dyn_ack_lifetime=3600 > > > > fixed problem for me. I didn't experiment with the value though. So, > > possibly, changing default value (300s) to 1 hour is overkill :). > > By default the OpenSSH SSH client is configured to use TCP keepalives. > Those should produce enough packets at a short enough interval to keep > the dynamic IPFW state established. > > Does your traffic pass through libalias? I guess not. How can I be sure? -- Regards, | "In theory there is no difference between theory Vladimir Zakharov | and practice. In practice there is."- Yogi Berra ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CURRENT: ipfw: problems with timeouts and worse network performance
Hello On Fri, May 20, 2016, O. Hartmann wrote: > I reported earlier about broken pipes in ssh sessions to remote hosts, > which occur on an erratic basis. i'm investigating this problem now and > it seems that it is also ipfw-related, but I'm not sure. This problem > is present since a couple of weeks now. Maybe this could help... I've also experienced problems with broken pipes in ssh sessions some time ago. Setting in sysctl.conf net.inet.ip.fw.dyn_ack_lifetime=3600 fixed problem for me. I didn't experiment with the value though. So, possibly, changing default value (300s) to 1 hour is overkill :). -- Regards, | "In theory there is no difference between theory Vladimir Zakharov | and practice. In practice there is."- Yogi Berra ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Question about _POSIX2_VERSION value
Hello Currently _POSIX2_VERSION is set to 199212L [1]: $ grep _POSIX2_VERSION /usr/src/include/*.h /usr/src/include/unistd.h:#define _POSIX2_VERSION 199212L Unfortunately, I couldn't find any authoritative open source for possible _POSIX2_VERSION values. But, for example, GNU diff uses value 199209 for setting conformity with POSIX 1003.2-1992 standard [2]. Example code from "Advanced Unix Programming" book [3] also uses value 199209. So shouldn't be _POSIX2_VERSION value changed to 199209L? Or even to 200112L (almost 14 years have passed from the commit [1])? 1: https://svnweb.freebsd.org/base?view=revision=103929 2: https://www.gnu.org/software/diffutils/manual/html_node/Standards-conformance.html 3: http://basepath.com/aup/ex/ckstdvers_8c-source.html -- Regards, | "In theory there is no difference between theory Vladimir Zakharov | and practice. In practice there is."- Yogi Berra ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: GENERIC-NODEBUG panics, GENERIC does not
On Fri, Apr 15, 2016, Konstantin Belousov wrote: > On Fri, Apr 15, 2016 at 02:38:18PM +0300, Vladimir Zakharov wrote: > > On Fri, Apr 15, 2016, Konstantin Belousov wrote: > > > On Fri, Apr 15, 2016 at 01:26:44PM +0300, Vladimir Zakharov wrote: > > > > Hello > > > > > > > > Setting 'kern.eventtimer.periodic = 1' in /etc/sysctl.conf leads to > > > > GENERIC-NODEBUG panic. GENERIC loads without problems. > > > > So do GENERIC-NODEBUG as of r297245. > > > > > > > > https://imgur.com/0DtDU3m > > > > > > > > $ uname -a > > > > > > > > FreeBSD vzakharov 11.0-CURRENT FreeBSD 11.0-CURRENT #4 r298037: Fri Apr > > > > 15 12:27:40 MSK 2016 > > > > root@vzakharov:/home/obj/usr/src/sys/GENERIC-NODEBUG amd64 > > > > > > > > > > I cannot reproduce it locally. > > > Please provide me verbose dmesg from the successfull boot on your machine. > > > > GENERIC with kern.eventtimer.periodic=1: http://pastebin.com/raw/TB0TKSje > > GENERIC-NODEBUG: http://pastebin.com/raw/05CchraS > I need _verbose_ dmesg. I need the reports about LAPICs initializations, > with register dumps. dmesg before patching (kern.eventtimer.periodic is not set to avoid panic): http://pastebin.com/raw/CnJ911gX dmesg for patched kernel (kern.eventtimer.periodic = 1): http://pastebin.com/raw/9Azz9LxT > > > > > > Also, for the panic, show me the output of the same data as on the > > > screenshot and the output of 'show registers'. > > > > https://imgur.com/pO8Yc3w > Ok, this seems to be yet another case of missed count mode divisor > initialization. Please try the patch at the end of the messasge. Patched kernel doesn't panic anymore. Thanks. > > > Also please load your kernel into kgdb and do > > > list *lapic_et_start+0x281 > By 'your kernel' I mean 'your panicing kernel'. It _was_ panicing kernel. Than not sure what you meant. There is no any dump/core files because dumpdev is not configured yet at the moment of panic. What should I do to retrieve the required information? I've simply run: $ kgdb /boot/kernel/kernel -- Regards, | "In theory there is no difference between theory Vladimir Zakharov | and practice. In practice there is."- Yogi Berra ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: GENERIC-NODEBUG panics, GENERIC does not
On Fri, Apr 15, 2016, Vladimir Zakharov wrote:
> $ kgdb /boot/kernel/kernel
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for details.
> This GDB was configured as "amd64-marcel-freebsd"...
> (kgdb) list *lapic_et_start+0x281
> 0x81099411 is in lapic_et_start (cpufunc.h:408).
> 403 cpufunc.h: No such file or directory.
> in cpufunc.h
The same for GENERIC:
$ kgdb /boot/kernel.GENERIC/kernel
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...
(kgdb) list *lapic_et_start+0x281
0x80fdd3b1 is in lapic_et_start (/usr/src/sys/x86/x86/local_apic.c:846).
841 lapic_calibrate_initcount(et, la);
842 et->et_min_period = (0x0002LLU << 32) /
et->et_frequency;
843 et->et_max_period = (0xfffeLLU << 32) /
et->et_frequency;
844 }
845 if (period != 0) {
846 if (la->la_timer_mode == LAT_MODE_UNDEF)
847 lapic_timer_set_divisor(lapic_timer_divisor);
848 la->la_timer_mode = LAT_MODE_PERIODIC;
849 la->la_timer_period = ((uint32_t)et->et_frequency *
period) >>
850 32;
(kgdb)
--
Regards, | "In theory there is no difference between theory
Vladimir Zakharov | and practice. In practice there is."- Yogi Berra
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: GENERIC-NODEBUG panics, GENERIC does not
On Fri, Apr 15, 2016, Konstantin Belousov wrote:
> On Fri, Apr 15, 2016 at 01:26:44PM +0300, Vladimir Zakharov wrote:
> > Hello
> >
> > Setting 'kern.eventtimer.periodic = 1' in /etc/sysctl.conf leads to
> > GENERIC-NODEBUG panic. GENERIC loads without problems.
> > So do GENERIC-NODEBUG as of r297245.
> >
> > https://imgur.com/0DtDU3m
> >
> > $ uname -a
> >
> > FreeBSD vzakharov 11.0-CURRENT FreeBSD 11.0-CURRENT #4 r298037: Fri Apr
> > 15 12:27:40 MSK 2016 root@vzakharov:/home/obj/usr/src/sys/GENERIC-NODEBUG
> > amd64
> >
>
> I cannot reproduce it locally.
> Please provide me verbose dmesg from the successfull boot on your machine.
GENERIC with kern.eventtimer.periodic=1: http://pastebin.com/raw/TB0TKSje
GENERIC-NODEBUG: http://pastebin.com/raw/05CchraS
> Also, for the panic, show me the output of the same data as on the
> screenshot and the output of 'show registers'.
https://imgur.com/pO8Yc3w
> Also please load your kernel into kgdb and do
> list *lapic_et_start+0x281
$ kgdb /boot/kernel/kernel
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...
(kgdb) list *lapic_et_start+0x281
0x81099411 is in lapic_et_start (cpufunc.h:408).
403 cpufunc.h: No such file or directory.
in cpufunc.h
(kgdb) list *lapic_et_start
0x81099190 is in lapic_et_start (/usr/src/sys/x86/x86/local_apic.c:833).
828 }
829 }
830
831 static int
832 lapic_et_start(struct eventtimer *et, sbintime_t first, sbintime_t
period)
833 {
834 struct lapic *la;
835
836 la = [PCPU_GET(apic_id)];
837 if (et->et_frequency == 0) {
(kgdb)
PS. I've started building kernel with clean OBJDIR and with ccache disabled.
--
Regards, | "In theory there is no difference between theory
Vladimir Zakharov | and practice. In practice there is."- Yogi Berra
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
GENERIC-NODEBUG panics, GENERIC does not
Hello Setting 'kern.eventtimer.periodic = 1' in /etc/sysctl.conf leads to GENERIC-NODEBUG panic. GENERIC loads without problems. So do GENERIC-NODEBUG as of r297245. https://imgur.com/0DtDU3m $ uname -a FreeBSD vzakharov 11.0-CURRENT FreeBSD 11.0-CURRENT #4 r298037: Fri Apr 15 12:27:40 MSK 2016 root@vzakharov:/home/obj/usr/src/sys/GENERIC-NODEBUG amd64 -- Regards, | "In theory there is no difference between theory Vladimir Zakharov | and practice. In practice there is."- Yogi Berra ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SVN r296272 breaks virtualbox
On Tue, Mar 01, 2016, Michael Butler wrote:
> The removal of "taskqueue_enqueue_fast" breaks the virtualbox kmods:
>
> Mar 1 16:54:36 toshi kernel: vboxdrv: fAsync=0 offMin=0x914 offMax=0x151c
> Mar 1 16:54:36 toshi kernel: link_elf_obj: symbol
> taskqueue_enqueue_fast undefined
> Mar 1 16:54:36 toshi kernel: linker_load_file: Unsupported file type
> Mar 1 16:54:36 toshi kernel: link_elf_obj: symbol
> taskqueue_enqueue_fast undefined
> Mar 1 16:54:36 toshi kernel: linker_load_file: Unsupported file type
> Mar 1 16:54:36 toshi kernel: KLD vboxnetadp.ko: depends on vboxnetflt -
> not available or version mismatch
> Mar 1 16:54:36 toshi kernel: linker_load_file: Unsupported file type
Attached patch for emulators/virtualbox-ose and rebuilding
virtualbox-ose and virtualbox-ose-kmod fixed problem for me.
===
---
files/patch-src-VBox-HostDrivers-VBoxNetFlt-freebsd-VBoxNetFlt-freebsd.c.orig
2016-03-02 10:15:39.814893000 +0300
+++ files/patch-src-VBox-HostDrivers-VBoxNetFlt-freebsd-VBoxNetFlt-freebsd.c
2016-03-02 10:16:39.070847000 +0300
@@ -1,10 +1,5 @@
-Add VLAN trunking support to vboxnetflt
-
-See:
http://lists.freebsd.org/pipermail/freebsd-emulation/2012-April/009698.html
-See:
http://lists.freebsd.org/pipermail/freebsd-emulation/2013-May/010605.html
-Submitted by: Landon J Fuller
./src/VBox/HostDrivers/VBoxNetFlt/freebsd/VBoxNetFlt-freebsd.c.orig
2013-04-12 06:38:11.0 -0400
-+++ ./src/VBox/HostDrivers/VBoxNetFlt/freebsd/VBoxNetFlt-freebsd.c
2013-05-25 20:14:52.152180452 -0400
+--- src/VBox/HostDrivers/VBoxNetFlt/freebsd/VBoxNetFlt-freebsd.c.orig
2016-01-19 22:18:38.0 +0300
src/VBox/HostDrivers/VBoxNetFlt/freebsd/VBoxNetFlt-freebsd.c
2016-03-02 10:10:21.181922000 +0300
@@ -51,6 +51,7 @@
#include
#include
@@ -13,6 +8,24 @@
#include
#include
+@@ -369,7 +370,7 @@
+ mtx_lock_spin(>u.s.inq.ifq_mtx);
+ _IF_ENQUEUE(>u.s.inq, m);
+ mtx_unlock_spin(>u.s.inq.ifq_mtx);
+-taskqueue_enqueue_fast(taskqueue_fast, >u.s.tskin);
++taskqueue_enqueue(taskqueue_fast, >u.s.tskin);
+ }
+ /*
+ * Handle mbufs on the outgoing hook, frames going to the interface
+@@ -387,7 +388,7 @@
+ mtx_lock_spin(>u.s.outq.ifq_mtx);
+ _IF_ENQUEUE(>u.s.outq, m);
+ mtx_unlock_spin(>u.s.outq.ifq_mtx);
+-taskqueue_enqueue_fast(taskqueue_fast, >u.s.tskout);
++taskqueue_enqueue(taskqueue_fast, >u.s.tskout);
+ }
+ else
+ {
@@ -427,6 +428,8 @@
struct ifnet *ifp = pThis->u.s.ifp;
unsigned int cSegs = 0;
===
--
Regards, | "In theory there is no difference between theory
Vladimir Zakharov | and practice. In practice there is."- Yogi Berra
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: LibreOffice doesn't work anymore
On Fri, Jan 22, 2016, Konstantin Belousov wrote: > On Fri, Jan 22, 2016 at 11:17:08AM +0300, Vladimir Zakharov wrote: > > Hello! > > > > Updating from r294203 to r294460 has broken LibreOffice. Now LO core > > dumps with the following message: > > > > GLib (gthread-posix.c): Unexpected error from C library during > > 'pthread_key_create': Function not implemented. Aborting. > > > > Here is the backtrace: > > > > GNU gdb 6.1.1 [FreeBSD] > > ... > > This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols > > found)... > > Core was generated by `soffice.bin'. > > Program terminated with signal 6, Aborted. > > Reading symbols from > > /usr/local/lib/libreoffice/program/libuno_sal.so.3...(no debugging symbols > > found)...done. > > Loaded symbols for /usr/local/lib/libreoffice/program/libuno_sal.so.3 > > ... > > (skipped lots of "Reading symbols ... (no debugging symbols found)" and > > "Loaded symbols ..." strings) > > ... > Did you skipped the message about libthr.so.3 ? > > If yes, update to at least r294470. Works for me again on r294556. Thanks. -- Regards, | "In theory there is no difference between theory Vladimir Zakharov | and practice. In practice there is."- Yogi Berra ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: LibreOffice doesn't work anymore
On Fri, Jan 22, 2016, Konstantin Belousov wrote: > On Fri, Jan 22, 2016 at 11:17:08AM +0300, Vladimir Zakharov wrote: > > Hello! > > > > Updating from r294203 to r294460 has broken LibreOffice. Now LO core > > dumps with the following message: > > > > GLib (gthread-posix.c): Unexpected error from C library during > > 'pthread_key_create': Function not implemented. Aborting. > > > > Here is the backtrace: > > > > GNU gdb 6.1.1 [FreeBSD] > > ... > > This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols > > found)... > > Core was generated by `soffice.bin'. > > Program terminated with signal 6, Aborted. > > Reading symbols from > > /usr/local/lib/libreoffice/program/libuno_sal.so.3...(no debugging symbols > > found)...done. > > Loaded symbols for /usr/local/lib/libreoffice/program/libuno_sal.so.3 > > ... > > (skipped lots of "Reading symbols ... (no debugging symbols found)" and > > "Loaded symbols ..." strings) > > ... > Did you skipped the message about libthr.so.3 ? Yes, there was message about libthr.so.3 in omitted part. > > If yes, update to at least r294470. > Ok. Started updating to r294556. -- Regards, | "In theory there is no difference between theory Vladimir Zakharov | and practice. In practice there is."- Yogi Berra ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
LibreOffice doesn't work anymore
Hello! Updating from r294203 to r294460 has broken LibreOffice. Now LO core dumps with the following message: GLib (gthread-posix.c): Unexpected error from C library during 'pthread_key_create': Function not implemented. Aborting. Here is the backtrace: GNU gdb 6.1.1 [FreeBSD] ... This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols found)... Core was generated by `soffice.bin'. Program terminated with signal 6, Aborted. Reading symbols from /usr/local/lib/libreoffice/program/libuno_sal.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libreoffice/program/libuno_sal.so.3 ... (skipped lots of "Reading symbols ... (no debugging symbols found)" and "Loaded symbols ..." strings) ... Reading symbols from /usr/local/lib/libtasn1.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libtasn1.so.6 Reading symbols from /usr/local/lib/libnettle.so.4...Error while reading shared library symbols: Dwarf Error: wrong version in compilation unit header (is 3, should be 2) [in module /usr/local/lib/libnettle.so.4] Reading symbols from /usr/local/lib/libhogweed.so.2...Error while reading shared library symbols: Dwarf Error: wrong version in compilation unit header (is 3, should be 2) [in module /usr/local/lib/libhogweed.so.2] Reading symbols from /usr/local/lib/libgmp.so.10...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgmp.so.10 Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x000800dc9b0a in thr_kill () from /lib/libc.so.7 [New LWP 100189] (gdb) -- Regards, | "In theory there is no difference between theory Vladimir Zakharov | and practice. In practice there is."- Yogi Berra ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
