Re: svn error during 'make buildkernel'?
On 06.08.13 21:11, Matthew D. Fuller wrote: Sure, right _now_ devel/subversion and base svnlite get along, but what happens when ports moves to 1.9 which changes the WT format? This is just one of the quirks that subversion has, in that it's database can't be easily parsed with other tools. Perhaps a fix might be caching the last revision number in a text file so you don't need svnversion in order to extract it from the source tree? A fix/patch to subversion, that is. Daniel ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] VMware vmxnet3 ethernet driver
On 8/6/13 6:52 AM, Bryan Venteicher wrote: - Original Message - I have ~100 FreeBSD 8/9 VMs in my vSphere 5.1 environment, all using the VMware tools package from VMware. Everything has been running great for years. (we skipped vSphere 5.0). Why should I use this vmxnet driver instead of the VMware tools driver or the emulated e1000? They are out of tree and subject to rotting. I had to use the patches at [1] to even get them to compile on 9.1 and -current. I don't think VMware puts much engineering resources behind it; there was a compiler warning of a silly bug like: if (foo) ; do_something(); vmxnet3 has modern features LRO, IPv6 checksum offloading, etc that the emulated e1000 lacks. In my test setup, e1000 tops out at 30MB/sec but vmxnet3 goes to 50MB/sec. I'd like to hear other's experiences. it'd be nice if we could get vmware to just support the drivers in tree.. by which I mean, just submit patches.. why do they need to have it out of tree? [1] - http://ogris.de/vmware/ -- Joel ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [net] protecting interfaces from races between control and data ?
On Wed, Aug 7, 2013 at 5:26 AM, Mike Karels m...@karels.net wrote: I'm replying to one of the last messages of this thread, but in part going back to the beginning; then I'm following up on Andre's proposal. Luigi wrote: i am slightly unclear of what mechanisms we use to prevent races between interface being reconfigured (up/down/multicast setting, etc, all causing reinitialization of the rx and tx rings) and i) packets from the host stack being sent out; ii) interrupts from the network card being processed. I think in the old times IFF_DRV_RUNNING was used for this purpose, but now it is not enough. Acquiring the core lock in the NIC does not seem enough, either, because newer drivers, especially multiqueue ones, have per-queue rx and tx locks. Does anyone know if there is a generic mechanism, or each driver reimplements its own way ? I'm not sure I understand the question, or its motivation. What problem(s) are we trying to solve here? It seems to me that this is mostly internal to drivers, and I don't see the issue with races. In particular, the only external guarantees that I see are that control operations will affect the packet stream soon but at some undefined place. Not all of the cited operations (e.g. multicast changes) need to cause the rings to be reinitialized; if they do, that's a chip or driver flaw. Clearing the UP flag should cause packets to stop arriving soon, but presumably processing those already in memory; packets to stop being sent soon, probably including some already accepted for transmission; and new attempts to transmit receiving an error soon. And, of course, the driver should not crash or misbehave. Other than that, I don't see what external guarantees need to be met. i only want 'driver should not crash or misbehave', which is something that (I believe) many current drivers do not guarantee because of the races mentioned in the thread (control path reinitializes rings without waiting for the datapath to drain). My specific problem was achieving this safe behaviour when moving between netmap mode and regular mode; i hoped i could replicate whatever scheme was implemented by the drivers in 'normal' mode, and this is when i realized that there was no such protection in place. Jumping to (near) the end of the thread, I like most of Andre's proposal. Running with minimal locks at this layer is an admirable goal, and I agree with most of what was said. I have a few observations on the general changes, or related issues: There was mention of taskqueues. I think that with MSI-X, taskqueues should not be needed or used. More specifically, having separate ithreads and taskqueues, with ithreads deferring to taskqueues after some limit, makes sense only for MSI and legacy interrupts. With MSI-X, an interrupt thread should be able to process packets indefinitely with sufficient CPU resources, and there is no reason to context switch to a different thread periodically. A periodic yield might be reasonable, but if it is necessary, small packet performance will suffer. However, most of this is internal to the driver. i am not completely clear on what is the difference between ithreads and taskqueues. Also, Andre's proposal requires to force-kill the ithread, but i am unclear on how to do it safely (i.e. without leaving the data structures in some inconsistent state), unless ithread periodically yields the CPU when it is in a safe state. While this is internal to the driver, we should probably provide some template code to avoid that each driver implements its own way to shutdown the ithread. cheers luigi ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: make buildworld fails
06.08.2013 03:45, Robert Huff пишет:
Boris Samorodov writes:
This note from /usr/src/UPDATING may be relevant:
-
20130613:
Some people report the following error after the switch to bmake:
make: illegal option -- J
usage: make [-BPSXeiknpqrstv] [-C directory] [-D variable]
...
*** [buildworld] Error code 2
this likely due to an old instance of make in
${MAKEPATH} (${MAKEOBJDIRPREFIX}${.CURDIR}/make.${MACHINE})
which src/Makefile will use that blindly, if it exists, so if
you see the above error:
rm -rf `make -V MAKEPATH`
should resolve it.
Would that it were so. :-(
1)
huff@ make -V MAKEPATH
huff@
2) After running the above, buildworld stops at the same place:
(cd /usr/src make bmake)
echo
echo --
--
echo Building an up-to-date make(1)
Building an up-to-date make(1)
echo --
--
cd /usr/src/usr.bin/bmake; MAKEOBJDIRPREFIX=/usr/obj/usr/src/make.amd64
DESTDIR= INSTALL=sh /usr/src/tools/install.sh make -D_UPGRADING -DNOMAN
-DNO_MAN -DNOSHARED -DNO_SHARED -DNO_CPU_CFLAGS -DNO_WERROR obj
MAKEOBJDIRPREFIX=/usr/obj/usr/src/make.amd64 DESTDIR= INSTALL=sh
/usr/src/tools/install.sh make -D_UPGRADING -DNOMAN -DNO_MAN -DNOSHARED
-DNO_SHARED -DNO_CPU_CFLAGS -DNO_WERROR depend
MAKEOBJDIRPREFIX=/usr/obj/usr/src/make.amd64 DESTDIR= INSTALL=sh
/usr/src/tools/install.sh make -D_UPGRADING -DNOMAN -DNO_MAN -DNOSHARED
-DNO_SHARED -DNO_CPU_CFLAGS -DNO_WERROR all
MAKEOBJDIRPREFIX=/usr/obj/usr/src/make.amd64 DESTDIR= INSTALL=sh
/usr/src/tools/install.sh make -D_UPGRADING -DNOMAN -DNO_MAN -DNOSHARED
-DNO_SHARED -DNO_CPU_CFLAGS -DNO_WERROR install
DESTDIR=/usr/obj/usr/src/make.amd64 BINDIR= PROGNAME=bmake
if ! test -d /usr/obj/usr/src/make.amd64/usr/src/usr.bin/bmake/; then mkdir
-p /usr/obj/usr/src/make.amd64/usr/src/usr.bin/bmake; if ! test -d
/usr/obj/usr/src/make.amd64/usr/src/usr.bin/bmake/; then echo Unable to
create /usr/obj/usr/src/make.amd64/usr/src/usr.bin/bmake.; exit 1; fi;
echo /usr/obj/usr/src/make.amd64/usr/src/usr.bin/bmake created for
/usr/src/usr.bin/bmake; fi
/usr/obj/usr/src/make.amd64/usr/src/usr.bin/bmake created for
/usr/src/usr.bin/bmake
set -e; for entry in unit-tests; do if test -d
/usr/src/usr.bin/bmake/${entry}.amd64; then echo === ${entry}.amd64
(obj); edir=${entry}.amd64; cd /usr/src/usr.bin/bmake/${edir}; else echo
=== $entry (obj); edir=${entry}; cd /usr/src/usr.bin/bmake/${edir}; fi;
make obj DIRPRFX=$edir/; done
=== unit-tests (obj)
if ! test -d /usr/obj/usr/src/make.amd64/usr/src/usr.bin/bmake/unit-tests/;
then mkdir -p /usr/obj/usr/src/make.amd64/usr/src/usr.bin/bmake/unit-tests;
if ! test -d /usr/obj/usr/src/make.amd64/usr/src/usr.bin/bmake/unit-tests/;
then echo Unable to create
/usr/obj/usr/src/make.amd64/usr/src/usr.bin/bmake/unit-tests.; exit 1; fi;
echo /usr/obj/usr/src/make.amd64/usr/src/usr.bin/bmake/unit-tests created
for /usr/src/usr.bin/bmake/unit-tests; fi
/usr/obj/usr/src/make.amd64/usr/src/usr.bin/bmake/unit-tests created for
/usr/src/usr.bin/bmake/unit-tests
rm -f .depend
mkdep -f .depend -a-DNO_PWD_OVERRIDE -I/usr/src/usr.bin/bmake -DUSE_META
-DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DUSE_META -DMAKE_NATIVE
-DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\.../share/mk:/usr/share/mk\ -I.
-I/usr/src/contrib/bmake -DMAKE_NATIVE -std=gnu99
/usr/src/contrib/bmake/arch.c /usr/src/contrib/bmake/buf.c
/usr/src/contrib/bmake/compat.c /usr/src/contrib/bmake/cond.c
/usr/src/contrib/bmake/dir.c /usr/src/contrib/bmake/for.c
/usr/src/contrib/bmake/hash.c /usr/src/contrib/bmake/job.c
/usr/src/contrib/bmake/main.c /usr/src/contrib/bmake/make.c
/usr/src/contrib/bmake/make_malloc.c /usr/src/contrib/bmake/meta.c
/usr/src/contrib/bmake/parse.c /usr/src/contrib/bmake/str.c
/usr/src/contrib/bmake/strlist.c /usr/src/contrib/bmake/suff.c
/usr/src/contrib/bmake/targ.c /usr/src/contrib/bmake/trace.c
/usr/src/contrib/bmake/util.c /usr/src/contrib/bmake/var.c
/usr/src/contrib/bmake/lst.lib/lstAppend.c
/usr/src/contrib/bmake/lst.lib/lstAtEnd.c /usr/src/contrib/bmake/ls
t.lib/lst
AtFront.c /usr/src/contrib/bmake/lst.lib/lstClose.c
/usr/src/contrib/bmake/lst.lib/lstConcat.c
/usr/src/contrib/bmake/lst.lib/lstDatum.c
/usr/src/contrib/bmake/lst.lib/lstDeQueue.c
/usr/src/contrib/bmake/lst.lib/lstDestroy.c
/usr/src/contrib/bmake/lst.lib/lstDupl.c
/usr/src/contrib/bmake/lst.lib/lstEnQueue.c
/usr/src/contrib/bmake/lst.lib/lstFind.c
/usr/src/contrib/bmake/lst.lib/lstFindFrom.c
Re: make buildworld fails
On Aug 7, 2013, at 12:31, Boris Samorodov b...@passap.ru wrote: 06.08.2013 03:45, Robert Huff пишет: ... cd /usr/src; PATH=/sbin:/bin:/usr/sbin:/usr/bin `test -x /usr/obj/usr/src/make.amd64/bmake echo /usr/obj/usr/src/make.amd64/bmake || echo make` -m /usr/src/share/mk -f Makefile.inc1 TARGET=amd64 TARGET_ARCH=amd64 buildworld usage: bmake [-BeikNnqrstWwX] [-C directory] [-D variable] [-d flags] [-f makefile] [-I directory] [-J private] [-j max_jobs] [-m directory] [-T file] [-V variable] [variable=value] [target ...] *** [buildworld] Error code 2 Stop in /usr/src. OK, the note may be written not user-friendly. Well, I've had something like you get: http://lists.freebsd.org/pipermail/freebsd-current/2013-May/041976.html The culprit was /usr/obj/usr/src/make.amd64/make. Seems to be your case as well. BTW, total removing of /usr/src should help also. I assume you meant /usr/obj here? :-) -Dimitry ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: make buildworld fails
07.08.2013 15:14, Dimitry Andric пишет: On Aug 7, 2013, at 12:31, Boris Samorodov b...@passap.ru wrote: 06.08.2013 03:45, Robert Huff пишет: ... cd /usr/src; PATH=/sbin:/bin:/usr/sbin:/usr/bin `test -x /usr/obj/usr/src/make.amd64/bmake echo /usr/obj/usr/src/make.amd64/bmake || echo make` -m /usr/src/share/mk -f Makefile.inc1 TARGET=amd64 TARGET_ARCH=amd64 buildworld usage: bmake [-BeikNnqrstWwX] [-C directory] [-D variable] [-d flags] [-f makefile] [-I directory] [-J private] [-j max_jobs] [-m directory] [-T file] [-V variable] [variable=value] [target ...] *** [buildworld] Error code 2 Stop in /usr/src. OK, the note may be written not user-friendly. Well, I've had something like you get: http://lists.freebsd.org/pipermail/freebsd-current/2013-May/041976.html The culprit was /usr/obj/usr/src/make.amd64/make. Seems to be your case as well. BTW, total removing of /usr/src should help also. I assume you meant /usr/obj here? :-) :-) Aha! Sorry. Sure it's /usr/obj! Thanks for correction. -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: make buildworld fails
Boris Samorodov writes: sh /usr/src/tools/install.sh -o root -g wheel -m 555 make /usr/obj/usr/src/make.amd64/bmake cd /usr/src; PATH=/sbin:/bin:/usr/sbin:/usr/bin `test -x /usr/obj/usr/src/make.amd64/bmake echo /usr/obj/usr/src/make.amd64/bmake || echo make` -m /usr/src/share/mk -f Makefile.inc1 TARGET=amd64 TARGET_ARCH=amd64 buildworld usage: bmake [-BeikNnqrstWwX] [-C directory] [-D variable] [-d flags] [-f makefile] [-I directory] [-J private] [-j max_jobs] [-m directory] [-T file] [-V variable] [variable=value] [target ...] *** [buildworld] Error code 2 Stop in /usr/src. OK, the note may be written not user-friendly. Well, I've had something like you get: http://lists.freebsd.org/pipermail/freebsd-current/2013-May/041976.html Looks like the same thing. The culprit was /usr/obj/usr/src/make.amd64/make. Seems to be your case as well. huff@ dir /usr/obj/usr/src/make.amd64 total 2284 drwxr-xr-x 3 root wheel 512 Aug 7 07:39 . drwxr-xr-x 3 root wheel 512 Aug 7 07:39 .. -rwxr-xr-x 1 root wheel 2291577 Aug 7 07:39 bmake drwxr-xr-x 3 root wheel 512 Aug 7 07:39 usr BTW, total removing of /usr/src should help also. The 'make buildworld' is part of: #! /bin/csh cd /usr/src rm buildworld.log rm -rf /usr/obj make -v cleandir date ./buildworld.time make -v -d l buildworld ./buildworld.log tail -n 50 /usr/src/buildworld.log | sendmail huff Robert Huff ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: make buildworld fails
07.08.2013 16:14, Robert Huff пишет: Boris Samorodov writes: sh /usr/src/tools/install.sh -o root -g wheel -m 555 make /usr/obj/usr/src/make.amd64/bmake cd /usr/src; PATH=/sbin:/bin:/usr/sbin:/usr/bin `test -x /usr/obj/usr/src/make.amd64/bmake echo /usr/obj/usr/src/make.amd64/bmake || echo make` -m /usr/src/share/mk -f Makefile.inc1 TARGET=amd64 TARGET_ARCH=amd64 buildworld usage: bmake [-BeikNnqrstWwX] [-C directory] [-D variable] [-d flags] [-f makefile] [-I directory] [-J private] [-j max_jobs] [-m directory] [-T file] [-V variable] [variable=value] [target ...] *** [buildworld] Error code 2 Stop in /usr/src. OK, the note may be written not user-friendly. Well, I've had something like you get: http://lists.freebsd.org/pipermail/freebsd-current/2013-May/041976.html Looks like the same thing. Not quite -- for me that was old and stale file from some previous buildworld. The culprit was /usr/obj/usr/src/make.amd64/make. Seems to be your case as well. huff@ dir /usr/obj/usr/src/make.amd64 total 2284 drwxr-xr-x 3 root wheel 512 Aug 7 07:39 . drwxr-xr-x 3 root wheel 512 Aug 7 07:39 .. -rwxr-xr-x 1 root wheel 2291577 Aug 7 07:39 bmake drwxr-xr-x 3 root wheel 512 Aug 7 07:39 usr Hm, I do not have such directory now: - % ls -l /usr/obj/usr/src/make\* ls: /usr/obj/usr/src/make*: No such file or directory - BTW, total removing of /usr/src should help also. The 'make buildworld' is part of: #! /bin/csh cd /usr/src rm buildworld.log rm -rf /usr/obj make -v cleandir date ./buildworld.time make -v -d l buildworld ./buildworld.log tail -n 50 /usr/src/buildworld.log | sendmail huff One more thing. I do not have a file named bmake at /usr/obj, but have just make (at this host I build world for i386 as well): - % find /usr/obj -type f -name bmake % find /usr/obj -type f -name make /usr/obj/usr/src/usr.bin/bmake/make /usr/obj/i386.i386/usr/src/usr.bin/bmake/make - While at the first e-mail last log line was: sh /usr/src/tools/install.sh -o root -g wheel -m 555 make \ /usr/obj/usr/src/make.amd64/make Are there some non-default configure/environment values? -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: make buildworld fails
Boris Samorodov writes:
While at the first e-mail last log line was:
sh /usr/src/tools/install.sh -o root -g wheel -m 555 make \
/usr/obj/usr/src/make.amd64/make
Are there some non-default configure/environment values?
Not as far as I know. There is no src.conf; make.conf is appended.
Robert Huff
CFLAGS= -O -pipe -g
STRIP=
SYMVER_ENABLED= yes
X_WINDOW_SYSTEM=xorg
HAVE_MOTIF= yes
KERNCONF=JERUSALEM
# To avoid building various parts of the base system:
# (copied from /usr/share/examples/etc/make.conf
NO_BIND_ETC= true# Do not install files to /etc/namedb
NO_BLUETOOTH= true# do not build Bluetooth related stuff
NO_PROFILE= true# Avoid compiling profiled libraries
# to get automatic SASL in sendmail
SENDMAIL_CFLAGS+= -I/usr/local/include/ -DSASL=2
SENDMAIL_LDFLAGS+= -L/usr/local/lib
SENDMAIL_LDADD+=-lsasl2
#
# to make CUPS magically keep working
# See: http://www.csua.berkeley.edu/~ranga/notes/freebsd_cups.html
#
CUPS_OVERWRITE_BASE=yes
NO_LPR= true
# added per /usr/ports/UPDATING entry 20090401
OVERRIDE_LINUX_BASE_PORT=f10
OVERRIDE_LINUX_NONBASE_PORTS=f10
#
WITH_MOZILLA= libxul
WITH_GECKO= libxul
#
# added 2007/03/04 per advice of free...@troback.com
# in re science/gramps
#
WITH_BERKELEYDB=db43
WITH_BDB_VER=43
WANT_OPENLDAP_VER=24
WANT_OPENLDAP_SASL=true
#
# as required by ports/UPDATING of 20121012
#
SAMBA_ENABLE=YES
#
# PORTS: use clang unless gcc is explicitly required
#
#
# default to using clang for all port builds, with the following
# exceptions
# ports which will only build with the base system GNU compiler (4.2)
#
# the make index target also seems to need this, for some reason
.if target(index) | \
${.CURDIR:M*/devel/antlr*} | \
${.CURDIR:M*/devel/google-perftools* } | \
${.CURDIR:M*/graphics/ImageMagick* } | \
${.CURDIR:M*/graphics/opencv*} | \
${.CURDIR:M*/x11/kdelibs4*} | \
USE_GCC?=4.2
.endif
# ports which need *some* version of the GNU compiler (won't build with
# clang or have runtime issues if built with clang)
# use the highest version of gcc we have installed from ports (4.6)
.if ${.CURDIR:M*/accessibility/jovie*} | \
${.CURDIR:M*/accessibility/kdeaccessibility4*} | \
${.CURDIR:M*/audio/grip*} | \
${.CURDIR:M*/audio/mpg123*} | \
${.CURDIR:M*/audio/rosegarden*} | \
${.CURDIR:M*/databases/virtuoso*} | \
${.CURDIR:M*/deskutils/kdepimlibs4*} | \
${.CURDIR:M*/devel/apache-ant*} | \
${.CURDIR:M*/devel/icu*} | \
${.CURDIR:M*/devel/kdevelop-kde4*} | \
${.CURDIR:M*/devel/kdevplatform*} | \
${.CURDIR:M*/devel/log4j*} | \
${.CURDIR:M*/games/kdegames4*} | \
${.CURDIR:M*/graphics/tonicpoint-viewer*} | \
${.CURDIR:M*/java/* } | \
${.CURDIR:M*/lang/gcc* } | \
${.CURDIR:M*/math/fftw3*} | \
${.CURDIR:M*/multimedia/avidemux2*} | \
${.CURDIR:M*/multimedia/kdemultimedia4*} | \
${.CURDIR:M*/multimedia/vlc*} | \
${.CURDIR:M*/multimedia/xbmc*} | \
${.CURDIR:M*/net/kdenetwork4*} | \
${.CURDIR:M*/net/mpich2*} | \
${.CURDIR:M*/net/opal3*} | \
${.CURDIR:M*/net-p2p/ktorrent*} | \
${.CURDIR:M*/net-p2p/vuze*} | \
${.CURDIR:M*/sysutils/lsof*} | \
${.CURDIR:M*/textproc/docbook-xsl*} | \
${.CURDIR:M*/textproc/fop*} | \
${.CURDIR:M*/www/libxul*} | \
${.CURDIR:M*/x11/kde4-baseapps*} | \
${.CURDIR:M*/x11/kde4-workspace*} | \
${.CURDIR:M*/x11/lxpanel*} | \
USE_GCC?=4.6+
.endif
.if ${.CURDIR:M*/usr/ports/*}
.if !defined(USE_GCC)
.if !defined(CC) || ${CC} == cc
CC=clang
.endif
.if !defined(CXX) || ${CXX} == c++
CXX=clang++
.endif
.if !defined(CPP) || ${CPP} == cpp
CPP=clang-cpp
.endif
.endif
.endif
WITH_NEW_XORG=yes
WITH_BSD_SORT=
WITH_PKGNG=yes
# added by use.perl 2013-06-13 09:50:52
PERL_VERSION=5.16.3
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] VMware vmxnet3 ethernet driver
- Original Message - it'd be nice if we could get vmware to just support the drivers in tree.. by which I mean, just submit patches.. why do they need to have it out of tree? I agree. But they are all unfriendly licensed. The FF had a discussion to get them relicensed to something more suitable, but that went no where over the past year. It is unfortunate this vendor supplied, out of tree driver, issue is still around. Linux should have taught companies how foolish this is. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: svn commit: r254021 - head/contrib/wpa/src/drivers
On 07.08.2013 15:48, Jean-Sébastien Pédron wrote: On 07.08.2013 06:03, Rui Paulo wrote: -*status = ifmr.ifm_status IFM_ACTIVE; +*status = ifmr.ifm_status (IFM_ACTIVE|IFM_AVALID); The timing problem is back with this change. I guess because IFM_AVALID is set but not IFM_ACTIVE. Maybe they must be both set? (sorry, typo in mailing-list address...) -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: make buildworld fails
On Aug 7, 2013, at 15:40, Robert Huff roberth...@rcn.com wrote: Boris Samorodov writes: ... Are there some non-default configure/environment values? Not as far as I know. There is no src.conf; make.conf is appended. Robert Huff CFLAGS= -O -pipe -g Just a note: don't set CFLAGS with =, always use +=, e.g.: CFLAGS+=-O -pipe -g Also, you might want to set -g in DEBUG_FLAGS instead, not directly in CFLAGS. -Dimitry ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Port problems after r253839 on HEAD
After introducing r253839 on HEAD (/head/contrib/binutils/ld/ldmain.c), I recognized some wired behaviour in the ports system on my CURRENT boxes. Some of the ports do not build anymore. They print almost similar messages about an ld problem (invalid DSO for symbol 'xxx' definition), followed by the lib, which symbols are not found. With a recent 10.0-CURRENT (at least r253839) you can try this for example with the following two ports: (1) editors/nano cc -O2 -pipe -fno-strict-aliasing -L/usr/local/lib -o nano browser.o chars.o color.o cut.o files.o global.o help.o move.o nano.o prompt.o rcfile.o search.o text.o utils.o winio.o /usr/local/lib/libintl.so /usr/local/lib/libiconv.so -Wl,-rpath -Wl,/usr/local/lib -lncursesw /usr/bin/ld: .: invalid DSO for symbol `keypad' definition /usr/local/lib/libtinfow.so.5.9: could not read symbols: Bad value cc: error: linker command failed with exit code 1 (use -v to see invocation) (2) www/evolution-webcal cc -O2 -pipe -fno-strict-aliasing -L/usr/local/lib -o evolution-webcal evolution-webcal-main.o evolution-webcal-notify.o -lgtk-x11-2.0 -lgdk-x11-2.0 -lpangocairo-1.0 -lXext -lXrender -lXinerama -lXi -lXrandr -lXcursor -lXcomposite -lXdamage -lXfixes -lX11 -latk-1.0 -lcairo -lgdk_pixbuf-2.0 -lpangoft2-1.0 -lpango-1.0 -lfreetype -lfontconfig -lecal-1.2 -lical -licalss -licalvcal -pthread -ledataserver-1.2 -lxml2 -lgconf-2 -lsoup-2.4 -lgio-2.0 -lgobject-2.0 -L/usr/local/lib -lglib-2.0 -lintl /usr/bin/ld: R: invalid DSO for symbol `g_thread_init' definition /usr/local/lib/libgthread-2.0.so.0: could not read symbols: Bad value cc: error: linker command failed with exit code 1 (use -v to see invocation) This errors disappear when I revert /usr/bin/ld to a revision before 253839. Furthermore I observed some wired behaviour for SAGA GIS (math/saga; I am the maintainer of it). This port should build and install a SAGA GIS module as /usr/local/lib/saga/libopencv.so (for this it has graphics/opencv as a dependency). With /usr/bin/ld rev. 253839 installed, the autotools configure process from math/saga is not able to find /usr/local/lib/libopencv_legacy.so and so it does not build the module. Unfortunately it gives no clarifying hint about the problem). Reverting the version of /usr/bin/ld before r253839 solves this problem ... I hope my description is of some use and does not point in the wrong direction. Rainer Hurling ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Port problems after r253839 on HEAD
On Wed, Aug 07, 2013 at 07:28:41PM +0200, Rainer Hurling wrote: After introducing r253839 on HEAD (/head/contrib/binutils/ld/ldmain.c), I recognized some wired behaviour in the ports system on my CURRENT boxes. Some of the ports do not build anymore. They print almost similar messages about an ld problem (invalid DSO for symbol 'xxx' definition), followed by the lib, which symbols are not found. With a recent 10.0-CURRENT (at least r253839) you can try this for example with the following two ports: normally I had tracked down all those ports, except if you are building them with nom default options, What that means is basically the said ports are missing some -lbla in ldflags, The missing ones are those listed in the line following the DSO bla in nano for example the first failure means -liconv is missing. I afk until 24th so I can't commit any fix to the said ports. There were properly building in my exp-run for the said change, meaning either you build with non default options im that case the port requires a fix or perhaps your ports tree is not uptodate, in particular lots of those failures are fixed by the recent glib update. regards, Bapt pgp9MTr65Vx4X.pgp Description: PGP signature
Re: MPSAFE VFS -- List of upcoming actions
Bezüglich Attilio Rao's Nachricht vom 14.10.2012 02:27 (localtime): On Fri, Sep 21, 2012 at 1:22 AM, Attilio Rao atti...@freebsd.org wrote: On Wed, Sep 19, 2012 at 3:48 AM, Attilio Rao atti...@freebsd.org wrote: On Fri, Jul 13, 2012 at 12:18 AM, Attilio Rao atti...@freebsd.org wrote: 2012/7/4 Attilio Rao atti...@freebsd.org: 2012/6/29 Attilio Rao atti...@freebsd.org: As already published several times, according to the following plan: http://wiki.freebsd.org/NONMPSAFE_DEORBIT_VFS I still haven't heard from Vivien or Edward, anyway as NTFS is basically only used RO these days (also the mount_ntfs code just permits RO mounting) I stripped all the uncomplete/bogus write support with the following patch: http://www.freebsd.org/~attilio/ntfs_remove_write.patch This is an attempt to make the code smaller and possibly just focus on ... I've committed the FUSE support into base as r241519. Thank you for your great work! I had used http://www.freebsd.org/~attilio/fuse_import/fuse_stable9_241030.patch with releng/9.1. Some improovements were made in the meantime in head. I'm not familiar with svn. Was it possible to generate a new patchset against releng/9.2? I'd have to concat manually downloadad revisions via svnweb... :-( Thanks a lot, -Harry signature.asc Description: OpenPGP digital signature
Re: Port problems after r253839 on HEAD
Thanks, Bapt, for answering.
Am 07.08.2013 19:43, schrieb Baptiste Daroussin:
On Wed, Aug 07, 2013 at 07:28:41PM +0200, Rainer Hurling wrote:
After introducing r253839 on HEAD (/head/contrib/binutils/ld/ldmain.c),
I recognized some wired behaviour in the ports system on my CURRENT boxes.
Some of the ports do not build anymore. They print almost similar
messages about an ld problem (invalid DSO for symbol 'xxx' definition),
followed by the lib, which symbols are not found.
With a recent 10.0-CURRENT (at least r253839) you can try this for
example with the following two ports:
normally I had tracked down all those ports, except if you are building them
with nom default options,
#cd /usr/ports/www/evolution-webcal
#make config
=== No options to configure
#cd /usr/ports/editors/nano
#make config
=== No options to configure
What that means is basically the said ports are missing some -lbla in ldflags,
The missing ones are those listed in the line following the DSO bla
in nano for example the first failure means -liconv is missing.
Yupp, thanks, the following two patches seem to work:
--- Makefile.orig 2013-07-17 16:59:50.0 +0200
+++ Makefile2013-08-07 20:42:11.0 +0200
@@ -15,11 +15,13 @@
CONFLICTS= nano-devel-2*
+LIB_DEPENDS= tinfow:${PORTSDIR}/devel/ncurses
+
GNU_CONFIGURE= yes
CONFIGURE_ARGS=--docdir=${DOCSDIR}
CPPFLAGS+= -I${LOCALBASE}/include
-LDFLAGS+= -L${LOCALBASE}/lib
+LDFLAGS+= -L${LOCALBASE}/lib -ltinfow
.include bsd.port.options.mk
--- Makefile.orig 2013-06-20 17:40:13.0 +0200
+++ Makefile2013-08-07 20:47:21.0 +0200
@@ -23,7 +23,7 @@
USE_GNOME= gnomeprefix gnomehack intlhack evolutiondataserver libgnomeui
GNU_CONFIGURE= yes
CPPFLAGS+= -I${LOCALBASE}/include
-LDFLAGS+= -L${LOCALBASE}/lib
+LDFLAGS+= -L${LOCALBASE}/lib -lgthread-2.0
GCONF_SCHEMAS= evolution-webcal.schemas
I afk until 24th so I can't commit any fix to the said ports.
There were properly building in my exp-run for the said change, meaning either
you build with non default options im that case the port requires a fix or
perhaps your ports tree is not uptodate, in particular lots of those failures
are fixed by the recent glib update.
Hmm. As far as I can say my ports tree is uptodate and I did the
complete glib update (/usr/ports/UPDATING entry 20130731). So I have no
clue, why editors/nano does complain about devel/ncurses.
In particular I am wondering about the misbehaviour of my port
math/saga. As I wrote before, the autotools process does not find
libopencv.so, only and only if HEAD is using /usr/bin/ld r253839.
Probably there is a hidden problem, not seen before without the ld
patch? Any hint would be very appreciated.
Many thanks for your fast help and greetings from Göttingen in Germany,
Rainer
regards,
Bapt
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [net] protecting interfaces from races between control and data ?
On 07.08.2013 09:18, Luigi Rizzo wrote: On Wed, Aug 7, 2013 at 5:26 AM, Mike Karels m...@karels.net mailto:m...@karels.net wrote: Jumping to (near) the end of the thread, I like most of Andre's proposal. Running with minimal locks at this layer is an admirable goal, and I agree with most of what was said. I have a few observations on the general changes, or related issues: There was mention of taskqueues. I think that with MSI-X, taskqueues should not be needed or used. More specifically, having separate ithreads and taskqueues, with ithreads deferring to taskqueues after some limit, makes sense only for MSI and legacy interrupts. With MSI-X, an interrupt thread should be able to process packets indefinitely with sufficient CPU resources, and there is no reason to context switch to a different thread periodically. A periodic yield might be reasonable, but if it is necessary, small packet performance will suffer. However, most of this is internal to the driver. i am not completely clear on what is the difference between ithreads and taskqueues. The difference between ithreads and taskqueues is actually very small and mostly in name and how they're set up and kicked off when work is to be done. Both are real kernel threads. Most of the confusion, also in Mikes response, seems to come from the name ithreads for interrupt-threads. However an ithread is not running in interrupt context, only the interrupt handler (called filter) does. Scheduling a taskqueue from an ithread is a bit round-about but commonly done. The bus_setup_intr(9) man page isn't helping to clear up the confusion. The idea is that a (legacy) interrupt is handled in two stages: 1) a small function reading the hardware interrupt status register to determine if this hardware actually raised an interrupt, and acknowledge it (to prevent additional interrupts from firing while this one is handled). If it wasn't this card, it hands off to the handler if this interrupt line is shared; 2) the actual function/thread handling the data that was indicated by the interrupt. Only step 1 runs in interrupt context and thus must be very small and avoid any form of blocking. Step 2 is a normal kernel thread set up as an ithread running at an elevated priority compared to user-space processes/threads. MSI and MSI-X always are exclusive and non-shared interrupts. Thus a handler running in interrupt context isn't necessary for non-legacy interrupt sources. The ithread can be scheduled right away to do its work. Also, Andre's proposal requires to force-kill the ithread, but i am unclear on how to do it safely (i.e. without leaving the data structures in some inconsistent state), unless ithread periodically yields the CPU when it is in a safe state. While this is internal to the driver, we should probably provide some template code to avoid that each driver implements its own way to shutdown the ithread. Yes, when done a well-tested, stable and performant template will be provided. -- Andre ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: MPSAFE VFS -- List of upcoming actions
On Wed, Aug 7, 2013 at 11:04 AM, Harald Schmalzbauer h.schmalzba...@omnilan.de wrote: Bezüglich Attilio Rao's Nachricht vom 14.10.2012 02:27 (localtime): On Fri, Sep 21, 2012 at 1:22 AM, Attilio Rao atti...@freebsd.org wrote: On Wed, Sep 19, 2012 at 3:48 AM, Attilio Rao atti...@freebsd.org wrote: On Fri, Jul 13, 2012 at 12:18 AM, Attilio Rao atti...@freebsd.org wrote: 2012/7/4 Attilio Rao atti...@freebsd.org: 2012/6/29 Attilio Rao atti...@freebsd.org: As already published several times, according to the following plan: http://wiki.freebsd.org/NONMPSAFE_DEORBIT_VFS I still haven't heard from Vivien or Edward, anyway as NTFS is basically only used RO these days (also the mount_ntfs code just permits RO mounting) I stripped all the uncomplete/bogus write support with the following patch: http://www.freebsd.org/~attilio/ntfs_remove_write.patch This is an attempt to make the code smaller and possibly just focus on ... I've committed the FUSE support into base as r241519. Thank you for your great work! I had used http://www.freebsd.org/~attilio/fuse_import/fuse_stable9_241030.patch with releng/9.1. Some improovements were made in the meantime in head. I'm not familiar with svn. Was it possible to generate a new patchset against releng/9.2? I'd have to concat manually downloadad revisions via svnweb... :-( Thanks a lot, -Harry Already done. All of the changes in head have been back-ported to 9.2-PRERELEASE with the exception of a locking enhancement not available outside of current. You can find it at: https://docs.google.com/file/d/0B9QNUQlebx5UdlhPUTB4TXF6enc/edit?usp=sharing The changes were minor, mostly updating line numbers. There was a major update to the new fuse release, but it was rolled back because it would not work with fusefs-libs. Both will need to be updated at the same time. I don't know what the state of any effort to do this might be or how difficult it will be. -- R. Kevin Oberman, Network Engineer E-mail: rkober...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [net] protecting interfaces from races between control and data ?
On Aug 6, 2013, at 9:43 AM, Andre Oppermann wrote: The driver supplies a TX frame transmit function (mostly like if_transmit today) which does all locking and multi-queue handling internally (driver owned. This gives driver writers the freedom to better adjust to different hardware communication methods as they become available, like we witnessed a couple of times in the past. How would you handle TX dequeue? I'm curious because I got a nice speedup with cpsw by not using the TX interrupt at all: I just dequeued completed packets at the end of the TX transmit function. I suppose this would still work with your scheme. Tim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [net] protecting interfaces from races between control and data ?
On Aug 6, 2013, at 9:43 AM, Andre Oppermann wrote: The driver supplies a TX frame transmit function (mostly like if_transmit today) which does all locking and multi-queue handling internally (driver owned. This gives driver writers the freedom to better adjust to different hardware communication methods as they become available, like we witnessed a couple of times in the past. How would you handle TX dequeue? I'm curious because I got a nice speedup with cpsw by not using the TX interrupt at all: I just dequeued completed packets at the end of the TX transmit function. I suppose this would still work with your scheme. Tim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [net] protecting interfaces from races between control and data ?
On Aug 5, 2013, at 11:20 AM, Adrian Chadd wrote: .. and I bet it's not a design pattern, and this is total conjecture on my part: * the original drivers weren't SMP safe; * noone really sat down and figured out how to correctly synchronise all of this stuff; * people did the minimum amount of work to keep the driver from immediately crashing, but didn't really think things through at a larger scale. Almost every driver is this way Luigi. :-) Most of the drivers in the three don't support hardware that performs well enough for this to be a problem. :) Any driver that's still around from the pre-locking days can easily saturate the lines (or the hardware) on today's (and even yesterday's hardware). All the rest have come up with different ways to cope... Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
