Re: svn commit: r252032 - head/sys/amd64/include
On Sun, Jun 23, 2013 at 10:33:43AM +0300, Konstantin Belousov wrote: K On Sat, Jun 22, 2013 at 06:58:15PM +1000, Bruce Evans wrote: K So the i386 version be simply addl; adcl to memory. Each store in K this is atomic at the per-CPU level. If there is no carry, then the K separate stores are equivalent to adding separate nonnegative values and K the counter value is valid at all times. If there is carry, then the K separate stores are equivalent to adding a negative value followed by K a larger positive value. The counter transiently goes backwards, but K no information is lost and the counter is eventually set to the correct K forward-going value. K K This is quite interesting idea, but I still did not decided if it K acceptable. The issue is that we could add the carry to the other K processor counter, if the preemption kicks in at right time between K two instructions. I did not found any argument why would it be K wrong, the races for fetch operation seems to be the same with either K local update method. This would be wrong since update isn't locked. Thus, if we are put on other CPU between two instructions, and in second instruction updating another CPU counter simultaneously with the original CPU we were on, then we are losing an update. Yes, the probability of such event is extremely low, but still possible. The idea on counter(9) is that although fetching might be not precise, the internal value of a counter is consistent and doesn't lose even a single update. This would allow later to use counter(9) as a cheap reference counter. -- Totus tuus, Glebius. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r252032 - head/sys/amd64/include
Bruce, did you run your benchmarks in userland or in kernel? How many parallel threads were updating the same counter? Can you please share your benchmarks? -- Totus tuus, Glebius. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r252121 - in head/release/doc: en_US.ISO8859-1/errata share/xml
On Mon, Jun 24, 2013 at 02:30:38PM +0900, Hiroki Sato wrote: gj Author: gjb gj Date: Sun Jun 23 20:19:00 2013 gj New Revision: 252121 gj URL: http://svnweb.freebsd.org/changeset/base/252121 gj gj Log: gj Add a new macro, release.current.release, to denote the head/ branch gj with the -RELEASE suffix. This fixes the incorrect text on the -CURRENT gj errata page from showing '10.0-CURRENT' followed by 'until 9.1-RELEASE is gj released.' No, please revert this. release.next is correct, but the value cannot be defined meaningfully for a branch which has no release yet. Errata never works for head, so please leave it as-is. This errata document for FreeBSD 10.0-CURRENT will be maintained until the release of FreeBSD 10.0-RELEASE is still incorrect. The previous version was incorrect. Using release.next caused the page to display: This errata document for FreeBSD 10.0-CURRENT will be maintained until the release of FreeBSD 9.1-RELEASE. I do not see how my change is more incorrect than the previous version, but if you would still like it reverted, I will do so. Glen pgpKPI9MwkcSY.pgp Description: PGP signature
Urgent Order
Goodday , This is Barry Buckner i send this inquiry to your company in regards to order some Gorilla Tape i will like to know the types and sizes of Gorilla Tape you have.Immediate responds is require and advise on payment method. waiting to hear from you advise. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r252121 - in head/release/doc: en_US.ISO8859-1/errata share/xml
Glen Barber g...@freebsd.org wrote in 20130624084009.gk1...@glenbarber.us: gj On Mon, Jun 24, 2013 at 02:30:38PM +0900, Hiroki Sato wrote: gj gj Author: gjb gj gj Date: Sun Jun 23 20:19:00 2013 gj gj New Revision: 252121 gj gj URL: http://svnweb.freebsd.org/changeset/base/252121 gj gj gj gj Log: gj gj Add a new macro, release.current.release, to denote the head/ branch gj gj with the -RELEASE suffix. This fixes the incorrect text on the -CURRENT gj gj errata page from showing '10.0-CURRENT' followed by 'until 9.1-RELEASE is gj gj released.' gj gj No, please revert this. release.next is correct, but the value gj cannot be defined meaningfully for a branch which has no release yet. gj Errata never works for head, so please leave it as-is. This errata gj document for FreeBSD 10.0-CURRENT will be maintained until the gj release of FreeBSD 10.0-RELEASE is still incorrect. gj gj gj The previous version was incorrect. Using release.next caused the page gj to display: It is just because the value of release.next is not updated. Again, Errata for head never generates correct sentences *by design*. It only works in a branch and we do not need to touch a copy on head since it is a placeholder. If you want to fix the sentence, updating release.next is the correct way. I do not care about which release number is in the sentence, but please do not change entity names. gj I do not see how my change is more incorrect than the previous version, gj but if you would still like it reverted, I will do so. Please do. -- Hiroki pgpcX8JwBH2yw.pgp Description: PGP signature
svn commit: r252147 - in head/release/doc: en_US.ISO8859-1/errata share/xml
Author: gjb Date: Mon Jun 24 09:18:41 2013 New Revision: 252147 URL: http://svnweb.freebsd.org/changeset/base/252147 Log: Revert r252126, r252124, r252121. Submitted by: hrs Modified: head/release/doc/en_US.ISO8859-1/errata/article.xml head/release/doc/share/xml/release.ent Modified: head/release/doc/en_US.ISO8859-1/errata/article.xml == --- head/release/doc/en_US.ISO8859-1/errata/article.xml Mon Jun 24 09:14:38 2013(r252146) +++ head/release/doc/en_US.ISO8859-1/errata/article.xml Mon Jun 24 09:18:41 2013(r252147) @@ -28,7 +28,12 @@ pubdate$FreeBSD$/pubdate copyright - year2013/year + year2000/year + year2001/year + year2002/year + year2003/year + year2004/year + year2005/year holder role=mailto:d...@freebsd.org;The os; Documentation Project/holder /copyright @@ -51,8 +56,8 @@ should always be consulted before installing this version of os;./para -paraThis errata document for os; release; will be maintained - until the release of os; release.current.release;./para +paraThis errata document for os; release; + will be maintained until the release of os; release.next;./para /abstract sect1 id=intro Modified: head/release/doc/share/xml/release.ent == --- head/release/doc/share/xml/release.ent Mon Jun 24 09:14:38 2013 (r252146) +++ head/release/doc/share/xml/release.ent Mon Jun 24 09:18:41 2013 (r252147) @@ -6,9 +6,7 @@ !-- Version of the OS we're describing. This needs to be updated with each new release. -- -!ENTITY release.current.version 10.0 -!ENTITY release.current release.current.version;-CURRENT -!ENTITY release.current.release release.current.version;-RELEASE +!ENTITY release.current 10.0-CURRENT !-- The previous version used for comparison in the What's New section. For -CURRENT, we might point back to the last ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r251886 - in head: contrib/apr contrib/apr-util contrib/serf contrib/sqlite3 contrib/subversion share/mk usr.bin usr.bin/svn usr.bin/svn/lib usr.bin/svn/lib/libapr usr.bin/svn/lib/liba
On 2013-06-23 21:30, Peter Wemm wrote: On Sun, Jun 23, 2013 at 10:12 AM, Warner Losh i...@bsdimp.com wrote: On Jun 23, 2013, at 6:22 AM, Tijl Coosemans wrote: On 2013-06-23 04:43, Garance A Drosehn wrote: On 6/22/13 2:38 PM, Tijl Coosemans wrote: On 2013-06-20 21:34, Warner Losh wrote: I think insisting on a definitive statement on svn lite's mission statement is a way to obstruct progress. Sometimes you just need to things because they feel right, not because they have been through a 20-step approval process... For what it's worth, my reservations have always been because it didn't feel right. I never asked for an approval process. I do think there should be a tool in base that can fetch source updates and it would be nice if it could roll back changes and even nicer if it could do bisects. But svn itself is not the right tool for that. For instance, will you allow that svn is updated from version x.y to x.(y+1) in a stable branch? If yes, then users might have to run run svn upgrade which is a one way process, so how does importing svn allow you to roll back changes or do bisects then? If no, then who's volunteering to backport security fixes? What was added to the base system was 'svnlite', not 'svn' from the official subversion project. The distinction is that 'svnlite' is a version meant only for access to the official FreeBSD repositories. 'svnlite' in the base system would only be upgraded when it is needed to match the FreeBSD respository. And if you need to run 'svn upgrade' to access the FreeBSD repository, then it doesn't make much difference if you have to do that with 'svnlite' or via the official 'svn' port. I'm not sure that my comments provide an answer to what you're concerned about, but anyone who wants the latest version of 'svn' to match their own repositories is still going to need to install the port. We're not going to blindly update 'svnlite' every time a new version of 'svn' is released. 'svnlite' is going to be updated on *FreeBSD*'s schedule, not on the schedule of the subversion project. It is true that we're going to have to be careful when it does come time to switch to some new repo-format for the FreeBSD repository. We might find ourselves in some kind of chicken- and-egg situation at that point. And when we do make a significant upgrade to the FreeBSD repository, then we're going to have to upgrade 'svnlite' across multiple FreeBSD branches at the same time, including all -stable branches. But when that issue comes up it'll come up on our schedule, because we'll control both 'svnlite' and the FreeBSD repo. It is precisely the other way around. Once you do a FreeBSD release (releng branch) that release will be stuck with the same version of svnlite for years. You will end up with multiple releases with multiple versions of svnlite that you cannot change. You have zero control. Then they will never have to do svn update, since their checked out tree will never be obsolete in relationship to the version that's installed. They are on an errata branch. A port on the other hand is the same for all branches and releases of FreeBSD. It is a single point where you have total control over the version of svn for all users. Conceptually, a port corresponds to the fact all branches and releases share the same subversion repo. Except that you still need to do svn update on trees that are checked out from old repos. I'm having a real hard time seeing this as an issue based on my experience with the svn port since we made the switch. Then again, I've been talking to the svn repo over http, which is independent of the version of the repo on the other end... Subversion has been very good at forward and backward compatibility so let's assume it'll continue to be that way, then there's still the issue that at some point we'll switch away from it. We switched away from cvs, it'll happen with svn too someday (maybe with svn 1.x-2.0). And now we're setting everything up exactly the same as with cvs, just cvs-svn and cvsup-svnup, which means we'll see an exact repeat of the cvs-to-svn migration, a process that has taken 5 years of project resources already and is still ongoing for 8.3 users. All other users have already been forced to change their ways in the middle of stable branches. Don't you think it would be good to try to avoid that? As an example of inconvenient, take this clean 24 core system with 24 GB ram. Suppose I have a problem that I want to do a bisection search to see when it first appeared (right there, freebsd-update is excluded). Something to think about: what if your bisection window contains a new version of svnlite that requires running svnlite upgrade? # rm -rf /usr/local/* /var/db/pkg/* /var/db/ports/* then a config-recursive, taking default options to match packages: # cd /usr/ports/devel/subversion; time make config-recursive (immediately hitting enter) 41.693u 4.778s
Re: svn commit: r252032 - head/sys/amd64/include
On Mon, 24 Jun 2013, Gleb Smirnoff wrote:
did you run your benchmarks in userland or in kernel? How many
parallel threads were updating the same counter?
Can you please share your benchmarks?
Only userland, with 1 thread.
I don't have any more benchmarks than the test program in previous mail.
I don't see how threads have anything to do with efficiency of counter
incrementation, unless slow locking is used. With threads for the same
process on the same CPU, the accesses are not really different from
accesses by a single thread. With threads for different processes on
the same CPU, switching the address space will thrash the cache for
user threads, but the pcpu area in kernel memory shouldn't be switched.
It seems difficult to simulate pcpu in user address space. With threads
for the same or different processes on different CPUs, there is no
contention for pcpu counters.
Please remind me of your old tests that did show some efficiency
differences. IIRC, direct increment was unexpectedly slower. Was
that on a 64-bit system? I guess it wasn't, since the committed version
just uses a direct increment on amd64. On i386 with cmpxch86b, using
cmpxchg8b might be more efficient because it is a 64-bit access. I
don't see how that can be, since 4 32-bit accesses are needed to set
up the cmpxchg8b. In fact, 1 of these accesses can be extremely slow
since it has a store-to-load penalty on some arches (I have considerable
experience with store-to-load penalties in FP code and large uncommitted
asms in libm to avoid them.).
Here is the access which is likely to have the penalty:
% static inline void
% counter_64_inc_8b(uint64_t *p, int64_t inc)
% {
%
% __asm __volatile(
% movl %%fs:(%%esi),%%eax\n\t
The previous store was a cmpchg8b. Presumably that was 64 bits. No
problem for this load, since it is at the same address as the store
and its size mismatch doesn't have the penalty on any CPU that I
know of.
% movl %%fs:4(%%esi),%%edx\n
Store to load mismatch penalty on at least AthlonXP and Athlon64. The
load is from the middle of a 64-bit store, and at least these CPUs
don't have hardware to forward it from the write buffer. Costs 10-20
cycles. Phenom is documented to have extra hardware to make this case
as fast as the previous case. I haven't tested Pheonom. Acccording
to FP benchmarks, store-to-load penalties are large on core2 and corei7
too.
% 1:\n\t
% movl %%eax,%%ebx\n\t
% movl %%edx,%%ecx\n\t
% addl (%%edi),%%ebx\n\t
% adcl 4(%%edi),%%ecx\n\t
These extra memory accesses are unfortunately necessary because there
aren't enough registers and the asm is a bit too simple (e.g., to add
1, more complicated asm could just add $1 with carry here, but the
current asm has to store 1 to a 64-bit temporary memory variable so
that it can be loaded here). These are all 32-bit accesses so they
don't have penalties. There is just a lot of memory traffic for them.
% cmpxchg8b %%fs:(%%esi)\n\t
This presumably does a 64-bit load followed by a 64-bit store (when it
succeeds). The load matches the previous store, so there is no penalty.
% jnz 1b
% :
% : S ((char *)p - (char *)__pcpu[0]), D (inc)
% : memory, cc, eax, edx, ebx, ecx);
% }
The penalty may be unimportant in normal use because loads are normally
separated from stores by long enough to give the write buffers a chance
to flush to the cache. But loop benchmarks will always see it unless
loop does enough things between the store and the load to give the
large separation. Note that the penalty affects loads, so its latency
is normally not hidden.
I forgot about this when I ran tests on Athlon64. Athlon64 was only
about 6 cycles slower than core2, for about 20 cycles per iteration
altogther. Not much more, but 20 is about the penalty time, so maybe
the loop is ending up testing just the penalty time, with all the other
latencies in parallel with the penalty. For a quick test of this, I
replaced the load that has the penalty by a load of immediate 0. This
reduced the time to 14.5 cycles. So the penalty is at least 5.5 cycles.
(Note that in the benchmark, the counter only goes up to about 2
billion, so the high 32 bits always has value 0, so loading immediate
0 gives the same result.) On core2 (ref10-i386) and corei7 (freefall),
the same change has no effect on the time. This shows that the penalty
doesn't apply on core2 or corei7, and the FP penalties that I see there
have a different source. ... Testing shows that they are for loads
of 64-bit values that are mismatched since the value was built up using
2 32-bit stores. Test program:
% #include stdint.h
%
% uint64_t foo;
%
% int
% main(void)
% {
% unsigned i;
%
% for (i = 0; i 2666813872; i++) /* sysctl -n machdep.tsc_freq */
% asm volatile(
% #ifdef NO_PENALTY
% movq %%rax,foo; movq foo,%%rax
% : : : rax);
%
Re: svn commit: r252032 - head/sys/amd64/include
On Mon, 24 Jun 2013, Gleb Smirnoff wrote: On Sun, Jun 23, 2013 at 10:33:43AM +0300, Konstantin Belousov wrote: K On Sat, Jun 22, 2013 at 06:58:15PM +1000, Bruce Evans wrote: K So the i386 version be simply addl; adcl to memory. Each store in K this is atomic at the per-CPU level. If there is no carry, then the K separate stores are equivalent to adding separate nonnegative values and K the counter value is valid at all times. If there is carry, then the K separate stores are equivalent to adding a negative value followed by K a larger positive value. The counter transiently goes backwards, but K no information is lost and the counter is eventually set to the correct K forward-going value. K K This is quite interesting idea, but I still did not decided if it K acceptable. The issue is that we could add the carry to the other K processor counter, if the preemption kicks in at right time between K two instructions. I did not found any argument why would it be K wrong, the races for fetch operation seems to be the same with either K local update method. This would be wrong since update isn't locked. Thus, if we are put on other CPU between two instructions, and in second instruction updating another CPU counter simultaneously with the original CPU we were on, then we are losing an update. Hmm, this is subtle. The update is never lost, but is applied to different counter, non-atomically at a later time. Non-atomicity only matters when there is a carry since the counter only goes transiently backards in this case. For example: initial state: CPU1 counter: CPU2 counter: fffe Start adding 1 to the first counter, doing it non-atomically by incrementing the low word first. CPU1 counter: (carry in CPU1 eflags) CPU2 counter: fffe Get preempted at this point: CPU1 counter: CPU2 counter: fffe (carry in CPU2 eflags) The fetching code running at this point will see a wrong value, but has more serious bugs. Once it is fixed, it can try using a heuristic to detect this case, or the fix might involve a heuristic that detects this case too. I was thinking of keeping a global count of the previous value for each counter, and adding 0x1 when the count goes backwards. However, in the worst each component of a counter may be making the transition from 0x to 0x1, with the carry bit in eflags for all CPUs. Detecting this requires watching the low word of all components of all counters. Increments must be limited to considerably less than 32 bits, and negative increments should be disallowed, so that the low word doesn't wap faster than it can be watched. CPU2 runs and completes the increment by adding the carry to the high word: CPU1 counter: CPU2 counter: 0001 fffe The total count becomes correct once the second word is written. Statistics for each CPU should be correct, but losing this race is so rare that maybe we especially don't care about this subcase. There is currently no API for exporting the counter statistics for each CPU. Similarly if the preemption is to another thread on the same CPU, or to another thread that doesn't touch this counter and then back to the original thread (much later) on the same CPU. There may be any number of updates to the low word before the corresponding updates to the high word, mixed in any order except for the low word being updated before the high word for each increment. State for the half-done updates is saved in carry flags and registers in any number of threads. If large increments are allowed, the value may appear to have had many negative increments. Yes, the probability of such event is extremely low, but still possible. The idea on counter(9) is that although fetching might be not precise, the internal value of a counter is consistent and doesn't lose even a single update. This would allow later to use counter(9) as a cheap reference counter. The fetching code has essentially the same race (in the 32-bit case) that is laboriously worked around in the update code, irrespective of how atomic the update code is, even with 1 CPU: CPU1 counter: Start reading it on CPU1, using 32-bit load of the low word (the compiler could make this worse or just different by loading the high word first): (read this value) Get preempted; counter update occurs and adds 1 perfectly atomically: CPU1 counter: 0001 Back to fetching code on CPU1; read high word: 0001 (read this value; it is garbage) If the compiler loads the high word first, it will see the value off by ~2**32 in the opposite direction ( ). Like I said before, this can probably be handled by rereading each pcpu counter until it doesn't change. Or if large increments are not
svn commit: r252161 - head/sys/vm
Author: glebius Date: Mon Jun 24 13:36:16 2013 New Revision: 252161 URL: http://svnweb.freebsd.org/changeset/base/252161 Log: Typo in comment. Modified: head/sys/vm/vm_page.c Modified: head/sys/vm/vm_page.c == --- head/sys/vm/vm_page.c Mon Jun 24 12:46:59 2013(r252160) +++ head/sys/vm/vm_page.c Mon Jun 24 13:36:16 2013(r252161) @@ -2013,7 +2013,7 @@ vm_page_wire(vm_page_t m) * However, unless the page belongs to an object, it is not enqueued because * it cannot be paged out. * - * If a page is fictitious, then its wire count must alway be one. + * If a page is fictitious, then its wire count must always be one. * * A managed page must be locked. */ ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r252032 - head/sys/amd64/include
[snipping everything about counter64, atomic ops, cycles, etc.] I wonder if the idea explained in this paper: http://static.usenix.org/event/usenix03/tech/freenix03/full_papers/mcgarry/mcgarry_html/ Which seems to be used in FreeBSD for some ARM atomics: http://svnweb.freebsd.org/base/head/sys/arm/include/atomic.h?view=annotate , look for ARM_RAS_START would be more efficient. To summarize: one marks a section of code such that if a thread is interrupted during the code it restarts at the beginning instead of where it was interrupted. This has been used to implement atomic increment on some hardware without the necessary instructions. Here it could be used to implement atomic increment on the per-cpu counter without the overhead of an atomic instruction. It's multiple stores to mark the section of code doing the increment, but they're all per-cpu or per thread. That may be cheaper than an atomic increment, at least on 32-bit platforms that are doing an atomic 64-bit increment. I haven't benchmarked this (ENOTIME, plus I'm on vacation right now), but using restartable sections requires three stores (add an item to a linked list, 64-bit increment for the counter, remove an item from a linked list). Some of the penalty is payed in the context switch code, which has to check if the instruction pointer is in one of these critical sections. I haven't checked to see if this code is enabled on all architectures or just ARM. But if context switches are less frequent than counter increments in the networking code, it's still a win for most uses. Thanks, matthew ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r252032 - head/sys/amd64/include
On Sun, Jun 23, 2013 at 07:57:57PM +1000, Bruce Evans wrote:
The case that can't be fixed by rereading the counters is when fetching
code runs in between the stores. If the stores are on a another CPU
that is currently executing them, then we can keep checking that the
counters don't change for the maximum time that any pair of stores
take to complete. This time is quite long and difficult to determine
(but it can be bounded by hard-disabling interrupts in the storer, and
limited by prefetching). If the stores are on the same CPU, then we
have no good way to detect that another thread is in the middle of
them, or to switch back to that thread. So we currently prevent this
case using slow methods.
We are already explicit about the fetched value potentially not
reflecting any real moment value, but indeed, having the fetch result
off by 2^32 is not acceptable.
We need atomic 64bit loads to fix this, which is provided by the same
cmpxchg8b instruction on the 8-byte aligned elements. Intel guarantees
that 8-byte aligned loads and stores are atomic.
The following is the prototype for the x86. The other 64bit
architectures are handled exactly like amd64. For 32bit !x86 arches,
i.e. arm, mips32 and powerpc32, some more investigation is needed.
diff --git a/sys/amd64/include/counter.h b/sys/amd64/include/counter.h
index b37a4b8..ba302a3 100644
--- a/sys/amd64/include/counter.h
+++ b/sys/amd64/include/counter.h
@@ -36,6 +36,28 @@ extern struct pcpu __pcpu[1];
#definecounter_enter() do {} while (0)
#definecounter_exit() do {} while (0)
+#ifdef IN_SUBR_COUNTER_C
+static inline uint64_t
+counter_u64_fetch_inline(uint64_t *p)
+{
+ uint64_t r;
+ int i;
+
+ r = 0;
+ for (i = 0; i mp_ncpus; i++)
+ r += counter_u64_read_one((uint64_t *)c, i);
+
+ return (r);
+}
+#endif
+
+static inline uint64_t
+counter_u64_read_one(uint64_t *p, int cpu)
+{
+
+ return (*(uint64_t *)((char *)p + sizeof(struct pcpu) * cpu));
+}
+
#definecounter_u64_add_protected(c, i) counter_u64_add(c, i)
static inline void
diff --git a/sys/i386/include/counter.h b/sys/i386/include/counter.h
index 3e93b36..94dbee3 100644
--- a/sys/i386/include/counter.h
+++ b/sys/i386/include/counter.h
@@ -67,6 +67,50 @@ counter_64_inc_8b(uint64_t *p, int64_t inc)
: memory, cc, eax, edx, ebx, ecx);
}
+static inline uint64_t
+counter_u64_read_one_8b(uint64_t *p, int cpu)
+{
+ uint32_t res_lo, res_high;
+
+ __asm __volatile(
+ movl %%eax,%%ebx\n\t
+ movl %%edx,%%ecx\n\t
+ cmpxchg8b (%%esi)
+ : =a (res_lo), =d(res_high)
+ : S ((char *)p + sizeof(struct pcpu) * cpu)
+ : cc, ebx, ecx);
+ return (res_lo + ((uint64_t)res_high 32));
+}
+
+#ifdef IN_SUBR_COUNTER_C
+static inline uint64_t
+counter_u64_fetch_inline(uint64_t *p)
+{
+ uint64_t res;
+ int i;
+
+ res = 0;
+ if ((cpu_feature CPUID_CX8) == 0) {
+ /*
+* The machines without cmpxchg8b are not SMP.
+* Disabling the preemption provides atomicity of the
+* counter reading, since update is done in the
+* critical section as well.
+*/
+ critical_enter();
+ for (i = 0; i mp_ncpus; i++) {
+ res += *(uint64_t *)((char *)p +
+ sizeof(struct pcpu) * i);
+ }
+ critical_exit();
+ } else {
+ for (i = 0; i mp_ncpus; i++)
+ res += counter_u64_read_one_8b(p, i);
+ }
+ return (res);
+}
+#endif
+
#definecounter_u64_add_protected(c, inc) do {\
if ((cpu_feature CPUID_CX8) == 0) { \
CRITICAL_ASSERT(curthread); \
diff --git a/sys/kern/subr_counter.c b/sys/kern/subr_counter.c
index a98ed40..3222881 100644
--- a/sys/kern/subr_counter.c
+++ b/sys/kern/subr_counter.c
@@ -29,11 +29,13 @@ __FBSDID($FreeBSD$);
#include sys/param.h
#include sys/systm.h
-#include sys/counter.h
#include sys/kernel.h
#include sys/smp.h
#include sys/sysctl.h
#include vm/uma.h
+
+#define IN_SUBR_COUNTER_C
+#include sys/counter.h
static uma_zone_t uint64_pcpu_zone;
@@ -49,14 +51,8 @@ counter_u64_zero(counter_u64_t c)
uint64_t
counter_u64_fetch(counter_u64_t c)
{
- uint64_t r;
- int i;
- r = 0;
- for (i = 0; i mp_ncpus; i++)
- r += *(uint64_t *)((char *)c + sizeof(struct pcpu) * i);
-
- return (r);
+ return (counter_u64_fetch_inline(c));
}
counter_u64_t
pgpYUibcqooBj.pgp
Description: PGP signature
svn commit: r252166 - head/sys/dev/pci
Author: jhb Date: Mon Jun 24 18:30:44 2013 New Revision: 252166 URL: http://svnweb.freebsd.org/changeset/base/252166 Log: Disable hw.pci.realloc_bars by default. It wasn't needed for the original tester of this fix, and realloc_bars breaks some other cases as a small BAR that is reallocated can end up grabbing space needed by a much larger BAR in the existing window of a PCI-PCI bridge. MFC after:3 days Modified: head/sys/dev/pci/pci.c Modified: head/sys/dev/pci/pci.c == --- head/sys/dev/pci/pci.c Mon Jun 24 18:27:44 2013(r252165) +++ head/sys/dev/pci/pci.c Mon Jun 24 18:30:44 2013(r252166) @@ -280,7 +280,7 @@ SYSCTL_INT(_hw_pci, OID_AUTO, enable_io_ enable these bits correctly. We'd like to do this all the time, but there\n\ are some peripherals that this causes problems with.); -static int pci_do_realloc_bars = 1; +static int pci_do_realloc_bars = 0; TUNABLE_INT(hw.pci.realloc_bars, pci_do_realloc_bars); SYSCTL_INT(_hw_pci, OID_AUTO, realloc_bars, CTLFLAG_RW, pci_do_realloc_bars, 0, ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r251422 - in head: contrib/bmake usr.bin/bmake
On 2013-06-05 18:12, Simon J. Gerraty wrote:
Author: sjg
Date: Wed Jun 5 16:12:50 2013
New Revision: 251422
URL: http://svnweb.freebsd.org/changeset/base/251422
Log:
Update to bmake-20130604 to fix file descriptor leak.
Modified: head/contrib/bmake/job.c
==
--- head/contrib/bmake/job.c Wed Jun 5 15:52:24 2013(r251421)
+++ head/contrib/bmake/job.c Wed Jun 5 16:12:50 2013(r251422)
@@ -1,4 +1,4 @@
-/* $NetBSD: job.c,v 1.172 2013/03/05 22:01:43 christos Exp $ */
+/* $NetBSD: job.c,v 1.173 2013/06/05 03:59:43 sjg Exp $*/
/*
* Copyright (c) 1988, 1989, 1990 The Regents of the University of
California.
@@ -70,14 +70,14 @@
*/
#ifndef MAKE_NATIVE
-static char rcsid[] = $NetBSD: job.c,v 1.172 2013/03/05 22:01:43 christos
Exp $;
+static char rcsid[] = $NetBSD: job.c,v 1.173 2013/06/05 03:59:43 sjg Exp $;
#else
#include sys/cdefs.h
#ifndef lint
#if 0
static char sccsid[] = @(#)job.c8.2 (Berkeley) 3/19/94;
#else
-__RCSID($NetBSD: job.c,v 1.172 2013/03/05 22:01:43 christos Exp $);
+__RCSID($NetBSD: job.c,v 1.173 2013/06/05 03:59:43 sjg Exp $);
#endif
#endif /* not lint */
#endif
@@ -414,6 +414,15 @@ JobCreatePipe(Job *job, int minfd)
if (pipe(job-jobPipe) == -1)
Punt(Cannot create pipe: %s, strerror(errno));
+for (i = 0; i 2; i++) {
+ /* Avoid using low numbered fds */
+ fd = fcntl(job-jobPipe[i], F_DUPFD, minfd);
+ if (fd != -1) {
+close(job-jobPipe[i]);
+job-jobPipe[i] = fd;
+ }
+}
+
/* Set close-on-exec flag for both */
(void)fcntl(job-jobPipe[0], F_SETFD, 1);
(void)fcntl(job-jobPipe[1], F_SETFD, 1);
I've been noticing that bmake doesn't run parallel jobs as like fmake.
I've attached a Makefile that I think shows what's going wrong.
If you run make -j4 it outputs the following:
===
--- all ---
-j 4 -i -J 15,16
4
-j 4 -i
4
--- sub_2 ---
-j 4 -i -J 15,16
4
-j 4 -i
4
===
Bmake outputs the target name in -j mode (e.g. --- all ---), but
there's no --- sub_1 --- and --- sub_3 --- which suggests -j isn't
working there. The -J flag also doesn't appear in .MAKEFLAGS in those
targets.
I suspect the descriptors for the job server have to remain open so
submakes can pick them up. At least, when I comment out the two fcntl
calls above (and two more below), I do get the output I expect:
===
--- all ---
-j 4 -J 15,16
4
--- sub_1 ---
-j 4 -J 15,16
4
--- sub_2 ---
-j 4 -J 15,16
4
--- sub_3 ---
-j 4 -J 15,16
4
===
@@ -426,15 +435,6 @@ JobCreatePipe(Job *job, int minfd)
*/
fcntl(job-jobPipe[0], F_SETFL,
fcntl(job-jobPipe[0], F_GETFL, 0) | O_NONBLOCK);
-
-for (i = 0; i 2; i++) {
- /* Avoid using low numbered fds */
- fd = fcntl(job-jobPipe[i], F_DUPFD, minfd);
- if (fd != -1) {
-close(job-jobPipe[i]);
-job-jobPipe[i] = fd;
- }
-}
}
/*-
@@ -2828,6 +2828,8 @@ Job_ServerStart(int max_tokens, int jp_0
/* Pipe passed in from parent */
tokenWaitJob.inPipe = jp_0;
tokenWaitJob.outPipe = jp_1;
+ (void)fcntl(jp_0, F_SETFD, 1);
+ (void)fcntl(jp_1, F_SETFD, 1);
These two fcntl calls have to be commented out too.
all:
@echo ${.MAKEFLAGS}
@echo ${.MAKE.JOBS}
@${MAKE} sub_1
sub_1:
@echo ${.MAKEFLAGS}
@echo ${.MAKE.JOBS}
@${MAKE} sub_2
sub_2:
@echo ${.MAKEFLAGS}
@echo ${.MAKE.JOBS}
@${MAKE} sub_3
sub_3:
@echo ${.MAKEFLAGS}
@echo ${.MAKE.JOBS}
signature.asc
Description: OpenPGP digital signature
svn commit: r252170 - head/lib/msun/src
Author: eadler
Date: Mon Jun 24 19:12:17 2013
New Revision: 252170
URL: http://svnweb.freebsd.org/changeset/base/252170
Log:
Make the order of operations for lib/msun more clear.
Tested with md5 sum of object code
Reported by: swild...@dragonflybsd.org
Submitted by: bde
Modified:
head/lib/msun/src/s_fma.c
head/lib/msun/src/s_fmal.c
Modified: head/lib/msun/src/s_fma.c
==
--- head/lib/msun/src/s_fma.c Mon Jun 24 18:41:28 2013(r252169)
+++ head/lib/msun/src/s_fma.c Mon Jun 24 19:12:17 2013(r252170)
@@ -117,7 +117,7 @@ add_and_denormalize(double a, double b,
if (sum.lo != 0) {
EXTRACT_WORD64(hibits, sum.hi);
bits_lost = -((int)(hibits 52) 0x7ff) - scale + 1;
- if (bits_lost != 1 ^ (int)(hibits 1)) {
+ if ((bits_lost != 1) ^ (int)(hibits 1)) {
/* hibits += (int)copysign(1.0, sum.hi * sum.lo) */
EXTRACT_WORD64(lobits, sum.lo);
hibits += 1 - (((hibits ^ lobits) 62) 2);
Modified: head/lib/msun/src/s_fmal.c
==
--- head/lib/msun/src/s_fmal.c Mon Jun 24 18:41:28 2013(r252169)
+++ head/lib/msun/src/s_fmal.c Mon Jun 24 19:12:17 2013(r252170)
@@ -113,7 +113,7 @@ add_and_denormalize(long double a, long
if (sum.lo != 0) {
u.e = sum.hi;
bits_lost = -u.bits.exp - scale + 1;
- if (bits_lost != 1 ^ (int)(u.bits.manl 1))
+ if ((bits_lost != 1) ^ (int)(u.bits.manl 1))
sum.hi = nextafterl(sum.hi, INFINITY * sum.lo);
}
return (ldexp(sum.hi, scale));
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
svn commit: r252174 - head/usr.sbin/mergemaster
Author: eadler Date: Mon Jun 24 19:57:25 2013 New Revision: 252174 URL: http://svnweb.freebsd.org/changeset/base/252174 Log: Remove request to email suggestions and fixes to the author. He is no longer involved with the FreeBSD project. While here: remove no known bugs and related. This isn't present in other manual pages. PR: docs/179914 Modified: head/usr.sbin/mergemaster/mergemaster.8 Modified: head/usr.sbin/mergemaster/mergemaster.8 == --- head/usr.sbin/mergemaster/mergemaster.8 Mon Jun 24 19:28:36 2013 (r252173) +++ head/usr.sbin/mergemaster/mergemaster.8 Mon Jun 24 19:57:25 2013 (r252174) @@ -474,11 +474,3 @@ make world tutorial which is referenced .Sh AUTHORS This manual page and the script itself were written by .An Douglas Barton Aq do...@freebsd.org . -.Sh BUGS -There are no known bugs. -Please report any problems, -comments or suggestions to the author. -Several of the -improvements to this program have come from user -suggestions. -Thank you. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
svn commit: r252175 - head/tools/build/mk
Author: eadler
Date: Mon Jun 24 20:36:12 2013
New Revision: 252175
URL: http://svnweb.freebsd.org/changeset/base/252175
Log:
Add missing Obsolete Files
Submitted by: Kurt Lidl l...@pi-coral.com
Modified:
head/tools/build/mk/OptionalObsoleteFiles.inc
Modified: head/tools/build/mk/OptionalObsoleteFiles.inc
==
--- head/tools/build/mk/OptionalObsoleteFiles.inc Mon Jun 24 19:57:25
2013(r252174)
+++ head/tools/build/mk/OptionalObsoleteFiles.inc Mon Jun 24 20:36:12
2013(r252175)
@@ -388,6 +388,9 @@ OLD_FILES+=var/named/etc/namedb/PROTO.lo
OLD_FILES+=var/named/etc/namedb/make-localhost
#OLD_FILES+=var/named/etc/namedb/named.conf# intentionally left out
OLD_FILES+=var/named/etc/namedb/named.root
+OLD_FILES+=var/named/etc/namedb/master/empty.db
+OLD_FILES+=var/named/etc/namedb/master/localhost-forward.db
+OLD_FILES+=var/named/etc/namedb/master/localhost-reverse.db
OLD_DIRS+=var/named/etc/namedb/slave
OLD_DIRS+=var/named/etc/namedb/master
OLD_DIRS+=var/named/etc/namedb/dynamic
@@ -1553,6 +1556,7 @@ OLD_FILES+=usr/include/gcc/4.2/mmintrin.
OLD_FILES+=usr/include/gcc/4.2/pmmintrin.h
OLD_FILES+=usr/include/gcc/4.2/tmmintrin.h
OLD_FILES+=usr/include/gcc/4.2/xmmintrin.h
+OLD_FILES+=usr/include/gcc/4.2/mm3dnow.h
.elif ${TARGET_ARCH} == ia64
OLD_FILES+=usr/include/gcc/4.2/ia64intrin.h
.elif ${TARGET_ARCH} == arm
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
svn commit: r252176 - head/contrib/gcc
Author: pfg
Date: Mon Jun 24 20:38:27 2013
New Revision: 252176
URL: http://svnweb.freebsd.org/changeset/base/252176
Log:
gcc: add some configuration and references.
-Add configure support for FreeBSD 10 and 11.
-Adapt a threading fix to gnu POSIX95 (which we don't use).
-Refer to a bug fix for the disabled vrptree support.
This is all useless in our current build but it is included
for convenience in case someone may want to re-package our
older gcc.
Reviewed by: gerald (long ago)
Modified:
head/contrib/gcc/config.gcc
head/contrib/gcc/gthr-posix95.h
head/contrib/gcc/opts.c
Modified: head/contrib/gcc/config.gcc
==
--- head/contrib/gcc/config.gcc Mon Jun 24 20:36:12 2013(r252175)
+++ head/contrib/gcc/config.gcc Mon Jun 24 20:38:27 2013(r252176)
@@ -428,6 +428,10 @@ case ${target} in
tm_defines=${tm_defines} FBSD_MAJOR=8 ;;
*-*-freebsd9 | *-*-freebsd[9].*)
tm_defines=${tm_defines} FBSD_MAJOR=9 ;;
+*-*-freebsd10 | *-*-freebsd[10].*)
+ tm_defines=${tm_defines} FBSD_MAJOR=10 ;;
+*-*-freebsd11 | *-*-freebsd[11].*)
+ tm_defines=${tm_defines} FBSD_MAJOR=11 ;;
*)
echo 'Please update *-*-freebsd* in gcc/config.gcc'
exit 1
Modified: head/contrib/gcc/gthr-posix95.h
==
--- head/contrib/gcc/gthr-posix95.h Mon Jun 24 20:36:12 2013
(r252175)
+++ head/contrib/gcc/gthr-posix95.h Mon Jun 24 20:38:27 2013
(r252176)
@@ -115,9 +115,15 @@ __gthrw(pthread_setschedparam)
it is passed so we cannot pretend that the interface is active if -pthreads
is not specified. On Solaris 2.5.1, the interface is not exposed at all so
we need to play the usual game with weak symbols. On Solaris 10 and up, a
- working interface is always exposed. */
+ working interface is always exposed. On FreeBSD 6 and later, libc also
+ exposes a dummy POSIX threads interface, similar to what Solaris 2.6 up
+ to 9 does. FreeBSD = 700014 even provides a pthread_cancel stub in libc,
+ which means the alternate __gthread_active_p below cannot be used there. */
-#if defined(__sun) defined(__svr4__)
+
+ */
+
+#if defined(__FreeBSD__) || defined(__sun) defined(__svr4__)
static volatile int __gthread_active = -1;
@@ -160,7 +166,7 @@ __gthread_active_p (void)
return __gthread_active_latest_value != 0;
}
-#else /* not Solaris */
+#else /* neither FreeBSD nor Solaris */
static inline int
__gthread_active_p (void)
@@ -170,7 +176,7 @@ __gthread_active_p (void)
return __gthread_active_ptr != 0;
}
-#endif /* Solaris */
+#endif /* FreeBSD or Solaris */
#else /* not SUPPORTS_WEAK */
Modified: head/contrib/gcc/opts.c
==
--- head/contrib/gcc/opts.c Mon Jun 24 20:36:12 2013(r252175)
+++ head/contrib/gcc/opts.c Mon Jun 24 20:38:27 2013(r252176)
@@ -504,7 +504,7 @@ decode_options (unsigned int argc, const
/* XXX: some issues with ports have been traced to -ftree-vrp.
So remove it from -O2 and above. Note that jdk1{5,6} are affected
and they build with w/-O3 - so we cannot just move it to -O3. */
- // flag_tree_vrp = 1;
+ /* flag_tree_vrp = 1; // See GCC tree-optimization/33099 */
if (!optimize_size)
{
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
svn commit: r252177 - head/usr.sbin/bsdconfig
Author: dteske Date: Mon Jun 24 20:39:07 2013 New Revision: 252177 URL: http://svnweb.freebsd.org/changeset/base/252177 Log: Whitespace. Modified: head/usr.sbin/bsdconfig/bsdconfig Modified: head/usr.sbin/bsdconfig/bsdconfig == --- head/usr.sbin/bsdconfig/bsdconfig Mon Jun 24 20:38:27 2013 (r252176) +++ head/usr.sbin/bsdconfig/bsdconfig Mon Jun 24 20:39:07 2013 (r252177) @@ -263,8 +263,8 @@ while getopts f:h$GETOPTS_STDARGS flag; case $flag in f) [ $scripts_loaded -eq 0 ] f_include $BSDCFG_SHARE/script.subr f_script_load $OPTARG - scripts_loaded=$(( $scripts_loaded + 1 ));; - h|\?) usage;; + scripts_loaded=$(( $scripts_loaded + 1 )) ;; + h|\?) usage ;; esac done shift $(( $OPTIND -1 )) ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
svn commit: r252178 - in head/usr.sbin/bsdconfig: . console diskmgmt docsinstall dot mouse networking networking/share packages password security share share/media share/packages startup timezone t...
Author: dteske Date: Mon Jun 24 20:58:54 2013 New Revision: 252178 URL: http://svnweb.freebsd.org/changeset/base/252178 Log: More whitespace. Modified: head/usr.sbin/bsdconfig/bsdconfig head/usr.sbin/bsdconfig/console/console head/usr.sbin/bsdconfig/console/font head/usr.sbin/bsdconfig/console/keymap head/usr.sbin/bsdconfig/console/repeat head/usr.sbin/bsdconfig/console/saver head/usr.sbin/bsdconfig/console/screenmap head/usr.sbin/bsdconfig/console/ttys head/usr.sbin/bsdconfig/diskmgmt/diskmgmt head/usr.sbin/bsdconfig/docsinstall/docsinstall head/usr.sbin/bsdconfig/dot/dot head/usr.sbin/bsdconfig/mouse/disable head/usr.sbin/bsdconfig/mouse/enable head/usr.sbin/bsdconfig/mouse/flags head/usr.sbin/bsdconfig/mouse/mouse head/usr.sbin/bsdconfig/mouse/port head/usr.sbin/bsdconfig/mouse/type head/usr.sbin/bsdconfig/networking/defaultrouter head/usr.sbin/bsdconfig/networking/devices head/usr.sbin/bsdconfig/networking/hostname head/usr.sbin/bsdconfig/networking/nameservers head/usr.sbin/bsdconfig/networking/networking head/usr.sbin/bsdconfig/networking/share/device.subr head/usr.sbin/bsdconfig/networking/share/hostname.subr head/usr.sbin/bsdconfig/networking/share/ipaddr.subr head/usr.sbin/bsdconfig/networking/share/media.subr head/usr.sbin/bsdconfig/networking/share/netmask.subr head/usr.sbin/bsdconfig/networking/share/resolv.subr head/usr.sbin/bsdconfig/packages/packages head/usr.sbin/bsdconfig/password/password head/usr.sbin/bsdconfig/security/kern_securelevel head/usr.sbin/bsdconfig/security/security head/usr.sbin/bsdconfig/share/common.subr head/usr.sbin/bsdconfig/share/device.subr head/usr.sbin/bsdconfig/share/dialog.subr head/usr.sbin/bsdconfig/share/media/tcpip.subr head/usr.sbin/bsdconfig/share/packages/packages.subr head/usr.sbin/bsdconfig/share/sysrc.subr head/usr.sbin/bsdconfig/startup/misc head/usr.sbin/bsdconfig/startup/rcadd head/usr.sbin/bsdconfig/startup/rcconf head/usr.sbin/bsdconfig/startup/rcdelete head/usr.sbin/bsdconfig/startup/rcedit head/usr.sbin/bsdconfig/startup/rcvar head/usr.sbin/bsdconfig/startup/startup head/usr.sbin/bsdconfig/timezone/timezone head/usr.sbin/bsdconfig/ttys/ttys head/usr.sbin/bsdconfig/usermgmt/groupadd head/usr.sbin/bsdconfig/usermgmt/groupdel head/usr.sbin/bsdconfig/usermgmt/groupedit head/usr.sbin/bsdconfig/usermgmt/groupinput head/usr.sbin/bsdconfig/usermgmt/share/user_input.subr head/usr.sbin/bsdconfig/usermgmt/useradd head/usr.sbin/bsdconfig/usermgmt/userdel head/usr.sbin/bsdconfig/usermgmt/useredit head/usr.sbin/bsdconfig/usermgmt/userinput head/usr.sbin/bsdconfig/usermgmt/usermgmt Modified: head/usr.sbin/bsdconfig/bsdconfig == --- head/usr.sbin/bsdconfig/bsdconfig Mon Jun 24 20:39:07 2013 (r252177) +++ head/usr.sbin/bsdconfig/bsdconfig Mon Jun 24 20:58:54 2013 (r252178) @@ -340,7 +340,7 @@ while :; do f_getvar menu_program$mtag menu_program case $menu_program in - /*) cmd=$menu_program;; + /*) cmd=$menu_program ;; *) cmd=$BSDCFG_LIBE/$menu_program esac f_dprintf cmd=[%s] $cmd Modified: head/usr.sbin/bsdconfig/console/console == --- head/usr.sbin/bsdconfig/console/console Mon Jun 24 20:39:07 2013 (r252177) +++ head/usr.sbin/bsdconfig/console/console Mon Jun 24 20:58:54 2013 (r252178) @@ -102,7 +102,7 @@ dialog_menu_main() # while getopts h$GETOPTS_STDARGS flag; do case $flag in - h|\?) f_usage $BSDCFG_LIBE/$APP_DIR/USAGE PROGRAM_NAME $pgm;; + h|\?) f_usage $BSDCFG_LIBE/$APP_DIR/USAGE PROGRAM_NAME $pgm ;; esac done shift $(( $OPTIND - 1 )) Modified: head/usr.sbin/bsdconfig/console/font == --- head/usr.sbin/bsdconfig/console/fontMon Jun 24 20:39:07 2013 (r252177) +++ head/usr.sbin/bsdconfig/console/fontMon Jun 24 20:58:54 2013 (r252178) @@ -122,7 +122,7 @@ dialog_menu_main() # while getopts h$GETOPTS_STDARGS flag; do case $flag in - h|\?) f_usage $BSDCFG_LIBE/$APP_DIR/USAGE PROGRAM_NAME $pgm;; + h|\?) f_usage $BSDCFG_LIBE/$APP_DIR/USAGE PROGRAM_NAME $pgm ;; esac done shift $(( $OPTIND - 1 )) Modified: head/usr.sbin/bsdconfig/console/keymap == --- head/usr.sbin/bsdconfig/console/keymap Mon Jun 24 20:39:07 2013 (r252177) +++ head/usr.sbin/bsdconfig/console/keymap Mon Jun 24 20:58:54 2013 (r252178) @@ -221,7 +221,7 @@ dialog_menu_main() # while getopts h$GETOPTS_STDARGS flag; do case $flag in - h|\?) f_usage $BSDCFG_LIBE/$APP_DIR/USAGE PROGRAM_NAME $pgm;; + h|\?) f_usage $BSDCFG_LIBE/$APP_DIR/USAGE
svn commit: r252179 - head/contrib/gcc
Author: pfg
Date: Mon Jun 24 21:13:58 2013
New Revision: 252179
URL: http://svnweb.freebsd.org/changeset/base/252179
Log:
gcc: configuration fix.
-Fix configuration support for FreeBSD 10 and 11.
Note this change is based on GCC-SVN-131197 with permission
by gerald@ .
Reported by: jmallet
Modified:
head/contrib/gcc/config.gcc
Modified: head/contrib/gcc/config.gcc
==
--- head/contrib/gcc/config.gcc Mon Jun 24 20:58:54 2013(r252178)
+++ head/contrib/gcc/config.gcc Mon Jun 24 21:13:58 2013(r252179)
@@ -428,9 +428,9 @@ case ${target} in
tm_defines=${tm_defines} FBSD_MAJOR=8 ;;
*-*-freebsd9 | *-*-freebsd[9].*)
tm_defines=${tm_defines} FBSD_MAJOR=9 ;;
-*-*-freebsd10 | *-*-freebsd[10].*)
+*-*-freebsd10 | *-*-freebsd10.*)
tm_defines=${tm_defines} FBSD_MAJOR=10 ;;
-*-*-freebsd11 | *-*-freebsd[11].*)
+*-*-freebsd11 | *-*-freebsd11.*)
tm_defines=${tm_defines} FBSD_MAJOR=11 ;;
*)
echo 'Please update *-*-freebsd* in gcc/config.gcc'
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
svn commit: r252180 - head/sys/dev/mpt
Author: marius
Date: Mon Jun 24 21:27:15 2013
New Revision: 252180
URL: http://svnweb.freebsd.org/changeset/base/252180
Log:
Flag mpt(4) as supporting unmapped I/O; all necessary conversion actually
already has been done as part of r246713 except for a comment update.
MFC after:3 days
Modified:
head/sys/dev/mpt/mpt_cam.c
Modified: head/sys/dev/mpt/mpt_cam.c
==
--- head/sys/dev/mpt/mpt_cam.c Mon Jun 24 21:13:58 2013(r252179)
+++ head/sys/dev/mpt/mpt_cam.c Mon Jun 24 21:27:15 2013(r252180)
@@ -1254,7 +1254,8 @@ mpt_timeout(void *arg)
}
/*
- * Callback routine from bus_dmamap_load or, in simple cases, called
directly.
+ * Callback routine from bus_dmamap_load_ccb(9) or, in simple cases, called
+ * directly.
*
* Takes a list of physical segments and builds the SGL for SCSI IO command
* and forwards the commard to the IOC after one last check that CAM has not
@@ -1688,7 +1689,6 @@ mpt_execute_req(void *arg, bus_dma_segme
hdrp = req-req_vbuf;
mpt_off = req-req_vbuf;
-
if (error == 0 ((uint32_t)nseg) = mpt-max_seg_cnt) {
error = EFBIG;
}
@@ -3595,21 +3595,21 @@ mpt_action(struct cam_sim *sim, union cc
#ifdef CAM_NEW_TRAN_CODE
cpi-protocol = PROTO_SCSI;
if (mpt-is_fc) {
- cpi-hba_misc = PIM_NOBUSRESET;
+ cpi-hba_misc = PIM_NOBUSRESET | PIM_UNMAPPED;
cpi-base_transfer_speed = 10;
cpi-hba_inquiry = PI_TAG_ABLE;
cpi-transport = XPORT_FC;
cpi-transport_version = 0;
cpi-protocol_version = SCSI_REV_SPC;
} else if (mpt-is_sas) {
- cpi-hba_misc = PIM_NOBUSRESET;
+ cpi-hba_misc = PIM_NOBUSRESET | PIM_UNMAPPED;
cpi-base_transfer_speed = 30;
cpi-hba_inquiry = PI_TAG_ABLE;
cpi-transport = XPORT_SAS;
cpi-transport_version = 0;
cpi-protocol_version = SCSI_REV_SPC2;
} else {
- cpi-hba_misc = PIM_SEQSCAN;
+ cpi-hba_misc = PIM_SEQSCAN | PIM_UNMAPPED;
cpi-base_transfer_speed = 3300;
cpi-hba_inquiry = PI_SDTR_ABLE|PI_TAG_ABLE|PI_WIDE_16;
cpi-transport = XPORT_SPI;
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r251886 - in head: contrib/apr contrib/apr-util contrib/serf contrib/sqlite3 contrib/subversion share/mk usr.bin usr.bin/svn usr.bin/svn/lib usr.bin/svn/lib/libapr usr.bin/svn/lib/liba
Hi Peter, On Tue, Jun 18, 2013 at 02:53:45AM +, Peter Wemm wrote: Author: peter Date: Tue Jun 18 02:53:45 2013 New Revision: 251886 URL: http://svnweb.freebsd.org/changeset/base/251886 Log: Introduce svnlite so that we can check out our source code again. This is actually a fully functional build except: * All internal shared libraries are static linked to make sure there is no interference with ports (and to reduce build time). * It does not have the python/perl/etc plugin or API support. * By default, it installs as svnlite rather than svn. * If WITH_SVN added in make.conf, you get svn. * If WITHOUT_SVNLITE is in make.conf, this is completely disabled. To be absolutely clear, this is not intended for any use other than checking out freebsd source and committing, like we once did with cvs. It should be usable for small scale local repositories that don't need the python/perl plugin architecture. Any plan to MFC this to stable/9? If yes, possible for 9.1? -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
svn commit: r252184 - head/sys/net
Author: qingli
Date: Tue Jun 25 00:10:49 2013
New Revision: 252184
URL: http://svnweb.freebsd.org/changeset/base/252184
Log:
Due to the routing related networking kernel redesign work
in FBSD 8.0, interface routes have been returened to the
applications without the RTF_GATEWAY bit. This incompatibility
has caused some issues with Zebra, Qugga and the like.
This patch provides the RTF_GATEWAY flag bit in returned interface
routes so to behave similarly to pre 8.0 systems.
Reviewed by: hrs
Verified by: mackn at opendns dot com
Modified:
head/sys/net/route.h
head/sys/net/rtsock.c
Modified: head/sys/net/route.h
==
--- head/sys/net/route.hMon Jun 24 23:41:16 2013(r252183)
+++ head/sys/net/route.hTue Jun 25 00:10:49 2013(r252184)
@@ -185,6 +185,9 @@ struct ortentry {
#defineRTF_RNH_LOCKED 0x4000 /* radix node head is locked */
+#defineRTF_GWFLAG_COMPAT 0x8000/* a compatibility bit for
interacting
+ with existing routing apps */
+
/* Mask of RTF flags that are allowed to be modified by RTM_CHANGE. */
#define RTF_FMASK \
(RTF_PROTO1 | RTF_PROTO2 | RTF_PROTO3 | RTF_BLACKHOLE | \
Modified: head/sys/net/rtsock.c
==
--- head/sys/net/rtsock.c Mon Jun 24 23:41:16 2013(r252183)
+++ head/sys/net/rtsock.c Tue Jun 25 00:10:49 2013(r252184)
@@ -652,8 +652,10 @@ route_output(struct mbuf *m, struct sock
*/
if (gw_ro.ro_rt != NULL
gw_ro.ro_rt-rt_gateway-sa_family == AF_LINK
- gw_ro.ro_rt-rt_ifp-if_flags IFF_LOOPBACK)
+ gw_ro.ro_rt-rt_ifp-if_flags IFF_LOOPBACK) {
info.rti_flags = ~RTF_GATEWAY;
+ info.rti_flags |= RTF_GWFLAG_COMPAT;
+ }
if (gw_ro.ro_rt != NULL)
RTFREE(gw_ro.ro_rt);
}
@@ -853,7 +855,11 @@ route_output(struct mbuf *m, struct sock
Free(rtm); rtm = new_rtm;
}
(void)rt_msg2(rtm-rtm_type, info, (caddr_t)rtm, NULL);
- rtm-rtm_flags = rt-rt_flags;
+ if (rt-rt_flags RTF_GWFLAG_COMPAT)
+ rtm-rtm_flags = RTF_GATEWAY |
+ (rt-rt_flags ~RTF_GWFLAG_COMPAT);
+ else
+ rtm-rtm_flags = rt-rt_flags;
rt_getmetrics(rt-rt_rmx, rtm-rtm_rmx);
rtm-rtm_addrs = info.rti_addrs;
break;
@@ -905,6 +911,7 @@ route_output(struct mbuf *m, struct sock
RT_UNLOCK(rt);
senderr(error);
}
+ rt-rt_flags = ~RTF_GATEWAY;
rt-rt_flags |= (RTF_GATEWAY info.rti_flags);
}
if (info.rti_ifa != NULL
@@ -1591,7 +1598,11 @@ sysctl_dumpentry(struct radix_node *rn,
if (w-w_req w-w_tmem) {
struct rt_msghdr *rtm = (struct rt_msghdr *)w-w_tmem;
- rtm-rtm_flags = rt-rt_flags;
+ if (rt-rt_flags RTF_GWFLAG_COMPAT)
+ rtm-rtm_flags = RTF_GATEWAY |
+ (rt-rt_flags ~RTF_GWFLAG_COMPAT);
+ else
+ rtm-rtm_flags = rt-rt_flags;
/*
* let's be honest about this being a retarded hack
*/
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
svn commit: r252185 - in head/sys/dev/usb: . net
Author: yongari Date: Tue Jun 25 00:26:30 2013 New Revision: 252185 URL: http://svnweb.freebsd.org/changeset/base/252185 Log: Add Lenovo USB 2.0 Ethernet adapter. PR: usb/179920 MFC After:1 week Modified: head/sys/dev/usb/net/if_axe.c head/sys/dev/usb/usbdevs Modified: head/sys/dev/usb/net/if_axe.c == --- head/sys/dev/usb/net/if_axe.c Tue Jun 25 00:10:49 2013 (r252184) +++ head/sys/dev/usb/net/if_axe.c Tue Jun 25 00:26:30 2013 (r252185) @@ -163,6 +163,7 @@ static const STRUCT_USB_HOST_ID axe_devs AXE_DEV(GOODWAY, GWUSB2E, 0), AXE_DEV(IODATA, ETGUS2, AXE_FLAG_178), AXE_DEV(JVC, MP_PRX1, 0), + AXE_DEV(LENOVO, ETHERNET, AXE_FLAG_772B), AXE_DEV(LINKSYS2, USB200M, 0), AXE_DEV(LINKSYS4, USB1000, AXE_FLAG_178), AXE_DEV(LOGITEC, LAN_GTJU2A, AXE_FLAG_178), Modified: head/sys/dev/usb/usbdevs == --- head/sys/dev/usb/usbdevsTue Jun 25 00:10:49 2013(r252184) +++ head/sys/dev/usb/usbdevsTue Jun 25 00:26:30 2013(r252185) @@ -681,6 +681,7 @@ vendor ASUS20x1761 ASUS vendor SWEEX2 0x177f Sweex vendor METAGEEK0x1781 MetaGeek vendor KAMSTRUP0x17a8 Kamstrup A/S +vendor LENOVO 0x17ef Lenovo vendor WAVESENSE 0x17f4 WaveSense vendor VAISALA 0x1843 Vaisala vendor AMIT0x18c5 AMIT @@ -2462,6 +2463,9 @@ product LARSENBRUSGAARD ALTITRACK 0x0001 /* Leadtek products */ product LEADTEK 9531 0x2101 9531 GPS +/* Lenovo products */ +product LENOVO ETHERNET0x7203 USB 2.0 Ethernet + /* Lexar products */ product LEXAR JUMPSHOT 0x0001 jumpSHOT CompactFlash Reader product LEXAR CF_READER0xb002 USB CF Reader ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r252032 - head/sys/amd64/include
On Mon, 24 Jun 2013, Konstantin Belousov wrote: On Sun, Jun 23, 2013 at 07:57:57PM +1000, Bruce Evans wrote: The case that can't be fixed by rereading the counters is when fetching code runs in between the stores. If the stores are on a another CPU that is currently executing them, then we can keep checking that the counters don't change for the maximum time that any pair of stores take to complete. This time is quite long and difficult to determine (but it can be bounded by hard-disabling interrupts in the storer, and limited by prefetching). If the stores are on the same CPU, then we have no good way to detect that another thread is in the middle of them, or to switch back to that thread. So we currently prevent this case using slow methods. We are already explicit about the fetched value potentially not reflecting any real moment value, but indeed, having the fetch result off by 2^32 is not acceptable. We need atomic 64bit loads to fix this, which is provided by the same cmpxchg8b instruction on the 8-byte aligned elements. Intel guarantees that 8-byte aligned loads and stores are atomic. The following is the prototype for the x86. The other 64bit architectures are handled exactly like amd64. For 32bit !x86 arches, i.e. arm, mips32 and powerpc32, some more investigation is needed. That works of course, but is too complicated, machine-dependent and slow for me. (I just checked all the pcpu.h implementations and found that all of them except amd64 and i386 still use the quick and racy PCPU_PTR(member) += (value) for PCPU_ADD(). This has 1 sure race and 1 compiler/machine-dependent race: - PCPU_PTR() is only usable if preemption (resulting in rescheduling to run on a different CPU) is prevented in the caller. Otherwise, the pointer may become invalid immediately iafter it is initialized. - the compiler may generate a racy load-add-store operation for +=. Using PCPU_PTR() makes this a smaller problem than using a thread- local pointer. It prevents the store going to a different CPU than the load. PCPU_GET() and PCPU_SET() have the first of these problems on all arches except amd64 and i386. Even curthread wouldn't work in the SMP case if it has the default implementation of PCPU_GET(curthread). However, it has a non-default implementation on all arches except arm and mips. So even curthread seems to be broken for arm and mips.) The non-optimized machine/counter.h avoids these problems using a critical section. I'm not sure that works. Anyway, counter.h shouldn't have to understand pcpu better than pcpu.h does in order to work. The arm implementation of atomic.h is also relevant and is especially interesting. I looked at it after mdf@ pointed out ARM_RAS_START. This seems to only be used by arm in userland. It is even larger and slower and more complicated than critical sections, so it doesn't seem to be useful for counters. In the kernel, arm has several implementations depending on machine capabilities. The ifdefs are hard to understand. On some machine, it seems to use the equivalent of a cmpxchg loop. On others, it just disables interrupts. Disabling interrupts is presumably better than a critical section, and userland has to use ARM_RAS_START for some arches because neither disabling interrupts not critical sections are available in userland. None of this care helps avoid the races in pcpu.h, since pcpu.h intentionally avoids using atomic ops. None of this care helps avoid the races in counter.h or make counter.h efficient, since counter.h uses its own methods. To reach the same quality as atomic.h, counter.h would have to copy half of the ifdefs and methods in atomic.h. The slowness that I care about is only in the counter update. Anything complicated there will be slow. My current best design: - use ordinary mutexes to protect counter fetches in non-per-CPU contexts. - use native-sized or always 32-bit counters. Counter updates are done by a single addl on i386. Fix pcpu.h on arches other than amd64 and i386 and use the same method as there. - counter fetches add the native-sized pcpu counters to 64-bit non-pcpu counters, when the native-size counters are in danger of overflowing or always, under the mutex. Transferring data uses an ordinary atomic_cmpset. To avoid ifdefs, always use u_int pcpu counters. The 64-bit non-pcpu counters can easily be changed to pcpu counters if the API is extended to support pcpu data. - run a daemon every few minutes to fetch all the counters, so that the native-sized counters are in no danger of overflowing on systems that don't run statistics programs often enough to fetch the counters to actually use. ... diff --git a/sys/kern/subr_counter.c b/sys/kern/subr_counter.c index a98ed40..3222881 100644 --- a/sys/kern/subr_counter.c +++ b/sys/kern/subr_counter.c ... @@ -49,14 +51,8 @@
Re: svn commit: r252032 - head/sys/amd64/include
On Tue, 25 Jun 2013, I wrote:
My current best design:
- use ordinary mutexes to protect counter fetches in non-per-CPU contexts.
- use native-sized or always 32-bit counters. Counter updates are done
by a single addl on i386. Fix pcpu.h on arches other than amd64 and
i386 and use the same method as there.
- counter fetches add the native-sized pcpu counters to 64-bit non-pcpu
counters, when the native-size counters are in danger of overflowing
or always, under the mutex. Transferring data uses an ordinary
atomic_cmpset. To avoid ifdefs, always use u_int pcpu counters.
The 64-bit non-pcpu counters can easily be changed to pcpu counters
if the API is extended to support pcpu data.
- run a daemon every few minutes to fetch all the counters, so that
the native-sized counters are in no danger of overflowing on systems
that don't run statistics programs often enough to fetch the counters
to actually use.
There is at least 1 counter decrement (add -1) in tcp, so the native counters
need to be signed.
...
With my design:
extern struct mtx counter_locks[];
extern uint64_t counters[];
This is pseudo-code. The extra structure must be dynamically allocated
with each counter. I'm not sure how to do that. uint64_t_pcpu_zone
is specialized for pcpu counters, and a non-pcpu part is needed.
uint64_t r;
volatile u_int *p;
u_int v;
Change to int.
int cnum;
cnum = ctonum(c);
mtx_lock(counter_locks[cnum]); /* might not need 1 per counter */
r = counters[cnum];
for (i = 0; i mp_ncpus; i++) {
p = (u_int *)((char *)c + sizeof(struct pcpu) * i);
Change to int *.
v = *p; /* don't care if it is stale */
if (v = 0x8000) {
Change the critical level to 2 critical levels, 0x4000 for positive
values and -0x4000 for negative values.
/* Transfer only when above critical level. */
while (atomic_cmpset_rel_int(p, v, 0) == 0)
v = *p; /* still don't care if it is stale */
counters[cnum] += v;
Even though full counter values are not expected to become negative,
the native counters can easily become negative when a decrement occurs
after the transfer resets them to 0.
}
r += v;
}
mtx_unlock(counter_locks[cnum]);
return (r);
Mutexes give some slowness in the fetching code, but fetches eare expected
to be relatively rare.
I added the complication to usually avoid atomic ops at the last minute.
The complication might not be worth it.
The complication is to test v so as to normally avoid doing the transfer
and its atomic ops (and to not use atomic ops for loading v). The
complication is larger with 2 thresholds. If we always transferred,
then *p would usually be small and often 0, so that decrementing it
would often make it -1. This -1 must be transferred by adding -1, not
by adding 0xf. Changing the type of the native counter to int
gives this.
Bruce
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r252032 - head/sys/amd64/include
On 25/06/2013, at 12:54, Bruce Evans b...@optusnet.com.au wrote: - run a daemon every few minutes to fetch all the counters, so that the native-sized counters are in no danger of overflowing on systems that don't run statistics programs often enough to fetch the counters to actually use. There is at least 1 counter decrement (add -1) in tcp, so the native counters need to be signed. You could convert decrements into an increment of a separate counter and then subtract that value from the others when collecting them all. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
