aarch64 head -r338921 vs. man ld vs. ld -v : man ld describes GNU when ld is lld
[This is based on buildworld buildkernel and installing.]
I've updated to:
# uname -apKU
FreeBSD pine64 12.0-ALPHA7 FreeBSD 12.0-ALPHA7 #17 r338921M: Mon Sep 24
19:19:08 PDT 2018
markmi@pine64:/usr/obj/cortexA53_clang/arm64.aarch64/usr/src/arm64.aarch64/sys/GENERIC-NODBG
arm64 aarch64 1200084 1200084
For which:
# ld -v
LLD 6.0.1 (FreeBSD 335540-124) (compatible with GNU linkers)
But man ld reports GNU/BFD material:
# man ld
LD(1)GNU Development Tools LD(1)
NAME
ld - The GNU linker
SYNOPSIS
ld [options] objfile ...
DESCRIPTION
. . .
This man page does not describe the command language; see the ld entry
in "info" for full details on the command language and on other aspects
of the GNU linker.
This version of ld uses the general purpose BFD libraries to operate on
object files. . . .
Aside from its flexibility, the GNU linker is more helpful than other
linkers in providing diagnostic information. . . .
The GNU linker ld is meant to cover a broad range of situations, and to
be as compatible as possible with other linkers. As a result, you have
many choices to control its behavior.
. . .
(I do not see such in my amd64 builds.)
I'm not claiming this is new: I just noticed.
For reference on the Pine64+ 2GB aarch64 system
being used for this (avoiding >>> prefixes on lines):
#
~/sys_build_scripts.aarch64-host/make_cortexA53_nodebug_clang_bootstrap-aarch64-host.sh
check-old
Script started, output file is
/root/sys_typescripts/typescript_make_cortexA53_nodebug_clang_bootstrap-aarch64-host-2018-09-24:22:53:10
... Checking for old files
... Checking for old libraries
... Checking for old directories
To remove old files and directories run 'make delete-old'.
To remove old libraries run 'make delete-old-libs'.
Script done, output file is
/root/sys_typescripts/typescript_make_cortexA53_nodebug_clang_bootstrap-aarch64-host-2018-09-24:22:53:10
(So I'd run delete-old before this.)
# more
~/sys_build_scripts.aarch64-host/make_cortexA53_nodebug_clang_bootstrap-aarch64-host.sh
kldload -n filemon && \
script
~/sys_typescripts/typescript_make_cortexA53_nodebug_clang_bootstrap-aarch64-host-$(date
+%Y-%m-%d:%H:%M:%S) \
env __MAKE_CONF="/root/src.configs/make.conf" \
SRCCONF="/dev/null"
SRC_ENV_CONF="/root/src.configs/src.conf.cortexA53-clang-bootstrap.aarch64-host"
\
WITH_META_MODE=yes \
MAKEOBJDIRPREFIX="/usr/obj/cortexA53_clang/arm64.aarch64" \
make $*
# more ~/src.configs/src.conf.cortexA53-clang-bootstrap.aarch64-host
TO_TYPE=aarch64
#
KERNCONF=GENERIC-NODBG
TARGET=arm64
.if ${.MAKE.LEVEL} == 0
TARGET_ARCH=${TO_TYPE}
.export TARGET_ARCH
.endif
#
#WITH_CROSS_COMPILER=
WITH_SYSTEM_COMPILER=
WITH_SYSTEM_LINKER=
#
#CPUTYPE=soft
WITH_LIBCPLUSPLUS=
#WITH_LLD_BOOTSTRAP=
WITHOUT_BINUTILS_BOOTSTRAP=
WITH_ELFTOOLCHAIN_BOOTSTRAP=
#WITH_CLANG_BOOTSTRAP=
WITH_CLANG=
WITH_CLANG_IS_CC=
WITH_CLANG_FULL=
WITH_CLANG_EXTRAS=
WITH_LLD=
WITH_LLD_IS_LD=
WITHOUT_BINUTILS=
WITH_LLDB=
#
WITH_BOOT=
WITHOUT_LIB32=
#
WITHOUT_GCC_BOOTSTRAP=
WITHOUT_GCC=
WITHOUT_GCC_IS_CC=
WITHOUT_GNUCXX=
#
NO_WERROR=
#WERROR=
MALLOC_PRODUCTION=
#
WITH_REPRODUCIBLE_BUILD=
WITH_DEBUG_FILES=
#
# Use of the .clang 's here avoids
# interfering with other CFLAGS
# usage, such as ?= usage.
CFLAGS.clang+= -mcpu=cortex-a53
CXXFLAGS.clang+= -mcpu=cortex-a53
CPPFLAGS.clang+= -mcpu=cortex-a53
ACFLAGS.arm64cpuid.S+= -mcpu=cortex-a53+crypto
ACFLAGS.aesv8-armx.S+= -mcpu=cortex-a53+crypto
ACFLAGS.ghashv8-armx.S+=-mcpu=cortex-a53+crypto
# more ~/src.configs/make.conf
CFLAGS.gcc+= -v
LDFLAGS.lld+= -Wl,--no-threads
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
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: r338641 && /dev/cyapa0: moused does not show pointer on console
El día Monday, September 24, 2018 a las 09:01:34PM +0200, Michael Gmelin escribió: > >> On 24/09/2018 13:21, Matthias Apitz wrote: > >> Re/ i915kms, I have to load it with kldload by hand. If I load it via > >> loader.conf, the cyapa devices (both) say 'Unable to bring the device > >> out of bootstrap'. > > > > That's probably because you use device hints to configure cyapa, but i2c bus > > numbers are different depending on whether the kms driver is loaded or not > > (because it also creates i2c buses). > > > > Try to remove the hints and to use chromebook_platform(4) instead. Thanks, I will test chromebook_platform_load="YES" > Also, I think the preferred way to load i915kms is to use kld_list (might be > unrelated, but still). > > pkg install drm-next-kmod > sysrc kld_list="/boot/modules/i915kms.ko" Thanks too. On my laptop in production I do use a handmade script /usr/local/etc/rc.d/loadi915kms to load the module at late time. matthias -- Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/ 📱 +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub ___ 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: error: undefined symbol: main in poudriere jail
On 24 Sep, blubee blubeeme wrote:
> This issue seemed to have come up in the past:
> https://lists.freebsd.org/pipermail/freebsd-current/2018-March/068870.html
>
>
> Jail name: amd64_cur
> Jail version: 12.0-ALPHA7 1200084
> Jail vcs version: r338898
> Jail arch: amd64
> Jail method: svn
> Jail mount:/usr/local/poudriere/jails/amd64_cur
> Jail fs: zroot/poudriere/jails/amd64_cur
> Jail updated: 2018-09-24 03:39:31
> Tree name: default
> Tree method: portsnap
> Status:
>
> error
> /usr/bin/cc -pipe -fno-strict-aliasing -fno-common -fexceptions -std=gnu99
> -m64 -Qunused-arguments -O3 -march=native -finline-functions -flto
> -fomit-frame-pointer -pedantic -pedantic-errors -Wall -Wextra -Wundef
> -Wfloat-equal -Wshadow -Wbad-function-cast -Wdeclaration-after-statement
> -Wc++-compat -Winline -Wno-long-long -Wno-variadic-macros -Wdocumentation
> -m64 src/rttherm/CMakeFiles/rttherm.dir/spectrum.c.o
> src/rttherm/CMakeFiles/rttherm.dir/viewtherm.c.o -o bin/rttherm
> -Wl,-rpath,/wrkdirs/usr/ports/cad/brlcad/work/.build/lib:/usr/local/lib:
> lib/libged.so.20.0.1 lib/librtuif_multispectral.a
> lib/libmultispectral.so.20.0.1 lib/libfb.so.20.0.1 lib/libpkg.so.20.0.1
> /usr/local/lib/libSM.so /usr/local/lib/libICE.so /usr/local/lib/libGLU.so
> /usr/local/lib/libGL.so /usr/local/lib/libSM.so /usr/local/lib/libICE.so
> /usr/local/lib/libGLU.so /usr/local/lib/libGL.so lib/libtk.so.8.5
> /usr/local/lib/libX11.so /usr/local/lib/libXext.so lib/libtkstub.a
> lib/libtclstub.a /usr/local/lib/libXrender.so lib/libwdb.so.20.0.1
> lib/libicv.so.20.0.1 lib/libpng16.so.16.29.0 lib/libnetpbm.so
> lib/libanalyze.so.20.0.1 lib/libtcl.so.8.5.19 lib/libclipper.so.4.6.0
> lib/librt.so.20.0.1 lib/libnmg.so lib/libgdiam.so lib/libvds.so.1.0.1
> lib/libbrep.so.20.0.1 lib/libbg.so.20.0.1 lib/libopenNURBS.so.2012.10.245
> lib/libp2t.so.1.0.1 lib/libz.so.1.2.11 lib/libtinycthread.so lib/liblz4.so
> lib/libbn.so.20.0.1 lib/libbu.so.20.0.1 lib/libregex.so.1.0.4 -lm -pthread
> -ldl && :
> FAILED: bin/rttherm
> : && /usr/bin/cc -pipe -fno-strict-aliasing -fno-common -fexceptions
> -std=gnu99 -m64 -Qunused-arguments -O3 -march=native -finline-functions
> -flto -fomit-frame-pointer -pedantic -pedantic-errors -Wall -Wextra -Wundef
> -Wfloat-equal -Wshadow -Wbad-function-cast -Wdeclaration-after-statement
> -Wc++-compat -Winline -Wno-long-long -Wno-variadic-macros -Wdocumentation
> -m64 src/rttherm/CMakeFiles/rttherm.dir/spectrum.c.o
> src/rttherm/CMakeFiles/rttherm.dir/viewtherm.c.o -o bin/rttherm
> -Wl,-rpath,/wrkdirs/usr/ports/cad/brlcad/work/.build/lib:/usr/local/lib:
> lib/libged.so.20.0.1 lib/librtuif_multispectral.a
> lib/libmultispectral.so.20.0.1 lib/libfb.so.20.0.1 lib/libpkg.so.20.0.1
> /usr/local/lib/libSM.so /usr/local/lib/libICE.so /usr/local/lib/libGLU.so
> /usr/local/lib/libGL.so /usr/local/lib/libSM.so /usr/local/lib/libICE.so
> /usr/local/lib/libGLU.so /usr/local/lib/libGL.so lib/libtk.so.8.5
> /usr/local/lib/libX11.so /usr/local/lib/libXext.so lib/libtkstub.a
> lib/libtclstub.a /usr/local/lib/libXrender.so lib/libwdb.so.20.0.1
> lib/libicv.so.20.0.1 lib/libpng16.so.16.29.0 lib/libnetpbm.so
> lib/libanalyze.so.20.0.1 lib/libtcl.so.8.5.19 lib/libclipper.so.4.6.0
> lib/librt.so.20.0.1 lib/libnmg.so lib/libgdiam.so lib/libvds.so.1.0.1
> lib/libbrep.so.20.0.1 lib/libbg.so.20.0.1 lib/libopenNURBS.so.2012.10.245
> lib/libp2t.so.1.0.1 lib/libz.so.1.2.11 lib/libtinycthread.so lib/liblz4.so
> lib/libbn.so.20.0.1 lib/libbu.so.20.0.1 lib/libregex.so.1.0.4 -lm -pthread
> -ldl && :
> /usr/bin/ld: error: undefined symbol: main
referenced by crt1.c:74
> (/usr/local/poudriere/jails/amd64_cur/usr/src/lib/csu/amd64/crt1.c:74)
/usr/lib/crt1.o:(_start)
> cc: error: linker command failed with exit code 1 (use -v to see invocation)
> ninja: build stopped: subcommand failed.
> *** Error code 1
It looks like you are trying to build an executable, but none of the
source files (viewtherm.c or spectrum.c) for the executable contain a
main() function.
Here is simple example showing how to reproduce this error:
%cat test.c
void
test()
{
}
%cc -o test test.c
/usr/bin/ld: error: undefined symbol: main
>>> referenced by crt1.c:74 (/usr/src/lib/csu/amd64/crt1.c:74)
>>> /usr/lib/crt1.o:(_start)
cc: error: linker command failed with exit code 1 (use -v to see invocation)
___
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: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored
On 23 September 2018 at 07:31, Michael Tuexen wrote: > Using this patch I was able to build/install world and kernel on an i386 > system. > However, after removing it, I can't build world then. When trying to compile a > kernel "the old way" I end up with: > > tuexen@head:~/head/sys/i386/conf % config -g TCP > WARNING: duplicate option `GEOM_PART_GPT' encountered. > Kernel build directory is ../compile/TCP > Don't forget to do ``make cleandepend && make depend'' > tuexen@head:~/head/sys/i386/conf % cd ../compile/TCP/ > tuexen@head:~/head/sys/i386/compile/TCP % make -j 6 > make: "../../../conf/../../../conf/kern.pre.mk" line 126: amd64/i386 kernel > requires linker ifunc support > > This is r338893. > > amd64 works without any problem. So this is i386 specific. Any idea how to > fix it? This safety belt is in place to ensure we don't build a non-functional kernel - now that the i386 kernel requires ifunc support using old GNU ld results in a kernel that doesn't boot. The workaround for the "old way" is to explicitly set LD=ld.lld in the environment - "LD=ld.lld make -j 6" should work. More details in this -arch thread, when amd64 encountered this hiccup: https://lists.freebsd.org/pipermail/freebsd-arch/2018-May/018967.html The same issue now affects i386 as it has started using ifuncs, and will be resolved once we can switch i386's /usr/bin/ld to be lld, which is waiting on ports fixes in PR214864. ___ 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: r338641 && /dev/cyapa0: moused does not show pointer on console
> On 24. Sep 2018, at 15:08, Andriy Gapon wrote: > >> On 24/09/2018 13:21, Matthias Apitz wrote: >> Re/ i915kms, I have to load it with kldload by hand. If I load it via >> loader.conf, the cyapa devices (both) say 'Unable to bring the device >> out of bootstrap'. > > That's probably because you use device hints to configure cyapa, but i2c bus > numbers are different depending on whether the kms driver is loaded or not > (because it also creates i2c buses). > > Try to remove the hints and to use chromebook_platform(4) instead. Also, I think the preferred way to load i915kms is to use kld_list (might be unrelated, but still). pkg install drm-next-kmod sysrc kld_list="/boot/modules/i915kms.ko" Yours, Michael > > -- > Andriy Gapon > ___ > 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" ___ 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: r338902 error buildworld on i386
Yes. Thank you. 24.09.2018 21:28, Ed Maste пишет: > On 24 September 2018 at 06:43, Alex V. Petrov wrote: >> ===> lib/libc (cleandir) >> make[4]: "/usr/src/lib/libc/Makefile" line 26: i386 libc requires linker >> ifunc support >> *** Error code 1 > > Please try r338903. > -- - Alex. ___ 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: netipsec/key.c ALPHA3 uma_zalloc->witness_warn, exclusive sleep mutex xforms_list (IPsec transforms list)
Am 24.09.2018 um 14:50 schrieb Andrey V. Elsukov: On 24.09.2018 11:31, Harry Schmalzbauer wrote: Hello, unfortunately this is far beyond my scope and I forgot to report in time. If this is begnin, feel free to ignore, but in any case I'd appreciate any comments. Hi, I posted a review targeted to fix this problem: https://reviews.freebsd.org/D17302 Thank you very much for your quick solution. I won't be able to test before next weekend, sorry, but will report afterwards. Thanks, -harry ___ 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: IPv6 for local_unbound?
On 23 Sep 2018, at 22:10, David P. Discher wrote:
I say yes, especially if we wish to support a IPv6 only system at some
point in the future … which seemed to be a “think” of the few
major IPv6 advocates in the industry.
I guess best practice, this should suck in rc.* config files, and use
v6 if v6 is set via one of the ipv6_* variables.
It should probably check if
kern.features.inet6: 1
kern.features.inet: 1
are set and only add v6 and v4 in these cases; you could go further and
check how ipv6_prefer is set in case both are there and make the order
dependent on that ..
All will be just more magic to automystriously break things some way ..
The reason I don’t like these kind of scripts a lot is that we have a
handful of places all thinking they should manage resolv.conf manually
in their own way rather than using one thing.
On Sep 23, 2018, at 2:19 PM, Sean Bruno wrote:
Does it make sense to add an IPv6 localhost (::1) to our setup
scripts
for local_unbound? unbound is definitely listening on ::1 as well at
127.0.0.1 so things like "host -6" will work if we add it like this
perhaps?
--- /usr/sbin/local-unbound-setup 2018-09-20 21:47:41.0 -0600
+++ /tmp/local-unbound-setup2018-09-23 13:27:01.841365000 -0600
@@ -152,6 +152,7 @@
done
if [ "${localhost}" = "no" ] ; then
echo "nameserver 127.0.0.1"
+ echo "nameserver ::1"
fi
if [ "${edns0}" = "no" ] ; then
echo "options edns0"
___
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"
___
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: Good motherboard for Ryzen (first-gen)
On 9/21/2018 10:53 PM, Eric van Gyzen wrote: > I would like to build a Ryzen desktop. Can anyone recommend a good > motherboard? I like the ASUS X370-PRO (currently BIOS 04/19/2018). igb0 for the onboard nic igb0@pci0:7:0:0:class=0x02 card=0x85f01043 chip=0x15398086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'I211 Gigabit Network Connection' and its been VERY stable since the various microcode updates and OS updates went in. (0x8001137) CPU: AMD Ryzen 5 1600X Six-Core Processor(3593.34-MHz K8-class CPU) Origin="AuthenticAMD" Id=0x800f11 Family=0x17 Model=0x1 Stepping=1 Features=0x178bfbff Features2=0x7ed8320b AMD Features=0x2e500800 AMD Features2=0x35c233ff Structured Extended Features=0x209c01a9 XSAVE Features=0xf AMD Extended Feature Extensions ID EBX=0x1007 SVM: NP,NRIP,VClean,AFlush,DAssist,NAsids=32768 TSC: P-state invariant, performance statistics real memory = 34359738368 (32768 MB) avail memory = 33226657792 (31687 MB) ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 x203 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada ___ 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: Buildowrld tries to use old ld, and fails
On 23 September 2018 at 21:18, wrote: > > Howdy! > > Since a couple months ago, the world on -CURRENT cannot be built using > the normal procedure: >time env LD=ld.lld make -j6 buildworld buildkernel The normal procedure shouldn't need any LD= overrides; is there something unique in your build? Any src.conf settings? > Here's the result: >[late in buildowrld process] >--- all_subdir_stand --- >/usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: unrecognized option > '--no-rosegment' >/usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: use the --help option for > usage information >cc: error: linker command failed with exit code 1 (use -v to see > invocation) >make[5]: stopped in /usr/src/stand/i386/mbr > > Workaround is to use linker from binutils: >env LD=/usr/local/bin/ld make buildworld Just overriding LD isn't sufficient to choose a linker, because most linking is performed by the compiler driver (i.e., cc) which does not use the LD variable. ___ 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: r338902 error buildworld on i386
On 24 September 2018 at 06:43, Alex V. Petrov wrote: > ===> lib/libc (cleandir) > make[4]: "/usr/src/lib/libc/Makefile" line 26: i386 libc requires linker > ifunc support > *** Error code 1 Please try r338903. ___ 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: r338641 && /dev/cyapa0: moused does not show pointer on console
On 24/09/2018 13:21, Matthias Apitz wrote: > Re/ i915kms, I have to load it with kldload by hand. If I load it via > loader.conf, the cyapa devices (both) say 'Unable to bring the device > out of bootstrap'. That's probably because you use device hints to configure cyapa, but i2c bus numbers are different depending on whether the kms driver is loaded or not (because it also creates i2c buses). Try to remove the hints and to use chromebook_platform(4) instead. -- Andriy Gapon ___ 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: netipsec/key.c ALPHA3 uma_zalloc->witness_warn, exclusive sleep mutex xforms_list (IPsec transforms list)
On 24.09.2018 11:31, Harry Schmalzbauer wrote: > Hello, > > unfortunately this is far beyond my scope and I forgot to report in time. > If this is begnin, feel free to ignore, but in any case I'd appreciate > any comments. Hi, I posted a review targeted to fix this problem: https://reviews.freebsd.org/D17302 -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
r338902 error buildworld on i386
-- >>> stage 2.1: cleaning up the object tree -- cd /usr/src; MACHINE_ARCH=i386 MACHINE=i386 CPUTYPE= CC="cc -target i386-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/i386.i386/tmp -B/usr/obj/usr/src/i386.i386/tmp/usr/bin" CXX="c++ -target i386-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/i386.i386/tmp -B/usr/obj/usr/src/i386.i386/tmp/usr/bin" CPP="cpp -target i386-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/i386.i386/tmp -B/usr/obj/usr/src/i386.i386/tmp/usr/bin" AS="as" AR="ar" LD="ld" LLVM_LINK="" NM=nm OBJCOPY="objcopy" RANLIB=ranlib STRINGS= SIZE="size" INSTALL="sh /usr/src/tools/install.sh" PATH=/usr/obj/usr/src/i386.i386/tmp/legacy/usr/sbin:/usr/obj/usr/src/i386.i386/tmp/legacy/usr/bin:/usr/obj/usr/src/i386.i386/tmp/legacy/bin:/usr/obj/usr/src/i386.i386/tmp/usr/sbin:/usr/obj/usr/src/i386.i386/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin SYSROOT=/usr/obj/usr/src/i386.i386/tmp make -f Makefile.inc1 BWPHASE=cleanobj DESTDIR=/usr/obj/usr/src/i386.i386/tmp cleandir ===> lib (cleandir) ===> lib/csu (cleandir) ===> lib/csu/i386 (cleandir) rm -f crti.o crtn.o gcrt1.o crt1.o Scrt1.o crt1_c.o crt1_s.o gcrt1_c.o Scrt1_c.o crt1_c.s gcrt1_c.s Scrt1_c.s lib.bc lib.ll rm -f .depend .depend.* GPATH GRTAGS GSYMS GTAGS ===> lib/libc (cleandir) make[4]: "/usr/src/lib/libc/Makefile" line 26: i386 libc requires linker ifunc support *** Error code 1 Stop. make[3]: stopped in /usr/src/lib *** Error code 1 -- - Alex. ___ 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: r338641 && /dev/cyapa0: moused does not show pointer on console
El día Monday, September 24, 2018 a las 12:46:17PM +0300, Michael Gmelin escribió: > > What could be wrong? > > Do you by any chance use vt(4) in vga textmode (hw.vga.textmode=1)? > > vt doesn’t support hardware mouse cursors, so no cursor in text mode (see > https://wiki.freebsd.org/Newcons) > Thanks. When I remove hw.vga.textmode=1 the mouse pointer comes up and works. Re/ i915kms, I have to load it with kldload by hand. If I load it via loader.conf, the cyapa devices (both) say 'Unable to bring the device out of bootstrap'. matthias -- Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/ 📱 +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub ___ 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: r338641 && /dev/cyapa0: moused does not show pointer on console
> On 24. Sep 2018, at 12:42, Matthias Apitz wrote: > >> El día Monday, September 24, 2018 a las 10:31:38AM +0200, Matthias Apitz >> escribió: >> >> >> Hello, >> >> I've booted a fresh r338641 from an USB key on my Acer C720, and have >> the required modules loaded at boot (cyapa and ig4) and the values for cyapa >> in >> /boot/device.hints, as I do use them in r314251. The moused is running as >> >> /usr/sbin/moused -p /dev/cyapa0 -t ps/2 >> >> but no mouse pointer is written on the console. If I do >> >> # cat /dev/cyapa0 >> >> on TP movements, bytes can be read by cat(1). And trussing the PID of >> the moused shows too that it is reading bytes. >> >> What could be wrong? > > additional information: when I do load *after* boot > > # kldload i915kms > > the mouse pointer appears and can be moved. How do you load i915kms on boot? In loader.conf or in rc.conf? > >matthias > > -- > Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/ 📱 > +49-176-38902045 > Public GnuPG key: http://www.unixarea.de/key.pub > ___ > 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" ___ 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: r338641 && /dev/cyapa0: moused does not show pointer on console
> On 24. Sep 2018, at 11:31, Matthias Apitz wrote: > > > Hello, > > I've booted a fresh r338641 from an USB key on my Acer C720, and have > the required modules loaded at boot (cyapa and ig4) and the values for cyapa > in > /boot/device.hints, as I do use them in r314251. The moused is running as > > /usr/sbin/moused -p /dev/cyapa0 -t ps/2 > > but no mouse pointer is written on the console. If I do > > # cat /dev/cyapa0 > > on TP movements, bytes can be read by cat(1). And trussing the PID of > the moused shows too that it is reading bytes. > > What could be wrong? Do you by any chance use vt(4) in vga textmode (hw.vga.textmode=1)? vt doesn’t support hardware mouse cursors, so no cursor in text mode (see https://wiki.freebsd.org/Newcons) Best, Michael > >matthias > -- > Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/ 📱 > +49-176-38902045 > Public GnuPG key: http://www.unixarea.de/key.pub > ___ > 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" ___ 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: r338641 && /dev/cyapa0: moused does not show pointer on console
El día Monday, September 24, 2018 a las 10:31:38AM +0200, Matthias Apitz escribió: > > Hello, > > I've booted a fresh r338641 from an USB key on my Acer C720, and have > the required modules loaded at boot (cyapa and ig4) and the values for cyapa > in > /boot/device.hints, as I do use them in r314251. The moused is running as > > /usr/sbin/moused -p /dev/cyapa0 -t ps/2 > > but no mouse pointer is written on the console. If I do > > # cat /dev/cyapa0 > > on TP movements, bytes can be read by cat(1). And trussing the PID of > the moused shows too that it is reading bytes. > > What could be wrong? additional information: when I do load *after* boot # kldload i915kms the mouse pointer appears and can be moved. matthias -- Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/ 📱 +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub ___ 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"
r338641 && /dev/cyapa0: moused does not show pointer on console
Hello, I've booted a fresh r338641 from an USB key on my Acer C720, and have the required modules loaded at boot (cyapa and ig4) and the values for cyapa in /boot/device.hints, as I do use them in r314251. The moused is running as /usr/sbin/moused -p /dev/cyapa0 -t ps/2 but no mouse pointer is written on the console. If I do # cat /dev/cyapa0 on TP movements, bytes can be read by cat(1). And trussing the PID of the moused shows too that it is reading bytes. What could be wrong? matthias -- Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/ 📱 +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub ___ 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"
netipsec/key.c ALPHA3 uma_zalloc->witness_warn, exclusive sleep mutex xforms_list (IPsec transforms list)
Hello, unfortunately this is far beyond my scope and I forgot to report in time. If this is begnin, feel free to ignore, but in any case I'd appreciate any comments. uma_zalloc_arg: zone "1024" with the following non-sleepable locks held: exclusive sleep mutex xforms_list (IPsec transforms list) r = 0 (0x815385e0) locked @ /usr/local/share/deploy-tools/HEAD/src/sys/netipsec/key.c:8676 stack backtrace: #0 0x8084c1a3 at witness_debugger+0x73 #1 0x8084d118 at witness_warn+0x448 #2 0x80ad4f48 at uma_zalloc_arg+0x38 #3 0x807bd12a at malloc+0x9a #4 0x80a45953 at crypto_newsession+0x1d3 #5 0x80a354fc at esp_init+0x37c #6 0x80a2dfec at key_setsaval+0x7ec #7 0x80a2c9b2 at key_newsav+0x302 #8 0x80a27e77 at key_add+0x4c7 #9 0x80a22a4c at key_parse+0xa8c #10 0x8087e557 at sosend_generic+0x457 #11 0x8087e78d at sosend+0x6d #12 0x80885611 at kern_sendit+0x201 #13 0x80885979 at sendit+0x199 #14 0x808857cd at sys_sendto+0x4d #15 0x80b3116c at amd64_syscall+0x28c #16 0x80b0f1ed at fast_syscall_common+0x101 : 4 times repeatied with all addresses beeing identical. Thanks, -harry ___ 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"
