Re: svn commit: r244865 - in head: . lib lib/libdisk share/mk
On Sun, Dec 30, 2012 at 06:57:45PM -0800, Garrett Cooper wrote: > This is what exp- runs are for (portmgr can help with this). OTOH -exp runs are currently off the air. mcl ___ 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: [RFC/RFT] calloutng
On Sun, Dec 30, 2012 at 04:13:43PM -0700, Ian Lepore wrote: ... > I grabbed testsleep.c to test an arm event timer implementation, and had > to fix a couple nits... kqueueto was missing from the names[] array, and > I had to add a "* 1000" to a couple places where usec was stuffed into a > timespec's tv_nsec. > > I also tested the calloutng_12_17 patches and the kqueue stuff behaved > very strangely. Then I noticed you had a 12_26 patchset so I tested > that (after crudely fixing a couple uninitialized var warnings), and it > all looks good on this arm (Raspberry Pi). I'll attach the results. > > It's so sweet to be able to do precision sleeps. interesting numbers, but there seems to be some problem in computing the exact interval; delays are much larger than expected. In this test, the original timer code used to round to the next multiple of 1 tick and then add another tick (except for the kqueue case), which is exactly what you see in the second set of measurements. The calloutng code however seems to do something odd: in addition to fixed overhead (some 50us, which you can see in the tests for 1us and 300us), all delay seem to be ~10% larger than what is requested, upper bounded to 10ms (note, the numbers are averages so i cannot tell whether all samples are the same or there is some distribution of values). I am not sure if this error is peculiar of the ARM version or also appears on x86/amd64 but I believe it should be fixed. If you look at the results below: 1us possily ok: for very short intervals i would expect some kind of 'reschedule' without actually firing a timer; maybe 50us are what it takes to do a round through the scheduler ? 300us probably ok i guess the extra 50-90us are what it takes to do a round through the scheduler 1000us borderline (this is the case for poll and kqueue, which are rounded to 1ms) here intervals seem to be increased by 10%, and i cannot see a good reason for this (more below). 3000us and above: wrong here again, the intervals seem to be 10% larger than what is requested, perhaps limiting the error to 10-20ms. Maybe the 10% extension results from creating a default 'precision' for legacy calls, but i do not think this is done correctly. First of all, if users do not specify a precision themselves, the automatically generated value should never exceed one tick. Second, the only point of a 'precision' parameter is to merge requests that may be close in time, so if there is already a timer scheduled within [Treq, Treq+precision] i will get it; but if there no pending timer, then one should schedule it for the requested interval. Davide/Alexander, any ideas ? cheers luigi > for t in 1 300 3000 3 30 ; do > for m in select poll usleep nanosleep kqueue kqueueto syscall ; do > ./testsleep $t $m > done > done > > > With calloutng_12_26.patch... > > HZ=100 HZ=250 HZ=1000 > -- > select 1 55.79 1 50.96 1 61.32 > poll1 1109.46 1 1107.86 1 1114.38 > usleep 1 56.33 1 72.90 1 62.78 > nanosleep 1 52.66 1 55.23 1 64.23 > kqueue 1 1114.23 1 1113.81 1 1121.21 > kqueueto1 65.44 1 71.00 1 75.01 > syscall 1 4.70 1 4.45 1 4.55 > select300355.79300357.76300362.35 > poll 300 1107.85300 1122.55300 1115.62 > usleep300355.28300357.28300360.79 > nanosleep 300354.49300355.82300360.62 > kqueue300 1112.57300 1118.13300 1117.16 > kqueueto 300375.98300378.62300395.61 > syscall 300 4.41300 4.45300 4.54 > select 3000 3246.75 3000 3246.74 3000 3252.72 > poll 3000 3238.10 3000 3229.12 3000 3250.10 > usleep 3000 3242.47 3000 3237.06 3000 3249.61 > nanosleep3000 3238.79 3000 3231.55 3000 3248.11 > kqueue 3000 3240.01 3000 3236.07 3000 3247.60 > kqueueto 3000 3265.36 3000 3267.22 3000 3274.96 > syscall 3000 4.69 3000 4.44 3000 4.50 > select 3 31714.60 3 31941.17 3 32467.69 > poll3 31522.76 3 31983.00 3 32497.81 > usleep 3 31459.67 3 31980.76 3 32458.71 > nanosleep 3 31431.02 3 31982.22 3 32525.20 > kqueue 3 31466.75 3 31873.90 3 31973.54 > kqueueto3 31564.67
Re: svn commit: r244865 - in head: . lib lib/libdisk share/mk
On Sun, Dec 30, 2012 at 6:54 PM, Adrian Chadd wrote:
> .. not that I mind old things being retired, but we really should
> announce things like this.
>
> Also - you disconnected libftpio too; is that intentional?
I would assume so, given that this only removed the static library
name, which nothing else could be using still, seeing as how the
library was disconnected and removed in r225952.
> Just because libdisk/libftpio isn't used by anything in the base -HEAD
> doesn't mean that:
>
> * it's not used by third party programs in ports;
> * it's not used by any external, non open source utilities that people
> have read.
>
> So I'd suggest creating a port for them both and begin the process of
> deprecating the kernel side interfaces that are unique to this API.
Pretty sure the addition of and widespread use of GEOM things
initiated the deprecation of the really lousy and properly-disliked
kernel interfaces involved.
> On 30 December 2012 08:28, Nathan Whitehorn wrote:
>> Author: nwhitehorn
>> Date: Sun Dec 30 16:28:06 2012
>> New Revision: 244865
>> URL: http://svnweb.freebsd.org/changeset/base/244865
>>
>> Log:
>> With the old sade removed, libdisk is no longer used by anything in HEAD
>> and uses a number of problematic pre-gpart interfaces. Since it has been
>> entirely obsoleted by interfaces in geom, remove it.
>>
>> Deleted:
>> head/lib/libdisk/
>> Modified:
>> head/ObsoleteFiles.inc
>> head/lib/Makefile
>> head/share/mk/bsd.libnames.mk
>>
>> Modified: head/ObsoleteFiles.inc
>> ==
>> --- head/ObsoleteFiles.inc Sun Dec 30 15:38:06 2012(r244864)
>> +++ head/ObsoleteFiles.inc Sun Dec 30 16:28:06 2012(r244865)
>> @@ -38,6 +38,9 @@
>> # xargs -n1 | sort | uniq -d;
>> # done
>>
>> +# 20121230: libdisk removed
>> +OLD_FILES+=usr/share/man/man3/libdisk.3.gz usr/include/libdisk.h
>> +OLD_FILES+=usr/lib/libdisk.a usr/lib32/libdisk.a
>> # 20121230: remove wrongly created directories for auditdistd
>> OLD_DIRS+=var/dist
>> OLD_DIRS+=var/remote
>>
>> Modified: head/lib/Makefile
>> ==
>> --- head/lib/Makefile Sun Dec 30 15:38:06 2012(r244864)
>> +++ head/lib/Makefile Sun Dec 30 16:28:06 2012(r244865)
>> @@ -69,7 +69,6 @@ SUBDIR= ${SUBDIR_ORDERED} \
>> libcompat \
>> libdevinfo \
>> libdevstat \
>> - libdisk \
>> libdwarf \
>> libedit \
>> ${_libefi} \
>>
>> Modified: head/share/mk/bsd.libnames.mk
>> ==
>> --- head/share/mk/bsd.libnames.mk Sun Dec 30 15:38:06 2012
>> (r244864)
>> +++ head/share/mk/bsd.libnames.mk Sun Dec 30 16:28:06 2012
>> (r244865)
>> @@ -45,7 +45,6 @@ LIBCURSES?= ${DESTDIR}${LIBDIR}/libcurse
>> LIBDEVINFO?= ${DESTDIR}${LIBDIR}/libdevinfo.a
>> LIBDEVSTAT?= ${DESTDIR}${LIBDIR}/libdevstat.a
>> LIBDIALOG?=${DESTDIR}${LIBDIR}/libdialog.a
>> -LIBDISK?= ${DESTDIR}${LIBDIR}/libdisk.a
>> LIBDNS?= ${DESTDIR}${LIBDIR}/libdns.a
>> LIBDTRACE?=${DESTDIR}${LIBDIR}/libdtrace.a
>> LIBDWARF?= ${DESTDIR}${LIBDIR}/libdwarf.a
>> @@ -54,7 +53,6 @@ LIBELF?= ${DESTDIR}${LIBDIR}/libelf.a
>> LIBFETCH?= ${DESTDIR}${LIBDIR}/libfetch.a
>> LIBFL?="don't use LIBFL, use LIBL"
>> LIBFORM?= ${DESTDIR}${LIBDIR}/libform.a
>> -LIBFTPIO?= ${DESTDIR}${LIBDIR}/libftpio.a
>> LIBG2C?= ${DESTDIR}${LIBDIR}/libg2c.a
>> LIBGCC?= ${DESTDIR}${LIBDIR}/libgcc.a
>> LIBGCC_PIC?= ${DESTDIR}${LIBDIR}/libgcc_pic.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"
Re: svn commit: r244604 - head/usr.sbin/gssd
On Sun, Dec 30, 2012 at 4:49 PM, Rick Macklem wrote:
> bf1783 wrote:
>> >Author: rmacklem
>> >Date: Sat Dec 22 23:21:17 2012
>> >New Revision: 244604
>> >URL: http://svnweb.freebsd.org/changeset/base/244604
>> >
>> >Log:
>> > It was reported via email that some sshds create kerberos
>> > credential cache files with names other than /tmp/krb5cc_.
>> > The gssd daemon does not know how to find these credential caches.
>> > This patch implements a new option "-s" that does a search for
>> > credential cache files, using roughly the same algorithm as the
>> > gssd daemon for Linux uses. The gssd behaviour is only changed
>> > if the new "-s" option is specified. It also implements two other
>> > new options related to the "-s" option.
>> >
>> > Reported by: Piete.Brooks at cl.cam.ac.uk, Herbert Poeckl
>> > Tested by: Herbert Poeckl (admin at ist.tugraz.at), Illias A.
>> > Marinos
>> > MFC after: 2 weeks
>>
>> ...
>>
>> >+#include
>>
>> Rick:
>>
>> This breaks world built WITHOUT_KERBEROS and WITH_GSSAPI.
>>
>> Regards,
>> b.
> Could you please test the attached patch.
>
> Also, if someone who is familiar with the build/Makefile side
> of things could review this, it would be appreciated.
1. I would name WITHOUT_KERBEROS to KERBEROS_SUPPORT in the sourcefile
and CFLAGS to avoid potential confusion/noise with build logic.
2. This code should be revised per style(9):
+#else
+ fprintf(stderr, "This option not available when built"
+ " without MK_KERBEROS\n");
+ exit(1);
In particular:
errx(1, "This option requires Kerberos support");
Seems more succinct and addresses the actual item at hand.
3. This could be simplified as well potentially:
+.if ${MK_KERBEROS} != "no"
DPADD= ${LIBGSSAPI} ${LIBKRB5} ${LIBHX509} ${LIBASN1} ${LIBROKEN}
${LIBCOM_ERR} ${LIBCRYPT} ${LIBCRYPTO}
LDADD= -lgssapi -lkrb5 -lhx509 -lasn1 -lroken -lcom_err -lcrypt -lcrypto
+.else
+CFLAGS+= -DWITHOUT_KERBEROS
+DPADD= ${LIBGSSAPI}
+LDADD= -lgssapi
+.endif
to this:
DPADD= ${LIBGSSAPI}
LDADD= -lgssapi
.if ${MK_KERBEROS} != "no"
CFLAGS+= -DKERBEROS_SUPPORT
DPADD+= ${LIBKRB5} ${LIBHX509} ${LIBASN1} ${LIBROKEN} ${LIBCOM_ERR}
${LIBCRYPT} ${LIBCRYPTO}
LDADD+= -lkrb5 -lhx509 -lasn1 -lroken -lcom_err -lcrypt -lcrypto
.endif
Thanks!
-Garrett
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: svn commit: r244865 - in head: . lib lib/libdisk share/mk
On Sun, Dec 30, 2012 at 6:54 PM, Adrian Chadd wrote: > .. not that I mind old things being retired, but we really should > announce things like this. > > Also - you disconnected libftpio too; is that intentional? > > Just because libdisk/libftpio isn't used by anything in the base -HEAD > doesn't mean that: > > * it's not used by third party programs in ports; > * it's not used by any external, non open source utilities that people > have read. > > So I'd suggest creating a port for them both and begin the process of > deprecating the kernel side interfaces that are unique to this API. +1 This is what exp- runs are for (portmgr can help with this). HTH, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: svn commit: r244865 - in head: . lib lib/libdisk share/mk
.. not that I mind old things being retired, but we really should
announce things like this.
Also - you disconnected libftpio too; is that intentional?
Just because libdisk/libftpio isn't used by anything in the base -HEAD
doesn't mean that:
* it's not used by third party programs in ports;
* it's not used by any external, non open source utilities that people
have read.
So I'd suggest creating a port for them both and begin the process of
deprecating the kernel side interfaces that are unique to this API.
Thanks,
Adrian
On 30 December 2012 08:28, Nathan Whitehorn wrote:
> Author: nwhitehorn
> Date: Sun Dec 30 16:28:06 2012
> New Revision: 244865
> URL: http://svnweb.freebsd.org/changeset/base/244865
>
> Log:
> With the old sade removed, libdisk is no longer used by anything in HEAD
> and uses a number of problematic pre-gpart interfaces. Since it has been
> entirely obsoleted by interfaces in geom, remove it.
>
> Deleted:
> head/lib/libdisk/
> Modified:
> head/ObsoleteFiles.inc
> head/lib/Makefile
> head/share/mk/bsd.libnames.mk
>
> Modified: head/ObsoleteFiles.inc
> ==
> --- head/ObsoleteFiles.inc Sun Dec 30 15:38:06 2012(r244864)
> +++ head/ObsoleteFiles.inc Sun Dec 30 16:28:06 2012 (r244865)
> @@ -38,6 +38,9 @@
> # xargs -n1 | sort | uniq -d;
> # done
>
> +# 20121230: libdisk removed
> +OLD_FILES+=usr/share/man/man3/libdisk.3.gz usr/include/libdisk.h
> +OLD_FILES+=usr/lib/libdisk.a usr/lib32/libdisk.a
> # 20121230: remove wrongly created directories for auditdistd
> OLD_DIRS+=var/dist
> OLD_DIRS+=var/remote
>
> Modified: head/lib/Makefile
> ==
> --- head/lib/Makefile Sun Dec 30 15:38:06 2012(r244864)
> +++ head/lib/Makefile Sun Dec 30 16:28:06 2012(r244865)
> @@ -69,7 +69,6 @@ SUBDIR= ${SUBDIR_ORDERED} \
> libcompat \
> libdevinfo \
> libdevstat \
> - libdisk \
> libdwarf \
> libedit \
> ${_libefi} \
>
> Modified: head/share/mk/bsd.libnames.mk
> ==
> --- head/share/mk/bsd.libnames.mk Sun Dec 30 15:38:06 2012
> (r244864)
> +++ head/share/mk/bsd.libnames.mk Sun Dec 30 16:28:06 2012
> (r244865)
> @@ -45,7 +45,6 @@ LIBCURSES?= ${DESTDIR}${LIBDIR}/libcurse
> LIBDEVINFO?= ${DESTDIR}${LIBDIR}/libdevinfo.a
> LIBDEVSTAT?= ${DESTDIR}${LIBDIR}/libdevstat.a
> LIBDIALOG?=${DESTDIR}${LIBDIR}/libdialog.a
> -LIBDISK?= ${DESTDIR}${LIBDIR}/libdisk.a
> LIBDNS?= ${DESTDIR}${LIBDIR}/libdns.a
> LIBDTRACE?=${DESTDIR}${LIBDIR}/libdtrace.a
> LIBDWARF?= ${DESTDIR}${LIBDIR}/libdwarf.a
> @@ -54,7 +53,6 @@ LIBELF?= ${DESTDIR}${LIBDIR}/libelf.a
> LIBFETCH?= ${DESTDIR}${LIBDIR}/libfetch.a
> LIBFL?="don't use LIBFL, use LIBL"
> LIBFORM?= ${DESTDIR}${LIBDIR}/libform.a
> -LIBFTPIO?= ${DESTDIR}${LIBDIR}/libftpio.a
> LIBG2C?= ${DESTDIR}${LIBDIR}/libg2c.a
> LIBGCC?= ${DESTDIR}${LIBDIR}/libgcc.a
> LIBGCC_PIC?= ${DESTDIR}${LIBDIR}/libgcc_pic.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"
Re: svn commit: r244604 - head/usr.sbin/gssd
bf1783 wrote:
> >Author: rmacklem
> >Date: Sat Dec 22 23:21:17 2012
> >New Revision: 244604
> >URL: http://svnweb.freebsd.org/changeset/base/244604
> >
> >Log:
> > It was reported via email that some sshds create kerberos
> > credential cache files with names other than /tmp/krb5cc_.
> > The gssd daemon does not know how to find these credential caches.
> > This patch implements a new option "-s" that does a search for
> > credential cache files, using roughly the same algorithm as the
> > gssd daemon for Linux uses. The gssd behaviour is only changed
> > if the new "-s" option is specified. It also implements two other
> > new options related to the "-s" option.
> >
> > Reported by: Piete.Brooks at cl.cam.ac.uk, Herbert Poeckl
> > Tested by: Herbert Poeckl (admin at ist.tugraz.at), Illias A.
> > Marinos
> > MFC after: 2 weeks
>
> ...
>
> >+#include
>
> Rick:
>
> This breaks world built WITHOUT_KERBEROS and WITH_GSSAPI.
>
> Regards,
> b.
Could you please test the attached patch.
Also, if someone who is familiar with the build/Makefile side
of things could review this, it would be appreciated.
Thanks, rick
--- usr.sbin/gssd/gssd.c.sav0 2012-12-30 19:04:19.0 -0500
+++ usr.sbin/gssd/gssd.c 2012-12-30 19:35:06.648603000 -0500
@@ -37,7 +37,9 @@ __FBSDID("$FreeBSD: head/usr.sbin/gssd/g
#include
#include
#include
+#ifndef WITHOUT_KERBEROS
#include
+#endif
#include
#include
#include
@@ -102,12 +104,18 @@ main(int argc, char **argv)
debug_level++;
break;
case 's':
+#ifndef WITHOUT_KERBEROS
/*
* Set the directory search list. This enables use of
* find_ccache_file() to search the directories for a
* suitable credentials cache file.
*/
strlcpy(ccfile_dirlist, optarg, sizeof(ccfile_dirlist));
+#else
+ fprintf(stderr, "This option not available when built"
+ " without MK_KERBEROS\n");
+ exit(1);
+#endif
break;
case 'c':
/*
@@ -814,6 +822,7 @@ static int
is_a_valid_tgt_cache(const char *filepath, uid_t uid, int *retrating,
time_t *retexptime)
{
+#ifndef WITHOUT_KERBEROS
krb5_context context;
krb5_principal princ;
krb5_ccache ccache;
@@ -913,5 +922,8 @@ is_a_valid_tgt_cache(const char *filepat
*retexptime = exptime;
}
return (ret);
+#else /* WITHOUT_KERBEROS */
+ return (0);
+#endif /* !WITHOUT_KERBEROS */
}
--- usr.sbin/gssd/Makefile.sav0 2012-12-30 19:18:00.0 -0500
+++ usr.sbin/gssd/Makefile 2012-12-30 19:35:02.0 -0500
@@ -1,5 +1,7 @@
# $FreeBSD: head/usr.sbin/gssd/Makefile 244638 2012-12-23 20:12:57Z rmacklem $
+.include
+
PROG= gssd
MAN= gssd.8
SRCS= gssd.c gssd.h gssd_svc.c gssd_xdr.c gssd_prot.c
@@ -7,8 +9,14 @@ SRCS= gssd.c gssd.h gssd_svc.c gssd_xdr.
CFLAGS+= -I.
WARNS?= 1
+.if ${MK_KERBEROS} != "no"
DPADD= ${LIBGSSAPI} ${LIBKRB5} ${LIBHX509} ${LIBASN1} ${LIBROKEN} ${LIBCOM_ERR} ${LIBCRYPT} ${LIBCRYPTO}
LDADD= -lgssapi -lkrb5 -lhx509 -lasn1 -lroken -lcom_err -lcrypt -lcrypto
+.else
+CFLAGS+= -DWITHOUT_KERBEROS
+DPADD= ${LIBGSSAPI}
+LDADD= -lgssapi
+.endif
CLEANFILES= gssd_svc.c gssd.h
___
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: Amd(8) Hangs at Boot
David Wolfskill wrote: > On Sat, Dec 29, 2012 at 09:38:42AM -0800, Cy Schubert wrote: > > Just udated to the latest current and amd hangs at boot. Ideas? > > > > I don't see a problem @r244855. On my build machine, /usr/ports is a > symlink to a "ports" working copy that resides on a ReadyNAS: > > freebeast(10.0-C)[2] ls -F /usr/ports > /usr/ports@ > freebeast(10.0-C)[3] ls -F /usr/ports/ > CHANGES accessibility/ emulators/ misc/ sysutils/ > COPYRIGHT arabic/ finance/ multimedia/ textproc/ > GIDs archivers/ french/ net/ ukrainian/ > INDEX-8 astro/ ftp/ net-im/ vietnamese/ > INDEX-8.bz2 audio/ games/ net-mgmt/ www/ > INDEX-9 benchmarks/ german/ net-p2p/ x11/ > INDEX-9.bz2 biology/ graphics/ news/ x11-clocks/ > KNOBS cad/ head/ packages/ x11-drivers/ > LEGAL chinese/ hebrew/ palm/ x11-fm/ > MOVED comms/ hungarian/ polish/ x11-fonts/ > Makefile converters/ irc/ ports-mgmt/ x11-servers/ > Mk/ databases/ japanese/ portuguese/ x11-themes/ > README deskutils/ java/ print/ x11-toolkits/ > Templates/ devel/ korean/ russian/ x11-wm/ > Tools/ distfiles/ lang/ science/ > UIDs dns/ mail/ security/ > UPDATING editors/ math/ shells/ > freebeast(10.0-C)[4] uname -a > FreeBSD freebeast.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT > #1029 r244855M/244856: Sun Dec 30 10:48:45 PST 2012 > r...@freebeast.catwhisker.org:/usr/obj/usr/src/sys/GENERIC i386 > freebeast(10.0-C)[5] ps axwwl | grep -w amd > 0 764 1 0 20 0 10024 10052 select Ss - 0:00.07 /usr/sbin/amd -p -c > 1800 -k i386 -l syslog /net /etc/amd.map > 1001 1878 964 0 23 0 10104 9916 - R+ 1 0:00.01 grep -w amd > freebeast(10.0-C)[6] > > Peace, > david > -- > David H. Wolfskill da...@catwhisker.org > Taliban: Evil men with guns afraid of truth from a 14-year old girl. > > See http://www.catwhisker.org/~david/publickey.gpg for my public key. This message is basically for Cy and not David... Since David doesn't see the problem with r244855, I'd suggest trying a new kernel and seeing if the problem still exists. If you still see the problem, I'd be suspicious of any recent commit done to the network device driver for whatever network interface you are using. Beyond that, Kostik recently pointed me at this: http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html which covers the commands you can use under DB to try and figure out why it is stuck in udp_bind(). You can also do the following to figure out what source line# it is stuck at: - go to wherever the kernel binaries are # nm kernel | grep udp_bind - add the offset to the address for udp_bind # addr2line -e kernel.symbols - type in the hex value for address + offset --> it should give you a source line# It never hurts to capture packets between the client and NFS server and see if there what network traffic is occurring. If there is any traffic, wireshark does a good job of decoding it. Finally, there was an email w.r.t. loopback being broken, posted on Dec. 27, but I haven't seen any followup email about this being fixed. (I don't know if amd uses 127.0.0.1 or not?) Good luck with it and please let us know when you have more information, rick ___ 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: r244604 breaks build WITHOUT_KERBEROS + WITH_GSSAPI for gssd.c
On Sun, 30 Dec 2012, Rick Macklem wrote: Hi, Maybe someone familiar with the build environment can help with this. Someone reported via email that gssd.c no longer builds for the combination of WITHOUT_KERBEROS and WITH_GSSAPI. Now, the gssd is completely useless without kerberos, but I need a way to fix the build for this case? Can it just be set to not build the gssd daemon when WITHOUT_KERBEROS is specified? Alternately, if WITHOUT_KERBEROS is defined for the compile, I can #ifdef the code so that it builds, although the resultant binary is useless. With my kerberos hat on, I would expect that WITHOUT_KERBEROS and WITH_GSSAPI would build a GSS-API application that does not use the krb5 GSS mechanism, that is, your "#ifdef [...] builds, although the resultant binary is useless" case. -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: [RFC/RFT] calloutng
On Wed, 2012-12-26 at 21:24 +0200, Alexander Motin wrote: > On 26.12.2012 01:21, Marius Strobl wrote: > > On Tue, Dec 18, 2012 at 11:03:47AM +0200, Alexander Motin wrote: > >> Experiments with dummynet shown ineffective support for very short > >> tick-based callouts. New version fixes that, allowing to get as many > >> tick-based callout events as hz value permits, while still be able to > >> aggregate events and generating minimum of interrupts. > >> > >> Also this version modifies system load average calculation to fix some > >> cases existing in HEAD and 9 branches, that could be fixed with new > >> direct callout functionality. > >> > >> http://people.freebsd.org/~mav/calloutng_12_17.patch > >> > >> With several important changes made last time I am going to delay commit > >> to HEAD for another week to do more testing. Comments and new test cases > >> are welcome. Thanks for staying tuned and commenting. > > > > FYI, I gave both calloutng_12_15_1.patch and calloutng_12_17.patch a > > try on sparc64 and it at least survives a buildworld there. However, > > with the patched kernels, buildworld times seem to increase slightly but > > reproducible by 1-2% (I only did four runs but typically buildworld > > times are rather stable and don't vary more than a minute for the > > same kernel and source here). Is this an expected trade-off (system > > time as such doesn't seem to increase)? > > I don't think build process uses significant number of callouts to > affect results directly. I think this additional time could be result of > the deeper next event look up, done by the new code, that is practically > useless for sparc64, which effectively has no cpu_idle() routine. It > wouldn't affect system time and wouldn't show up in any statistics > (except PMC or something alike) because it is executed inside timer > hardware interrupt handler. If my guess is right, that is a part that > probably still could be optimized. I'll look on it. Thanks. > > > Is there anything specific to test? > > Since the most of code is MI, for sparc64 I would mostly look on related > MD parts (eventtimers and timecounters) to make sure they are working > reliably in more stressful conditions. I still have some worries about > possible deadlock on hardware where IPIs are used to fetch present time > from other CPU. > > Here is small tool we are using for test correctness and performance of > different user-level APIs: http://people.freebsd.org/~mav/testsleep.c > I grabbed testsleep.c to test an arm event timer implementation, and had to fix a couple nits... kqueueto was missing from the names[] array, and I had to add a "* 1000" to a couple places where usec was stuffed into a timespec's tv_nsec. I also tested the calloutng_12_17 patches and the kqueue stuff behaved very strangely. Then I noticed you had a 12_26 patchset so I tested that (after crudely fixing a couple uninitialized var warnings), and it all looks good on this arm (Raspberry Pi). I'll attach the results. It's so sweet to be able to do precision sleeps. -- Ian for t in 1 300 3000 3 30 ; do for m in select poll usleep nanosleep kqueue kqueueto syscall ; do ./testsleep $t $m done done With calloutng_12_26.patch... HZ=100 HZ=250 HZ=1000 -- select 1 55.79 1 50.96 1 61.32 poll1 1109.46 1 1107.86 1 1114.38 usleep 1 56.33 1 72.90 1 62.78 nanosleep 1 52.66 1 55.23 1 64.23 kqueue 1 1114.23 1 1113.81 1 1121.21 kqueueto1 65.44 1 71.00 1 75.01 syscall 1 4.70 1 4.45 1 4.55 select300355.79300357.76300362.35 poll 300 1107.85300 1122.55300 1115.62 usleep300355.28300357.28300360.79 nanosleep 300354.49300355.82300360.62 kqueue300 1112.57300 1118.13300 1117.16 kqueueto 300375.98300378.62300395.61 syscall 300 4.41300 4.45300 4.54 select 3000 3246.75 3000 3246.74 3000 3252.72 poll 3000 3238.10 3000 3229.12 3000 3250.10 usleep 3000 3242.47 3000 3237.06 3000 3249.61 nanosleep3000 3238.79 3000 3231.55 3000 3248.11 kqueue 3000 3240.01 3000 3236.07 3000 3247.60 kqueueto 3000 3265.36 3000 3267.22 3000 3274.96 syscall 3000 4.69 3000 4.44 3000 4.50 select 3 31714.60 3 31941.17 3 32467.69 poll3 31522.76 3 31983.00 3 32497.81
r244604 breaks build WITHOUT_KERBEROS + WITH_GSSAPI for gssd.c
Hi, Maybe someone familiar with the build environment can help with this. Someone reported via email that gssd.c no longer builds for the combination of WITHOUT_KERBEROS and WITH_GSSAPI. Now, the gssd is completely useless without kerberos, but I need a way to fix the build for this case? Can it just be set to not build the gssd daemon when WITHOUT_KERBEROS is specified? Alternately, if WITHOUT_KERBEROS is defined for the compile, I can #ifdef the code so that it builds, although the resultant binary is useless. Thanks in advance for any help with this, rick ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: clang 3.2 RC2 miscompiles libgcc?
On 2012-12-27 16:15, Nathan Whitehorn wrote: On 12/27/12 09:07, Stefan Farfeleder wrote: I noticed that most of my C++ applications in recent versions of FreeBSD head suddenly crash without me recompiling them. I tracked it down to r243830 which imported a new clang version. The new clang seems to compile libgcc in a wrong or at least incompatible way with what gcc expects. In fact, the breakage only occurs with libgcc compiled by a post-r243830 clang and an application compiled with g++ -O2. For me, the crash happens with boost::program_options, but I'm not sure if that is necessary for the crash. I've seen what I think is the same thing due to a miscompilation of unwind-dw2.c that caused crashes related to cross-shared-object exception handling. It seems to have been fixed with the 3.2 release but I haven't tested it too thoroughly yet. I have been playing with Stefan's testcase for a while now, and while I can reproduce the crashes, I am still at a loss about the cause. It does seem to have something to do with throwing exceptions, but I am still not sure whether I am looking at a bug in boost, gcc, clang, or libgcc... Do you happen to have a smaller testcase, by any chance? ___ 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: Amd(8) Hangs at Boot
Am 12/30/12 20:41, schrieb David Wolfskill: > On Sat, Dec 29, 2012 at 09:38:42AM -0800, Cy Schubert wrote: >> Just udated to the latest current and amd hangs at boot. Ideas? >> > > I don't see a problem @r244855. On my build machine, /usr/ports is a > symlink to a "ports" working copy that resides on a ReadyNAS: > > freebeast(10.0-C)[2] ls -F /usr/ports > /usr/ports@ > freebeast(10.0-C)[3] ls -F /usr/ports/ > CHANGES accessibility/ emulators/ misc/ sysutils/ > COPYRIGHT arabic/ finance/multimedia/ textproc/ > GIDsarchivers/ french/ net/ukrainian/ > INDEX-8 astro/ ftp/net-im/ vietnamese/ > INDEX-8.bz2 audio/ games/ net-mgmt/ www/ > INDEX-9 benchmarks/ german/ net-p2p/x11/ > INDEX-9.bz2 biology/graphics/ news/ x11-clocks/ > KNOBS cad/head/ packages/ x11-drivers/ > LEGAL chinese/hebrew/ palm/ x11-fm/ > MOVED comms/ hungarian/ polish/ x11-fonts/ > Makefileconverters/ irc/ports-mgmt/ x11-servers/ > Mk/ databases/ japanese/ portuguese/ x11-themes/ > README deskutils/ java/ print/ x11-toolkits/ > Templates/ devel/ korean/ russian/x11-wm/ > Tools/ distfiles/ lang/ science/ > UIDsdns/mail/ security/ > UPDATINGeditors/math/ shells/ > freebeast(10.0-C)[4] uname -a > FreeBSD freebeast.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #1029 > r244855M/244856: Sun Dec 30 10:48:45 PST 2012 > r...@freebeast.catwhisker.org:/usr/obj/usr/src/sys/GENERIC i386 > freebeast(10.0-C)[5] ps axwwl | grep -w amd >0 7641 0 20 0 10024 10052 select Ss- 0:00.07 > /usr/sbin/amd -p -c 1800 -k i386 -l syslog /net /etc/amd.map > 1001 1878 964 0 23 0 10104 9916 -R+1 0:00.01 grep -w amd > freebeast(10.0-C)[6] > > Peace, > david > I see a similar picture here and this AMD crap brought down my whole server. I'm not able to install new buildworld, since I got stuck when mtree accesses / and then the amd automounter mountpoint directory /extern is reported newnfs server pid767@telesto:/extern: not responding I have no remote filesystems containing the sources for the OS, so I do not understand whats going on. This is definitely a bug in the recent system. signature.asc Description: OpenPGP digital signature
Re: Amd(8) Hangs at Boot
On Sat, Dec 29, 2012 at 09:38:42AM -0800, Cy Schubert wrote: > Just udated to the latest current and amd hangs at boot. Ideas? > I don't see a problem @r244855. On my build machine, /usr/ports is a symlink to a "ports" working copy that resides on a ReadyNAS: freebeast(10.0-C)[2] ls -F /usr/ports /usr/ports@ freebeast(10.0-C)[3] ls -F /usr/ports/ CHANGES accessibility/ emulators/ misc/ sysutils/ COPYRIGHT arabic/ finance/multimedia/ textproc/ GIDsarchivers/ french/ net/ukrainian/ INDEX-8 astro/ ftp/net-im/ vietnamese/ INDEX-8.bz2 audio/ games/ net-mgmt/ www/ INDEX-9 benchmarks/ german/ net-p2p/x11/ INDEX-9.bz2 biology/graphics/ news/ x11-clocks/ KNOBS cad/head/ packages/ x11-drivers/ LEGAL chinese/hebrew/ palm/ x11-fm/ MOVED comms/ hungarian/ polish/ x11-fonts/ Makefileconverters/ irc/ports-mgmt/ x11-servers/ Mk/ databases/ japanese/ portuguese/ x11-themes/ README deskutils/ java/ print/ x11-toolkits/ Templates/ devel/ korean/ russian/x11-wm/ Tools/ distfiles/ lang/ science/ UIDsdns/mail/ security/ UPDATINGeditors/math/ shells/ freebeast(10.0-C)[4] uname -a FreeBSD freebeast.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #1029 r244855M/244856: Sun Dec 30 10:48:45 PST 2012 r...@freebeast.catwhisker.org:/usr/obj/usr/src/sys/GENERIC i386 freebeast(10.0-C)[5] ps axwwl | grep -w amd 0 7641 0 20 0 10024 10052 select Ss- 0:00.07 /usr/sbin/amd -p -c 1800 -k i386 -l syslog /net /etc/amd.map 1001 1878 964 0 23 0 10104 9916 -R+1 0:00.01 grep -w amd freebeast(10.0-C)[6] Peace, david -- David H. Wolfskill da...@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpAekLJzJSMg.pgp Description: PGP signature
Re: HEADS UP: FreeBSD git mirrors demoted to beta status, need your help
Just a reminder that this re-roll will happen in almost two weeks. Thanks to a couple of volunteers, I now have independent confirmation that the process is deterministic and repeatable and the switch can progress as planned. Regards, Uli On Sat, 2012-12-15 at 14:22:46 +0100, Ulrich Spörlein wrote: > Bad news everyone, > > tl;dr The git mirror of the source repository needs to be re-rolled to > make the conversion deterministically repeatable, this will change > pretty much all git commit hashes. > > The re-roll will be done January 15, 2013. > > Not affected are the ports and doc repositories, nor is the svn_head > (for use with git-svn) affected. > > > Background > > The converter (svn2git) was handing commits and objects to git's > fast-import in arbitrary order, this makes merge commits have an > arbitrary order of their parent commits and thus these merge commits > have changing commit hashes for each converter run. > > This has been fixed, but requires us to move all the branches over to > this deterministic scheme, which will change all their commit hashes. > None of the contents of these commits change, so rebasing/remerging your > work into these branches is possible without running into any merge > conflicts. > > > We need your help > > A goal of these conversions is to have them repeatable by you (yes, > you!), so the correctness of the conversion can be verified. There are > also no backups of the conversion runs, as they should be repeatable > anyway. > > We need 2-3 volunteers to run these conversions themselves and verify > that the produced commit hashes match the published ones. The necessary > steps to do this are documented on the Wiki under > >http://wiki.freebsd.org/GitWorkflow#History > > Please send me your output of git show-ref in a private mail, thanks. > > Cheers, > Uli > > PS: This re-roll has nothing to do with the recent security incident. pgpg80dxm9pfi.pgp Description: PGP signature
