10.0-RELEASE cycle status update
As some may have noticed, the 10.0-RELEASE cycle has slipped a bit behind schedule. Here is where we stand at the moment: - The iconv issues mentioned in a previous status update email[1] are being looked at extensively. There are a number of iconv(3) fixes that have been committed to head/, which are pending MFC to stable/10 following the default 3-day merge period. Those tracking -CURRENT are encouraged to update their systems and report back (on -current@) any issues. Those awaiting the next 10.0 builds, please be patient. We will have the next round of builds for the 10.0-RELEASE cycle started as soon as possible. [1] http://lists.freebsd.org/pipermail/freebsd-stable/2013-November/075658.html Glen pgpROoRcHpxZD.pgp Description: PGP signature
Re: WEAK_REFERENCE?
On 19.11.13 08:23, Konstantin Belousov wrote: On Mon, Nov 18, 2013 at 11:00:55PM +0100, Andreas Tobler wrote: I prepared two patches, see below. The amd64 one is reviewed by bde@ and the i386 is compile tested by me (runtime is theoretically also done, but I'm not sure since I do not have 32-bit apps on my amd64). Use cc -m32. The amd64 is compile and runtime tested. The tools, nm, shows that we have the weak_references as before. If you agree I'd like to commit both within a few days to -CURRENT. If someone steps up and confirms that the i386 part also runs, would be great, but I expect it to work. If I'm correct, there is some similar work to be done on arm, mips and sparc64, I'm happy to do this if the people like to have it done. But I do not own either of them to test in native config. Except sparc64. Here I have blech ;) Here the two patches amd64: http://people.freebsd.org/~andreast/weak_ref_amd64.diff i386: http://people.freebsd.org/~andreast/weak_ref_i386.diff Amd64 patch is fine. For i386, I do not see a definition of the WEAK_REFERENCE in the patch, and quick search of the pre-existing definition in sys/i386 or lib/libc/i386 does not reveal anything. It's there now. Updated the diff. Thanks, Andreas ___ 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
provide fast versions of ffsl and flsl for i386; ffsll and flsll for amd64
These are just trivial wrappers based on the fact that int and long on i386 have
the same bit layout and likewise for long and long long on amd64.
For your reviewing pleasure :-)
Thanks!
commit fdc1228b113f8b4c9dbda2b0323cb087c6b6df9d
Author: Andriy Gapon a...@icyb.net.ua
Date: Thu Nov 7 19:13:00 2013 +0200
provide fast versions of ffsl and flsl for i386; ffsll and flsll for amd64
diff --git a/sys/amd64/include/cpufunc.h b/sys/amd64/include/cpufunc.h
index 5f8197b..7464739 100644
--- a/sys/amd64/include/cpufunc.h
+++ b/sys/amd64/include/cpufunc.h
@@ -154,6 +154,14 @@ ffsl(long mask)
return (mask == 0 ? mask : (int)bsfq((u_long)mask) + 1);
}
+#defineHAVE_INLINE_FFSLL
+
+static __inline int
+ffsll(long long mask)
+{
+ return (ffsl((long)mask));
+}
+
#defineHAVE_INLINE_FLS
static __inline int
@@ -170,6 +178,14 @@ flsl(long mask)
return (mask == 0 ? mask : (int)bsrq((u_long)mask) + 1);
}
+#defineHAVE_INLINE_FLSLL
+
+static __inline int
+flsll(long long mask)
+{
+ return (flsl((long)mask));
+}
+
#endif /* _KERNEL */
static __inline void
diff --git a/sys/conf/files b/sys/conf/files
index d41b9d2..8077bfc 100644
--- a/sys/conf/files
+++ b/sys/conf/files
@@ -3029,7 +3029,6 @@ libkern/arc4random.c standard
libkern/bcd.c standard
libkern/bsearch.c standard
libkern/crc32.cstandard
-libkern/flsll.c standard
libkern/fnmatch.c standard
libkern/iconv.coptional libiconv
libkern/iconv_converter_if.m optional libiconv
diff --git a/sys/conf/files.arm b/sys/conf/files.arm
index 603fb2d..d15f014 100644
--- a/sys/conf/files.arm
+++ b/sys/conf/files.arm
@@ -87,6 +87,7 @@ libkern/divdi3.c standard
libkern/ffsl.c standard
libkern/fls.c standard
libkern/flsl.c standard
+libkern/flsll.cstandard
libkern/lshrdi3.c standard
libkern/moddi3.c standard
libkern/qdivrem.c standard
diff --git a/sys/conf/files.i386 b/sys/conf/files.i386
index 23e03a3..030dbe1 100644
--- a/sys/conf/files.i386
+++ b/sys/conf/files.i386
@@ -524,8 +524,7 @@ kern/kern_clocksource.c standard
kern/imgact_aout.c optional compat_aout
kern/imgact_gzip.c optional gzip
libkern/divdi3.c standard
-libkern/ffsl.c standard
-libkern/flsl.c standard
+libkern/flsll.cstandard
libkern/memmove.c standard
libkern/memset.c standard
libkern/moddi3.c standard
diff --git a/sys/conf/files.ia64 b/sys/conf/files.ia64
index 6719c98..e85c35d 100644
--- a/sys/conf/files.ia64
+++ b/sys/conf/files.ia64
@@ -120,6 +120,7 @@ libkern/bcmp.c standard
libkern/ffsl.c standard
libkern/fls.c standard
libkern/flsl.c standard
+libkern/flsll.cstandard
libkern/ia64/__divdi3.Sstandard
libkern/ia64/__divsi3.Sstandard
libkern/ia64/__moddi3.Sstandard
diff --git a/sys/conf/files.mips b/sys/conf/files.mips
index 82d9a69..6522bb2 100644
--- a/sys/conf/files.mips
+++ b/sys/conf/files.mips
@@ -56,6 +56,7 @@ kern/subr_dummy_vdso_tc.c standard
libkern/ffsl.c standard
libkern/fls.c standard
libkern/flsl.c standard
+libkern/flsll.cstandard
libkern/memmove.c standard
libkern/cmpdi2.c optionalmips | mipsel
libkern/ucmpdi2.c optionalmips | mipsel
diff --git a/sys/conf/files.pc98 b/sys/conf/files.pc98
index fd3ad4a..c95d956 100644
--- a/sys/conf/files.pc98
+++ b/sys/conf/files.pc98
@@ -210,6 +210,7 @@ kern/imgact_gzip.c optional gzip
libkern/divdi3.c standard
libkern/ffsl.c standard
libkern/flsl.c standard
+libkern/flsll.cstandard
libkern/memmove.c standard
libkern/memset.c standard
libkern/moddi3.c standard
diff --git a/sys/conf/files.powerpc b/sys/conf/files.powerpc
index 6d90fc7..98b3da0 100644
--- a/sys/conf/files.powerpc
+++ b/sys/conf/files.powerpc
@@ -79,6 +79,7 @@ libkern/ffs.c standard
libkern/ffsl.c standard
libkern/fls.c standard
libkern/flsl.c standard
+libkern/flsll.cstandard
libkern/lshrdi3.c optionalpowerpc
libkern/memmove.c standard
libkern/memset.c standard
diff --git a/sys/conf/files.sparc64 b/sys/conf/files.sparc64
index 5c00350..ccee247 100644
--- a/sys/conf/files.sparc64
+++ b/sys/conf/files.sparc64
@@ -68,6 +68,7 @@
Re: random_harvestq eats much on geode-lx alix2c3
On 19 Nov 2013, at 00:22, Stanisław Halik stha...@misaki.pl wrote: Hey, random_harvestq eats much, much CPU on alix2c3: CPU: Geode(TM) Integrated Processor by AMD PCS (498.06-MHz 586-class CPU) glxsb0: AMD Geode LX Security Block (AES-128-CBC, RNG) mem 0xefff4000-0xefff7fff irq 9 at device 1.2 on pci0 Could you please add a sysctl/loader knob for it, or a way to throttle collection? Here's top output: 14 root 1 -16- 0K 8K -6:12 15.97% rand_harvestq Take a look at random(4) - sysctls to turn off harvesting are documented there. That is quite a busy harvestq - could you please give me some more details of what that box is and what it was doing at the time (numbers would be good!) Thanks! M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP using GPGMail
Re: 10.0-RELEASE cycle status update
As some may have noticed, the 10.0-RELEASE cycle has slipped a bit behind schedule. Here is where we stand at the moment: - The iconv issues mentioned in a previous status update email[1] are being looked at extensively. There are a number of iconv(3) fixes that have been committed to head/, which are pending MFC to stable/10 following the default 3-day merge period. Those tracking -CURRENT are encouraged to update their systems and report back (on -current@) any issues. Those awaiting the next 10.0 builds, please be patient. We will have the next round of builds for the 10.0-RELEASE cycle started as soon as possible. [1] http://lists.freebsd.org/pipermail/freebsd-stable/2013-November/075658.html Glen What are the symptoms I might look for on FreeBSD-current? Release engineering estimated dates ought to be updated on the website. Better to wait for a solid 10.0-RELEASE than rush to a buggy release. I am also concerned about the bug in re(4) driver. Tom ___ 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: 10.0-RELEASE cycle status update
On Tue, Nov 19, 2013 at 11:03:56PM +, Thomas Mueller wrote: What are the symptoms I might look for on FreeBSD-current? Software crashes because of incorrect/missing character encodings are one symptom in particular. Release engineering estimated dates ought to be updated on the website. Once -BETA4 is out, the remaining dates will be updated accordingly. I do not want to update the schedule page for the -RCs and -RELEASE until somewhat confident they can be met. Better to wait for a solid 10.0-RELEASE than rush to a buggy release. I am also concerned about the bug in re(4) driver. Is it fixed in head/? Glen pgp01K4FTjPWD.pgp Description: PGP signature
Re: Is there already staging support within /ports/Mk/bsd.java.mk?
On Mon, Nov 18, 2013 at 07:26:10PM +0100, Matthias Petermann wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
while updating my SweetHome3D port I'd like to enable staging support.
The build process is using bsd.java.mk to build via ant.
After removing NO_STAGE and adding ${STAGEDIR} to the respective
directories, I get the following message at *make stage*:
=== Building for sweethome3d-4.2
Buildfile: /usr/ports/cad/sweethome3d/work/SweetHome3D-4.2-src/build.xml
BUILD FAILED
Target DESTDIR=/usr/ports/cad/sweethome3d/work/stage does not exist
in the project SweetHome3D.
Appears like the DESTDIR is passed as a target to ant. I will
definitely do more investigation here, but before I do I'd like to
know if the bsd.java.mk already supports staging, or if this is a case
for staying with NO_STAGE temporarely?
Best regards,
Matthias
This should be fixed now, update your ports tree, I fixed it a couple of weeks
ago iirc.
regards,
Bapt
pgpBdm3je4MYi.pgp
Description: PGP signature
Re: 10.0-RELEASE cycle status update
On Tue, 19 Nov 2013 11:22:05 -0500, Glen Barber wrote: As some may have noticed, the 10.0-RELEASE cycle has slipped a bit behind schedule. No worries; release it when it's ready. Many thanks to all concerned for their efforts. ___ 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: random_harvestq eats much on geode-lx alix2c3
On Tue November 19 2013 23:01:37 Mark Robert Vaughan Murray wrote: rand_harvestq Take a look at random(4) - sysctls to turn off harvesting are documented there. Thanks! Turning off software interrupt collection brings the cpu usage next to nothing. That is quite a busy harvestq - could you please give me some more details of what that box is and what it was doing at the time (numbers would be good!) The box is a home firewall with pf/altq. HZ=1000, despite poor hardware. It's alix2c3. Uses polling and a long, bloated pf.conf. Also, scrubs packets a bit. I'd be glad to attach more detail, but what do you ask for? Also, can text attachments be put here? For posterity's sake, better not to link to them. cheers, -sh -- xmpp:stha...@jabster.pl sip:stha...@misaki.pl ___ 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: 10.0-RELEASE cycle status update
from Glen Barber and my previous message: Software crashes because of incorrect/missing character encodings are one symptom in particular. Release engineering estimated dates ought to be updated on the website. Once -BETA4 is out, the remaining dates will be updated accordingly. I do not want to update the schedule page for the -RCs and -RELEASE until somewhat confident they can be met. Better to wait for a solid 10.0-RELEASE than rush to a buggy release. I am also concerned about the bug in re(4) driver. Is it fixed in head/? Glen re(4) driver bug seems to have not been fixed in head. Since I last tried, there has been no further update as of about two days ago. I use subversion built from pkgsrc on a USB-stick installation of NetBSD-current amd64, and then check relevant dates for re(4)-related files. NetBSD-current source tree and pkgsrc tree are in separate directories on the FreeBSD-current amd64 partition. Having directories /netbsd-HEAD and /pkgsrc apparently does not bother FreeBSD. Tom ___ 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: zpool requires re-import on reboot
Alan: This corrects the zpool import problem (thanks for that): zpool_cache_type=/boot/zfs/zpool.cache zpool_cache_name=/boot/zfs/zpool.cache But boot still drops to single user and needs zfs mount -a to locate the fstab entries. Some datasets have canmount=noauto (but have a corresponding fstab entry). However, the primary dataset of the zpool (where dataset name = zpoll name) for both pools has canmount=on. One other non-standard property I have is that the dataset name is different than mountpoint (zfs set mountpoint=/some other folder) Nothing else out of the ordinary that I can think of. Regards. - FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS -- View this message in context: http://freebsd.1045724.n5.nabble.com/zpool-requires-re-import-on-reboot-tp5861930p5862442.html Sent from the freebsd-current mailing list archive at Nabble.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: WEAK_REFERENCE?
On Tue, Nov 19, 2013 at 06:50:56PM +0100, Andreas Tobler wrote: On 19.11.13 08:23, Konstantin Belousov wrote: On Mon, Nov 18, 2013 at 11:00:55PM +0100, Andreas Tobler wrote: Here the two patches amd64: http://people.freebsd.org/~andreast/weak_ref_amd64.diff i386: http://people.freebsd.org/~andreast/weak_ref_i386.diff Amd64 patch is fine. For i386, I do not see a definition of the WEAK_REFERENCE in the patch, and quick search of the pre-existing definition in sys/i386 or lib/libc/i386 does not reveal anything. It's there now. Updated the diff. i386 patch looks fine. pgpv0zeuDTdYV.pgp Description: PGP signature
