FreeBSD 10.0-CURRENT r244916M: osm_console.c:70:1: error: use of GNU old-style field designator extension [-Werror,-Wgnu-designator],on: 0, delay_s: 2, loop_function:NULL};
Current r244916M fails to compile a world with following error: [...] cc -O2 -pipe -O3 -march=native -I/usr/src/contrib/ofed/usr.bin/opensm/../../include/infiniband -I/usr/src/contrib/ofed/usr.bin/opensm/../../management/opensm/include/ -pthread -DVENDOR_RMPP_SUPPORT -DDUAL_SIDED_RMPP -I/usr/src/contrib/ofed/usr.bin/opensm/../../include/infiniband -I/usr/src/contrib/ofed/usr.bin/opensm/../../management/opensm/include/ -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -Wno-parentheses -c /usr/src/contrib/ofed/usr.bin/opensm/../../management/opensm/opensm/main.c cc -O2 -pipe -O3 -march=native -I/usr/src/contrib/ofed/usr.bin/opensm/../../include/infiniband -I/usr/src/contrib/ofed/usr.bin/opensm/../../management/opensm/include/ -pthread -DVENDOR_RMPP_SUPPORT -DDUAL_SIDED_RMPP -I/usr/src/contrib/ofed/usr.bin/opensm/../../include/infiniband -I/usr/src/contrib/ofed/usr.bin/opensm/../../management/opensm/include/ -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -Wno-parentheses -c /usr/src/contrib/ofed/usr.bin/opensm/../../management/opensm/opensm/osm_console_io.c cc -O2 -pipe -O3 -march=native -I/usr/src/contrib/ofed/usr.bin/opensm/../../include/infiniband -I/usr/src/contrib/ofed/usr.bin/opensm/../../management/opensm/include/ -pthread -DVENDOR_RMPP_SUPPORT -DDUAL_SIDED_RMPP -I/usr/src/contrib/ofed/usr.bin/opensm/../../include/infiniband -I/usr/src/contrib/ofed/usr.bin/opensm/../../management/opensm/include/ -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -Wno-parentheses -c /usr/src/contrib/ofed/usr.bin/opensm/../../management/opensm/opensm/osm_console.c /usr/src/contrib/ofed/usr.bin/opensm/../../management/opensm/opensm/osm_console.c:70:1: error: use of GNU old-style field designator extension [-Werror,-Wgnu-designator] on: 0, delay_s: 2, loop_function:NULL}; ^~~ .on = /usr/src/contrib/ofed/usr.bin/opensm/../../management/opensm/opensm/osm_console.c:70:8: error: use of GNU old-style field designator extension [-Werror,-Wgnu-designator] on: 0, delay_s: 2, loop_function:NULL}; ^~~~ .delay_s = /usr/src/contrib/ofed/usr.bin/opensm/../../management/opensm/opensm/osm_console.c:70:20: error: use of GNU old-style field designator extension [-Werror,-Wgnu-designator] on: 0, delay_s: 2, loop_function:NULL}; ^~ .loop_function = 3 errors generated. *** [osm_console.o] Error code 1 Stop in /usr/src/contrib/ofed/usr.bin/opensm. *** [all] Error code 1 Stop in /usr/src/contrib/ofed/usr.bin. *** [all] Error code 1 Stop in /usr/src/contrib/ofed. *** [contrib/ofed.all__D] Error code 1 Stop in /usr/src. *** [everything] Error code 1 Stop in /usr/src. *** [buildworld] Error code 1 Stop in /usr/src. signature.asc Description: OpenPGP digital signature
Re: FreeBSD 10.0-CURRENT r244916M: osm_console.c:70:1: error: use of GNU old-style field designator extension [-Werror, -Wgnu-designator], on: 0, delay_s: 2, loop_function:NULL};
On Wed, Jan 2, 2013 at 1:21 AM, O. Hartmann ohart...@zedat.fu-berlin.de wrote: Current r244916M fails to compile a world with following error: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/174214 -- not sure why it hasn't already been committed. 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: [RFC/RFT] calloutng
On Mon, Dec 31, 2012 at 12:17:27PM +0200, Alexander Motin wrote: On 31.12.2012 08:17, Luigi Rizzo wrote: On Sun, Dec 30, 2012 at 04:13:43PM -0700, Ian Lepore wrote: ... 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. Thank you for testing, Ian. 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 ? 300usprobably 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 ? All mentioned effects could be explained with implemented logic. 50us at 1us is probably sum of minimal latency of the hardware eventtimer on the specific platform and some software processing overhead (syscall, callout, timecouters, scheduler, etc). At later points system starts to noticeably use precision specified by kern.timecounter.alloweddeviation sysctl. It affects results from two sides: 1) extending intervals for specified percent of time to allow event aggregation, and 2) choosing time base between fast getbinuptime() and precise binuptime(). Extending interval is needed to aggregate not only callouts with each other, but also callouts with other system events, which are impossible to schedule in advance. It gives specified relative error, but no more then one CPU wakeup period in absolute: for busy CPU (not skipping hardclock() ticks) it is 1/hz, for completely idle one it can be up to 0.5s. Second point allows to reduce processing overhead by the cost of error up to 1/hz for long periods ((100/allowed)*(1/hz)), when it is used. i am not sure what you mean by extending interval, but i believe the logic should be the following: - say user requests a timeout after X seconds and with a tolerance of D second (both X and D are fractional, so they can be short). Interpret this as the system should do its best to generate an event between X and X+D seconds - convert X to an absolute time, T_X - if there are any pending events already scheduled between T_X and T_X+D, then by definition they are acceptable. Attach the requested timeout to the earliest of these events. - otherwise, schedule an event at time T_X (because there is no valid reason to generate a late event, and it makes no sense from an energy saving standpoint, either -- see below). It seems to me that you are instead extending the requested interval upfront, which causes some gratuitous pessimizations in scheduling the callout. Re. energy savings: the gain in extending the timeout cannot exceed the value D/X. So while it may make sense to extend a 1us request to 50us to go (theoretically) from 1M callouts/s to 20K callouts/s, it is completely pointless from an energy saving standpoint to introduce a 10ms error on a 300ms request. (even though i hate the idea that a 1us request defaults to a 50us delay; but that is hopefully something that can be tuned in a
Re: [RFC/RFT] calloutng
On 02.01.2013 12:57, Luigi Rizzo wrote: On Mon, Dec 31, 2012 at 12:17:27PM +0200, Alexander Motin wrote: On 31.12.2012 08:17, Luigi Rizzo wrote: On Sun, Dec 30, 2012 at 04:13:43PM -0700, Ian Lepore wrote: ... 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. Thank you for testing, Ian. 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 ? All mentioned effects could be explained with implemented logic. 50us at 1us is probably sum of minimal latency of the hardware eventtimer on the specific platform and some software processing overhead (syscall, callout, timecouters, scheduler, etc). At later points system starts to noticeably use precision specified by kern.timecounter.alloweddeviation sysctl. It affects results from two sides: 1) extending intervals for specified percent of time to allow event aggregation, and 2) choosing time base between fast getbinuptime() and precise binuptime(). Extending interval is needed to aggregate not only callouts with each other, but also callouts with other system events, which are impossible to schedule in advance. It gives specified relative error, but no more then one CPU wakeup period in absolute: for busy CPU (not skipping hardclock() ticks) it is 1/hz, for completely idle one it can be up to 0.5s. Second point allows to reduce processing overhead by the cost of error up to 1/hz for long periods ((100/allowed)*(1/hz)), when it is used. i am not sure what you mean by extending interval, but i believe the logic should be the following: - say user requests a timeout after X seconds and with a tolerance of D second (both X and D are fractional, so they can be short). Interpret this as the system should do its best to generate an event between X and X+D seconds - convert X to an absolute time, T_X - if there are any pending events already scheduled between T_X and T_X+D, then by definition they are acceptable. Attach the requested timeout to the earliest of these events. All above is true, but not following. - otherwise, schedule an event at time T_X (because there is no valid reason to generate a late event, and it makes no sense from an energy saving standpoint, either -- see below). System may have many interrupts except timer: network, disk, ... WiFi cards generate interrupts with AP beacon rate -- dozens times per second. It is not very efficient to wake up CPU precisely at T_X time, that may be just 100us earlier then next hardware interrupt. That's why timer interrupts are scheduled at min(T_X+D, 0.5s, next hardclock, next statclock, ...). As result, event will be handled within allowed range, but real delay will depends on current environment conditions. It seems to me that you are instead extending the requested interval
installworld failure due to cross-device links
I'd be interested in the general policy on LINKS vs. SYMLINKS
between directories that might end up on different file systems.
There seems to be an assumption that system directories in /usr
(e.g. /usr/bin, /usr/sbin, /usr/libexec) are on the same file
system, but I do not think that this assumption is documented.
I'm using a ZFS only installation of -CURRENT and have separate file
systems for several of the directories in / and /usr, that usually
share a file system (e.g. /bin, /sbin, but also /usr/bin/, /usr/sbin
and /usr/libexec are independent file systems).
An older case is the link from /usr/bin/chgrp to /usr/sbin/chown
(see usr.sbin/chown/Makefile), which is easily fixed by using a
SMYLINK instead of a LINK.
And now there is usr.sbin/bsdinstall/partedit/Makefile, which as of
r244859 creates a link from /usr/libexec/bsdinstall to /usr/sbin/sade.
This breaks with /usr/bin and /usr/sbin on different file systems,
while it should not according to the commit message:
--
r244859 | nwhitehorn | 2012-12-30 15:35:00 +0100 (Sun, 30 Dec 2012) | 7
lines
Replace sade the extracted piece of sysinstall with sade the extracted
piece of bsdinstall (although this time with a symlink instead of
duplicated source code).
Discussed on: freebsd-geom
MFC after: 3 months
--
The SYMLINK mentioned in the commit message is a LINK to a different
directory, which might be on a different file system, actually.
This should be fixed by the attached patch, to remove the implied
assumption and to make the Makefile match the commit message.
Regards, STefan
Index: Makefile
===
--- Makefile(revision 244957)
+++ Makefile(working copy)
@@ -2,7 +2,8 @@
BINDIR= /usr/libexec/bsdinstall
PROG= partedit
-LINKS= ${BINDIR}/partedit ${BINDIR}/autopart ${BINDIR}/partedit /usr/sbin/sade
+LINKS= ${BINDIR}/partedit ${BINDIR}/autopart ${BINDIR}/partedit
+SYMLINKS= /usr/sbin/sade
LDADD= -lgeom -lncursesw -lutil -ldialog -lm
PARTEDIT_ARCH= ${MACHINE}
___
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, Jan 02, 2013 at 01:24:26PM +0200, Alexander Motin wrote: On 02.01.2013 12:57, Luigi Rizzo wrote: ... i am not sure what you mean by extending interval, but i believe the logic should be the following: - say user requests a timeout after X seconds and with a tolerance of D second (both X and D are fractional, so they can be short). Interpret this as the system should do its best to generate an event between X and X+D seconds - convert X to an absolute time, T_X - if there are any pending events already scheduled between T_X and T_X+D, then by definition they are acceptable. Attach the requested timeout to the earliest of these events. All above is true, but not following. - otherwise, schedule an event at time T_X (because there is no valid reason to generate a late event, and it makes no sense from an energy saving standpoint, either -- see below). System may have many interrupts except timer: network, disk, ... WiFi cards generate interrupts with AP beacon rate -- dozens times per second. It is not very efficient to wake up CPU precisely at T_X time, that may be just 100us earlier then next hardware interrupt. That's why timer interrupts are scheduled at min(T_X+D, 0.5s, next hardclock, next statclock, ...). As result, event will be handled within allowed range, but real delay will depends on current environment conditions. I don't see why system events (hardclock, statclock, 0.5s,...) need to be treated specially -- and i am saying this also in the interest of simplifying the logic of the code. First of all, if you know that there is already a hardclock/statclock/* scheduled in [T_X, T_X+D] you just reuse that. This particular bullet was no event scheduled in [T_X, T_X+D] so you need to generate a new one. Surely scheduling the event at T_X+D instead of T_X increases the chance of merging events. But the saving are smaller and smaller as the value X increases. This particular client will only change its request rate from 1/X to 1/(X+D) so in relative terms the gain is ( 1/X - 1/(X+D) ) / (1/(X+D) ) = D/X Example: if X = 300ms, and D = 10ms (as in the test case) you just save one interrupt every 30seconds by scheduling at T_X+D instead of T_X. Are we actually able to measure the difference ? Even at high interrupt rates (e.g. X = 1ms) you are not going to save a lot unless the tolerance D is very large, which is generally undesirable for other reasons (presumably, applications are not going to be happy if you artificially double their timeouts). Now, say your application requests timeouts every X = 300ms. It seems to me that you are instead extending the requested interval upfront, which causes some gratuitous pessimizations in scheduling the callout. Re. energy savings: the gain in extending the timeout cannot exceed the value D/X. So while it may make sense to extend a 1us request to 50us to go (theoretically) from 1M callouts/s to 20K callouts/s, it is completely pointless from an energy saving standpoint to introduce a 10ms error on a 300ms request. I am not so sure in this. When CPU package is in C7 sleep state with all buses and caches shut down and memory set to self refresh, it consumes very few (some milli-Watts) of power. Wake up from that state takes 100us or even more with power consumption much higher then normal operational one. Sure, if we compare it with power consumption of 100% CPU load, difference between 10 and 100 wakeups per second may be small, but when comparing to each other in some low-power environment for mostly idle system it may be much more significant. see above -- at low rates the difference is not measurable, at high rates thCe only obvious answer is do not use C7 unless if the next interrupt is due in less than 2..5 milliseconds (even though i hate the idea that a 1us request defaults to a 50us delay; but that is hopefully something that can be tuned in a platform-specific way and perhaps at runtime). It is 50us on this ARM. On SandyBridge Core i7 it is only about 2us. very good, i suspected something similar, just wanted to be sure :) cheers luigi -- Alexander Motin ___ 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
02.01.2013 14:28 пользователь Luigi Rizzo ri...@iet.unipi.it написал: On Wed, Jan 02, 2013 at 01:24:26PM +0200, Alexander Motin wrote: On 02.01.2013 12:57, Luigi Rizzo wrote: ... i am not sure what you mean by extending interval, but i believe the logic should be the following: - say user requests a timeout after X seconds and with a tolerance of D second (both X and D are fractional, so they can be short). Interpret this as the system should do its best to generate an event between X and X+D seconds - convert X to an absolute time, T_X - if there are any pending events already scheduled between T_X and T_X+D, then by definition they are acceptable. Attach the requested timeout to the earliest of these events. All above is true, but not following. - otherwise, schedule an event at time T_X (because there is no valid reason to generate a late event, and it makes no sense from an energy saving standpoint, either -- see below). System may have many interrupts except timer: network, disk, ... WiFi cards generate interrupts with AP beacon rate -- dozens times per second. It is not very efficient to wake up CPU precisely at T_X time, that may be just 100us earlier then next hardware interrupt. That's why timer interrupts are scheduled at min(T_X+D, 0.5s, next hardclock, next statclock, ...). As result, event will be handled within allowed range, but real delay will depends on current environment conditions. I don't see why system events (hardclock, statclock, 0.5s,...) need to be treated specially -- and i am saying this also in the interest of simplifying the logic of the code. Sure. That is mostly for historical reasons. At some point they should disappear, just not now, as patch is already quite big. First of all, if you know that there is already a hardclock/statclock/* scheduled in [T_X, T_X+D] you just reuse that. This particular bullet was no event scheduled in [T_X, T_X+D] so you need to generate a new one. That is true, but my main point was about merging with external events, which I can't predict and the only way to merge is increase sleep period, hoping for better. Surely scheduling the event at T_X+D instead of T_X increases the chance of merging events. But the saving are smaller and smaller as the value X increases. This particular client will only change its request rate from 1/X to 1/(X+D) so in relative terms the gain is ( 1/X - 1/(X+D) ) / (1/(X+D) ) = D/X Example: if X = 300ms, and D = 10ms (as in the test case) you just save one interrupt every 30seconds by scheduling at T_X+D instead of T_X. Are we actually able to measure the difference ? Even at high interrupt rates (e.g. X = 1ms) you are not going to save a lot unless the tolerance D is very large, which is generally undesirable for other reasons (presumably, applications are not going to be happy if you artificially double their timeouts). Now, say your application requests timeouts every X = 300ms. With default precision set to 5% it will be only 5% save from periods increase. But that is absolutely not my goal! Imagine different case: you have NIC interrupts at 1000Hz. Also you have 100 callouts with 100ms period each. If we program timer with absolute precision, you will get about 2000Hz of total interrupt rate. But if we allow just 2% deviation, most of callouts will be grouped with NIC interrupts and total rate will be 1000Hz. Loosing _less_ then 2% of precision we are reducing interrupt rate in _half_! It seems to me that you are instead extending the requested interval upfront, which causes some gratuitous pessimizations in scheduling the callout. Re. energy savings: the gain in extending the timeout cannot exceed the value D/X. So while it may make sense to extend a 1us request to 50us to go (theoretically) from 1M callouts/s to 20K callouts/s, it is completely pointless from an energy saving standpoint to introduce a 10ms error on a 300ms request. I am not so sure in this. When CPU package is in C7 sleep state with all buses and caches shut down and memory set to self refresh, it consumes very few (some milli-Watts) of power. Wake up from that state takes 100us or even more with power consumption much higher then normal operational one. Sure, if we compare it with power consumption of 100% CPU load, difference between 10 and 100 wakeups per second may be small, but when comparing to each other in some low-power environment for mostly idle system it may be much more significant. see above -- at low rates the difference is not measurable, at high rates thCe only obvious answer is do not use C7 unless if the next interrupt is due in less than 2..5 milliseconds (even though i hate the idea that a 1us request defaults to a 50us delay; but that is hopefully something that can be tuned in a platform-specific way and perhaps at runtime). It is 50us on this ARM.
Re: installworld failure due to cross-device links
On 01/02/13 07:04, Stefan Esser wrote: I'd be interested in the general policy on LINKS vs. SYMLINKS between directories that might end up on different file systems. There seems to be an assumption that system directories in /usr (e.g. /usr/bin, /usr/sbin, /usr/libexec) are on the same file system, but I do not think that this assumption is documented. I'm using a ZFS only installation of -CURRENT and have separate file systems for several of the directories in / and /usr, that usually share a file system (e.g. /bin, /sbin, but also /usr/bin/, /usr/sbin and /usr/libexec are independent file systems). An older case is the link from /usr/bin/chgrp to /usr/sbin/chown (see usr.sbin/chown/Makefile), which is easily fixed by using a SMYLINK instead of a LINK. And now there is usr.sbin/bsdinstall/partedit/Makefile, which as of r244859 creates a link from /usr/libexec/bsdinstall to /usr/sbin/sade. This breaks with /usr/bin and /usr/sbin on different file systems, while it should not according to the commit message: Thanks for the patch! I've committed it (slightly modified) as r244958. I haven't taken any action on the chgrp/chown issue, though. -Nathan ___ 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 Sun, Dec 30, 2012 at 11:17:10PM +0100, Dimitry Andric wrote: 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? Not yet, but I'll try to come up with something smaller. Stefan ___ 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, 2013-01-02 at 15:11 +0200, Alexander Motin wrote: 02.01.2013 14:28 пользователь Luigi Rizzo ri...@iet.unipi.it написал: On Wed, Jan 02, 2013 at 01:24:26PM +0200, Alexander Motin wrote: On 02.01.2013 12:57, Luigi Rizzo wrote: First of all, if you know that there is already a hardclock/statclock/* scheduled in [T_X, T_X+D] you just reuse that. This particular bullet was no event scheduled in [T_X, T_X+D] so you need to generate a new one. That is true, but my main point was about merging with external events, which I can't predict and the only way to merge is increase sleep period, hoping for better. This really is the crux of the problem, because you can't *by default* dispatch an event earlier than requested because that's just a violation of the usual rules of precision timing (where you expect to be late but never early). Sometimes there is no need for such precision, and an early wakeup is no more or less detrimental than a late wakeup. In fact, that may even be the majority case. I wonder if it might make sense to allow the precision specification to indicate whether it needs traditional never early behavior or whether it can be interpretted as plus or minus this amount is fine. Like maybe negative precision is interpretted as plus or minus abs(precision) or something like that. Or maybe even the other way around... you get plus or minus precision by default and the few things that really care about precision timing have a way of indicating that. (But in that case the userland sleeps would have to assume the traditional behavior because that's how they've always been documented.) -- Ian ___ 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: Auditdistd user question
On 2 January 2013 14:04, Alexander Yerenkow yeren...@gmail.com wrote: Hello there and please excuse my harshness. I just installed 9.1, and I tried to set up poudriere with 9/stable. It took a lot of time compiling kernel and world, and after this it all failed with message about missing auditdistd user. I just can't find words. Why this user presence not checked during buildworld at least? Or by just invoking updated Makefile? If there any need to build world without install it, wouldn't be better make some conditional flag, like BUILD_WITHOUT_AUDITDISTD, instead of silent building and failing after that at install stage. Of course, in current way just buildworld not broken, but buildworld installworld is. This looks like like carefully hidden trap, from someone with specific sense of humor. Or am I missing something, and this is not terribly wrong? While I agree with you in principle, I must point out that you mustn't try to run package builds on a newer jail than your host. This causes weird kernel/world synchronisation issues. http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/169659 [for an example] As far as I know there are no problems with running older jails on newer hosts (thankfully). Chris ___ 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: Auditdistd user question
2013/1/2 Chris Rees cr...@freebsd.org On 2 January 2013 14:04, Alexander Yerenkow yeren...@gmail.com wrote: Hello there and please excuse my harshness. I just installed 9.1, and I tried to set up poudriere with 9/stable. It took a lot of time compiling kernel and world, and after this it all failed with message about missing auditdistd user. I just can't find words. Why this user presence not checked during buildworld at least? Or by just invoking updated Makefile? If there any need to build world without install it, wouldn't be better make some conditional flag, like BUILD_WITHOUT_AUDITDISTD, instead of silent building and failing after that at install stage. Of course, in current way just buildworld not broken, but buildworld installworld is. This looks like like carefully hidden trap, from someone with specific sense of humor. Or am I missing something, and this is not terribly wrong? While I agree with you in principle, I must point out that you mustn't try to run package builds on a newer jail than your host. This causes weird kernel/world synchronisation issues. I'm just provided info about my setup as background. My main builder is on some current revision, and it can't build 9.1 due to some compiler bug. To not mess with upgrading it, I tried to setup additional 9.1 builder (With having in plans probably upgrade host to stable, maybe not). I just think that such improvements could be improved, and in future better think of all possible cases, not about one. http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/169659 [for an example] As far as I know there are no problems with running older jails on newer hosts (thankfully). Chris -- Regards, Alexander Yerenkow ___ 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, Jan 02, 2013 at 03:11:05PM +0200, Alexander Motin wrote: ... First of all, if you know that there is already a hardclock/statclock/* scheduled in [T_X, T_X+D] you just reuse that. This particular bullet was no event scheduled in [T_X, T_X+D] so you need to generate a new one. That is true, but my main point was about merging with external events, which I can't predict and the only way to merge is increase sleep period, hoping for better. ok, now i understand why you want to schedule for T_X+D. Probably one way to close this discussion would be to provide a sysctl so the sysadmin can decide which point in the interval to pick when there is no suitable callout already scheduled. cheers luigi -+--- Prof. Luigi RIZZO, ri...@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/. Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -+--- ___ 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
problem after installkernel going from 9.0 to CURRENT
(While this may not be a strictly CURRENT issue, I asked on questions@, but have not found a solution.) Situation: One of my boxes failed, and for various reasons it became easier to just scrub and rebuild it. Like its predecessor it will run CURRENT 1) Using BSDinstall, I flushed then created the first disk: ada2p1 freebsd-boot128k ada2p2 freebsd-swap4g ada2p3 freebsd-ufs 25g (There are non-bootable disks at ada0, -1, and -3.) 2) Installed off the 9.0 CD, got it up and running, everything was good. 3) Used csup (tag=.) to update the source tree as of 00:01 on 12/30. 4a) Built world - OK. 4b) Build kernel - OK. 4c) Ran mergemaster - OK. 4d) Installed kernel - OK. 5) On rebooting, the loader(??) claims to not be able to find a bootable partition - i.e. I get a screen that ends in mountroot . Providing the presumptive value by hand returns error 19. 6) Boot using installation CD and use gpart show to double check device names and partitions; everything looks good. 7) Try normal booting again, no go. This is my first time installing to a completely GPT partitioned system, and I have (obviously) failed to grok something. I checked src/UPDATING and found nothing which covered this. What have I bungled, and how do I fix it? Respectfully, Robert Huff ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
auditdistd (again)
My recent upgrading experience led to the installkernel portion of 'make kernel' failing on the lack of an auditdistd user, for which 'mergemaster -p' was ample workaround. However, the instructions for to rebuild everything in UPDATING still have 'mergemaster -p' before installworld and after kernel/installkernel. There is a bug here, but it could be either a documentation bug (fix UPDATING) or a code bug (only check UID/GIDs before installworld and not installkernel, which only ever uses root:wheel). Unfortunately, testing code for the latter is somewhat time-consuming. Pawel mentioned on #bsddev that he had an untested patch for the latter. Is there interest in testing that and getting it in the tree? (Or would people prefer to just change UPDATING?) -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, Jan 02, 2013 at 05:22:06PM +0100, Luigi Rizzo wrote: On Wed, Jan 02, 2013 at 03:11:05PM +0200, Alexander Motin wrote: ... First of all, if you know that there is already a hardclock/statclock/* scheduled in [T_X, T_X+D] you just reuse that. This particular bullet was no event scheduled in [T_X, T_X+D] so you need to generate a new one. That is true, but my main point was about merging with external events, which I can't predict and the only way to merge is increase sleep period, hoping for better. ok, now i understand why you want to schedule for T_X+D. Probably one way to close this discussion would be to provide a sysctl so the sysadmin can decide which point in the interval to pick when there is no suitable callout already scheduled. Isn't trying to synchronize to the external events in this way unsafe ? I remember, but cannot find the reference right now, a scheduler exploit(s) which completely hide malicious thread from the time accounting, by making it voluntary yielding right before statclock should fire. If statistic gathering could be piggy-backed on the external interrupt, and attacker can control the source of the external events, wouldn't this give her a handle ? pgpVV7IP9DZbJ.pgp Description: PGP signature
Re: problem after installkernel going from 9.0 to CURRENT
On Wed, 2 Jan 2013, Robert Huff wrote: (While this may not be a strictly CURRENT issue, I asked on questions@, but have not found a solution.) Situation: One of my boxes failed, and for various reasons it became easier to just scrub and rebuild it. Like its predecessor it will run CURRENT 1) Using BSDinstall, I flushed then created the first disk: ada2p1 freebsd-boot128k ada2p2 freebsd-swap4g ada2p3 freebsd-ufs 25g (There are non-bootable disks at ada0, -1, and -3.) For a full clean install, I believe that bsdinstall should prompt about installing bootcode around here. I don't really understand from your procedure how bsdinstall was used; there might be some edge case where there is no prompt about bootcode. 2) Installed off the 9.0 CD, got it up and running, everything was good. 3) Used csup (tag=.) to update the source tree as of 00:01 on 12/30. 4a) Built world - OK. 4b) Build kernel - OK. 4c) Ran mergemaster - OK. 4d) Installed kernel - OK. 5) On rebooting, the loader(??) claims to not be able to find a bootable partition - i.e. I get a screen that ends in mountroot . Providing the presumptive value by hand returns error 19. 6) Boot using installation CD and use gpart show to double check device names and partitions; everything looks good. 7) Try normal booting again, no go. This is my first time installing to a completely GPT partitioned system, and I have (obviously) failed to grok something. I checked src/UPDATING and found nothing which covered this. What have I bungled, and how do I fix it? I think you should investigate the 'bootcode' subcommand of gpart(8). -Ben Kaduk ___ 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
.. I'm pretty damned sure we're going to need to enforce a never earlier than X latency. Is there a more detailed writeup of calloutng somewhere, besides David's slides? The wiki page is rather empty. Eg - I think this work does coalesce wakeups, right? Or it can? So when in low-power scenarios you can end up with lower-resolution callout periods, but many less CPU wakeups a second? (Do we actually _expose_ wakeups-per-second somewhere?) Adrian ___ 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: auditdistd (again)
On 1/2/2013 12:10 PM, Benjamin Kaduk wrote: My recent upgrading experience led to the installkernel portion of 'make kernel' failing on the lack of an auditdistd user, for which 'mergemaster -p' was ample workaround. However, the instructions for to rebuild everything in UPDATING still have 'mergemaster -p' before installworld and after kernel/installkernel. This is also documented in misc/174405 There is a bug here, but it could be either a documentation bug (fix UPDATING) or a code bug (only check UID/GIDs before installworld and not installkernel, which only ever uses root:wheel). Unfortunately, testing code for the latter is somewhat time-consuming. Pawel mentioned on #bsddev that he had an untested patch for the latter. Is there interest in testing that and getting it in the tree? (Or would people prefer to just change UPDATING?) -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: loopback interface broken on current
On Tue, Jan 01, 2013 at 12:42:47PM -0800, Manfred Antar wrote: M OK M I tracked it down to revision 244678 M 244677 works M the files involved are: M (src)5012}svn up -r 244678 M Updating '.': M Usys/netinet/in.c M Usys/netinet6/in6.c M Updated to revision 244678 M M It seems like the ip6 for localhost is configured but ip4 isn't: M Setting hostname: pozo.com. M ifa_del_loopback_route: deletion failed: 3 M ifconfig: ioctl (SIOCAIFADDR): File exists M bge0: link state changed to DOWN M ifa_del_loopback_route: deletion failed: 3 M M lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384 M options=63RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6 M inet6 ::1 prefixlen 128 M inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 M nd6 options=21PERFORMNUD,AUTO_LINKLOCAL M M From 244677: M Setting hostname: pozo.com. M M Starting Network: lo0 bge0. M lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384 M options=63RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6 M inet 127.0.0.1 netmask 0xff00 M inet6 ::1 prefixlen 128 M inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 M nd6 options=21PERFORMNUD,AUTO_LINKLOCAL Ok, so this is my failure. :( Sorry. I will look at it as soon as I get to decent internet connection. Right now I am on very bad GPRS. Can you please show your rc.conf (the network related part)? -- Totus tuus, Glebius. ___ 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: problem after installkernel going from 9.0 to CURRENT
On 1/2/2013 1:57 PM, Benjamin Kaduk wrote: On Wed, 2 Jan 2013, Robert Huff wrote: For a full clean install, I believe that bsdinstall should prompt about installing bootcode around here. I don't really understand from your procedure how bsdinstall was used; there might be some edge case where there is no prompt about bootcode. 2) Installed off the 9.0 CD, got it up and running, everything was good. Let me elaborate on this: 2) Installed off the 9.0 CD, had a fully bootable system connected to the Internet, everything was good. I think you should investigate the 'bootcode' subcommand of gpart(8). Does the above change things? It was my expectation installkernel would Do The Right Thing with respect to new bootcode, and I am surprised it did not. Respectfully, Robert Huff ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CFT: Overhauled CPSW driver for BeagleBone
On Tue, 1 Jan 2013 10:55:58 -0800 Tim Kientzle kient...@freebsd.org wrote: On Jan 1, 2013, at 8:12 AM, Brett Wynkoop wrote: Greeting- The driver is working much better than the driver currently in head. I have maintained an ssh connection to the BeagleBone for more than 24 hours! Just committed this to -CURRENT r244939. Tim Ok time to cvsup then rebuild the kernel followed by a buildworld! Thanks Tim! -- wynk...@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6924 718-717-5435 ___ 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 02.01.2013 19:09, Konstantin Belousov wrote: On Wed, Jan 02, 2013 at 05:22:06PM +0100, Luigi Rizzo wrote: Probably one way to close this discussion would be to provide a sysctl so the sysadmin can decide which point in the interval to pick when there is no suitable callout already scheduled. Isn't trying to synchronize to the external events in this way unsafe ? I remember, but cannot find the reference right now, a scheduler exploit(s) which completely hide malicious thread from the time accounting, by making it voluntary yielding right before statclock should fire. If statistic gathering could be piggy-backed on the external interrupt, and attacker can control the source of the external events, wouldn't this give her a handle ? There are many different kinds of accounting with different characteristics. Run time for each thread calculated using high resolution per-CPU clocks on each context switch. It is impossible to hide from it. System load average updated using callout and aligned with hardclock(). Hiding from it was easy before, but it can be made more complicated (asynchronous) now. Per-CPU SYSTEM/INTERRUPT/USER/NICE/IDLE counters are updated by statcklock(), that is asynchronous to hardclock() and hiding from it supposed to be more complicated. But even before it was possible, since hardclock() frequency is 8 times higher then statclock() one. More important for scheduling fairness thread's CPU percentage is also based on hardclock() and hiding from it was trivial before, since all sleep primitives were strictly aligned to hardclock(). Now it is slightly less trivial, since this alignment was removed and user-level APIs provide no easy way to enforce it. The only way to get really safe accounting is forget about sampling and use potentially more expensive other ways. It was always stopped by lack of cheap and reliable clocks. But since TSC is P-state invariant on most of CPUs present now it could probably be reconsidered. -- Alexander Motin ___ 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 2 January 2013 08:59, Stefan Farfeleder stef...@freebsd.org wrote: On Sun, Dec 30, 2012 at 11:17:10PM +0100, Dimitry Andric wrote: 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? Not yet, but I'll try to come up with something smaller. Take a look at devel/delta as well as creduce (require ToT clang so it is unported at this time) to help you with finding minimal testcase. If you need help, let me know. -- Eitan Adler ___ 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 02.01.2013 18:08, Adrian Chadd wrote: .. I'm pretty damned sure we're going to need to enforce a never earlier than X latency. Do you mean here that we should never wake up before specified time (just as specified by the most of existing APIs), or that we should not allow sleep shorter then some value to avoid DoS? At least on x86 nanosleep(0) doesn't allow to block the system. Also there is already present mechanism for specifying minimum timer programming interval in eventtimers(9) KPI. Is there a more detailed writeup of calloutng somewhere, besides David's slides? The wiki page is rather empty. There are updated manual pages in the patch. Also Davide written some blog during GSoC. Now we are working on papers for the AsiaBSDCon. Eg - I think this work does coalesce wakeups, right? Or it can? So when in low-power scenarios you can end up with lower-resolution callout periods, but many less CPU wakeups a second? This work does coalesce wakeups out of the box, but also provide ways to improve it further, where possible. With additional tuning of some kernel subsystems and drivers I was able to drop total idle interrupt rate down to 10-15Hz on arm and 20-30Hz on x86. (Do we actually _expose_ wakeups-per-second somewhere?) On systems with ACPI there are average per-CPU sleep times exposed via sysctls dev.cpu.X.cx_usage. Also cpu_idle() call rate calculated by both schedulers for purposes of idle loop optimizations, but it is not exposed outside now. Also for idle SMP system enabling COUNT_IPIS should give number of interrupts in systat comparable to number of wakeups. I am mostly using the last way. -- Alexander Motin ___ 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: loopback interface broken on current
Ok, so this is my failure. :( Sorry. I will look at it as soon as I get to decent internet connection. Right now I am on very bad GPRS. Can you please show your rc.conf (the network related part)? -- Totus tuus, Glebius. Here you go: /etc/hosts: ::1 localhost localhost.pozo.com 127.0.0.1 localhost localhost.pozo.com /etc/rc.conf: ifconfig_lo0=inet 127.0.0.1 # default loopback device configuration. ifconfig_bge0=inet 192.168.0.5 netmask 255.255.255.0 defaultrouter=192.168.0.1 # Set to default gateway ipv6_network_interfaces=auto # List of IPv6 network interfaces # (or auto or none). ipv6_activate_all_interfaces=NO # If NO, interfaces which have no ipv6_defaultrouter=NO # Set to IPv6 default gateway (or NO). ipv6_static_routes= # Set to static route list (or leave empty). #ipv6_static_routes=xxx # An example to set fec0:::0006::/64 # route toward loopback interface. #ipv6_route_xxx=fec0:::0006:: -prefixlen 64 ::1 ipv6_gateway_enable=NO# Set to YES if this host will be a gateway. ipv6_cpe_wanif=NO # Set to the upstram interface name if this # node will work as a router to forward IPv6 # packets not explicitly addressed to itself. ipv6_privacy=NO # Use privacy address on RA-receiving IFs # (RFC 4941) route6d_enable=NO # Set to YES to enable an IPv6 routing daemon. route6d_program=/usr/sbin/route6d # Name of IPv6 routing daemon. route6d_flags=# Flags to IPv6 routing daemon. #route6d_flags=-l # Example for route6d with only IPv6 site local # addrs. #route6d_flags=-q # If you want to run a routing daemon on an end # node, you should stop advertisement. #ipv6_network_interfaces=ed0 ep0 # Examples for router # or static configuration for end node. # Choose correct prefix value. #ipv6_prefix_ed0=fec0:::0001 fec0:::0002 # Examples for rtr. #ipv6_prefix_ep0=fec0:::0003 fec0:::0004 # Examples for rtr. ipv6_default_interface=NO # Default output interface for scoped addrs. # This works only with # ipv6_gateway_enable=NO. That pretty much it, nothing special I haven't made any changes to it in over 2 years. The only thing about 1 year ago I enabled: ### Network link/usability verification options netwait_enable=YES# Enable rc.d/netwait (or NO) netwait_ip=192.168.0.1# IP addresses to be pinged by netwait. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on powerpc/powerpc
TB --- 2013-01-03 00:12:40 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-01-03 00:12:40 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-01-03 00:12:40 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2013-01-03 00:12:40 - cleaning the object tree TB --- 2013-01-03 00:12:40 - /usr/local/bin/svn stat /src TB --- 2013-01-03 00:14:21 - At svn revision 244959 TB --- 2013-01-03 00:14:22 - building world TB --- 2013-01-03 00:14:22 - CROSS_BUILD_TESTING=YES TB --- 2013-01-03 00:14:22 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-03 00:14:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-03 00:14:22 - SRCCONF=/dev/null TB --- 2013-01-03 00:14:22 - TARGET=powerpc TB --- 2013-01-03 00:14:22 - TARGET_ARCH=powerpc TB --- 2013-01-03 00:14:22 - TZ=UTC TB --- 2013-01-03 00:14:22 - __MAKE_CONF=/dev/null TB --- 2013-01-03 00:14:22 - cd /src TB --- 2013-01-03 00:14:22 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Thu Jan 3 00:14:27 UTC 2013 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries [...] ranlib libllvmasmprinter.a === lib/clang/libllvmbitreader (all) c++ -O2 -pipe -I/src/lib/clang/libllvmbitreader/../../../contrib/llvm/include -I/src/lib/clang/libllvmbitreader/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmbitreader/../../../contrib/llvm/lib/Bitcode/Reader -I. -I/src/lib/clang/libllvmbitreader/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\powerpc-unknown-freebsd10.0\ -DLLVM_HOSTTRIPLE=\powerpc-unknown-freebsd10.0\ -DDEFAULT_SYSROOT=\\ -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmbitreader/../../../contrib/llvm/lib/Bitcode/Reader/BitcodeReader.cpp -o BitcodeReader.o /src/lib/clang/libllvmbitreader/../../../contrib/llvm/lib/Bitcode/Reader/BitcodeReader.cpp: In member function 'bool llvm::BitcodeReader::ParseFunctionBody(llvm::Function*)': /src/lib/clang/libllvmbitreader/../../../contrib/llvm/lib/Bitcode/Reader/BitcodeReader.cpp:1905: internal compiler error: Segmentation fault: 11 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. *** [BitcodeReader.o] Error code 1 Stop in /src/lib/clang/libllvmbitreader. *** [all] Error code 1 Stop in /src/lib/clang. *** [all] Error code 1 Stop in /src/lib. *** [lib__L] Error code 1 Stop in /src. *** [libraries] Error code 1 Stop in /src. *** [_libraries] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-01-03 01:37:18 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-01-03 01:37:18 - ERROR: failed to build world TB --- 2013-01-03 01:37:18 - 4087.23 user 492.52 system 5077.28 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-powerpc-powerpc.full ___ 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: loopback interface broken on current
Hello, I have a similar problem if ifconfig_lo0 line is exist in /etc/rc.conf. Can you remove lo0 configure line from /etc/rc.conf. /etc/rc.conf: ifconfig_lo0=inet 127.0.0.1 # default loopback device configuration. -- vi...@elam.kais.kyoto-u.ac.jp ___ 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: loopback interface broken on current
At 07:09 PM 1/2/2013, KAHO Toshikazu wrote: Hello, I have a similar problem if ifconfig_lo0 line is exist in /etc/rc.conf. Can you remove lo0 configure line from /etc/rc.conf. /etc/rc.conf: ifconfig_lo0=inet 127.0.0.1 # default loopback device configuration. Ok I commented out that line and it seems to work. There is still ifa_del_loopback_route: deletion failed: 3 that wasn't there before,but the 127.0.0.1 seems to be configured now: Setting hostname: pozo.com. bge0: link state changed to DOWN ifa_del_loopback_route: deletion failed: 3 bge0: link state changed to UP Starting Network: lo0 bge0. lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384 options=63RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 inet 127.0.0.1 netmask 0xff00 nd6 options=21PERFORMNUD,AUTO_LINKLOCAL bge0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8009bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE ether 00:0e:7f:66:30:20 inet 192.168.0.5 netmask 0xff00 broadcast 192.168.0.255 inet6 fe80::20e:7fff:fe66:3020%bge0 prefixlen 64 scopeid 0x1 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: Ethernet autoselect (100baseTX full-duplex) status: active Starting devd. add net default: gateway 192.168.0.1 add net :::0.0.0.0: gateway ::1 add net ::0.0.0.0: gateway ::1 add net fe80::: gateway ::1 add net ff02::: gateway ::1 Waiting for bge0 to have link. Waiting for 192.168.0.1 to respond to ICMP. # (~)4999}ping localhost PING localhost (127.0.0.1): 56 data bytes 64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.029 ms 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.039 ms 64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.050 ms 64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.045 ms 64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=0.042 ms 64 bytes from 127.0.0.1: icmp_seq=5 ttl=64 time=0.044 ms 64 bytes from 127.0.0.1: icmp_seq=6 ttl=64 time=0.047 ms 64 bytes from 127.0.0.1: icmp_seq=7 ttl=64 time=0.045 ms ^C --- localhost ping statistics --- 8 packets transmitted, 8 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.029/0.043/0.050/0.006 ms (~)5000} Manfred || n...@pozo.com || || Ph. (415) 681-6235 || -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ 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, Jan 2, 2013 at 2:06 PM, Alexander Motin m...@freebsd.org wrote: On 02.01.2013 18:08, Adrian Chadd wrote: .. I'm pretty damned sure we're going to need to enforce a never earlier than X latency. Do you mean here that we should never wake up before specified time (just as specified by the most of existing APIs), or that we should not allow sleep shorter then some value to avoid DoS? At least on x86 nanosleep(0) doesn't allow to block the system. Also there is already present mechanism for specifying minimum timer programming interval in eventtimers(9) KPI. I can see serious performance issues with some hardware (wireless comes to mind) if things happen too quickly. Intuition is that it could also play hob with VMs. I believe that the proper way is to wake between T_X and T_X + D. This assumes that D is max_wake_delay, not deviation, which leaves us at the original of (T_X) = event_time = (T_X + D). -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
