Re: buildworld fails on FreeBSD 7.x for HEAD from 19.04.2012
Not even a full crossbuild? adrian ___ 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: Some performance measurements on the FreeBSD network stack
Hi, This honestly sounds like it's begging for an instrumentation/analysis/optimisation project. What do we need to do? Adrian ___ 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: clang and 'config KERNFILE' error
On 2012-04-20 02:40, Steve Kargl wrote:
laptop:root[227] uname -a
FreeBSD laptop 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r230975M: Sat Feb 4
09:03:27 PST 2012 root@laptop:/usr/obj/usr/src/sys/MOBILE i386
laptop:root[224] config MOBILE
Kernel build directory is ../compile/MOBILE
Don't forget to do ``make cleandepend&& make depend''
laptop:root[225] cd ../compile/MOBILE
laptop:root[226] make cleandepend&& make depend
"../../../conf/kern.pre.mk", line 87: Malformed conditional (${MK_CLANG_IS_CC} == "no"&&
${CC:T:Mclang} != "clang")
"../../../conf/kern.pre.mk", line 98: if-less endif
"../../../conf/kern.pre.mk", line 104: Malformed conditional (${MK_CLANG_IS_CC} != "no"
|| ${CC:T:Mclang} == "clang")
"../../../conf/kern.pre.mk", line 106: if-less endif
"../../../conf/kern.mk", line 18: Malformed conditional (${MK_CLANG_IS_CC} != "no" ||
${CC:T:Mclang} == "clang")
"../../../conf/kern.mk", line 31: if-less endif
"../../../conf/kern.mk", line 53: Malformed conditional (${MK_CLANG_IS_CC} == "no"&&
${CC:T:Mclang} != "clang")
"../../../conf/kern.mk", line 60: if-less endif
make: fatal errors encountered -- cannot continue
Hi Steve,
This means your /usr/share/mk files are out of sync with your source
tree. When you build kernels in the old way, this will not work
properly. I guess the simplest solution is to set MAKESYSPATH to
/usr/src/share/mk, or just use "make buildkernel KERNCONF=MOBILE".
___
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: contrib/jemalloc
On 04/21/12 02:23, Doug Barton wrote: ... In libedit we have incomplete merges from upstream (that was CVS fault), we have some changes that are obsolete wrt to how upstream solved the same issues and we have a couple of files that have diverged completely from upstream. I agree that sounds like an ugly mess ... who is working on cleaning it up? Is this something that we need to create a team to address? It certainly sounds like something too large for one person to handle on their own. I have a patch (pending approval) to improve things here: http://people.freebsd.org/~pfg/patches/patch-libedit-cvs20091228 and I will try to reduce some other differences with upstream code but I think at some point we will just have to do a brute merge from the code upstream. Either way it all can all be solved but it's just a lot of work and I can see how the direct approach helps understand better what is happening and can ultimately save time. I'm glad we have an area of agreement. It sounds to me like the lesson from libedit is to do it right from the very beginning, so that things like libedit don't happen again. The libedit case shows a case where the vendor branch approach failed. To be quite honest, it all depends on the maintainer and not really on the mechanics: if no one cares to keep up with the small changes during a while, eventually someone has to take care of a bigger set of changes in the future. In jemalloc's case I am really glad to see the code updated and maintained now. Pedro. ___ 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: : jemalloc_arena.c:182: Failed assertion: "p[i] == 0"
On Apr 21, 2012, at 11:54 AM, David Wolfskill wrote:
> After applying Dimitry Andric's patches to contrib/jemalloc and replacing
> /usr/bin/as with one built last Sunday, I was finally(!) able to rebuild
> head as of 234536:
>
> FreeBSD freebeast.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #797
> 234536M: Sat Apr 21 10:23:33 PDT 2012
> r...@freebeast.catwhisker.org:/usr/obj/usr/src/sys/GENERIC i386
>
> However, as I was copying a /usr/obj hierarchy via tar -- e.g.:
>
> root@freebeast:/common/home/david # (cd /var/tmp && rm -fr obj && mkdir obj)
> && (cd /usr && tar cpf - obj) | (cd /var/tmp && tar xpf -)
>
> it ran for a while, then:
>
> : jemalloc_arena.c:182: Failed assertion: "p[i] == 0"
> Abort (core dumped)
> root@freebeast:/common/home/david # echo $?
> 134
> root@freebeast:/common/home/david # ls -lTio *.core
> ls: No match.
> root@freebeast:/common/home/david #
>
> So ... no core file, apparently.
>
> freebeast(10.0-C)[2] find /usr/src/contrib/jemalloc -type f -name
> jemalloc_arena.c
> freebeast(10.0-C)[3]
>
> No file named "jemalloc_arena.c", either.
>
> But contrib/jemalloc/src/arena.c contains a function,
> arena_chunk_validate_zeroed():
>
>175 static inline void
>176 arena_chunk_validate_zeroed(arena_chunk_t *chunk, size_t run_ind)
>177 {
>178 size_t i;
>179 UNUSED size_t *p = (size_t *)((uintptr_t)chunk + (run_ind <<
> LG_PAGE));
>180
>181 for (i = 0; i < PAGE / sizeof(size_t); i++)
>182 assert(p[i] == 0);
>183 }
>
> Thoughts?
I received a similar report yesterday in the context of filezilla, but didn't
get as far as reproducing it. I think the problem is in chunk_alloc_dss(),
which dangerously claims that newly allocated memory is zeroed. It looks like
I formalized this bad assumption in early 2010, though the bug existed before
that. It's a bigger deal now because sbrk() is preferred over mmap(), so the
bug has languished for a couple of years. I'll get a fix committed today (and
revert the order of preference between sbrk() and mmap()).
By the way, I wonder why not everyone hits this (I don't).
Thanks,
Jason___
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"
: jemalloc_arena.c:182: Failed assertion: "p[i] == 0"
After applying Dimitry Andric's patches to contrib/jemalloc and replacing
/usr/bin/as with one built last Sunday, I was finally(!) able to rebuild
head as of 234536:
FreeBSD freebeast.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #797
234536M: Sat Apr 21 10:23:33 PDT 2012
r...@freebeast.catwhisker.org:/usr/obj/usr/src/sys/GENERIC i386
However, as I was copying a /usr/obj hierarchy via tar -- e.g.:
root@freebeast:/common/home/david # (cd /var/tmp && rm -fr obj && mkdir obj) &&
(cd /usr && tar cpf - obj) | (cd /var/tmp && tar xpf -)
it ran for a while, then:
: jemalloc_arena.c:182: Failed assertion: "p[i] == 0"
Abort (core dumped)
root@freebeast:/common/home/david # echo $?
134
root@freebeast:/common/home/david # ls -lTio *.core
ls: No match.
root@freebeast:/common/home/david #
So ... no core file, apparently.
freebeast(10.0-C)[2] find /usr/src/contrib/jemalloc -type f -name
jemalloc_arena.c
freebeast(10.0-C)[3]
No file named "jemalloc_arena.c", either.
But contrib/jemalloc/src/arena.c contains a function,
arena_chunk_validate_zeroed():
175 static inline void
176 arena_chunk_validate_zeroed(arena_chunk_t *chunk, size_t run_ind)
177 {
178 size_t i;
179 UNUSED size_t *p = (size_t *)((uintptr_t)chunk + (run_ind <<
LG_PAGE));
180
181 for (i = 0; i < PAGE / sizeof(size_t); i++)
182 assert(p[i] == 0);
183 }
Thoughts?
Peace,
david
--
David H. Wolfskill da...@catwhisker.org
Depriving a girl or boy of an opportunity for education is evil.
See http://www.catwhisker.org/~david/publickey.gpg for my public key.
pgppo3cjNVAuv.pgp
Description: PGP signature
Re: /usr/bin/as: out of memory allocating 4194304 bytes after a total of 524288000 bytes
On 2012-04-21 19:52, Cy Schubert wrote: In message<4f92f020.1000...@protected-networks.net>, Michael Butler writes: ... The problem is that /usr/bin/as is statically linked .. rebuild that and you'll be fine, I did. I restored from backup made a month ago and rebuilt world again. That worked. I then rebuilt world again. That's when it failed. At which revision was your source tree? In r234543, Jason committed the real fix, and I think that should work correctly. ___ 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"
[head tinderbox] failure on powerpc64/powerpc
TB --- 2012-04-21 17:36:18 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-04-21 17:36:18 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-04-21 17:36:18 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2012-04-21 17:36:18 - cleaning the object tree TB --- 2012-04-21 17:36:18 - cvsupping the source tree TB --- 2012-04-21 17:36:18 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2012-04-21 17:38:03 - building world TB --- 2012-04-21 17:38:03 - CROSS_BUILD_TESTING=YES TB --- 2012-04-21 17:38:03 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-21 17:38:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-21 17:38:03 - SRCCONF=/dev/null TB --- 2012-04-21 17:38:03 - TARGET=powerpc TB --- 2012-04-21 17:38:03 - TARGET_ARCH=powerpc64 TB --- 2012-04-21 17:38:03 - TZ=UTC TB --- 2012-04-21 17:38:03 - __MAKE_CONF=/dev/null TB --- 2012-04-21 17:38:03 - cd /src TB --- 2012-04-21 17:38:03 - /usr/bin/make -B buildworld >>> World build started on Sat Apr 21 17:38:04 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] from /src/gnu/lib/libgcc/../../../contrib/gcc/config/fp-bit.c:44: /src/gnu/lib/libgcc/../../../contrib/gcc/config/rs6000/sysv4.h:285:1: warning: "PTRDIFF_TYPE" redefined In file included from ./tm.h:12, from /src/gnu/lib/libgcc/../../../contrib/gcc/config/fp-bit.c:44: /src/gnu/lib/libgcc/../../../contrib/gcc/config/freebsd.h:77:1: warning: this is the location of the previous definition ( -pg tramp.So unwind-dw2.So unwind-dw2-fde-glibc.So unwind-sjlj.So gthr-gnat.So unwind-c.So _muldi3.So _negdi2.So _lshrdi3.So _ashldi3.So _ashrdi3.So _cmpdi2.So _ucmpdi2.So _clear_cache.So _enable_execute_stack.So _trampoline.So __main.So _absvsi2.So _absvdi2.So _addvsi3.So _addvdi3.So _subvsi3.So _subvdi3.So _mulvsi3.So _mulvdi3.So _negvsi2.So _negvdi2.So _ctors.So _ffssi2.So _ffsdi2.So _clz.So _clzsi2.So _clzdi2.So _ctzsi2.So _ctzdi2.So _popcount_tab.So _popcountsi2.So _popcountdi2.So _paritysi2.So _paritydi2.So _powisf2.So _powidf2.So _powixf2.So _powitf2.So _mulsc3.So _muldc3.So _mulxc3.So _multc3.So _divsc3.So _divdc3.So _divxc3.So _divtc3.So _fixunssfsi.So _fixunsdfsi.So _fixunsxfsi.So _fixsfdi.So _fixunssfdi.So _floatdisf.So _floatundisf.So _fixdfdi.So _fixunsdfdi.So _floatdidf.So _floatundidf.So _fixxfdi.So _fixunsxfdi.So _floatdixf.So _floatundixf.So _fixtfdi.So _fixunstfdi.So _floatditf.So _floatunditf.So _divdi3.So _moddi3.So _udivdi3.So _umoddi3.So _udiv_w_sdi! v.So _udivmoddi4.So _pack_sf.So _unpack_sf.So _addsub_sf.So _mul_sf.So _div_sf.So _fpcmp_parts_sf.So _compare_sf.So _eq_sf.So _ne_sf.So _gt_sf.So _ge_sf.So _lt_sf.So _le_sf.So _unord_sf.So _si_to_sf.So _sf_to_si.So _negate_sf.So _make_sf.So _sf_to_df.So _thenan_sf.So _sf_to_usi.So _usi_to_sf.So _pack_df.So _unpack_df.So _addsub_df.So _mul_df.So _div_df.So _fpcmp_parts_df.So _compare_df.So _eq_df.So _ne_df.So _gt_df.So _ge_df.So _lt_df.So _le_df.So _unord_df.So _si_to_df.So _df_to_si.So _negate_df.So _make_df.So _df_to_sf.So _thenan_df.So _df_to_usi.So _usi_to_df.So tramp.So;echo %% ; cat /src/gnu/lib/libgcc/../../../contrib/gcc/libgcc-std.ver | sed -e '/^[ ]*#/d' -e 's/^%\(if\|else\|elif\|endif\|define\)/#\1/' | cc -O2 -pipe -DIN_GCC -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -DHAVE_GTHR_DEFAULT -I/src/gnu/lib/libgcc/../../../contrib/gcclibs/include -I/src/gnu/lib/libgcc/../../../contrib/gcc/config -I/src/gnu/lib/libgcc/../../../contrib/gcc -I. -I/src/gnu/lib/libgcc/.! ./../usr.bin/cc/cc_tools -std=gnu99 -E -xassembler-with-cpp -! ; ) | awk -f /src/gnu/lib/libgcc/../../../contrib/gcc/mkmap-symver.awk > libgcc.map -pg: not found No symbols seen -- broken or mis-installed nm? *** Error code 1 Stop in /src/gnu/lib/libgcc. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-04-21 17:55:19 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-04-21 17:55:19 - ERROR: failed to build world TB --- 2012-04-21 17:55:19 - 784.57 user 124.75 system 1141.36 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full ___ 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: /usr/bin/as: out of memory allocating 4194304 bytes after a total of 524288000 bytes
In message <4f92f020.1000...@protected-networks.net>, Michael Butler writes: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 04/21/12 13:21, Cy Schubert wrote: > > In message <4f91c8fe.4070...@freebsd.org>, Dimitry Andric writes: > >> This is a multi-part message in MIME format. > >> --030506060901050002030508 > >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed > >> Content-Transfer-Encoding: 7bit > >> > >> On 2012-04-20 22:21, Jason Evans wrote: > >>> On Apr 20, 2012, at 1:14 PM, Jason Evans wrote: > On Apr 20, 2012, at 1:10 PM, Dimitry Andric wrote: > > On 2012-04-20 21:54, Jason Evans wrote: > >> On Apr 20, 2012, at 12:49 PM, Dimitry Andric wrote: > >>> I think the best solution would be for jemalloc to avoid using obviou > s > >>> names like "chunksize" for its globals, because it is basically a > >>> library that could be linked to any sort of program out there. > >>> > >>> For example, it could prefix all its internal-use only globals with > >>> "jemalloc_" or some other mangling scheme. Jason, any thoughts? > >> > >> jemalloc has optional namespace mangling support built in for just thi > s > >> reason. I'll turn it on, hopefully today. > > > > Indeed, I had just found jemalloc/internal/private_namespace.h. :) It > > does seem to list only functions, not variables, is that right? > > Ah right, functions only. Well then, I don't have any bright ideas for > so > >> lving this problem in the short run. > >>> > >>> I take it back. There's spotty mangling coverage for variables. I'll tr > y > >> to add full coverage. > >> > >> I'm now using the attached. It seems to work... > > > > It didn't work for me. > > The problem is that /usr/bin/as is statically linked .. rebuild that and > you'll be fine, I did. I restored from backup made a month ago and rebuilt world again. That worked. I then rebuilt world again. That's when it failed. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.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"
[head tinderbox] failure on sparc64/sparc64
TB --- 2012-04-21 17:36:42 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-04-21 17:36:42 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-04-21 17:36:42 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2012-04-21 17:36:42 - cleaning the object tree TB --- 2012-04-21 17:36:42 - cvsupping the source tree TB --- 2012-04-21 17:36:42 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2012-04-21 17:38:20 - building world TB --- 2012-04-21 17:38:20 - CROSS_BUILD_TESTING=YES TB --- 2012-04-21 17:38:20 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-21 17:38:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-21 17:38:20 - SRCCONF=/dev/null TB --- 2012-04-21 17:38:20 - TARGET=sparc64 TB --- 2012-04-21 17:38:20 - TARGET_ARCH=sparc64 TB --- 2012-04-21 17:38:20 - TZ=UTC TB --- 2012-04-21 17:38:20 - __MAKE_CONF=/dev/null TB --- 2012-04-21 17:38:20 - cd /src TB --- 2012-04-21 17:38:20 - /usr/bin/make -B buildworld >>> World build started on Sat Apr 21 17:38:20 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -c -O2 -pipe -DIN_GCC -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -DHAVE_GTHR_DEFAULT -I/src/gnu/lib/libgcc/../../../contrib/gcclibs/include -I/src/gnu/lib/libgcc/../../../contrib/gcc/config -I/src/gnu/lib/libgcc/../../../contrib/gcc -I. -I/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools -std=gnu99 -fPIC -DSHARED -DFINE_GRAINED_LIBRARIES -DL_df_to_usi -o _df_to_usi.So /src/gnu/lib/libgcc/../../../contrib/gcc/config/fp-bit.c cc -c -O2 -pipe -DIN_GCC -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -DHAVE_GTHR_DEFAULT -I/src/gnu/lib/libgcc/../../../contrib/gcclibs/include -I/src/gnu/lib/libgcc/../../../contrib/gcc/config -I/src/gnu/lib/libgcc/../../../contrib/gcc -I. -I/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools -std=gnu99 -fPIC -DSHARED -DFINE_GRAINED_LIBRARIES -DL_usi_to_df -o _usi_to_df.So /src/gnu/lib/libgcc/../../../contrib/gcc/config/fp-bit.c cc -x assembler-with-cpp -c -fPIC -O2 -pipe -DIN_GCC -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -DHAVE_GTHR_DEFAULT -I/src/gnu/lib/libgcc/../../../contrib/gcclibs/include -I/src/gnu/lib/libgcc/../../../contrib/gcc/config -I/src/gnu/lib/libgcc/../../../contrib/gcc -I. -I/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools -std=gnu99 -DL_mulsi3 -o _mulsi3.So /src/gnu/lib/libgcc/../../../contrib/gcc/config/sparc/lb1spc.asm cc -x assembler-with-cpp -c -fPIC -O2 -pipe -DIN_GCC -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -DHAVE_GTHR_DEFAULT -I/src/gnu/lib/libgcc/../../../contrib/gcclibs/include -I/src/gnu/lib/libgcc/../../../contrib/gcc/config -I/src/gnu/lib/libgcc/../../../contrib/gcc -I. -I/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools -std=gnu99 -DL_divsi3 -o _divsi3.So /src/gnu/lib/libgcc/../../../contrib/gcc/config/sparc/lb1spc.asm cc -x assembler-with-cpp -c -fPIC -O2 -pipe -DIN_GCC -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -DHAVE_GTHR_DEFAULT -I/src/gnu/lib/libgcc/../../../contrib/gcclibs/include -I/src/gnu/lib/libgcc/../../../contrib/gcc/config -I/src/gnu/lib/libgcc/../../../contrib/gcc -I. -I/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools -std=gnu99 -DL_modsi3 -o _modsi3.So /src/gnu/lib/libgcc/../../../contrib/gcc/config/sparc/lb1spc.asm ( -pg unwind-dw2.So unwind-dw2-fde-glibc.So unwind-sjlj.So gthr-gnat.So unwind-c.So _muldi3.So _negdi2.So _lshrdi3.So _ashldi3.So _ashrdi3.So _cmpdi2.So _ucmpdi2.So _clear_cache.So _enable_execute_stack.So _trampoline.So __main.So _absvsi2.So _absvdi2.So _addvsi3.So _addvdi3.So _subvsi3.So _subvdi3.So _mulvsi3.So _mulvdi3.So _negvsi2.So _negvdi2.So _ctors.So _ffssi2.So _ffsdi2.So _clz.So _clzsi2.So _clzdi2.So _ctzsi2.So _ctzdi2.So _popcount_tab.So _popcountsi2.So _popcountdi2.So _paritysi2.So _paritydi2.So _powisf2.So _powidf2.So _powixf2.So _powitf2.So _mulsc3.So _muldc3.So _mulxc3.So _multc3.So _divsc3.So _divdc3.So _divxc3.So _divtc3.So _fixunssfsi.So _fixunsdfsi.So _fixunsxfsi.So _fixsfdi.So _fixunssfdi.So _floatdisf.So _floatundisf.So _fixdfdi.So _fixunsdfdi.So _floatdidf.So _floatundidf.So _fixxfdi.So _fixunsxfdi.So _floatdixf.So _floatundixf.So _fixtfdi.So _fixunstfdi.So _floatditf.So _floatunditf.So _divdi3.So _moddi3.So _udivdi3.So _umoddi3.So _udiv_w_sdiv.So _udi! vmoddi4.So _pack_sf.So _unpack_sf.So _addsub_sf.So _mul_sf.So _div_sf.So _fpcmp_parts_sf.So _compare_sf.So _eq_sf.So _ne_sf.So _gt_sf.So _ge_sf.So _lt_sf.So _le_sf.So _unord_sf.So _si_to_sf.So _sf_to_si.So _negate_sf.So _make_sf.So _sf_to_df.So _thenan_sf.So _sf_to_usi.So _usi_to_sf.So _pack_df.So _unpack_df.So _addsub_df.So _mul_df.
Re: /usr/bin/as: out of memory allocating 4194304 bytes after a total of 524288000 bytes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/21/12 13:21, Cy Schubert wrote: > In message <4f91c8fe.4070...@freebsd.org>, Dimitry Andric writes: >> This is a multi-part message in MIME format. >> --030506060901050002030508 >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> Content-Transfer-Encoding: 7bit >> >> On 2012-04-20 22:21, Jason Evans wrote: >>> On Apr 20, 2012, at 1:14 PM, Jason Evans wrote: On Apr 20, 2012, at 1:10 PM, Dimitry Andric wrote: > On 2012-04-20 21:54, Jason Evans wrote: >> On Apr 20, 2012, at 12:49 PM, Dimitry Andric wrote: >>> I think the best solution would be for jemalloc to avoid using obvious >>> names like "chunksize" for its globals, because it is basically a >>> library that could be linked to any sort of program out there. >>> >>> For example, it could prefix all its internal-use only globals with >>> "jemalloc_" or some other mangling scheme. Jason, any thoughts? >> >> jemalloc has optional namespace mangling support built in for just this >> reason. I'll turn it on, hopefully today. > > Indeed, I had just found jemalloc/internal/private_namespace.h. :) It > does seem to list only functions, not variables, is that right? Ah right, functions only. Well then, I don't have any bright ideas for so >> lving this problem in the short run. >>> >>> I take it back. There's spotty mangling coverage for variables. I'll try >> to add full coverage. >> >> I'm now using the attached. It seems to work... > > It didn't work for me. The problem is that /usr/bin/as is statically linked .. rebuild that and you'll be fine, imb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk+S8CAACgkQQv9rrgRC1JJs/ACcC9Sg1n37dQICmkRkeF3dLSi/ EX8An1IjGbLT6N9YM9p6fOyGL4V6ep1f =NooP -END PGP SIGNATURE- ___ 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"
[head tinderbox] failure on powerpc/powerpc
TB --- 2012-04-21 17:18:15 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-04-21 17:18:15 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-04-21 17:18:15 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2012-04-21 17:18:15 - cleaning the object tree TB --- 2012-04-21 17:18:15 - cvsupping the source tree TB --- 2012-04-21 17:18:15 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2012-04-21 17:18:56 - building world TB --- 2012-04-21 17:18:56 - CROSS_BUILD_TESTING=YES TB --- 2012-04-21 17:18:56 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-21 17:18:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-21 17:18:56 - SRCCONF=/dev/null TB --- 2012-04-21 17:18:56 - TARGET=powerpc TB --- 2012-04-21 17:18:56 - TARGET_ARCH=powerpc TB --- 2012-04-21 17:18:56 - TZ=UTC TB --- 2012-04-21 17:18:56 - __MAKE_CONF=/dev/null TB --- 2012-04-21 17:18:56 - cd /src TB --- 2012-04-21 17:18:56 - /usr/bin/make -B buildworld >>> World build started on Sat Apr 21 17:18:57 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] from /src/gnu/lib/libgcc/../../../contrib/gcc/config/fp-bit.c:44: /src/gnu/lib/libgcc/../../../contrib/gcc/config/rs6000/sysv4.h:285:1: warning: "PTRDIFF_TYPE" redefined In file included from ./tm.h:11, from /src/gnu/lib/libgcc/../../../contrib/gcc/config/fp-bit.c:44: /src/gnu/lib/libgcc/../../../contrib/gcc/config/freebsd.h:77:1: warning: this is the location of the previous definition ( -pg tramp.So unwind-dw2.So unwind-dw2-fde-glibc.So unwind-sjlj.So gthr-gnat.So unwind-c.So _muldi3.So _negdi2.So _lshrdi3.So _ashldi3.So _ashrdi3.So _cmpdi2.So _ucmpdi2.So _clear_cache.So _enable_execute_stack.So _trampoline.So __main.So _absvsi2.So _absvdi2.So _addvsi3.So _addvdi3.So _subvsi3.So _subvdi3.So _mulvsi3.So _mulvdi3.So _negvsi2.So _negvdi2.So _ctors.So _ffssi2.So _ffsdi2.So _clz.So _clzsi2.So _clzdi2.So _ctzsi2.So _ctzdi2.So _popcount_tab.So _popcountsi2.So _popcountdi2.So _paritysi2.So _paritydi2.So _powisf2.So _powidf2.So _powixf2.So _powitf2.So _mulsc3.So _muldc3.So _mulxc3.So _multc3.So _divsc3.So _divdc3.So _divxc3.So _divtc3.So _fixunssfsi.So _fixunsdfsi.So _fixunsxfsi.So _fixsfdi.So _fixunssfdi.So _floatdisf.So _floatundisf.So _fixdfdi.So _fixunsdfdi.So _floatdidf.So _floatundidf.So _fixxfdi.So _fixunsxfdi.So _floatdixf.So _floatundixf.So _fixtfdi.So _fixunstfdi.So _floatditf.So _floatunditf.So _divdi3.So _moddi3.So _udivdi3.So _umoddi3.So _udiv_w_sdi! v.So _udivmoddi4.So _pack_sf.So _unpack_sf.So _addsub_sf.So _mul_sf.So _div_sf.So _fpcmp_parts_sf.So _compare_sf.So _eq_sf.So _ne_sf.So _gt_sf.So _ge_sf.So _lt_sf.So _le_sf.So _unord_sf.So _si_to_sf.So _sf_to_si.So _negate_sf.So _make_sf.So _sf_to_df.So _thenan_sf.So _sf_to_usi.So _usi_to_sf.So _pack_df.So _unpack_df.So _addsub_df.So _mul_df.So _div_df.So _fpcmp_parts_df.So _compare_df.So _eq_df.So _ne_df.So _gt_df.So _ge_df.So _lt_df.So _le_df.So _unord_df.So _si_to_df.So _df_to_si.So _negate_df.So _make_df.So _df_to_sf.So _thenan_df.So _df_to_usi.So _usi_to_df.So tramp.So;echo %% ; cat /src/gnu/lib/libgcc/../../../contrib/gcc/libgcc-std.ver | sed -e '/^[ ]*#/d' -e 's/^%\(if\|else\|elif\|endif\|define\)/#\1/' | cc -O2 -pipe -DIN_GCC -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -DHAVE_GTHR_DEFAULT -I/src/gnu/lib/libgcc/../../../contrib/gcclibs/include -I/src/gnu/lib/libgcc/../../../contrib/gcc/config -I/src/gnu/lib/libgcc/../../../contrib/gcc -I. -I/src/gnu/lib/libgcc/.! ./../usr.bin/cc/cc_tools -std=gnu99 -E -xassembler-with-cpp -! ; ) | awk -f /src/gnu/lib/libgcc/../../../contrib/gcc/mkmap-symver.awk > libgcc.map -pg: not found No symbols seen -- broken or mis-installed nm? *** Error code 1 Stop in /src/gnu/lib/libgcc. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-04-21 17:36:41 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-04-21 17:36:41 - ERROR: failed to build world TB --- 2012-04-21 17:36:41 - 796.01 user 119.89 system 1106.18 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full ___ 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: /usr/bin/as: out of memory allocating 4194304 bytes after a total of 524288000 bytes
In message <4f91c8fe.4070...@freebsd.org>, Dimitry Andric writes: > This is a multi-part message in MIME format. > --030506060901050002030508 > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > Content-Transfer-Encoding: 7bit > > On 2012-04-20 22:21, Jason Evans wrote: > > On Apr 20, 2012, at 1:14 PM, Jason Evans wrote: > >> On Apr 20, 2012, at 1:10 PM, Dimitry Andric wrote: > >>> On 2012-04-20 21:54, Jason Evans wrote: > On Apr 20, 2012, at 12:49 PM, Dimitry Andric wrote: > > I think the best solution would be for jemalloc to avoid using obvious > > names like "chunksize" for its globals, because it is basically a > > library that could be linked to any sort of program out there. > > > > For example, it could prefix all its internal-use only globals with > > "jemalloc_" or some other mangling scheme. Jason, any thoughts? > > jemalloc has optional namespace mangling support built in for just this > reason. I'll turn it on, hopefully today. > >>> > >>> Indeed, I had just found jemalloc/internal/private_namespace.h. :) It > >>> does seem to list only functions, not variables, is that right? > >> > >> Ah right, functions only. Well then, I don't have any bright ideas for so > lving this problem in the short run. > > > > I take it back. There's spotty mangling coverage for variables. I'll try > to add full coverage. > > I'm now using the attached. It seems to work... It didn't work for me. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.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"
[head tinderbox] failure on i386/pc98
TB --- 2012-04-21 13:10:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-04-21 13:10:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-04-21 13:10:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2012-04-21 13:10:00 - cleaning the object tree TB --- 2012-04-21 13:10:00 - cvsupping the source tree TB --- 2012-04-21 13:10:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2012-04-21 13:16:25 - building world TB --- 2012-04-21 13:16:25 - CROSS_BUILD_TESTING=YES TB --- 2012-04-21 13:16:25 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-21 13:16:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-21 13:16:25 - SRCCONF=/dev/null TB --- 2012-04-21 13:16:25 - TARGET=pc98 TB --- 2012-04-21 13:16:25 - TARGET_ARCH=i386 TB --- 2012-04-21 13:16:25 - TZ=UTC TB --- 2012-04-21 13:16:25 - __MAKE_CONF=/dev/null TB --- 2012-04-21 13:16:25 - cd /src TB --- 2012-04-21 13:16:25 - /usr/bin/make -B buildworld >>> World build started on Sat Apr 21 13:16:26 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] c++ -O2 -pipe -I/src/lib/clang/libllvminstcombine/../../../contrib/llvm/include -I/src/lib/clang/libllvminstcombine/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvminstcombine/../../../contrib/llvm/lib/Transforms/InstCombine -I. -I/src/lib/clang/libllvminstcombine/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"i386-unknown-freebsd10.0\" -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libllvminstcombine/../../../contrib/llvm/lib/Transforms/InstCombine/InstCombinePHI.cpp c++ -O2 -pipe -I/src/lib/clang/libllvminstcombine/../../../contrib/llvm/include -I/src/lib/clang/libllvminstcombine/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvminstcombine/../../../contrib/llvm/lib/Transforms/InstCombine -I. -I/src/lib/clang/libllvminstcombine/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"i386-unknown-freebsd10.0\" -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libllvminstcombine/../../../contrib/llvm/lib/Transforms/InstCombine/InstCombineSelect.cpp c++ -O2 -pipe -I/src/lib/clang/libllvminstcombine/../../../contrib/llvm/include -I/src/lib/clang/libllvminstcombine/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvminstcombine/../../../contrib/llvm/lib/Transforms/InstCombine -I. -I/src/lib/clang/libllvminstcombine/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"i386-unknown-freebsd10.0\" -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libllvminstcombine/../../../contrib/llvm/lib/Transforms/InstCombine/InstCombineShifts.cpp /src/lib/clang/libllvminstcombine/../../../contrib/llvm/lib/Transforms/InstCombine/InstCombineShifts.cpp: In member function 'llvm::Instruction* llvm::InstCombiner::FoldShiftByConstant(llvm::Value*, llvm::ConstantInt*, llvm::BinaryOperator&)': /src/lib/clang/libllvminstcombine/../../../contrib/llvm/lib/Transforms/InstCombine/InstCombineShifts.cpp:313: internal compiler error: Bus error: 10 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. *** Error code 1 Stop in /src/lib/clang/libllvminstcombine. *** Error code 1 Stop in /src/lib/clang. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-04-21 14:40:06 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-04-21 14:40:06 - ERROR: failed to build world TB --- 2012-04-21 14:40:06 - 4078.23 user 524.56 system 5405.80 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full ___ 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: gstat don't work after update to 10.0-CURRENT
I believe that this was fixed in r234107 http://svn.freebsd.org/changeset/base/234107 ___ 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: Some performance measurements on the FreeBSD network stack
On Fri, 20 Apr 2012, K. Macy wrote: On Fri, Apr 20, 2012 at 4:44 PM, Luigi Rizzo wrote: The small penalty when flowtable is disabled but compiled in is probably because the net.flowtable.enable flag is checked a bit deep in the code. The advantage with non-connect()ed sockets is huge. I don't quite understand why disabling the flowtable still helps there. Do you mean having it compiled in but disabled still helps performance? Yes, that is extremely strange. This reminds me that when I worked on this, I saw very large throughput differences (in the 20-50% range) as a result of minor changes in unrelated code. I could get these changes intentionally by adding or removing padding in unrelated unused text space, so the differences were apparently related to text alignment. I thought I had some significant micro-optimizations, but it turned out that they were acting mainly by changing the layout in related used text space where it is harder to control. Later, I suspected that the differences were more due to cache misses for data than for text. The CPU and its caching must affect this significantly. I tested on an AthlonXP and Athlon64, and the differences were larger on the AthlonXP. Both of these have a shared I/D cache so pressure on the I part would affect the D part, but in this benchmark the D part is much more active than the I part so it is unclear how text layout could have such a large effect. Anyway, the large differences made it impossible to trust the results of benchmarking any single micro-benchmark. Also, ministat is useless for understanding the results. (I note that luigi didn't provide any standard deviations and neither would I. :-). My results depended on the cache behaviour but didn't change significantly when rerun, unless the code was changed. Bruce ___ 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: gstat don't work after update to 10.0-CURRENT
On Tue, Apr 10, 2012 at 11:52:57AM +, you (Anton Yuzhaninov) sent the following to [freebsd-current] : > On Tue, 10 Apr 2012 15:19:37, Anton Yuzhaninov wrote: > AY> gstat don't work after update to 10.0-CURRENT r233947 > AY> It don't show any providers, and don't print any errors: > AY> # gstat -b > AY> dT: 1.166s w: 1.000s > AY> L(q) ops/sr/s kBps ms/rw/s kBps ms/w %busy Name > AY> # > > After reverting r233646 gstat show: > > dT: 1.001s w: 1.000s > L(q) ops/sr/s kBps ms/rw/s kBps ms/w %busy Name > 0 0 0 00.0 0 00.00.0 ada0 > 0 0 0 00.0 0 00.00.0 ada0s1 > 0 0 0 00.0 0 00.00.0 ada1 > 1392392 19032.3 0 00.0 91.6 ada2 > 0 0 0 00.0 0 00.00.0 ada1s1 > 1392392 19032.4 0 00.0 92.5 ufs/backup > 0 0 0 00.0 0 00.00.0 mirror/gm0 > 0 0 0 00.0 0 00.00.0 mirror/gm0a > 0 0 0 00.0 0 00.00.0 mirror/gm0b > 0 0 0 00.0 0 00.00.0 mirror/gm0d > > so problem somewhere in > http://svn.freebsd.org/changeset/base/233646 I'm also seeing the same behaviour. I updated my 10-CURRENT from r230839 (gstat worked here still) to r233779 where it's broken. -- marco Proud recurring donor of the FreeBSD Foundation You can have any color you want, as long as it is black! ___ 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: Complete hang on 9.0-RELEASE
Hi, On Wed, Apr 18, 2012 at 2:22 AM, Arnaud Lacombe wrote: > Hi, > > On Mon, Apr 16, 2012 at 5:50 PM, Arnaud Lacombe wrote: >> [...] >> I reproduced the previous problem on 10-CURRENT from r233917, on the >> following platform (here running 8.2-RELEASE): >> >> FreeBSD is a registered trademark of The FreeBSD Foundation. >> FreeBSD 8.2-RELEASE #0: Thu Feb 17 02:41:51 UTC 2011 >> r...@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 >> Timecounter "i8254" frequency 1193182 Hz quality 0 >> CPU: Intel(R) Atom(TM) CPU D525 @ 1.80GHz (1800.01-MHz K8-class CPU) >> Origin = "GenuineIntel" Id = 0x106ca Family = 6 Model = 1c Stepping = 10 >> Features=0xbfebfbff >> Features2=0x40e31d >> AMD Features=0x20100800 >> AMD Features2=0x1 >> TSC: P-state invariant >> real memory = 2136539136 (2037 MB) >> avail memory = 2043772928 (1949 MB) >> ACPI APIC Table: <010312 APIC0947> >> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs >> FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 HTT threads >> cpu0 (BSP): APIC ID: 0 >> cpu1 (AP/HT): APIC ID: 1 >> cpu2 (AP): APIC ID: 2 >> cpu3 (AP/HT): APIC ID: 3 >> >> Complete system freeze while running about 2400 threads. I had to >> power cycle the system to get it back alive. I discussed a way to >> debug this with attilio@ on freebsd-stable@, but still did not had >> time to implement it. >> > 10-CURRENT from r233917 hanged again today while running 3600 threads. > I enabled WITNESS and INVARIANTS on that specific kernel, secretly > hoping that they would trigger some meaningful information, but they > did not. I would guess my last attempt is to enable SW_WATCHDOG, and > gather some state information out of DDB when the watchdog trigger, if > it does... > > Btw, this issue seems to be specifically happening on Atom/ICH8M > platform running amd64 kernel, as I've never seen it on other > platforms, and yet ran extensive tests. I am not entirely sure it > happens on i386. I would need to check. > For the record, 9.0-RELEASE i386 has been running the test for about 2 days on the D510 platform without any hang so far. I'll keep it running all week-end to give me a better idea. - Arnaud ___ 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: Disabling an arbitrary device
Hi, On Fri, Apr 20, 2012 at 8:50 PM, Attilio Rao wrote: > Il 20 aprile 2012 19:18, Arnaud Lacombe ha scritto: >> Hi, >> >> On Fri, Apr 20, 2012 at 2:16 PM, Arnaud Lacombe wrote: >>> Hi, >>> >>> I will be bringing up an old thread there, but it would seem the >>> situation did not evolve in the past 9 years. I have a machine running >>> 7.1 whose UHCI controller is generating some interrupt storm: >>> >>> # vmstat -i >>> interrupt total rate >>> irq4: sio0 1328 2 >>> irq19: uhci1+ 63514509 96380 >>> [...] >>> >>> generating useless load on one CPU: >>> >>> # top -SH >>> last pid: 5223; load averages: 0.00, 0.00, 0.00 up 0+00:17:21 >>> 13:10:35 >>> 117 processes: 14 running, 79 sleeping, 24 waiting >>> CPU: 0.2% user, 0.0% nice, 0.2% system, 6.6% interrupt, 93.0% idle >>> Mem: 33M Active, 9348K Inact, 67M Wired, 400K Cache, 29M Buf, 2892M Free >>> [...] >>> 57 root -64 - 0K 8K CPU0 0 11:59 86.57% irq19: >>> uhci1+ >>> >>> I thought I could use an hint to forbid uhci(4) attachment, ala: >>> >>> hint.uhci.0.disabled="1" >>> hint.uhci.1.disabled="1" >>> >>> in /boot/loader.conf. However, it would seem that what should be >>> usable with any arbitrary devices, ie. be an integral part of >>> device(9), has to be hardcoded in every driver, sad. >>> >> as for the usual "if you're not happy, please provide a patch": >> >> https://github.com/lacombar/freebsd/commit/30786d09b0cb441890cdc749ee5243238e81d2d8 > > I think a generalized kludge should really belong to > device_probe_child() rather than device_add_child_ordered(). > suit me. > When you have a tested patch against -CURRENT, can you please send to > freebsd-newbus@? > will give it a try, eventually. > BTW, IIRC 7.x doesn't have the new USB stack, which means that you can > have caught easilly a driver bug there, did you consider switching at > least to 8.x kernel? > That is unfortunately not a decision for me to make, though a switch to 9.x will be more likely. That said, it seems that it is not a USB specific issue, but an IRQ19's issue. I did not had a chance to investigate that further, but with uhci(4) disabled, atapci(4) is now IRQ-storming. This is a known issue relatively widely encountered, with various workarounds possible. - Arnaud ___ 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: contrib/jemalloc
On 04/20/2012 06:06 PM, Pedro Giffuni wrote: > On 04/20/12 19:32, David O'Brien wrote: >> On Fri, Apr 20, 2012 at 02:13:32PM -0700, Pedro Giffuni wrote: >>> Easier said than done. Feel free to give libedit a try. >> That has nothing to do with our process and everything to do with us >> blindly hacking away pissing all over to be our own thing -- BUT still >> wanting to take work from the original author. >> >> I fail to see how not updating thru $FBSDrepo/vendor/NetBSD/libedit >> is easier than updating thru it. >> >> Either way you have to figure out what to do with our great divergance. >> At least when using the vendor branch you can use a good 3-way diff merge >> tool (e.g. svn). >> > > Usually the vendor upgrade approach works just fine if we do > the periodic work of keeping up to date and we are careful to > submit our changes upstream. That's an expected part of the role of maintainer, so, yeah. :) > The issue is that you really have to be in sync with one upstream > version so that the changes you merge from the vendor branch > are consistent. To a large extent, yes. > In libedit we have incomplete merges from upstream (that was > CVS fault), we have some changes that are obsolete wrt to how > upstream solved the same issues and we have a couple of > files that have diverged completely from upstream. I agree that sounds like an ugly mess ... who is working on cleaning it up? Is this something that we need to create a team to address? It certainly sounds like something too large for one person to handle on their own. > Either way it all can all be solved but it's just a lot of work and I > can see how the direct approach helps understand better what > is happening and can ultimately save time. I'm glad we have an area of agreement. It sounds to me like the lesson from libedit is to do it right from the very beginning, so that things like libedit don't happen again. Doug ___ 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"
