223758 |
04-Jul-2011 |
attilio |
With retirement of cpumask_t and usage of cpuset_t for representing a mask of CPUs, pc_other_cpus and pc_cpumask become highly inefficient.
Remove them and replace their usage with custom pc_cpuid magic (as, atm, pc_cpumask can be easilly represented by (1 << pc_cpuid) and pc_other_cpus by (all_cpus & ~(1 << pc_cpuid))).
This change is not targeted for MFC because of struct pcpu members removal and dependency by cpumask_t retirement.
MD review by: marcel, marius, alc Tested by: pluknet MD testing by: marcel, marius, gonzo, andreast
|
223667 |
29-Jun-2011 |
bz |
In case ntp cannot resolve a hostname on startup it will queue the entry for resolving by a child process that, upon success, will add the entry to the config of the running running parent process.
Unfortunately there are a couple of bugs with this, fixed in various later versions of upstream in potentially different ways due to other code changes:
1) Upon server [-46] <FQDN> the [-46] are used as FQDN for later resolving which does not work. Make sure we always pass the name (or IP there).
2) The intermediate file to carry the information to the child process does not know about -4/-6 restrictions, so that a dual-stacked host could resolve to an IPv6 address but that might be unreachable (see r223626) leading to no working synchronization ignoring a IPv4 record. Thus alter the intermediate format to also pass the address family (AF_UNSPEC (default), AF_INET or AF_INET6) to the child process depending on -4 or -6.
3) Make the child process to parse the new intermediate file format and save the address family for getaddrinfo() hints flags.
4) Change child to always reload resolv.conf calling res_init() before trying to resolve names. This will pick up resolv.conf changes or new resolv.confs should they have not existed or been empty or unusable on ntp startup. This fix is more conditional in upstream versions but given FreeBSD has res_init there is no need for the configure logic as well.
Approved by: roberto Sponsored by: Sandvine Incorporated MFC after: 9 days
|
223626 |
28-Jun-2011 |
bz |
Compare port numbers correctly. They are stored by SRCPORT() in host byte order, so we need to compare them as such. Properly compare IPv6 addresses as well.
This allows the, by default, 8 badaddrs slots per address family to work correctly and only print sendto() errors once.
The change is no longer applicable to any latest upstream versions.
Approved by: roberto Sponsored by: Sandvine Incorporated MFC after: 1 week
|
222813 |
07-Jun-2011 |
attilio |
etire the cpumask_t type and replace it with cpuset_t usage.
This is intended to fix the bug where cpu mask objects are capped to 32. MAXCPU, then, can now arbitrarely bumped to whatever value. Anyway, as long as several structures in the kernel are statically allocated and sized as MAXCPU, it is suggested to keep it as low as possible for the time being.
Technical notes on this commit itself: - More functions to handle with cpuset_t objects are introduced. The most notable are cpusetobj_ffs() (which calculates a ffs(3) for a cpuset_t object), cpusetobj_strprint() (which prepares a string representing a cpuset_t object) and cpusetobj_strscan() (which creates a valid cpuset_t starting from a string representation). - pc_cpumask and pc_other_cpus are target to be removed soon. With the moving from cpumask_t to cpuset_t they are now inefficient and not really useful. Anyway, for the time being, please note that access to pcpu datas is protected by sched_pin() in order to avoid migrating the CPU while reading more than one (possible) word - Please note that size of cpuset_t objects may differ between kernel and userland. While this is not directly related to the patch itself, it is good to understand that concept and possibly use the patch as a reference on how to deal with cpuset_t objects in userland, when accessing kernland members. - KTR_CPUMASK is changed and now is represented through a string, to be set as the example reported in NOTES.
Please additively note that no MAXCPU is bumped in this patch, but private testing has been done until to MAXCPU=128 on a real 8x8x2(htt) machine (amd64).
Please note that the FreeBSD version is not yet bumped because of the upcoming pcpu changes. However, note that this patch is not targeted for MFC.
People to thank for the time spent on this patch: - sbruno, pluknet and Nicholas Esborn (nick AT desert DOT net) tested several revision of the patches and really helped in improving stability of this work. - marius fixed several bugs in the sparc64 implementation and reviewed patches related to ktr. - jeff and jhb discussed the basic approach followed. - kib and marcel made targeted review on some specific part of the patch. - marius, art, nwhitehorn and andreast reviewed MD specific part of the patch. - marius, andreast, gonzo, nwhitehorn and jceel tested MD specific implementations of the patch. - Other people have made contributions on other patches that have been already committed and have been listed separately.
Companies that should be mentioned for having participated at several degrees: - Yahoo! for having offered the machines used for testing on big count of CPUs. - The FreeBSD Foundation for having sponsored my devsummit attendance, which has been instrumental. - Sandvine for having offered offices and infrastructure during development.
(I really hope I didn't forget anyone, if it happened I apologize in advance).
|
222444 |
29-May-2011 |
bz |
The argument to setsockopt for IP_MULTICAST_LOOP depends on operating system and is decided upon by configure and could be an u_int or a u_char. For FreeBSD it is a u_char.
For IPv6 however RFC 3493, 5.2 defines the argument to IPV6_MULTICAST_LOOP to be an unsigned integer so make sure we always use that using a second variable for the IPV6 case. This is to get rid of these error messages every 5 minutes on some systems: ntpd[1530]: setsockopt IPV6_MULTICAST_LOOP failure: Invalid argument on socket 22, addr fe80::... for multicast address ff02::101
While here also fix the copy&paste error in the log message for IPV6_MULTICAST_LOOP.
Reviewed by: roberto Sponsored by: The FreeBSD Foundation Sponsored by: iXsystems MFC after: 10 days Filed as: Bug 1936 on ntp.org
|
207736 |
07-May-2010 |
mckusick |
Merger of the quota64 project into head.
This joint work of Dag-Erling Smørgrav and myself updates the FFS quota system to support both traditional 32-bit and new 64-bit quotas (for those of you who want to put 2+Tb quotas on your users).
By default quotas are not compiled into the kernel. To include them in your kernel configuration you need to specify:
options QUOTA # Enable FFS quotas
If you are already running with the current 32-bit quotas, they should continue to work just as they have in the past. If you wish to convert to using 64-bit quotas, use `quotacheck -c 64'; if you wish to revert from 64-bit quotas back to 32-bit quotas, use `quotacheck -c 32'.
There is a new library of functions to simplify the use of the quota system, do `man quotafile' for details. If your application is currently using the quotactl(2), it is highly recommended that you convert your application to use the quotafile interface. Note that existing binaries will continue to work.
Special thanks to John Kozubik of rsync.net for getting me interested in pursuing 64-bit quota support and for funding part of my development time on this project.
|
195626 |
11-Jul-2009 |
cperciva |
Remove build timestamps from the following files: /boot/kernel/hptrr.ko /etc/mail/*.cf /lib/libcrypto.so.5 /usr/bin/ntpq /usr/sbin/amd /usr/sbin/iasl /usr/sbin/ntpd /usr/sbin/ntpdate /usr/sbin/ntpdc
There does not appear to be any purpose to having these timestamps, and they have the irritating consequence that the aforementioned files will be different every time they are rebuilt.
After this commit, the only remaining build timestamps are in the kernel, the boot loaders, /usr/include/osreldate.h (the year in the copyright notice), and lib*.a (the timestamps on all of the included .o files).
Reviewed by: scottl (hptrr), gshapiro (sendmail), simon (openssl), roberto (ntp), jkim (acpica) Approved by: re (kib)
|
54362 |
09-Dec-1999 |
roberto |
Please all welcome the long-awaited upgrade from our ancient xntpd 3.4f to a brand new and shiny ntpd 4.0.98f.
I got tired of waiting for 4.1.0 and there is the feature freeze deadline so here it is. This is the contrib/ part of the upgrade. The Makefile glue will be added very soon in usr.sbin.
It builds and runs on both i386 and alpha (Thanks Peter!).
The bad news is that manpages no longer exist, everything is in HTML. I'll commit the text version of each HTML file in /usr/share/doc/ntp soon to have at least the help files w/o needing to get the entire contrib/ntp tree.
I'll commit FREEBSD-Xlist as soon as I can skip over $FreeBSD$ checks...
Reviewed by: peter, obrien Pushed by: phk
|