Re: Leaving the Desktop Market
On Wed, Apr 2, 2014 at 7:14 PM, Alexey Dokuchaev da...@nsu.ru wrote: On Tue, Apr 01, 2014 at 03:10:22PM -0700, Kevin Oberman wrote: FreeBSD desktop since 3.3 (makes me a newbie!) I really dislike pulseaudio and have managed to live without it. Firefox works fine without it. Unfortunately they dropped OSS support a while go, so I now must use alsa, but it works well and without the pain of dealing with pulseaudio, a solution in search of a problem it I ever saw one. PA should just die, of course, just like that kid's other products. OSS is so nice; it supports all those nifty features like per-application mixing and stuff, we have a very strong implementation of it (kudos to ariff@, let me remind us all: http://people.freebsd.org/~ariff/SOUND_4.TXT.html). Giving Firerox back its OSS support is my on TODO list, unfortunately I do not have any idea when (or if) I can look at it, but that would be a nice step in dealsificaion of our Ports Collection. OSS was, and should remain, the standard Unixish sound system API. Wow! That would be great! It's really annoying that some tools won't (not can't) do OSS. PA really had no reason to exist, but some people have such determination to do their own thing, even if it means throwing out a better solution. (OK, so the author did play some unfortunate games with licensing, but that was years ago.) Audio output is pretty system dependent, but I had little problem getting my audio to auto-switch to headphones when I plugged them in. The setup is a bit ugly,but I only had to check the available PINs (ugly, ugly) and set up stuff once. It just works. Not always, unfortunately. I also had a working pin override configuration in /boot/loader.conf, but after r236750 (major snd_hda driver rewrite) it stopped working. I've reported it and tried to get some support from mav@ but he never replied. Since then, I have to carry pre-r236750 version of snd_hda(4) to have working sound. Is that just in head? Do I have more fun to look forward to? Power is an issue and I find the current defaults suck. Read mav's article on the subject on the wiki. From reading that article, I've only added hw.pci.do_power_nodriver=3 and hw.pci.do_power_resume=0 to /boot/loader.conf. More aggressive settings, like cx_lowest=C2, made my laptop very sluggish and unpleasant to operate; powerd(8) behaves sanely with no tuning, so I wouldn't say that our current defaults suck. The reason why we're behind on the green lane is because we generally do not pay much attention when it comes to power-saving during development of FreeBSD. (I'd like to be proven wrong.) The key poblem with power, as I have written several times is the conflation of TCC or throttling as power management tools. Mix them (they really don't save power) with Cx states is often worse than what you are seeing. It canl cause many systems to lock up . Try setting: powerd_enable=YES performance_cx_lowest=Cmax economy_cx_lowest=Cmax into /etc/rc.conf and putting: # Disable CPU throttling hint.p4tcc.0.disabled=1 hint.acpi_throttle.0.disabled=1 into /boot/loader.conf. That should work MUCH better and will really save power (assuming that your system supports better than C2 as C2 usually is a pretty minor power savings. C3 or higher is usually where things really start to improve. I've read a paper from SDSC (San Diego Supercomputer Center) showing that CX states are by far and away the most significant power saver and they should cause only very trivial and unnoticeable impact on performance. Number two is EST, but that is almost always enabled on FreeBSD, so I assume that you have that running already (or the AMD equivalent). ./danfe -- R. Kevin Oberman, Network Engineer, Retired 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
[head tinderbox] failure on ia64/ia64
TB --- 2014-04-03 07:33:05 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-04-03 07:33:05 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-04-03 07:33:05 - starting HEAD tinderbox run for ia64/ia64 TB --- 2014-04-03 07:33:05 - cleaning the object tree TB --- 2014-04-03 07:33:21 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-04-03 07:33:37 - At svn revision 264059 TB --- 2014-04-03 07:33:38 - building world TB --- 2014-04-03 07:33:38 - CROSS_BUILD_TESTING=YES TB --- 2014-04-03 07:33:38 - MAKEOBJDIRPREFIX=/obj TB --- 2014-04-03 07:33:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-04-03 07:33:38 - SRCCONF=/dev/null TB --- 2014-04-03 07:33:38 - TARGET=ia64 TB --- 2014-04-03 07:33:38 - TARGET_ARCH=ia64 TB --- 2014-04-03 07:33:38 - TZ=UTC TB --- 2014-04-03 07:33:38 - __MAKE_CONF=/dev/null TB --- 2014-04-03 07:33:38 - cd /src TB --- 2014-04-03 07:33:38 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Thu Apr 3 07:33:45 UTC 2014 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 -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/ia64 -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/ia64.ia64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -w -c gdtoa_gethex.c -o gdtoa_gethex.o cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/ia64 -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/ia64.ia64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -w -c gdtoa_gmisc.c -o gdtoa_gmisc.o cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/ia64 -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/ia64.ia64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -w -c gdtoa_hd_init.c -o gdtoa_hd_init.o cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/ia64 -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/ia64.ia64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -w -c gdtoa_hexnan.c -o gdtoa_hexnan.o cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/ia64 -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/ia64.ia64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -w -c gdtoa_misc.c -o gdtoa_misc.o cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/ia64 -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/ia64.ia64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -w -c gdtoa_smisc.c -o gdtoa_smisc.o cc -O2 -pipe -I/src/lib/libc/include
Re: Leaving the Desktop Market
There are a few alternatives to Lightroom available in Ports Collection, you might want to give them a try one day. offtopic: But it does not even come close to Lightroom. Gimp is also not even close to Photoshop. Maybe Pixelmator. But Gimp? The UI and usability is such a mess. But again it's the difference between free and paying alot of money. ___ 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 mips/mips
TB --- 2014-04-03 07:46:09 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-04-03 07:46:09 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-04-03 07:46:09 - starting HEAD tinderbox run for mips/mips TB --- 2014-04-03 07:46:09 - cleaning the object tree TB --- 2014-04-03 07:46:28 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-04-03 07:46:31 - At svn revision 264059 TB --- 2014-04-03 07:46:32 - building world TB --- 2014-04-03 07:46:32 - CROSS_BUILD_TESTING=YES TB --- 2014-04-03 07:46:32 - MAKEOBJDIRPREFIX=/obj TB --- 2014-04-03 07:46:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-04-03 07:46:32 - SRCCONF=/dev/null TB --- 2014-04-03 07:46:32 - TARGET=mips TB --- 2014-04-03 07:46:32 - TARGET_ARCH=mips TB --- 2014-04-03 07:46:32 - TZ=UTC TB --- 2014-04-03 07:46:32 - __MAKE_CONF=/dev/null TB --- 2014-04-03 07:46:32 - cd /src TB --- 2014-04-03 07:46:32 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Thu Apr 3 07:46:39 UTC 2014 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 -O -pipe -G0 -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/mips -DNLS -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/mips.mips/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/mips/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -w -c gdtoa_gethex.c -o gdtoa_gethex.o cc -O -pipe -G0 -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/mips -DNLS -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/mips.mips/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/mips/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -w -c gdtoa_gmisc.c -o gdtoa_gmisc.o cc -O -pipe -G0 -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/mips -DNLS -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/mips.mips/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/mips/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -w -c gdtoa_hd_init.c -o gdtoa_hd_init.o cc -O -pipe -G0 -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/mips -DNLS -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/mips.mips/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/mips/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -w -c gdtoa_hexnan.c -o gdtoa_hexnan.o cc -O -pipe -G0 -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/mips -DNLS -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/mips.mips/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/mips/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -w -c gdtoa_misc.c -o gdtoa_misc.o cc -O -pipe -G0 -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/mips -DNLS -DSOFTFLOAT -D__DBINTERFACE_PRIVATE
[head tinderbox] failure on mips64/mips
TB --- 2014-04-03 07:57:51 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-04-03 07:57:51 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-04-03 07:57:51 - starting HEAD tinderbox run for mips64/mips TB --- 2014-04-03 07:57:51 - cleaning the object tree TB --- 2014-04-03 07:58:08 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-04-03 07:58:11 - At svn revision 264059 TB --- 2014-04-03 07:58:12 - building world TB --- 2014-04-03 07:58:12 - CROSS_BUILD_TESTING=YES TB --- 2014-04-03 07:58:12 - MAKEOBJDIRPREFIX=/obj TB --- 2014-04-03 07:58:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-04-03 07:58:12 - SRCCONF=/dev/null TB --- 2014-04-03 07:58:12 - TARGET=mips TB --- 2014-04-03 07:58:12 - TARGET_ARCH=mips64 TB --- 2014-04-03 07:58:12 - TZ=UTC TB --- 2014-04-03 07:58:12 - __MAKE_CONF=/dev/null TB --- 2014-04-03 07:58:12 - cd /src TB --- 2014-04-03 07:58:12 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Thu Apr 3 07:58:19 UTC 2014 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 -O -pipe -G0 -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/mips -DNLS -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/mips.mips64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/mips/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -w -c gdtoa_gethex.c -o gdtoa_gethex.o cc -O -pipe -G0 -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/mips -DNLS -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/mips.mips64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/mips/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -w -c gdtoa_gmisc.c -o gdtoa_gmisc.o cc -O -pipe -G0 -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/mips -DNLS -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/mips.mips64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/mips/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -w -c gdtoa_hd_init.c -o gdtoa_hd_init.o cc -O -pipe -G0 -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/mips -DNLS -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/mips.mips64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/mips/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -w -c gdtoa_hexnan.c -o gdtoa_hexnan.o cc -O -pipe -G0 -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/mips -DNLS -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/mips.mips64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/mips/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -w -c gdtoa_misc.c -o gdtoa_misc.o cc -O -pipe -G0 -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/mips -DNLS -DSOFTFLOAT -D__DBINTERFACE_PRIVATE
Re: gcc compilation broken with SVN r264042
On 3 Apr 2014, at 00:23, Warner Losh i...@bsdimp.com wrote: So less carping and more fixing is needed here. Should be fixed in r264069 - I'm sure Jenkins / Tinderbox will tell me if it isn't... libc now builds for me with gcc and clang. David ___ 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 --- 2014-04-03 08:09:47 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-04-03 08:09:47 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-04-03 08:09:47 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2014-04-03 08:09:47 - cleaning the object tree TB --- 2014-04-03 08:10:05 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-04-03 08:10:09 - At svn revision 264059 TB --- 2014-04-03 08:10:10 - building world TB --- 2014-04-03 08:10:10 - CROSS_BUILD_TESTING=YES TB --- 2014-04-03 08:10:10 - MAKEOBJDIRPREFIX=/obj TB --- 2014-04-03 08:10:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-04-03 08:10:10 - SRCCONF=/dev/null TB --- 2014-04-03 08:10:10 - TARGET=powerpc TB --- 2014-04-03 08:10:10 - TARGET_ARCH=powerpc TB --- 2014-04-03 08:10:10 - TZ=UTC TB --- 2014-04-03 08:10:10 - __MAKE_CONF=/dev/null TB --- 2014-04-03 08:10:10 - cd /src TB --- 2014-04-03 08:10:10 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Thu Apr 3 08:10:17 UTC 2014 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 -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/powerpc.powerpc/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -w -c gdtoa_gethex.c -o gdtoa_gethex.o cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/powerpc.powerpc/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -w -c gdtoa_gmisc.c -o gdtoa_gmisc.o cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/powerpc.powerpc/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -w -c gdtoa_hd_init.c -o gdtoa_hd_init.o cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/powerpc.powerpc/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -w -c gdtoa_hexnan.c -o gdtoa_hexnan.o cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/powerpc.powerpc/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -w -c gdtoa_misc.c -o gdtoa_misc.o cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/powerpc.powerpc/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN
[head tinderbox] failure on powerpc64/powerpc
TB --- 2014-04-03 08:26:18 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-04-03 08:26:18 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-04-03 08:26:18 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2014-04-03 08:26:18 - cleaning the object tree TB --- 2014-04-03 08:26:36 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-04-03 08:26:40 - At svn revision 264059 TB --- 2014-04-03 08:26:41 - building world TB --- 2014-04-03 08:26:41 - CROSS_BUILD_TESTING=YES TB --- 2014-04-03 08:26:41 - MAKEOBJDIRPREFIX=/obj TB --- 2014-04-03 08:26:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-04-03 08:26:41 - SRCCONF=/dev/null TB --- 2014-04-03 08:26:41 - TARGET=powerpc TB --- 2014-04-03 08:26:41 - TARGET_ARCH=powerpc64 TB --- 2014-04-03 08:26:41 - TZ=UTC TB --- 2014-04-03 08:26:41 - __MAKE_CONF=/dev/null TB --- 2014-04-03 08:26:41 - cd /src TB --- 2014-04-03 08:26:41 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Thu Apr 3 08:26:48 UTC 2014 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 -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc64 -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/powerpc.powerpc64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -w -c gdtoa_gethex.c -o gdtoa_gethex.o cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc64 -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/powerpc.powerpc64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -w -c gdtoa_gmisc.c -o gdtoa_gmisc.o cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc64 -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/powerpc.powerpc64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -w -c gdtoa_hd_init.c -o gdtoa_hd_init.o cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc64 -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/powerpc.powerpc64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -w -c gdtoa_hexnan.c -o gdtoa_hexnan.o cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc64 -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/powerpc.powerpc64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -w -c gdtoa_misc.c -o gdtoa_misc.o cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc64 -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/powerpc.powerpc64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale
[head tinderbox] failure on sparc64/sparc64
TB --- 2014-04-03 08:42:23 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-04-03 08:42:23 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-04-03 08:42:23 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2014-04-03 08:42:23 - cleaning the object tree TB --- 2014-04-03 08:42:44 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-04-03 08:42:48 - At svn revision 264059 TB --- 2014-04-03 08:42:49 - building world TB --- 2014-04-03 08:42:49 - CROSS_BUILD_TESTING=YES TB --- 2014-04-03 08:42:49 - MAKEOBJDIRPREFIX=/obj TB --- 2014-04-03 08:42:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-04-03 08:42:49 - SRCCONF=/dev/null TB --- 2014-04-03 08:42:49 - TARGET=sparc64 TB --- 2014-04-03 08:42:49 - TARGET_ARCH=sparc64 TB --- 2014-04-03 08:42:49 - TZ=UTC TB --- 2014-04-03 08:42:49 - __MAKE_CONF=/dev/null TB --- 2014-04-03 08:42:49 - cd /src TB --- 2014-04-03 08:42:49 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Thu Apr 3 08:42:56 UTC 2014 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 -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -DNLS -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/sparc64.sparc64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -w -c gdtoa_gethex.c -o gdtoa_gethex.o cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -DNLS -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/sparc64.sparc64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -w -c gdtoa_gmisc.c -o gdtoa_gmisc.o cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -DNLS -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/sparc64.sparc64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -w -c gdtoa_hd_init.c -o gdtoa_hd_init.o cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -DNLS -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/sparc64.sparc64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -w -c gdtoa_hexnan.c -o gdtoa_hexnan.o cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -DNLS -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/sparc64.sparc64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -w -c gdtoa_misc.c -o gdtoa_misc.o cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -DNLS -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa
Re: Leaving the Desktop Market
Since when is GIMP an alternative to Lightroom? I was talking about raw processors, not raster image manipulators. The opensource alternatives to Lightroom come not close to the original. The _same_ is true for GIMP which is hardly workable and is not more then a nice showcase but its usability is just horrible. ___ 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: kevent has bug?
From: Konstantin Belousov kostik...@gmail.com
Date: Wed, 2 Apr 2014 20:44:00 +0300
On Wed, Apr 02, 2014 at 09:45:43AM -0700, John-Mark Gurney wrote:
Konstantin Belousov wrote this message on Wed, Apr 02, 2014 at 15:07 +0300:
Well, it's not that its preventing waking up the waiter, but failing to
register the event on the knote because of the _INFLUX flag...
Yes, I used the wrong terminology.
Patch below fixed your test case for me, also tools/regression/kqueue did
not noticed a breakage. I tried to describe the situation in the
comment in knote(). Also, I removed unlocked check for the KN_INFLUX
in knote, since it seems to be an optimization for rare case, and is
the race on its own.
Comments below...
diff --git a/sys/kern/kern_event.c b/sys/kern/kern_event.c
index b3fb23d..380f1ff 100644
--- a/sys/kern/kern_event.c
+++ b/sys/kern/kern_event.c
[...]
@@ -1506,7 +1506,7 @@ retry:
KQ_LOCK(kq);
kn = NULL;
} else {
- kn-kn_status |= KN_INFLUX;
+ kn-kn_status |= KN_INFLUX | KN_SCAN;
KQ_UNLOCK(kq);
if ((kn-kn_status KN_KQUEUE) == KN_KQUEUE)
KQ_GLOBAL_LOCK(kq_global, haskqglobal);
Is there a reason you don't add the KN_SCAN to the other cases in
kqueue_scan that set the _INFLUX flag?
Other cases in kqueue_scan() which set influx do the detach and drop,
so I do not see a need to ensure that note is registered. Except I missed
one case, which you pointed out.
[...]
@@ -1865,28 +1866,33 @@ knote(struct knlist *list, long hint, int
lockflags)
*/
SLIST_FOREACH(kn, list-kl_list, kn_selnext) {
kq = kn-kn_kq;
- if ((kn-kn_status KN_INFLUX) != KN_INFLUX) {
+ KQ_LOCK(kq);
+ if ((kn-kn_status (KN_INFLUX | KN_SCAN)) == KN_INFLUX) {
+ /*
+ * Do not process the influx notes, except for
+ * the influx coming from the kq unlock in the
+ * kqueue_scan(). In the later case, we do
+ * not interfere with the scan, since the code
+ * fragment in kqueue_scan() locks the knlist,
+ * and cannot proceed until we finished.
+ */
We might want to add a marker node, and reprocess the list from the
marker node, because this might introduce other races in the code too...
but the problem with that is that knote is expected to keep the list
locked throughout the call if called w/ it already locked, and so we
can't do that, without major work... :(
Why ? If the knlist lock is not dropped, I do not see a need for the
marker. The patch does not introduce the sleep point for the KN_SCAN
knotes anyway.
I added a similar comment in knote_fork:
* XXX - Why do we skip the kn if it is _INFLUX? Does this
* mean we will not properly wake up some notes?
and it looks like it was true...
So, upon reading the other _INFLUX cases, it looks like we should change
_SCAN to be, _CHANGING or something similar, and any place we don't end
up dropping the knote, we set this flag also... Once such case is at
the end of kqueue_register, just before the label done_ev_add, where we
update the knote w/ new udata and other fields.. Or change the logic
of the flag, and set it for all the cases we are about to drop the
knote..
So do you prefer KN_CHANGING instead of KN_SCAN ? I do not have any
objections against renaming the flag, but _CHANGING seems to not say
anything about the flag intent. I would say that KN_STABLE is more
useful, or KN_INFLUX_NODEL, or whatever.
The done_ev_add case is indeed missed in my patch, thank you for noting.
The case of EV_ADD does not need the KN_SCAN workaround, IMO, since the
race is possible just by the nature of adding the knote.
+ KQ_UNLOCK(kq);
+ } else if ((lockflags KNF_NOKQLOCK) != 0) {
+ kn-kn_status |= KN_INFLUX;
+ KQ_UNLOCK(kq);
+ error = kn-kn_fop-f_event(kn, hint);
KQ_LOCK(kq);
I believe we can drop this unlock/lock pair as it's safe to hold the
KQ lock over f_event, we do that in knote_fork...
The knote_fork() is for the special kinds of knote only, where we indeed know
in advance that having the kqueue locked around f_event does not break things.
Updated patch below.
diff --git a/sys/kern/kern_event.c b/sys/kern/kern_event.c
index b3fb23d..fadb8fd 100644
--- a/sys/kern/kern_event.c
+++ b/sys/kern/kern_event.c
@@ -474,7 +474,7 @@ knote_fork(struct knlist *list, int pid)
continue;
kq = kn-kn_kq;
KQ_LOCK(kq);
- if ((kn-kn_status KN_INFLUX) == KN_INFLUX) {
+ if ((kn-kn_status (KN_INFLUX | KN_SCAN)) == KN_INFLUX) {
Re: Leaving the Desktop Market
On Tue, Apr 01, 2014 at 03:10:22PM -0700, Kevin Oberman wrote: FreeBSD desktop since 3.3 (makes me a newbie!) I really dislike pulseaudio and have managed to live without it. Firefox works fine without it. Unfortunately they dropped OSS support a while go, so I now must use alsa, but it works well and without the pain of dealing with pulseaudio, a solution in search of a problem it I ever saw one. PA should just die, of course, just like that kid's other products. OSS is so nice; it supports all those nifty features like per-application mixing and stuff, we have a very strong implementation of it (kudos to ariff@, let me remind us all: http://people.freebsd.org/~ariff/SOUND_4.TXT.html). Giving Firerox back its OSS support is my on TODO list, unfortunately I do not have any idea when (or if) I can look at it, but that would be a nice step in dealsificaion of our Ports Collection. OSS was, and should remain, the standard Unixish sound system API. Audio output is pretty system dependent, but I had little problem getting my audio to auto-switch to headphones when I plugged them in. The setup is a bit ugly,but I only had to check the available PINs (ugly, ugly) and set up stuff once. It just works. Not always, unfortunately. I also had a working pin override configuration in /boot/loader.conf, but after r236750 (major snd_hda driver rewrite) it stopped working. I've reported it and tried to get some support from mav@ but he never replied. Since then, I have to carry pre-r236750 version of snd_hda(4) to have working sound. Power is an issue and I find the current defaults suck. Read mav's article on the subject on the wiki. From reading that article, I've only added hw.pci.do_power_nodriver=3 and hw.pci.do_power_resume=0 to /boot/loader.conf. More aggressive settings, like cx_lowest=C2, made my laptop very sluggish and unpleasant to operate; powerd(8) behaves sanely with no tuning, so I wouldn't say that our current defaults suck. The reason why we're behind on the green lane is because we generally do not pay much attention when it comes to power-saving during development of FreeBSD. (I'd like to be proven wrong.) ./danfe ___ 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: Leaving the Desktop Market
On Thu, Apr 03, 2014 at 11:21:34AM +0200, Matthias Gamsjager wrote: Since when is GIMP an alternative to Lightroom? I was talking about raw processors, not raster image manipulators. The opensource alternatives to Lightroom come not close to the original. They maybe not yet a drop-in replacement, but they are competitive enough to be discussed on photo forums (read: outside open source geeky cabal): http://www.pentaxforums.com/forums/32-digital-processing-software-printing/242584-darktable-vs-lightroom.html http://photo.stackexchange.com/questions/37238/how-does-darktable-compare-to-adobe-lightroom-for-editing-jpegs http://photo.stackexchange.com/questions/23272/simple-comparison-of-lightroom-4-corel-aftershot-pro-darktable http://www.dpreview.com/forums/post/39475179 As they say, The differences in actual editing are negligible. It's not even worth migrating between the two. LR comes with a price-tag, Darktable comes with bugs. ./danfe ___ 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: Leaving the Desktop Market
On Thu, Apr 03, 2014 at 09:49:31AM +0200, Matthias Gamsjager wrote: There are a few alternatives to Lightroom available in Ports Collection, you might want to give them a try one day. offtopic: But it does not even come close to Lightroom. Gimp is also not even close to Photoshop. Maybe Pixelmator. But Gimp? The UI and usability is such a mess. Since when is GIMP an alternative to Lightroom? I was talking about raw processors, not raster image manipulators. ./danfe ___ 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: Leaving the Desktop Market
On Tue, Apr 01, 2014 at 08:38:28AM +0100, David Chisnall wrote: On 1 Apr 2014, at 08:11, Jordan Hubbard j...@mail.turbofuzz.com wrote: 1. Power. As you point out, being truly power efficient is a complete top-to-bottom engineering effort and it takes a lot more than just trying to idle the processor whenever possible to achieve that. You need to optimize all of the hot-spot routines in the system for power efficiency (which actually involves a fair amount of micro architecture knowledge), you need a kernel scheduler that is power management aware, you need a process management system that runs as few things as possible and knows how to schedule things during package wake-up intervals, you need timers to be coalesced at the level where applications consume them, the list just goes on and on. It's a lot of engineering work, and to drive that work you also need a lot of telemetry data and people with big sticks running around hitting people who write power-inefficient code. FreeBSD has neither. Thanks Jordan, this is an excellent elaboration on why exactly we're behind on the green lane, and on power-neglective FreeBSD development overall. Just a small note here: Improving power management is something that the Core Team and the Foundation have jointly identified as an important goal, in particular for mobile/embedded scenarios. We're currently coordinating potential sponsors for the work and soliciting proposals from people interested in doing the work. If you know of anyone in either category then please drop either me, core, or the Foundation an email. Some things have already seen progress, for example Davide's calloutng work includes timer coalescing, but there are still a lot of, uh, opportunities for improvement. The Symbian EKA2 book has some very interesting detail on their power management infrastructure, which would be worth looking at for anyone interested in working on this, and I believe your former employer had some expertise in this area. Now that's something I'm glad to hear. It would be cool if FreeBSD gained some power-efficient software that run smoothly together with hardware (and laptops in particular) developed by Jordan's former employer. ;-) For example, currently hald wakes up every 30 seconds and polls the optical drive if you have one. Why? Because there's no devd event when a CD is inserted, so the only way for it to get these notifications is polling. I'm surprised to find out that our devd(8) does not emit some event on CD insertion. On the other, if by hald you mean the one installed by the `sysutils/hal' port, I've personally never run it, and do not recommend it to anyone. ./danfe ___ 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: iwn(4) in -HEAD supporting Centrino Wireless-N 135
Hi, I'm just wondering if you had any time to look at this? I'm happy to test any patches or diffs. Regards, Tom On Tue, Mar 11, 2014 at 11:03:20AM -0700, Adrian Chadd wrote: I still don't have any ideas here. I do however want to try hacking the driver to transmit EAPOL frames at the management rate, and then ensure the management rate is non-MCS. -a On 28 February 2014 15:14, Adrian Chadd adr...@freebsd.org wrote: Hi, the interesting bits: Feb 28 22:55:22 kernel: iwn_tx_data: qid 3 idx 3 len 129 nsegs 2 rate 0002 plcp 0x420a Feb 28 22:55:22 kernel: iwn_tx_data: qid 3 idx 4 len 129 nsegs 2 rate 0002 plcp 0x420a Feb 28 22:55:22 kernel: iwn5000_tx_done: qid 3 idx 3 retries 16 nkill 0 rate 80006902 duration 2815 status 83 Feb 28 22:55:22 kernel: iwn5000_tx_done: qid 3 idx 4 retries 16 nkill 0 rate 80006902 duration 2815 status 83 Feb 28 22:55:23 kernel: iwn_tx_data: qid 3 idx 5 len 129 nsegs 2 rate 0002 plcp 0x420a Feb 28 22:55:23 kernel: iwn_tx_data: qid 3 idx 6 len 129 nsegs 2 rate 0002 plcp 0x420a Feb 28 22:55:23 kernel: iwn5000_tx_done: qid 3 idx 5 retries 16 nkill 0 rate 80006902 duration 2815 status 83 Feb 28 22:55:23 kernel: iwn5000_tx_done: qid 3 idx 6 retries 16 nkill 0 rate 80006902 duration 2815 status 83 Feb 28 22:55:24 kernel: iwn_tx_data: qid 3 idx 7 len 129 nsegs 2 rate 0002 plcp 0x420a Feb 28 22:55:24 kernel: iwn_tx_data: qid 3 idx 8 len 129 nsegs 2 rate 0002 plcp 0x420a Feb 28 22:55:24 kernel: iwn5000_tx_done: qid 3 idx 7 retries 16 nkill 0 rate 80006902 duration 2815 status 83 Feb 28 22:55:24 kernel: iwn5000_tx_done: qid 3 idx 8 retries 16 nkill 0 rate 80006902 duration 2815 status 83 .. so it's failing to transmit the management frames after association - they're being transmitted at MCS0 and the AP is just plain not ACKing them. Now, I don't know why this is. It's trying to transmit the initial frame at non-MCS rates, but I have a feeling the multi-rate retry table thing is confusing it and it's trying to send it as MCS. So maybe the AP doesn't like management frames at MCS rates. I'll have to think about this a little. -a On 28 February 2014 15:07, Tom Murphy free...@pertho.net wrote: I've attached my iwn debug messages to this email starting with the point I tried to associate to the Wifi. Thanks again for looking at this! Kind regards, Tom On Thu, Feb 27, 2014 at 12:13:51PM -0800, Adrian Chadd wrote: On 26 February 2014 23:52, Alexandr shur...@shurik.kiev.ua wrote: Tom, could you: 1. compile kernel WITH_IWNDEBUG 2. sysctl dev.iwn.0.debug=0x1 3. wlandebug -i wlan0 auth+assoc 4. Associate with AP in 11n mode 5. Send us appropriate /var/log/messages Then I try to compare it with my log. Please do. I've been trying to track down the source of this ht just doesn't work! but it works fine with all of the Intel NICs I have here. Can someone see if they can find a mtaching NIC online (amazon,ebay?) Owning one that I can whack in a laptop is likely going ot help things a lot. Thanks, -a ___ 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
svn commits r264007-264011: disks missing
On 04/01/14 12:02, Ryan Stone wrote: Author: rstone Date: Tue Apr 1 16:02:02 2014 New Revision: 264011 URL: http://svnweb.freebsd.org/changeset/base/264011 Log: Add support for PCIe ARI With the changes between r264007-264011, my 4-port RocketRAID 640 card in JBOD mode just lost (?) 2 out of 4 disks. I disabled bhyve pci passthrough, tried looking for these disks with various tools, but no luck. There is no trace of them being available in dmesg, etc. I narrowed it down to that range of revisions, and going back to r264006 makes the disks show up again. - Nikolai Lifanov ___ 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: Call for testers: SNMPv3 support for bsnmpd(1)
Hi all, OK, I discovered and fixed several v3 bugs while testing this config. 1) A regresion introduced with SVN r256678 breaking parsing of v3 authentication part of a PDU - this is only in current; stable should be fine; I've uploaded a patch here - http://people.freebsd.org/~syrinx/snmp/libsnmp-v3-auth-20140403-01.diff 2) A bug in decoding string indexes in snmp_target(3), thus causing bsnmpd(1) to not send v3 notifications properly and two missing return statements which could lead to abort() in case of a rollback - this has never worked in the svn tree, I am not sure why the patch didn't make it - a patch is available here - http://people.freebsd.org/~syrinx/snmp/snmp_target-20140403-01.diff, it was generated against head, but should apply cleanly against stable too - to patch the module #cd #fetch http://people.freebsd.org/~syrinx/snmp/snmp_target-20140403-01.diff #cd sources-directory/contrib/bsnmp #patch snmp_target-20140403-01.diff #cd ../../usr.sbin/bsnmpd/modules/snmp_target/ #make make install 3) A problem with old SNMP engine time being returned to the client in some cases (relevant to v3 only again) which would cause subsequent PDUs comming from the same client to be considered out-of-time-window and discarded - patch is available here - http://people.freebsd.org/~syrinx/snmp/bsnmpd-engine-time-20140403-01.diff 4) There is also a problem with the handling of the connected UDP sockets - e.g. if the client listening for the trap has not been available for sometime, the socket error is not cleared until the first send() - causing snmpd[8573]: send: Connection refused messages in syslog even though the trap was successfully send - an old patch (pre-v3 sources) is available here - http://people.freebsd.org/~syrinx/snmp/bsnmp-20101220-03.diff, I'll update it against head too Comments, reviews and test reports are very welcome. Now, the needed configuration for encrypted traps - 1) bsnmpd(1) part #First v3 SNMP Engine value should be set, e.g. engine := 0x80:0x10:0x08:0x10:0x80:0x25 snmpEngineID = $(engine) #USM module should be enabled and at least one user with proper credentials created user1 := bsnmp user1passwd := 0x22:0x98:0x1a:0x6e:0x39:0x93:0x16:0x5e:0x6a:0x21:0x1b:0xd8:0xa9:0x81:0x31:0x05:0x16:0x33:0x38:0x60 # # SNMPv3 User-based security module - must be loaded for SNMPv3 USM # begemotSnmpdModulePath.usm= /usr/lib/snmp_usm.so # Definition of user bsnmp with password bsnmptest usmUserStatus.$(engine).$(user1) = 5 usmUserAuthProtocol.$(engine).$(user1) = $(HMACSHAAuthProtocol) usmUserAuthKeyChange.$(engine).$(user1) = $(user1passwd) usmUserPrivProtocol.$(engine).$(user1) = $(AesCfb128Protocol) usmUserPrivKeyChange.$(engine).$(user1) = $(user1passwd) usmUserStatus.$(engine).$(user1) = 1 #Definition of a Notification target where traps will be sent with the credentials of $user1 # # SNMPv3 Notification Targets module # begemotSnmpdModulePath.target= /usr/lib/snmp_target.so tag:= test snmpNotifyRowStatus.$(tag) = 4 snmpNotifyTag.$(tag) = $(tag) # # Specify the target parameters for the notifications - send with the credentials # of user $user1 # snmpTargetParamsRowStatus.$(tag) = 5 snmpTargetParamsMPModel.$(tag) = $(MPmodelSNMPv3) snmpTargetParamsSecurityModel.$(tag) = $(securityModelUSM) snmpTargetParamsSecurityName.$(tag) = $(user1) snmpTargetParamsSecurityLevel.$(tag) = $(authPriv) snmpTargetParamsRowStatus.$(tag) = 1 # # Define the notifications' target address - port 162 on localhost # snmpTargetAddrRowStatus.$(tag) = 5 snmpTargetAddrTAddress.$(tag) = 0x0a:0x0:0x0:0x01:0x0:0xa2 # hexstring representing 10.0.0.119 in 4 octets and port 162 in two octets snmpTargetAddrTagList.$(tag) = test notification snmpTargetAddrParams.$(tag) = $(tag) snmpTargetAddrRowStatus.$(tag) = 1 2) To receive the traps with net-snmp's snmptrapd put the following coonfiguration in /etc/snmp/snmptrapd.conf createUser -e 0x801008108025 bsnmp SHA bsnmptest AES bsnmptest authuser log bsnmp and start it e.g. #snmptrapd -f -C -c /etc/snmp/snmptrapd.conf -Le cheers, Shteryana On Tue, Apr 1, 2014 at 2:47 PM, Marciano, Anthony amarc...@redcom.com wrote: Thank Harti. Tony -Original Message- From: Hartmut Brandt [mailto:hartmut.bra...@dlr.de] Sent: Tuesday, April 01, 2014 2:06 AM To: Marciano, Anthony Cc: syr...@freebsd.org; Bjoern A. Zeeb; freebsd-current@freebsd.org; tomaro...@gmail.com Subject: RE: Call for testers: SNMPv3 support for bsnmpd(1) On Mon, 31 Mar 2014, Marciano, Anthony wrote: MACurrently, we are just looking to monitor standard objects such as MAinterfaces and send traps accordingly. Would it be possible to MAprovide a trap example of what needs to be added to the snmpd.config MAfile to monitor an object and have it sent via V3? MA MAI've searched for this information and read through various RFCs but MAhave not discovered any bsnmpd specific trap syntax and/or examples. Well, bsnmp can send only the standard traps currently
Re: another Make (maybe) problem
On Apr 2, 2014, at 9:47 PM, Robert Huff roberth...@rcn.com wrote:
Warner:
This will happen with fmake. I?ve put some safety belts in place in
another fix to keep this from tripping people up (and plan on using a
similar technique to keep people from hitting the aicasm bug on
such systems).
As long as make-related issues are on the table ...
I have a system, running
FreeBSD 11.0-CURRENT #0 r263263: Mon Mar 17 15:09:18 EDT 2014 amd64
where make buildworld fails. The immediate problem can be seen at:
http://users.rcn.com/roberthuff/bw_tail
the full log at
http://users.rcn.com/roberthuff/bwl.bz2
make.conf is appended. There is no src.conf.
I never seen anything like this before; nothing like has come across
current@ (recently); and nothing in src/UPDATING appears relevant.
Help, please?
Neither have I. That’s a weird issue.
amd64, I assume? Can you prune down your make.conf to find the minimal line(s)
that cause this?
Warner
Robert Huff
◙♪
make.conf
BDBCFLAGS+= -O -pipe
DEBUG_FLAGS+= -g
STRIP=
SYMVER_ENABLED= yes
X_WINDOW_SYSTEM= xorg
HAVE_MOTIF= yes
#FC=gfortran42
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=db6
WITH_BDB_VER=6
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
.if !empty(.CURDIR:M/usr/ports/graphics/libcdr)
exists(/usr/local/bin/gcc47)
CC=gcc47
CXX=g++47
CPP=cpp47
.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_GALLIUM=yes
WITH_BSD_SORT=
WITH_PKGNG=yes
___
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: gcc compilation broken with SVN r264042
On Apr 3, 2014, at 2:11 AM, David Chisnall thera...@freebsd.org wrote: On 3 Apr 2014, at 00:23, Warner Losh i...@bsdimp.com wrote: So less carping and more fixing is needed here. Should be fixed in r264069 - I'm sure Jenkins / Tinderbox will tell me if it isn't... libc now builds for me with gcc and clang. thanks David… I’d planned a universe run later today to test some of my changes, so this will help… 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
Re: gcc compilation broken with SVN r264042
On 3 Apr 2014, at 14:26, Warner Losh i...@bsdimp.com wrote: On Apr 3, 2014, at 2:11 AM, David Chisnall thera...@freebsd.org wrote: On 3 Apr 2014, at 00:23, Warner Losh i...@bsdimp.com wrote: So less carping and more fixing is needed here. Should be fixed in r264069 - I'm sure Jenkins / Tinderbox will tell me if it isn't... libc now builds for me with gcc and clang. thanks David… I’d planned a universe run later today to test some of my changes, so this will help… Let me know if you encounter any issues. I've built libc now with: - clang 3.4 (FreeBSD edition) - clang 3.4 (FreeBSD edition) -fblocks - gcc 4.2.1 FreeBSD edition - gcc 4.2.1 FreeBSD edition -fblocks - gcc 4.7.3 (from ports) All of these seem to work, and all produce a libc with _b functions that work with my clang-compiled test program. David ___ 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: gcc compilation broken with SVN r264042
On Apr 3, 2014, at 7:35 AM, David Chisnall thera...@freebsd.org wrote: On 3 Apr 2014, at 14:26, Warner Losh i...@bsdimp.com wrote: On Apr 3, 2014, at 2:11 AM, David Chisnall thera...@freebsd.org wrote: On 3 Apr 2014, at 00:23, Warner Losh i...@bsdimp.com wrote: So less carping and more fixing is needed here. Should be fixed in r264069 - I'm sure Jenkins / Tinderbox will tell me if it isn't... libc now builds for me with gcc and clang. thanks David… I’d planned a universe run later today to test some of my changes, so this will help… Let me know if you encounter any issues. I've built libc now with: - clang 3.4 (FreeBSD edition) - clang 3.4 (FreeBSD edition) -fblocks - gcc 4.2.1 FreeBSD edition - gcc 4.2.1 FreeBSD edition -fblocks - gcc 4.7.3 (from ports) All of these seem to work, and all produce a libc with _b functions that work with my clang-compiled test program. Cool. In the background, I’m also testing patches against gcc48 and gcc49 ports to allow them to compile FreeBSD, though I’m not through all the bootstrapping issues for cross builds… 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
Re: kevent has bug?
On Thu, Apr 03, 2014 at 06:26:56PM +0900, Kohji Okuno wrote: The done_ev_add case is indeed missed in my patch, thank you for noting. The case of EV_ADD does not need the KN_SCAN workaround, IMO, since the race is possible just by the nature of adding the knote. I think, we should add KN_SCAN after knote_attach() in kqueue_register(), too. What do you think about this? See above, I noted this case in the previous mail. This may be elaborated. First, I think it is technically incorrect to allow the event notification before the f_attach() method is finished. So the KN_SCAN flag could be set only after f_attach() call, but due to both kq and knlist not locked there, we still have the same race. And this race is in fact acceptable, since it is the race between application calling EV_ADD, and external event occuring, which cannot be avoided. Until the kevent(EV_ADD) syscall returned, we do not have an obligation to report the event from the kqfd. Having the race somewhat bigger by not setting KN_SCAN is fine in my opinion. pgp_eM3PUg0OL.pgp Description: PGP signature
Re: another Make (maybe) problem
Warner Losh wl...@bsdimp.com writes amd64, I assume? Yes, as per the provided uname. Can you prune down your make.conf to find the minimal line(s) that cause this? Yes, but each run will take about three hours Starting with an empty make.conf, 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: Call for testers: SNMPv3 support for bsnmpd(1)
Awesome! Thanks so much for all of your work. Much appreciated. Tony -Original Message- From: shtery...@gmail.com [mailto:shtery...@gmail.com] On Behalf Of Shteryana Shopova Sent: Thursday, April 03, 2014 9:09 AM To: Marciano, Anthony Cc: Hartmut Brandt; Bjoern A. Zeeb; freebsd-current@freebsd.org; tomaro...@gmail.com Subject: Re: Call for testers: SNMPv3 support for bsnmpd(1) Hi all, OK, I discovered and fixed several v3 bugs while testing this config. 1) A regresion introduced with SVN r256678 breaking parsing of v3 authentication part of a PDU - this is only in current; stable should be fine; I've uploaded a patch here - http://people.freebsd.org/~syrinx/snmp/libsnmp-v3-auth-20140403-01.diff 2) A bug in decoding string indexes in snmp_target(3), thus causing bsnmpd(1) to not send v3 notifications properly and two missing return statements which could lead to abort() in case of a rollback - this has never worked in the svn tree, I am not sure why the patch didn't make it - a patch is available here - http://people.freebsd.org/~syrinx/snmp/snmp_target-20140403-01.diff, it was generated against head, but should apply cleanly against stable too - to patch the module #cd #fetch http://people.freebsd.org/~syrinx/snmp/snmp_target-20140403-01.diff #cd sources-directory/contrib/bsnmp #patch snmp_target-20140403-01.diff #cd ../../usr.sbin/bsnmpd/modules/snmp_target/ #make make install 3) A problem with old SNMP engine time being returned to the client in some cases (relevant to v3 only again) which would cause subsequent PDUs comming from the same client to be considered out-of-time-window and discarded - patch is available here - http://people.freebsd.org/~syrinx/snmp/bsnmpd-engine-time-20140403-01.diff 4) There is also a problem with the handling of the connected UDP sockets - e.g. if the client listening for the trap has not been available for sometime, the socket error is not cleared until the first send() - causing snmpd[8573]: send: Connection refused messages in syslog even though the trap was successfully send - an old patch (pre-v3 sources) is available here - http://people.freebsd.org/~syrinx/snmp/bsnmp-20101220-03.diff, I'll update it against head too Comments, reviews and test reports are very welcome. Now, the needed configuration for encrypted traps - 1) bsnmpd(1) part #First v3 SNMP Engine value should be set, e.g. engine := 0x80:0x10:0x08:0x10:0x80:0x25 snmpEngineID = $(engine) #USM module should be enabled and at least one user with proper credentials created user1 := bsnmp user1passwd := 0x22:0x98:0x1a:0x6e:0x39:0x93:0x16:0x5e:0x6a:0x21:0x1b:0xd8:0xa9:0x81:0x31:0x05:0x16:0x33:0x38:0x60 # # SNMPv3 User-based security module - must be loaded for SNMPv3 USM # begemotSnmpdModulePath.usm= /usr/lib/snmp_usm.so # Definition of user bsnmp with password bsnmptest usmUserStatus.$(engine).$(user1) = 5 usmUserAuthProtocol.$(engine).$(user1) = $(HMACSHAAuthProtocol) usmUserAuthKeyChange.$(engine).$(user1) = $(user1passwd) usmUserPrivProtocol.$(engine).$(user1) = $(AesCfb128Protocol) usmUserPrivKeyChange.$(engine).$(user1) = $(user1passwd) usmUserStatus.$(engine).$(user1) = 1 #Definition of a Notification target where traps will be sent with the credentials of $user1 # # SNMPv3 Notification Targets module # begemotSnmpdModulePath.target= /usr/lib/snmp_target.so tag:= test snmpNotifyRowStatus.$(tag) = 4 snmpNotifyTag.$(tag) = $(tag) # # Specify the target parameters for the notifications - send with the credentials # of user $user1 # snmpTargetParamsRowStatus.$(tag) = 5 snmpTargetParamsMPModel.$(tag) = $(MPmodelSNMPv3) snmpTargetParamsSecurityModel.$(tag) = $(securityModelUSM) snmpTargetParamsSecurityName.$(tag) = $(user1) snmpTargetParamsSecurityLevel.$(tag) = $(authPriv) snmpTargetParamsRowStatus.$(tag) = 1 # # Define the notifications' target address - port 162 on localhost # snmpTargetAddrRowStatus.$(tag) = 5 snmpTargetAddrTAddress.$(tag) = 0x0a:0x0:0x0:0x01:0x0:0xa2 # hexstring representing 10.0.0.119 in 4 octets and port 162 in two octets snmpTargetAddrTagList.$(tag) = test notification snmpTargetAddrParams.$(tag) = $(tag) snmpTargetAddrRowStatus.$(tag) = 1 2) To receive the traps with net-snmp's snmptrapd put the following coonfiguration in /etc/snmp/snmptrapd.conf createUser -e 0x801008108025 bsnmp SHA bsnmptest AES bsnmptest authuser log bsnmp and start it e.g. #snmptrapd -f -C -c /etc/snmp/snmptrapd.conf -Le cheers, Shteryana On Tue, Apr 1, 2014 at 2:47 PM, Marciano, Anthony amarc...@redcom.com wrote: Thank Harti. Tony -Original Message- From: Hartmut Brandt [mailto:hartmut.bra...@dlr.de] Sent: Tuesday, April 01, 2014 2:06 AM To: Marciano, Anthony Cc: syr...@freebsd.org; Bjoern A. Zeeb; freebsd-current@freebsd.org; tomaro...@gmail.com Subject: RE: Call for testers: SNMPv3 support for bsnmpd(1) On Mon, 31 Mar 2014, Marciano, Anthony wrote: MACurrently, we are just looking to monitor standard objects
Boot fails @r264070
Building/installing is fine, and building, installing, and booting stable/9 @r264061 on the same hardware (different slice) is fine. (I didn't rebuild stable/10 this morning, asth only change was to src/cddl/contrib/opensolaris/cmd/zpool/zpool_main.c, and I don't use ZFS. stable/10 works fine on the same hardware @r264032.) And on my laptop, I had no problems (using AHCI). The build machine, though, starts OK, then comes to an inglorious end: Booting... GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2014 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #1455 r264070M/264070:1100016: Thu Apr 3 07:48:16 PDT 2014 r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC i386 FreeBSD clang version 3.4 (tags/RELEASE_34/final 197956) 20140216 WARNING: WITNESS option enabled, expect reduced performance. CPU: Intel(R) Xeon(TM) CPU 3.60GHz (3600.21-MHz 686-class CPU) Origin=GenuineIntel Id=0xf41 Family=0xf Model=0x4 Stepping=1 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x659dSSE3,DTES64,MON,DS_CPL,EST,TM2,CNXT-ID,CX16,xTPR AMD Features=0x2010NX,LM TSC: P-state invariant real memory = 2147483648 (2048 MB) avail memory = 2080395264 (1984 MB) Event timer LAPIC quality 400 ACPI APIC Table: PTLTD APIC FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 2 package(s) x 1 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 6 random device not loaded; using insecure entropy ioapic0 Version 2.0 irqs 0-23 on motherboard ioapic1 Version 2.0 irqs 24-47 on motherboard ioapic2 Version 2.0 irqs 48-71 on motherboard random: Software, Yarrow initialized kbd1 at kbdmux0 acpi0: PTLTD RSDT on motherboard acpi0: Power Button (fixed) cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 atrtc0: AT realtime clock port 0x70-0x77 irq 8 on acpi0 Event timer RTC frequency 32768 Hz quality 0 attimer0: AT timer port 0x40-0x43 irq 0 on acpi0 Timecounter i8254 frequency 1193182 Hz quality 0 Event timer i8254 frequency 1193182 Hz quality 100 Timecounter ACPI-fast frequency 3579545 Hz quality 900 acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pci0: unknown at device 0.1 (no driver attached) pci0: base peripheral at device 1.0 (no driver attached) pcib1: ACPI PCI-PCI bridge irq 16 at device 2.0 on pci0 pci1: ACPI PCI bus on pcib1 pcib2: ACPI PCI-PCI bridge at device 0.0 on pci1 pci2: ACPI PCI bus on pcib2 pcib3: ACPI PCI-PCI bridge at device 0.2 on pci1 pci3: ACPI PCI bus on pcib3 em0: Intel(R) PRO/1000 Legacy Network Connection 1.0.6 port 0x2040-0x207f mem 0xd822-0xd823 irq 55 at device 2.1 on pci3 em0: Ethernet address: 00:30:48:2d:32:6b pcib4: ACPI PCI-PCI bridge irq 16 at device 4.0 on pci0 pci4: ACPI PCI bus on pcib4 pcib5: ACPI PCI-PCI bridge irq 16 at device 6.0 on pci0 pci5: ACPI PCI bus on pcib5 uhci0: Intel 82801EB (ICH5) USB controller USB-A port 0x1400-0x141f irq 16 at device 29.0 on pci0 usbus0 on uhci0 uhci1: Intel 82801EB (ICH5) USB controller USB-B port 0x1420-0x143f irq 19 at device 29.1 on pci0 usbus1 on uhci1 uhci2: Intel 82801EB (ICH5) USB controller USB-C port 0x1440-0x145f irq 18 at device 29.2 on pci0 usbus2 on uhci2 uhci3: Intel 82801EB (ICH5) USB controller USB-D port 0x1460-0x147f irq 16 at device 29.3 on pci0 usbus3 on uhci3 ehci0: Intel 82801EB/R (ICH5) USB 2.0 controller mem 0xd8001000-0xd80013ff irq 23 at device 29.7 on pci0 usbus4: EHCI version 1.0 usbus4 on ehci0 pcib6: ACPI PCI-PCI bridge at device 30.0 on pci0 pci6: ACPI PCI bus on pcib6 isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel ICH5 UDMA100 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x14a0-0x14af at device 31.1 on pci0 ata0: ATA channel at channel 0 on atapci0 ata1: ATA channel at channel 1 on atapci0 pci0: serial bus, SMBus at device 31.3 (no driver attached) acpi_button0: Power Button on acpi0 atkbdc0: Keyboard controller (i8042) port 0x60,0x64 irq 1 on acpi0 atkbd0: AT Keyboard irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0 uart0: 16550 or compatible port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: console (9600,n,8,1) uart1: 16550 or compatible port 0x2f8-0x2ff irq 3 on acpi0 fdc0: floppy drive controller port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fd0: 1440-KB 3.5 drive on fdc0 drive 0 pmtimer0 on isa0 orm0: ISA Option ROMs at iomem 0xc-0xc7fff,0xc8000-0xc8fff,0xc9000-0xc9fff,0xca000-0xcafff,0xcb000-0xcf7ff pnpid ORM on isa0 sc0: System console at flags 0x100
Re: Boot fails @r264070
On Thu, 3 Apr 2014, David Wolfskill wrote: And on my laptop, I had no problems (using AHCI). The build machine, though, starts OK, then comes to an inglorious end: Trying to mount root from ufs:/dev/aacd0s4a [rw]... mountroot: waiting for device /dev/aacd0s4a ... Mounting from ufs:/dev/aacd0s4a failed with error 19. [...] mountroot So... I have serial console access; is there any debugging I might do to help figure out what's wrong? Or is what's wrong already known? I have been able to reboot from this point to one of the other slices; I could probably also unload the default kernel load yesterday's (err... make that the day before's -- yesterday's didn't build -- @r263983). I'm also having some trouble booting (into single user mode, so as to run the installworld), at r264039. It seems that ciss never attaches, so my da0 (which is supposed to be on ciss0) does not appear. My kernel.old is much older, __FreeBSD_version 115, but does boot. However, attempting to boot kernel.old in either single-user mode or verbse mode also drops me to mountroot . That would seem to indicate some hardware problem or timing issues more than a problem with the code itself, so I had been holding off on posting until I could get more information. Unfortunately, my serial console is not working at the moment, so getting more information is a bit challenging. Diffing the dmesg from the good and bad boots would probably be helpful for you to do. -Ben ___ 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: Boot fails @r264070
On 04/03/14 12:06, Benjamin Kaduk wrote: On Thu, 3 Apr 2014, David Wolfskill wrote: And on my laptop, I had no problems (using AHCI). The build machine, though, starts OK, then comes to an inglorious end: Trying to mount root from ufs:/dev/aacd0s4a [rw]... mountroot: waiting for device /dev/aacd0s4a ... Mounting from ufs:/dev/aacd0s4a failed with error 19. [...] mountroot So... I have serial console access; is there any debugging I might do to help figure out what's wrong? Or is what's wrong already known? I have been able to reboot from this point to one of the other slices; I could probably also unload the default kernel load yesterday's (err... make that the day before's -- yesterday's didn't build -- @r263983). I'm also having some trouble booting (into single user mode, so as to run the installworld), at r264039. It seems that ciss never attaches, so my da0 (which is supposed to be on ciss0) does not appear. My kernel.old is much older, __FreeBSD_version 115, but does boot. However, attempting to boot kernel.old in either single-user mode or verbse mode also drops me to mountroot . That would seem to indicate some hardware problem or timing issues more than a problem with the code itself, so I had been holding off on posting until I could get more information. Unfortunately, my serial console is not working at the moment, so getting more information is a bit challenging. Diffing the dmesg from the good and bad boots would probably be helpful for you to do. -Ben I reported a similar problem on freebsd-current@ earlier today. Fortunately, my boot zpool is still fine, but a RocketRAID controller only shows 2/4 disks, which just happens to be a full leg of another raid10-like zpool. Try reverting revisions r264007-264013. This fixes the problem for me. - Nikolai Lifanov ___ 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 commits r264007-264011: disks missing
On 04/03/14 08:58, Nikolai Lifanov wrote: On 04/01/14 12:02, Ryan Stone wrote: Author: rstone Date: Tue Apr 1 16:02:02 2014 New Revision: 264011 URL: http://svnweb.freebsd.org/changeset/base/264011 Log: Add support for PCIe ARI With the changes between r264007-264011, my 4-port RocketRAID 640 card in JBOD mode just lost (?) 2 out of 4 disks. I disabled bhyve pci passthrough, tried looking for these disks with various tools, but no luck. There is no trace of them being available in dmesg, etc. I narrowed it down to that range of revisions, and going back to r264006 makes the disks show up again. - Nikolai Lifanov I updated to r264073 with revisions r264007-264013 reverted, and all my disks show up. Could you look into this please? I'll provide any information that can be helpful. - Nikolai Lifanov ___ 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: Boot fails @r264070
On Thu, Apr 03, 2014 at 12:06:51PM -0400, Benjamin Kaduk wrote: ... I'm also having some trouble booting (into single user mode, so as to run the installworld), at r264039 Sympathy That would seem to indicate some hardware problem or timing issues more than a problem with the code itself, Maybe so I had been holding off on posting until I could get more information. Fair enough. Unfortunately, my serial console is not working at the moment, so getting more information is a bit challenging. Diffing the dmesg from the good and bad boots would probably be helpful for you to do. OK; here it is. I was able to boot from the last-built kernel (01 Apr): --- ok 2014-04-03 09:12:45.0 -0700 +++ fail2014-04-03 09:13:16.0 -0700 @@ -6,11 +6,11 @@ Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. -FreeBSD 11.0-CURRENT #1453 r263983M/263984:1100016: Tue Apr 1 08:09:27 PDT 2014 +FreeBSD 11.0-CURRENT #1455 r264070M/264070:1100016: Thu Apr 3 07:48:16 PDT 2014 r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC i386 FreeBSD clang version 3.4 (tags/RELEASE_34/final 197956) 20140216 WARNING: WITNESS option enabled, expect reduced performance. -CPU: Intel(R) Xeon(TM) CPU 3.60GHz (3600.20-MHz 686-class CPU) +CPU: Intel(R) Xeon(TM) CPU 3.60GHz (3600.21-MHz 686-class CPU) Origin=GenuineIntel Id=0xf41 Family=0xf Model=0x4 Stepping=1 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x659dSSE3,DTES64,MON,DS_CPL,EST,TM2,CNXT-ID,CX16,xTPR @@ -49,18 +49,10 @@ pci1: ACPI PCI bus on pcib1 pcib2: ACPI PCI-PCI bridge at device 0.0 on pci1 pci2: ACPI PCI bus on pcib2 -aac0: Adaptec SCSI RAID 2200S mem 0xdc00-0xdfff irq 24 at device 1.0 on pci2 -aac0: Enable Raw I/O -aac0: New comm. interface enabled -aac0: Adaptec 2200S, aac driver 2.1.9-1 -aacp0 on aac0 -aacp1 on aac0 pcib3: ACPI PCI-PCI bridge at device 0.2 on pci1 pci3: ACPI PCI bus on pcib3 -em0: Intel(R) PRO/1000 Legacy Network Connection 1.0.6 port 0x2000-0x203f mem 0xd820-0xd821 irq 54 at device 2.0 on pci3 -em0: Ethernet address: 00:30:48:2d:32:6a -em1: Intel(R) PRO/1000 Legacy Network Connection 1.0.6 port 0x2040-0x207f mem 0xd822-0xd823 irq 55 at device 2.1 on pci3 -em1: Ethernet address: 00:30:48:2d:32:6b +em0: Intel(R) PRO/1000 Legacy Network Connection 1.0.6 port 0x2040-0x207f mem 0xd822-0xd823 irq 55 at device 2.1 on pci3 +em0: Ethernet address: 00:30:48:2d:32:6b pcib4: ACPI PCI-PCI bridge irq 16 at device 4.0 on pci0 pci4: ACPI PCI bus on pcib4 pcib5: ACPI PCI-PCI bridge irq 16 at device 6.0 on pci0 @@ -78,8 +70,6 @@ usbus4 on ehci0 pcib6: ACPI PCI-PCI bridge at device 30.0 on pci0 pci6: ACPI PCI bus on pcib6 -vgapci0: VGA-compatible display port 0x3000-0x30ff mem 0xd900-0xd9ff,0xd830-0xd8300fff irq 17 at device 1.0 on pci6 -vgapci0: Boot video device isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel ICH5 UDMA100 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x14a0-0x14af at device 31.1 on pci0 @@ -110,10 +100,6 @@ p4tcc0: CPU Frequency Thermal Control on cpu0 p4tcc1: CPU Frequency Thermal Control on cpu1 Timecounters tick every 1.000 msec -aacd0 on aac0 -aacd0: 34970MB (71619584 sectors) -aacd1 on aac0 -aacd1: 69974MB (143307008 sectors) random: unblocking device. usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 @@ -132,59 +118,45 @@ uhub4: Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 on usbus4 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered -uhub2: 2 ports with 2 removable, self powered ata1: DMA limited to UDMA33, controller found non-ATA66 cable +cd0 at ata1 bus 0 scbus1 target 1 lun 0 uhub3: 2 ports with 2 removable, self powered -uhub4: 8 ports with 8 removable, self powered -ses0 at aacp0 bus 0 scbus0 target 6 lun 0 -ses0: SUPER GEM318 0 Fixed Uninstalled SCSI-2 device -ses0: 3.300MB/s transfers -ses0: SAF-TE Compliant Device -pass0 at aacp0 bus 0 scbus0 target 0 lun 0 -pass0: cd0 at ata1 bus 0 scbus3 target 1 lun 0 +uhub2: 2 ports with 2 removable, self powered cd0: MATSHITA DVD-ROM SR-8178 PZ16 Removable CD-ROM SCSI-0 device -cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) -cd0: Attempt to query device size failed: NOT READY, Medium not present -SEAGATE ST336754LC 0003 Fixed Uninstalled SCSI-3 device -pass0: 0KB/s transfers -pass1 at aacp0 bus 0 scbus0 target 1 lun 0 -pass1: SEAGATE ST336754LC 0003 Fixed Uninstalled SCSI-3 device -pass1: 0KB/s transfers -pass2 at aacp0 bus 0 scbus0 target 2 lun 0 -pass2: SEAGATE ST373454LC 0005 Fixed Uninstalled SCSI-3 device -pass2: 0KB/s transfers -pass3 at aacp0
Re: svn commits r264007-264011: disks missing
On Thu, Apr 03, 2014 at 12:17:13PM -0400, Nikolai Lifanov wrote: On 04/03/14 08:58, Nikolai Lifanov wrote: On 04/01/14 12:02, Ryan Stone wrote: Author: rstone Date: Tue Apr 1 16:02:02 2014 New Revision: 264011 URL: http://svnweb.freebsd.org/changeset/base/264011 Log: Add support for PCIe ARI With the changes between r264007-264011, my 4-port RocketRAID 640 card in JBOD mode just lost (?) 2 out of 4 disks. I disabled bhyve pci passthrough, tried looking for these disks with various tools, but no luck. There is no trace of them being available in dmesg, etc. I narrowed it down to that range of revisions, and going back to r264006 makes the disks show up again. - Nikolai Lifanov I updated to r264073 with revisions r264007-264013 reverted, and all my disks show up. Could you look into this please? I'll provide any information that can be helpful. I think verbose dmesg from failing and running kernel should be good for the start. pgpgyzpADcs9r.pgp Description: PGP signature
Re: Boot fails @r264070
On Thu, 3 Apr 2014, David Wolfskill wrote: -em0: Intel(R) PRO/1000 Legacy Network Connection 1.0.6 port 0x2000-0x203f mem 0xd820-0xd821 irq 54 at device 2.0 on pci3 -em0: Ethernet address: 00:30:48:2d:32:6a -em1: Intel(R) PRO/1000 Legacy Network Connection 1.0.6 port 0x2040-0x207f mem 0xd822-0xd823 irq 55 at device 2.1 on pci3 -em1: Ethernet address: 00:30:48:2d:32:6b +em0: Intel(R) PRO/1000 Legacy Network Connection 1.0.6 port 0x2040-0x207f mem 0xd822-0xd823 irq 55 at device 2.1 on pci3 +em0: Ethernet address: 00:30:48:2d:32:6b I should also note that I lost my bge1 with the bad kernel, as well. The part: pci2: ACPI PCI bus on pcib2 -aac0: Adaptec SCSI RAID 2200S mem 0xdc00-0xdfff irq 24 at device 1.0 on pci2 -aac0: Enable Raw I/O -aac0: New comm. interface enabled -aac0: Adaptec 2200S, aac driver 2.1.9-1 -aacp0 on aac0 -aacp1 on aac0 pcib3: ACPI PCI-PCI bridge at device 0.2 on pci1 looks a tad suspicious to me. Indeed. Also, thanks to Nikolai for pointing out his experiences; I will try reverting those revisions and rebuilding. -Ben ___ 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 commits r264007-264011: disks missing
On Thu, Apr 03, 2014 at 07:23:57PM +0300, Konstantin Belousov wrote: ... I think verbose dmesg from failing and running kernel should be good for the start. http://www.catwhisker.org/~david/FreeBSD/r264070/ contains: [TXT] boot_diff.txt 03-Apr-2014 09:55 15K [TXT] boot_fail.txt 03-Apr-2014 09:55 40K [TXT] boot_ok.txt 03-Apr-2014 09:55 44K Here's a copy of the diff: --- ok 2014-04-03 09:48:33.0 -0700 +++ fail2014-04-03 09:53:14.0 -0700 @@ -1,7 +1,4 @@ Type '?' for a list of commands, 'help' for more detailed help. -OK unload -OK load /boot/kernel.old/kernel -/boot/kernel.old/kernel text=0xf2ed81 data=0xd30f0+0x3843f0 syms=[0x4+0xd8c40+0x4+0x15fc28] OK boot -v -s Booting... GDB: no debug ports present @@ -32,12 +29,12 @@ Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. -FreeBSD 11.0-CURRENT #1453 r263983M/263984:1100016: Tue Apr 1 08:09:27 PDT 2014 +FreeBSD 11.0-CURRENT #1455 r264070M/264070:1100016: Thu Apr 3 07:48:16 PDT 2014 r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC i386 FreeBSD clang version 3.4 (tags/RELEASE_34/final 197956) 20140216 WARNING: WITNESS option enabled, expect reduced performance. -Preloaded elf kernel /boot/kernel.old/kernel at 0xc19c. -Calibrating TSC clock ... TSC clock: 3600201519 Hz +Preloaded elf kernel /boot/kernel/kernel at 0xc19c2000. +Calibrating TSC clock ... TSC clock: 3600202176 Hz CPU: Intel(R) Xeon(TM) CPU 3.60GHz (3600.20-MHz 686-class CPU) Origin=GenuineIntel Id=0xf41 Family=0xf Model=0x4 Stepping=1 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE @@ -449,27 +446,6 @@ pci2: ACPI PCI bus on pcib2 pcib2: allocated bus range (2-2) for rid 0 of pci2 pci2: domain=0, physical bus=2 -found- vendor=0x9005, dev=0x0285, revid=0x01 -domain=0, bus=2, slot=1, func=0 -class=01-04-00, hdrtype=0x00, mfdev=0 -cmdreg=0x0316, statreg=0x04b0, cachelnsz=8 (dwords) -lattimer=0x20 (960 ns), mingnt=0x01 (250 ns), maxlat=0x01 (250 ns) -intpin=a, irq=5 -powerspec 2 supports D0 D3 current D0 -map[10]: type Prefetchable Memory, range 32, base 0xdc00, size 26, enabled -pcib2: allocated prefetch range (0xdc00-0xdfff) for rid 10 of pci0:2:1:0 -pcib2: matched entry for 2.1.INTA -pcib2: slot 1 INTA hardwired to IRQ 24 -aac0: Adaptec SCSI RAID 2200S mem 0xdc00-0xdfff irq 24 at device 1.0 on pci2 -aac0: Enable Raw I/O -aac0: New comm. interface enabled -ioapic1: routing intpin 0 (PCI IRQ 24) to lapic 0 vector 51 -aac0: i960 80303 100MHz, 64MB memory (48MB cache, 16MB execution), optional battery present -aac0: Kernel 4.2-0, Build 7349, S/N BAD0 -aac0: Supported Options=31d7eCLUSTERS,WCACHE,DATA64,HOSTTIME,RAID50,WINDOW4GB,SOFTERR,SGMAP64,ALARM,NONDASD,ADPTINFO,NEWCOMM -aac0: Adaptec 2200S, aac driver 2.1.9-1 -aacp0 on aac0 -aacp1 on aac0 pcib3: ACPI PCI-PCI bridge at device 0.2 on pci1 pcib3: allocating non-ISA range 0x2000-0x20ff pcib1: allocated I/O port range (0x2000-0x20ff) for rid 1c of pcib3 @@ -490,20 +466,6 @@ pcib3: allocated bus range (3-3) for rid 0 of pci3 pci3: domain=0, physical bus=3 found- vendor=0x8086, dev=0x1079, revid=0x03 -domain=0, bus=3, slot=2, func=0 -class=02-00-00, hdrtype=0x00, mfdev=1 -cmdreg=0x0117, statreg=0x0230, cachelnsz=8 (dwords) -lattimer=0x40 (1920 ns), mingnt=0xff (63750 ns), maxlat=0x00 (0 ns) -intpin=a, irq=7 -powerspec 2 supports D0 D3 current D0 -MSI supports 1 message, 64 bit -map[10]: type Memory, range 64, base 0xd820, size 17, enabled -pcib3: allocated memory range (0xd820-0xd821) for rid 10 of pci0:3:2:0 -map[20]: type I/O Port, range 32, base 0x2000, size 6, enabled -pcib3: allocated I/O port range (0x2000-0x203f) for rid 20 of pci0:3:2:0 -pcib3: matched entry for 3.2.INTA -pcib3: slot 2 INTA hardwired to IRQ 54 -found- vendor=0x8086, dev=0x1079, revid=0x03 domain=0, bus=3, slot=2, func=1 class=02-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0117, statreg=0x0230, cachelnsz=8 (dwords) @@ -517,14 +479,10 @@ pcib3: allocated I/O port range (0x2040-0x207f) for rid 20 of pci0:3:2:1 pcib3: matched entry for 3.2.INTB pcib3: slot 2 INTB hardwired to IRQ 55 -em0: Intel(R) PRO/1000 Legacy Network Connection 1.0.6 port 0x2000-0x203f mem 0xd820-0xd821 irq 54 at device 2.0 on pci3 -ioapic2: routing intpin 6 (PCI IRQ 54) to lapic 0 vector 52 +em0: Intel(R) PRO/1000 Legacy Network Connection 1.0.6 port 0x2040-0x207f mem 0xd822-0xd823 irq 55 at device 2.1 on pci3 +ioapic2: routing intpin 7 (PCI IRQ 55) to lapic 0 vector 51 em0: bpf attached -em0: Ethernet address:
Re: svn commits r264007-264011: disks missing
On 2014-04-03 12:23, Konstantin Belousov wrote: On Thu, Apr 03, 2014 at 12:17:13PM -0400, Nikolai Lifanov wrote: On 04/03/14 08:58, Nikolai Lifanov wrote: On 04/01/14 12:02, Ryan Stone wrote: Author: rstone Date: Tue Apr 1 16:02:02 2014 New Revision: 264011 URL: http://svnweb.freebsd.org/changeset/base/264011 Log: Add support for PCIe ARI With the changes between r264007-264011, my 4-port RocketRAID 640 card in JBOD mode just lost (?) 2 out of 4 disks. I disabled bhyve pci passthrough, tried looking for these disks with various tools, but no luck. There is no trace of them being available in dmesg, etc. I narrowed it down to that range of revisions, and going back to r264006 makes the disks show up again. - Nikolai Lifanov I updated to r264073 with revisions r264007-264013 reverted, and all my disks show up. Could you look into this please? I'll provide any information that can be helpful. I think verbose dmesg from failing and running kernel should be good for the start. Sure, here! http://lifanov.com/files/freebsd/bugs/dmesg.broken.txt http://lifanov.com/files/freebsd/bugs/dmesg.working.txt - Nikolai Lifanov ___ 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: another Make (maybe) problem
Warner Losh wl...@bsdimp.com writes Can you prune down your make.conf to find the minimal line(s) that cause this? Yes, but each run will take about three hours Starting with an empty make.conf, Empty make.conf = same result. Where do I look next? 1) I know very little about make, but I have seen additional debugging options in the man page. Are there any particular ones which are likely to be helpful? 2) Is there a way to just re-try the affected part of buildworld? Thanks, 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: Boot fails @r264070
Can somebody please confirm whether setting hw.pci.enable_ari=0 in the loader fixes the issue or not. That will help me to figure out if the issue is with ARI or if I have somehow broken PCI enumeration in general (I suspect the later). ___ 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: Boot fails @r264070
On 04/03/14 14:05, Ryan Stone wrote: Can somebody please confirm whether setting hw.pci.enable_ari=0 in the loader fixes the issue or not. That will help me to figure out if the issue is with ARI or if I have somehow broken PCI enumeration in general (I suspect the later). __ I already tried it. I can confirm that it does not help. - Nikolai Lifanov ___ 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: Boot fails @r264070
On 04/03/14 14:25, Nikolai Lifanov wrote: On 04/03/14 14:05, Ryan Stone wrote: Can somebody please confirm whether setting hw.pci.enable_ari=0 in the loader fixes the issue or not. That will help me to figure out if the issue is with ARI or if I have somehow broken PCI enumeration in general (I suspect the later). __ I already tried it. I can confirm that it does not help. - Nikolai Lifanov In fact, here is what it looks like: the disk discovery skips the first 2 and enumerates the rest. Thankfully, this isn't my boot pool and rebooting without ARI changes discovers every disk and imports it correctly. $ sysctl hw.pci.enable_ari hw.pci.enable_ari: 0 $ zpool status data pool: data state: UNAVAIL status: One or more devices could not be opened. There are insufficient replicas for the pool to continue functioning. action: Attach the missing device and online it using 'zpool online'. see: http://illumos.org/msg/ZFS-8000-3C scan: none requested config: NAME STATE READ WRITE CKSUM data UNAVAIL 0 0 0 mirror-0 UNAVAIL 0 0 0 820204606399244410 UNAVAIL 0 0 0 was /dev/ada0 7129954888383586426 UNAVAIL 0 0 0 was /dev/ada1 mirror-1 ONLINE 0 0 0 ada0 ONLINE 0 0 0 ada1 ONLINE 0 0 0 - Nikolai Lifanov ___ 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
Bad judgement using chflags
I thought I could clear the .svn directory using chflag -R noschg /usr/src/.svn/* and.. I screwed up my system for svn checkout of CURRENT. Live and learn. Anyway, how do I fix this? Thanks ___ 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: Bad judgement using chflags
chflags 0 will remove the flags ---Mike On 4/3/2014 4:52 PM, Joe Nosay wrote: I thought I could clear the .svn directory using chflag -R noschg /usr/src/.svn/* and.. I screwed up my system for svn checkout of CURRENT. Live and learn. Anyway, how do I fix this? Thanks ___ 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 -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: svn commits r264007-264011: disks missing
This is fixed in r264091. Apologies for the breakage; it seems to mostly effect legacy PCI devices and my testing was on PCIe-only systems. Thanks to everyone who reported the issue and provided verbose dmesgs; that really helped me to understand the problem. ___ 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: kevent has bug?
From: Konstantin Belousov kostik...@gmail.com Date: Thu, 3 Apr 2014 16:48:14 +0300 On Thu, Apr 03, 2014 at 06:26:56PM +0900, Kohji Okuno wrote: The done_ev_add case is indeed missed in my patch, thank you for noting. The case of EV_ADD does not need the KN_SCAN workaround, IMO, since the race is possible just by the nature of adding the knote. I think, we should add KN_SCAN after knote_attach() in kqueue_register(), too. What do you think about this? See above, I noted this case in the previous mail. This may be elaborated. First, I think it is technically incorrect to allow the event notification before the f_attach() method is finished. So the KN_SCAN flag could be set only after f_attach() call, but due to both kq and knlist not locked there, we still have the same race. And this race is in fact acceptable, since it is the race between application calling EV_ADD, and external event occuring, which cannot be avoided. Until the kevent(EV_ADD) syscall returned, we do not have an obligation to report the event from the kqfd. Having the race somewhat bigger by not setting KN_SCAN is fine in my opinion. Hi, Thank you for your detailed commnet. And I uderstood about your opinion. By the way, do you commit your change to HEAD? Regards, Kohji Okuno ___ 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: iwn(4) in -HEAD supporting Centrino Wireless-N 135
I've had no time to continue looking at this, I'm sorry. I'm very overworked and I'm not able to be both the net80211, ath and iwn maintainer given how much actual attention they all require. Someone has to step up and take command of the iwn code. -a On 3 April 2014 03:02, Tom Murphy free...@pertho.net wrote: Hi, I'm just wondering if you had any time to look at this? I'm happy to test any patches or diffs. Regards, Tom On Tue, Mar 11, 2014 at 11:03:20AM -0700, Adrian Chadd wrote: I still don't have any ideas here. I do however want to try hacking the driver to transmit EAPOL frames at the management rate, and then ensure the management rate is non-MCS. -a On 28 February 2014 15:14, Adrian Chadd adr...@freebsd.org wrote: Hi, the interesting bits: Feb 28 22:55:22 kernel: iwn_tx_data: qid 3 idx 3 len 129 nsegs 2 rate 0002 plcp 0x420a Feb 28 22:55:22 kernel: iwn_tx_data: qid 3 idx 4 len 129 nsegs 2 rate 0002 plcp 0x420a Feb 28 22:55:22 kernel: iwn5000_tx_done: qid 3 idx 3 retries 16 nkill 0 rate 80006902 duration 2815 status 83 Feb 28 22:55:22 kernel: iwn5000_tx_done: qid 3 idx 4 retries 16 nkill 0 rate 80006902 duration 2815 status 83 Feb 28 22:55:23 kernel: iwn_tx_data: qid 3 idx 5 len 129 nsegs 2 rate 0002 plcp 0x420a Feb 28 22:55:23 kernel: iwn_tx_data: qid 3 idx 6 len 129 nsegs 2 rate 0002 plcp 0x420a Feb 28 22:55:23 kernel: iwn5000_tx_done: qid 3 idx 5 retries 16 nkill 0 rate 80006902 duration 2815 status 83 Feb 28 22:55:23 kernel: iwn5000_tx_done: qid 3 idx 6 retries 16 nkill 0 rate 80006902 duration 2815 status 83 Feb 28 22:55:24 kernel: iwn_tx_data: qid 3 idx 7 len 129 nsegs 2 rate 0002 plcp 0x420a Feb 28 22:55:24 kernel: iwn_tx_data: qid 3 idx 8 len 129 nsegs 2 rate 0002 plcp 0x420a Feb 28 22:55:24 kernel: iwn5000_tx_done: qid 3 idx 7 retries 16 nkill 0 rate 80006902 duration 2815 status 83 Feb 28 22:55:24 kernel: iwn5000_tx_done: qid 3 idx 8 retries 16 nkill 0 rate 80006902 duration 2815 status 83 .. so it's failing to transmit the management frames after association - they're being transmitted at MCS0 and the AP is just plain not ACKing them. Now, I don't know why this is. It's trying to transmit the initial frame at non-MCS rates, but I have a feeling the multi-rate retry table thing is confusing it and it's trying to send it as MCS. So maybe the AP doesn't like management frames at MCS rates. I'll have to think about this a little. -a On 28 February 2014 15:07, Tom Murphy free...@pertho.net wrote: I've attached my iwn debug messages to this email starting with the point I tried to associate to the Wifi. Thanks again for looking at this! Kind regards, Tom On Thu, Feb 27, 2014 at 12:13:51PM -0800, Adrian Chadd wrote: On 26 February 2014 23:52, Alexandr shur...@shurik.kiev.ua wrote: Tom, could you: 1. compile kernel WITH_IWNDEBUG 2. sysctl dev.iwn.0.debug=0x1 3. wlandebug -i wlan0 auth+assoc 4. Associate with AP in 11n mode 5. Send us appropriate /var/log/messages Then I try to compare it with my log. Please do. I've been trying to track down the source of this ht just doesn't work! but it works fine with all of the Intel NICs I have here. Can someone see if they can find a mtaching NIC online (amazon,ebay?) Owning one that I can whack in a laptop is likely going ot help things a lot. Thanks, -a ___ 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
cannot build 9.2 from an 11-current host
Hi all, I've got a build machine that does package builds of net/openafs for upstream OpenAFS, and is supposed to build packages for all supported FreeBSD versions (and a few unsupported ones, too). I've recently updated to r264039M (the 'M' is reverting PCI ARI bits as discussed in a different thread), and now when I go back to build a 9.2 chroot, I find that I cannot build world: [...] c++ -O2 -pipe -I/usr/jail/amd64_fbsd_92/JAILROOT/usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/include -I/usr/jail/amd64_fbsd_92/JAILROOT/usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/tools/clang/include -I/usr/jail/amd64_fbsd_92/JAILROOT/usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen -I. -I/usr/jail/amd64_fbsd_92/JAILROOT/usr/src/usr.bin/clang/tblgen/../../../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=\x86_64-unknown-freebsd9.2\ -DLLVM_HOST_TRIPLE=\x86_64-unknown-freebsd9.2\ -DDEFAULT_SYSROOT=\\ -I/usr/obj/usr/jail/amd64_fbsd_92/JAILROOT/usr/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /usr/jail/amd64_fbsd_92/JAILROOT/usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen/X86RecognizableInstr.cpp make: don't know how to make /usr/lib/libstdc++.a. Stop *** [bootstrap-tools] Error code 2 Stop in /usr/jail/amd64_fbsd_92/JAILROOT/usr/src. *** [_bootstrap-tools] Error code 1 Stop in /usr/jail/amd64_fbsd_92/JAILROOT/usr/src. *** Error code 1 sys/conf/newvers.sh is at r260647 (9.2-RELEASE-p3), and the source tree was generated by performing a svn checkout on a different machine and tarring up the tree. (That would be a checkout of releng/9.2 .) This is supposed to be a supported operation, right? -Ben ___ 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: cannot build 9.2 from an 11-current host
On Thu, Apr 3, 2014 at 9:09 PM, Benjamin Kaduk ka...@mit.edu wrote: Hi all, I've got a build machine that does package builds of net/openafs for upstream OpenAFS, and is supposed to build packages for all supported FreeBSD versions (and a few unsupported ones, too). I've recently updated to r264039M (the 'M' is reverting PCI ARI bits as discussed in a different thread), and now when I go back to build a 9.2 chroot, I find that I cannot build world: Unfortunately the bug is in 9.2-RELEASE, not 11-CURRENT. This patch fixes it, but it came in after 9.2-RELEASE: http://svnweb.freebsd.org/changeset/base/257812 ___ 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: cannot build 9.2 from an 11-current host
On Thu, 3 Apr 2014, Ryan Stone wrote: On Thu, Apr 3, 2014 at 9:09 PM, Benjamin Kaduk ka...@mit.edu wrote: Hi all, I've got a build machine that does package builds of net/openafs for upstream OpenAFS, and is supposed to build packages for all supported FreeBSD versions (and a few unsupported ones, too). I've recently updated to r264039M (the 'M' is reverting PCI ARI bits as discussed in a different thread), and now when I go back to build a 9.2 chroot, I find that I cannot build world: Unfortunately the bug is in 9.2-RELEASE, not 11-CURRENT. This patch fixes it, but it came in after 9.2-RELEASE: I figured it would be, and almost sent to -stable instead of here. http://svnweb.freebsd.org/changeset/base/257812 Well, that was easy. Thanks for the quick pointer! -Ben ___ 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
