Re: recent update breaks some ports
On Tue, Apr 10, 2012 at 01:44:02AM -0400, AN wrote: FreeBSD FBSD10 10.0-CURRENT FreeBSD 10.0-CURRENT #7 r234042: Sun Apr 8 17:36:38 EDT 2012 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL amd64 After a recent update on Sunday to r234042 I am having a problem with 2 ports: gedit evince (using Gnome2 - ports tree up to date) My last update (before this past Sun build/install world) was 2 weeks ago, so it was definitely a change made in the last 2 weeks. Gedit will not start from the command line, or the applications menu. There is no error message on the command line. Evince will start, however when you try to open a document the program freezes. I have tried to: make deinstall make clean make install clean for both ports but they are still broken. I would appreciate any help. I'm experiencing that too (r234038), xine also no longer starts (hangs at splash screen). 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
Recent changes in libthr broke base bind package tools and named on amd64
I've recently installworld my test setup and found bind tools: dig, host hangs during usage (latest bind 9.8.2 in -CURRENT base. The same with named too. Replacing /lib/libthr.so.3 with previous build (26 march) eliminates the problem. backtrace every time the same: (gdb) bt #0 0x00080123ae4c in kevent () from /lib/libc.so.7 #1 0x0052a250 in ?? () #2 0x000800d64cdd in pthread_create () from /lib/libthr.so.3 #3 0x in ?? () Error accessing memory address 0x7f7fc000 Hang processes can be killed only by SIGKILL I see correlated messages in this list with subject recent update breaks some ports. I can assume they use libthr as well. The whole system compiled (in my case) with stock gcc 4.2.1, the kernel with the base clang. btw buildworld fails with clang. # uname -rp 10.0-CURRENT amd64 ___ 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: r234000: i386 freeze when HT enabled
09.04.2012 19:37, Gavin Atkinson пишет: On Mon, 9 Apr 2012, Alex Keda wrote: FreeBSD bsd-test.moskb.local 9.9-CURRENT FreeBSD 10.0-CURRENT #0 r234000: Sun Apr 8 03:02:51 MSK 2012 root@bsd-test.moskb.local:/usr/obj/usr/src/sys/GENERIC i386 Proliant 320 G4 freeze with Hyper-Threading enabled with last Line some about CPU1 AP Launched with disabled - boot OK Can you try reverting r233961 and seeing if this fixes boot for you? No. Yesterday, I reinstall all my desktops and laptops to 9.0 last 4-5 month too many not fixed problems with CURRENT- ___ 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: r234000: i386 freeze when HT enabled
on 10/04/2012 11:49 Alex Keda said the following: 09.04.2012 19:37, Gavin Atkinson пишет: On Mon, 9 Apr 2012, Alex Keda wrote: FreeBSD bsd-test.moskb.local 9.9-CURRENT FreeBSD 10.0-CURRENT #0 r234000: Sun Apr 8 03:02:51 MSK 2012 root@bsd-test.moskb.local:/usr/obj/usr/src/sys/GENERIC i386 Proliant 320 G4 freeze with Hyper-Threading enabled with last Line some about CPU1 AP Launched with disabled - boot OK Can you try reverting r233961 and seeing if this fixes boot for you? No. Yesterday, I reinstall all my desktops and laptops to 9.0 last 4-5 month too many not fixed problems with CURRENT- How about kern.eventtimer.periodic=1 ? -- Andriy Gapon ___ 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
Changes to sbin/init/init.c (r233944) makes x11/xdm impossible to start from /etc/ttys
Since I have had much trouble starting xdm via /etc/ttys, I tried to
investigate the revision when the bug was introduced and as I wrote in a
former message to the list, since I recompile world almost daily, I saw
the introduction with a commit to sbin/init/init.c.
A subversion diff reveals:
===
Index: sbin/init/init.c
===
--- sbin/init/init.c(revision 233944)
+++ sbin/init/init.c(working copy)
@@ -572,9 +572,13 @@
{
int fd;
- /* Try to open /dev/console. */
+ /*
+* Try to open /dev/console. Open the device with O_NONBLOCK to
+* prevent potential blocking on a carrier.
+*/
revoke(_PATH_CONSOLE);
if ((fd = open(_PATH_CONSOLE, O_RDWR | O_NONBLOCK)) != -1) {
+ (void)fcntl(fd, F_SETFL, fcntl(fd, F_GETFL) ~O_NONBLOCK);
if (login_tty(fd) == 0)
return;
close(fd);
===
Reverting init.c back to its previous state seems to make the error go away.
The error xdm is loggin is:
===
Build Date: 07 April 2012 04:51:08PM
Current version of pixman: 0.24.2
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: /var/log/Xorg.0.log, Time: Sat Apr 7 18:38:24 2012
(==) Using config file: /etc/X11/xorg.conf
xdm info (pid 2055): sourcing /usr/local/share/X11/xdm/Xsetup_0
xdm error (pid 2050): Unknown session exit code 2560 from process 2055
xdm info (pid 2050): Exiting
===
Some others report also misbehaviour of some ports, susepcting libthr. I
do not know wether this report is valuable, I also filed a PR upon this,
but I hope it could help finding the bug.
When xdm is failing via /etc/ttys, manipulating some of its config
files, even only comments (jn Xaccess, Xservers), makes xdm sometimes to
start, but this is highly erratic.
A more likely way is to start xdm by typing xdm from console, even with
/etc/ttys xdm startup configured or by reverting sbin/init/init.c
sources back to r233943.
Regards,
Oliver
signature.asc
Description: OpenPGP digital signature
gstat don't work after update to 10.0-CURRENT
gstat don't work after update to 10.0-CURRENT r233947 It don't show any providers, and don't print any errors: # gstat -b dT: 1.166s w: 1.000s L(q) ops/sr/s kBps ms/rw/s kBps ms/w %busy Name # HDD works via ATA_CAM. :~ sysctl kern.disks kern.disks: ada2 ada1 ada0 # camcontrol devlist WDC WD1600JS-00MHB0 02.01C03 at scbus3 target 0 lun 0 (ada0,pass0) WDC WD1600JS-60MHB5 10.02E04 at scbus4 target 0 lun 0 (ada1,pass1) WDC WD5001ABYS-01YNA0 59.01D01 at scbus5 target 0 lun 0 (ada2,pass2) sysctl kern.geom output: http://paste.org.ru/?i2a2zp Any suggestuions how to fix gstat? -- Anton Yuzhaninov ___ 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: recent update breaks some ports
On Tue, 10 Apr 2012 08:31:53 +0200 Stefan Farfeleder ste...@fafoe.narf.at wrote: On Tue, Apr 10, 2012 at 01:44:02AM -0400, AN wrote: FreeBSD FBSD10 10.0-CURRENT FreeBSD 10.0-CURRENT #7 r234042: Sun Apr 8 17:36:38 EDT 2012 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL amd64 After a recent update on Sunday to r234042 I am having a problem with 2 ports: gedit evince (using Gnome2 - ports tree up to date) My last update (before this past Sun build/install world) was 2 weeks ago, so it was definitely a change made in the last 2 weeks. Gedit will not start from the command line, or the applications menu. There is no error message on the command line. Evince will start, however when you try to open a document the program freezes. I have tried to: make deinstall make clean make install clean for both ports but they are still broken. I would appreciate any help. I'm experiencing that too (r234038), xine also no longer starts (hangs at splash screen). this might be related (or not, i did not have time to dig very deep). The issue i experienced is: ports/lang/erlang is not able to start it's wxgtk application. it boiled down to: any attempt to dlopen(3) /usr/lib/stdc++.so.6 from within the erlang vm results in a frozen erlang VM. how to repeat: # cd /usr/ports/lang/erlang # make -DWITHOUT_JAVA -DWITHOUT_X11 -DWITHOUT_ODBC -DWITHOUT_WX -DWITH_SMP install # erl 1 erl_ddll:load(/usr/lib, libstdc++). it hangs here. i attached gdb to a (debug enabled) erlang beam process, set some break points and saw that the the above erlang call results in dlopen(dlname, RTL_NOW), where dlname points to /usr/lib/libstdc++.so.6. since the problem goes away when using libstdc++ from the gcc48 port (i suspect it goes away when using _any_ libstdc++ except the base system one). i stopped investigating an put the relevant line into my /etc/libmap.conf best regards stefan grundmann ___ 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: gstat don't work after update to 10.0-CURRENT
On Tue, 10 Apr 2012 15:19:37, Anton Yuzhaninov wrote: AY gstat don't work after update to 10.0-CURRENT r233947 AY It don't show any providers, and don't print any errors: AY # gstat -b AY dT: 1.166s w: 1.000s AY L(q) ops/sr/s kBps ms/rw/s kBps ms/w %busy Name AY # After reverting r233646 gstat show: dT: 1.001s w: 1.000s L(q) ops/sr/s kBps ms/rw/s kBps ms/w %busy Name 0 0 0 00.0 0 00.00.0 ada0 0 0 0 00.0 0 00.00.0 ada0s1 0 0 0 00.0 0 00.00.0 ada1 1392392 19032.3 0 00.0 91.6 ada2 0 0 0 00.0 0 00.00.0 ada1s1 1392392 19032.4 0 00.0 92.5 ufs/backup 0 0 0 00.0 0 00.00.0 mirror/gm0 0 0 0 00.0 0 00.00.0 mirror/gm0a 0 0 0 00.0 0 00.00.0 mirror/gm0b 0 0 0 00.0 0 00.00.0 mirror/gm0d so problem somewhere in http://svn.freebsd.org/changeset/base/233646 -- Anton Yuzhaninov ___ 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: Idea for GEOM and policy based file encryption
On 2012-03-21, at 6:47, Andrey V. Elsukov a...@freebsd.org wrote: On 21.03.2012 14:09, Victor Balada Diaz wrote: You would need to modify UFS, or maybe do something like CFS[1]. CFS works as an NFS server and you could modify it to only cipher the needed files. Also you could write a simple FS on FUSE, but last time i checked, our FUSE support had some problems. Yet another link: http://www.arg0.net/encfs -- WBR, Andrey V. Elsukov ___ freebsd...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-fs To unsubscribe, send any mail to freebsd-fs-unsubscr...@freebsd.org Or you can check PEFS kernel module for FreeBSD. It is in the ports. ___ 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: (unionfs) panic: excl-share with r230341 and above
On Tue, 10 Apr 2012, Daichi GOTO wrote: Thanks kwhite, I found an another lock issue. Please try a patch included. ... Success. Your latest patch fixes the problem. Thanks! ...keith ___ 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: device_attach(9) and driver initialization
On Monday, April 09, 2012 4:05:29 pm Konstantin Belousov wrote:
On Mon, Apr 09, 2012 at 03:36:08PM -0400, John Baldwin wrote:
On Monday, April 09, 2012 3:10:00 pm Konstantin Belousov wrote:
On Mon, Apr 09, 2012 at 11:01:03AM -0400, John Baldwin wrote:
On Saturday, April 07, 2012 11:08:41 pm Warner Losh wrote:
On Apr 7, 2012, at 8:46 AM, Ian Lepore wrote:
On Sat, 2012-04-07 at 15:50 +0300, Konstantin Belousov wrote:
Hello,
there seems to be a problem with device attach sequence offered by
newbus.
Basically, when device attach method is executing, device is not
fully
initialized yet. Also the device state in the newbus part of the
world
is DS_ALIVE. There is definitely no shattering news in the
statements,
but drivers that e.g. create devfs node to communicate with
consumers
are prone to a race.
If /dev node is created inside device attach method, then usermode
can start calling cdevsw methods before device fully initialized
itself.
Even more, if device tries to use newbus helpers in cdevsw methods,
like device_busy(9), then panic occurs called for unatteched
device.
I get reports from users about this issues, to it is not something
that only could happen.
I propose to add DEVICE_AFTER_ATTACH() driver method, to be called
from newbus right after device attach finished and newbus considers
the device fully initialized. Driver then could create devfs node
in the after_attach method instead of attach. Please see the patch
below.
diff --git a/sys/kern/device_if.m b/sys/kern/device_if.m
index eb720eb..9db74e2 100644
--- a/sys/kern/device_if.m
+++ b/sys/kern/device_if.m
@@ -43,6 +43,10 @@ INTERFACE device;
# Default implementations of some methods.
#
CODE {
+ static void null_after_attach(device_t dev)
+ {
+ }
+
static int null_shutdown(device_t dev)
{
return 0;
@@ -199,6 +203,21 @@ METHOD int attach {
};
/**
+ * @brief Notify the driver that device is in attached state
+ *
+ * Called after driver is successfully attached to the device and
+ * corresponding device_t is fully operational. Driver now may
expose
+ * the device to the consumers, e.g. create devfs nodes.
+ *
+ * @param dev the device to probe
+ *
+ * @see DEVICE_ATTACH()
+ */
+METHOD void after_attach {
+ device_t dev;
+} DEFAULT null_after_attach;
+
+/**
* @brief Detach a driver from a device.
*
* This can be called if the user is replacing the
diff --git a/sys/kern/subr_bus.c b/sys/kern/subr_bus.c
index d485b9f..6d849cb 100644
--- a/sys/kern/subr_bus.c
+++ b/sys/kern/subr_bus.c
@@ -2743,6 +2743,7 @@ device_attach(device_t dev)
dev-state = DS_ATTACHED;
dev-flags = ~DF_DONENOMATCH;
devadded(dev);
+ DEVICE_AFTER_ATTACH(dev);
return (0);
}
Does device_get_softc() work before attach is completed? (I don't
have
time to go look in the code right now). If so, then a mutex
initialized
and acquired early in the driver's attach routine, and also
acquired in
the driver's cdev implementation routines before using any newbus
functions other than device_get_softc(), would solve the problem
without
a driver api change that would make it harder to backport/MFC driver
changes.
Also, more generally, don't create the dev nodes before you are ready
to
deal with requests. Why do we need to uglify everything here? If you
can't
do that, you can check a bit in the softc and return EBUSY or ENXIO on
open if
that bit says that your driver isn't ready to accept requests.
I agree, this dosen't actually fix anything as the decision for what to
put
in your foo_attach() method rather than foo_after_attach() is
non-obvious and
very arbitrary.
The actual bug appears to only be with using 'device_busy()'. I think
this should be fixed by making device_busy() better, not by adding
this type of obfuscation to attach. It should be trivial to make
device_busy() safe to use on a device that is currently being attached
which will not require any changes to drivers.
Could you, please, elaborate your proposal ? How do you think
device_busy()
can be enchanced ?
Obvious idea to sleep inside device_busy() until dev-state becomes !=
DS_ATTACHED is no go, IMO. The issue is that this causes immediate
deadlocks
if device_attach() method needs to call destroy_dev() to rollback.
I think you could have a DS_ATTACHING state and allow device_busy()
Re: Changes to sbin/init/init.c (r233944) makes x11/xdm impossible to start from /etc/ttys
Thanks a lot to investigate this problem so deeply. I have, maybe related, a bit strange phenomenon among xdm, too. I have a bit different setup than others: I'm using modified x11/gdm/files/gdm.in to launch xdm. The problem is, when I start xdm manually from ttyvX like this: exec sudo service xdm start xdm won't start, while doing like this: sudo service xdm start; sleep 10; exit xdm starts happily. To emulate this symptom for those who don't use rc.d/xdm, in ttyvX: exec sudo sh -c (sleep 10; /usr/local/bin/xdm) (The amount to sleep may differ if some race conditions are involved.) I guess the root cause seems to reside in accessing revoke(2)-ed (or possibly, about to be revoke(2)-ed) tty. I hope my shallow observation can shed some lights from different perspective. -- -|-__ YAMAMOTO, Taku | __ t...@tackymt.homeip.net - A chicken is an egg's way of producing more eggs. - Post Scriptum: In my environment and/or setup, xdm auto-starts fine 100% times via rc.d on system startup. ___ 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 i386/i386
TB --- 2012-04-10 09:00:01 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-04-10 09:00:01 - 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 --- 2012-04-10 09:00:01 - starting HEAD tinderbox run for i386/i386 TB --- 2012-04-10 09:00:01 - cleaning the object tree TB --- 2012-04-10 09:04:36 - cvsupping the source tree TB --- 2012-04-10 09:04:36 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2012-04-10 09:05:42 - building world TB --- 2012-04-10 09:05:42 - CROSS_BUILD_TESTING=YES TB --- 2012-04-10 09:05:42 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-10 09:05:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-10 09:05:42 - SRCCONF=/dev/null TB --- 2012-04-10 09:05:42 - TARGET=i386 TB --- 2012-04-10 09:05:42 - TARGET_ARCH=i386 TB --- 2012-04-10 09:05:42 - TZ=UTC TB --- 2012-04-10 09:05:42 - __MAKE_CONF=/dev/null TB --- 2012-04-10 09:05:42 - cd /src TB --- 2012-04-10 09:05:42 - /usr/bin/make -B buildworld World build started on Tue Apr 10 09:05:43 UTC 2012 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 stage 4.3: make dependencies stage 4.4: building everything World build completed on Tue Apr 10 11:23:21 UTC 2012 TB --- 2012-04-10 11:23:21 - generating LINT kernel config TB --- 2012-04-10 11:23:21 - cd /src/sys/i386/conf TB --- 2012-04-10 11:23:21 - /usr/bin/make -B LINT TB --- 2012-04-10 11:23:23 - cd /src/sys/i386/conf TB --- 2012-04-10 11:23:23 - /usr/sbin/config -m LINT TB --- 2012-04-10 11:23:23 - building LINT kernel TB --- 2012-04-10 11:23:23 - CROSS_BUILD_TESTING=YES TB --- 2012-04-10 11:23:23 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-10 11:23:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-10 11:23:23 - SRCCONF=/dev/null TB --- 2012-04-10 11:23:23 - TARGET=i386 TB --- 2012-04-10 11:23:23 - TARGET_ARCH=i386 TB --- 2012-04-10 11:23:23 - TZ=UTC TB --- 2012-04-10 11:23:23 - __MAKE_CONF=/dev/null TB --- 2012-04-10 11:23:23 - cd /src TB --- 2012-04-10 11:23:23 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Tue Apr 10 11:23:23 UTC 2012 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT completed on Tue Apr 10 11:56:58 UTC 2012 TB --- 2012-04-10 11:56:58 - cd /src/sys/i386/conf TB --- 2012-04-10 11:56:58 - /usr/sbin/config -m LINT-NOINET TB --- 2012-04-10 11:56:58 - building LINT-NOINET kernel TB --- 2012-04-10 11:56:58 - CROSS_BUILD_TESTING=YES TB --- 2012-04-10 11:56:58 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-10 11:56:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-10 11:56:58 - SRCCONF=/dev/null TB --- 2012-04-10 11:56:58 - TARGET=i386 TB --- 2012-04-10 11:56:58 - TARGET_ARCH=i386 TB --- 2012-04-10 11:56:58 - TZ=UTC TB --- 2012-04-10 11:56:58 - __MAKE_CONF=/dev/null TB --- 2012-04-10 11:56:58 - cd /src TB --- 2012-04-10 11:56:58 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET Kernel build for LINT-NOINET started on Tue Apr 10 11:56:58 UTC 2012 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT-NOINET completed on Tue Apr 10 12:28:13 UTC 2012 TB --- 2012-04-10 12:28:13 - cd /src/sys/i386/conf TB --- 2012-04-10 12:28:13 - /usr/sbin/config -m LINT-NOINET6 TB --- 2012-04-10 12:28:13 - building LINT-NOINET6 kernel TB --- 2012-04-10 12:28:13 - CROSS_BUILD_TESTING=YES TB --- 2012-04-10 12:28:13 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-10 12:28:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-10 12:28:13 - SRCCONF=/dev/null TB --- 2012-04-10 12:28:13 - TARGET=i386 TB --- 2012-04-10 12:28:13 - TARGET_ARCH=i386 TB --- 2012-04-10 12:28:13 - TZ=UTC TB --- 2012-04-10 12:28:13 - __MAKE_CONF=/dev/null TB --- 2012-04-10 12:28:13 - cd /src TB --- 2012-04-10 12:28:13 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 Kernel build for LINT-NOINET6 started on Tue Apr 10 12:28:14 UTC 2012 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT-NOINET6 completed on Tue Apr 10 13:00:04 UTC 2012 TB --- 2012-04-10 13:00:04 - cd /src/sys/i386/conf TB --- 2012-04-10 13:00:04 - /usr/sbin/config -m LINT-NOIP TB --- 2012-04-10 13:00:04 - building LINT-NOIP kernel TB --- 2012-04-10 13:00:04 - CROSS_BUILD_TESTING=YES TB --- 2012-04-10 13:00:04
Re: device_attach(9) and driver initialization
On Tue, Apr 10, 2012 at 09:56:06AM -0400, John Baldwin wrote:
On Monday, April 09, 2012 4:05:29 pm Konstantin Belousov wrote:
On Mon, Apr 09, 2012 at 03:36:08PM -0400, John Baldwin wrote:
On Monday, April 09, 2012 3:10:00 pm Konstantin Belousov wrote:
On Mon, Apr 09, 2012 at 11:01:03AM -0400, John Baldwin wrote:
On Saturday, April 07, 2012 11:08:41 pm Warner Losh wrote:
On Apr 7, 2012, at 8:46 AM, Ian Lepore wrote:
On Sat, 2012-04-07 at 15:50 +0300, Konstantin Belousov wrote:
Hello,
there seems to be a problem with device attach sequence offered
by
newbus.
Basically, when device attach method is executing, device is not
fully
initialized yet. Also the device state in the newbus part of the
world
is DS_ALIVE. There is definitely no shattering news in the
statements,
but drivers that e.g. create devfs node to communicate with
consumers
are prone to a race.
If /dev node is created inside device attach method, then
usermode
can start calling cdevsw methods before device fully initialized
itself.
Even more, if device tries to use newbus helpers in cdevsw
methods,
like device_busy(9), then panic occurs called for unatteched
device.
I get reports from users about this issues, to it is not
something
that only could happen.
I propose to add DEVICE_AFTER_ATTACH() driver method, to be
called
from newbus right after device attach finished and newbus
considers
the device fully initialized. Driver then could create devfs node
in the after_attach method instead of attach. Please see the
patch below.
diff --git a/sys/kern/device_if.m b/sys/kern/device_if.m
index eb720eb..9db74e2 100644
--- a/sys/kern/device_if.m
+++ b/sys/kern/device_if.m
@@ -43,6 +43,10 @@ INTERFACE device;
# Default implementations of some methods.
#
CODE {
+static void null_after_attach(device_t dev)
+{
+}
+
static int null_shutdown(device_t dev)
{
return 0;
@@ -199,6 +203,21 @@ METHOD int attach {
};
/**
+ * @brief Notify the driver that device is in attached state
+ *
+ * Called after driver is successfully attached to the device
and
+ * corresponding device_t is fully operational. Driver now may
expose
+ * the device to the consumers, e.g. create devfs nodes.
+ *
+ * @param dev the device to probe
+ *
+ * @see DEVICE_ATTACH()
+ */
+METHOD void after_attach {
+device_t dev;
+} DEFAULT null_after_attach;
+
+/**
* @brief Detach a driver from a device.
*
* This can be called if the user is replacing the
diff --git a/sys/kern/subr_bus.c b/sys/kern/subr_bus.c
index d485b9f..6d849cb 100644
--- a/sys/kern/subr_bus.c
+++ b/sys/kern/subr_bus.c
@@ -2743,6 +2743,7 @@ device_attach(device_t dev)
dev-state = DS_ATTACHED;
dev-flags = ~DF_DONENOMATCH;
devadded(dev);
+DEVICE_AFTER_ATTACH(dev);
return (0);
}
Does device_get_softc() work before attach is completed? (I
don't have
time to go look in the code right now). If so, then a mutex
initialized
and acquired early in the driver's attach routine, and also
acquired in
the driver's cdev implementation routines before using any newbus
functions other than device_get_softc(), would solve the problem
without
a driver api change that would make it harder to backport/MFC
driver
changes.
Also, more generally, don't create the dev nodes before you are
ready to
deal with requests. Why do we need to uglify everything here? If
you can't
do that, you can check a bit in the softc and return EBUSY or ENXIO
on open if
that bit says that your driver isn't ready to accept requests.
I agree, this dosen't actually fix anything as the decision for what
to put
in your foo_attach() method rather than foo_after_attach() is
non-obvious and
very arbitrary.
The actual bug appears to only be with using 'device_busy()'. I think
this should be fixed by making device_busy() better, not by adding
this type of obfuscation to attach. It should be trivial to make
device_busy() safe to use on a device that is currently being attached
which will not require any changes to drivers.
Could you, please, elaborate your proposal ? How do you think
device_busy()
can be enchanced ?
Obvious idea to sleep inside
Re: [RFT][patch] Scheduling for HTT and not only
Hi, 2012/4/9 Alexander Motin m...@freebsd.org: [...] I have strong feeling that while this test may be interesting for profiling, it's own results in first place depend not from how fast scheduler is, but from the pipes capacity and other alike things. Can somebody hint me what except pipe capacity and context switch to unblocked receiver prevents sender from sending all data in batch and then receiver from receiving them all in batch? If different OSes have different policies there, I think results could be incomparable. Let me disagree on your conclusion. If OS A does a task in X seconds, and OS B does the same task in Y seconds, if Y X, then OS B is just not performing good enough. Internal implementation's difference for the task can not be waived as an excuse for result's comparability. - Arnaud ___ 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: [RFT][patch] Scheduling for HTT and not only
On 04/10/12 19:58, Arnaud Lacombe wrote: 2012/4/9 Alexander Motinm...@freebsd.org: [...] I have strong feeling that while this test may be interesting for profiling, it's own results in first place depend not from how fast scheduler is, but from the pipes capacity and other alike things. Can somebody hint me what except pipe capacity and context switch to unblocked receiver prevents sender from sending all data in batch and then receiver from receiving them all in batch? If different OSes have different policies there, I think results could be incomparable. Let me disagree on your conclusion. If OS A does a task in X seconds, and OS B does the same task in Y seconds, if Y X, then OS B is just not performing good enough. Internal implementation's difference for the task can not be waived as an excuse for result's comparability. Sure, numbers are always numbers, but the question is what are they showing? Understanding of the test results is even more important for purely synthetic tests like this. Especially when one test run gives 25 seconds, while another gives 50. This test is not completely clear to me and that is what I've told. -- 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: [RFT][patch] Scheduling for HTT and not only
On 04/10/12 20:18, Alexander Motin wrote: On 04/10/12 19:58, Arnaud Lacombe wrote: 2012/4/9 Alexander Motinm...@freebsd.org: [...] I have strong feeling that while this test may be interesting for profiling, it's own results in first place depend not from how fast scheduler is, but from the pipes capacity and other alike things. Can somebody hint me what except pipe capacity and context switch to unblocked receiver prevents sender from sending all data in batch and then receiver from receiving them all in batch? If different OSes have different policies there, I think results could be incomparable. Let me disagree on your conclusion. If OS A does a task in X seconds, and OS B does the same task in Y seconds, if Y X, then OS B is just not performing good enough. Internal implementation's difference for the task can not be waived as an excuse for result's comparability. Sure, numbers are always numbers, but the question is what are they showing? Understanding of the test results is even more important for purely synthetic tests like this. Especially when one test run gives 25 seconds, while another gives 50. This test is not completely clear to me and that is what I've told. Small illustration to my point. Simple scheduler tuning affects thread preemption policy and changes this test results in three times: mav@test:/test/hackbench# ./hackbench 30 process 1000 Running with 30*40 (== 1200) tasks. Time: 9.568 mav@test:/test/hackbench# sysctl kern.sched.interact=0 kern.sched.interact: 30 - 0 mav@test:/test/hackbench# ./hackbench 30 process 1000 Running with 30*40 (== 1200) tasks. Time: 5.163 mav@test:/test/hackbench# sysctl kern.sched.interact=100 kern.sched.interact: 0 - 100 mav@test:/test/hackbench# ./hackbench 30 process 1000 Running with 30*40 (== 1200) tasks. Time: 3.190 I think it affects balance between pipe latency and bandwidth, while test measures only the last. It is clear that conclusion from these numbers depends on what do we want to have. -- 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: [RFT][patch] Scheduling for HTT and not only
Hi, On Tue, Apr 10, 2012 at 1:53 PM, Alexander Motin m...@freebsd.org wrote: On 04/10/12 20:18, Alexander Motin wrote: On 04/10/12 19:58, Arnaud Lacombe wrote: 2012/4/9 Alexander Motinm...@freebsd.org: [...] I have strong feeling that while this test may be interesting for profiling, it's own results in first place depend not from how fast scheduler is, but from the pipes capacity and other alike things. Can somebody hint me what except pipe capacity and context switch to unblocked receiver prevents sender from sending all data in batch and then receiver from receiving them all in batch? If different OSes have different policies there, I think results could be incomparable. Let me disagree on your conclusion. If OS A does a task in X seconds, and OS B does the same task in Y seconds, if Y X, then OS B is just not performing good enough. Internal implementation's difference for the task can not be waived as an excuse for result's comparability. Sure, numbers are always numbers, but the question is what are they showing? Understanding of the test results is even more important for purely synthetic tests like this. Especially when one test run gives 25 seconds, while another gives 50. This test is not completely clear to me and that is what I've told. Small illustration to my point. Simple scheduler tuning affects thread preemption policy and changes this test results in three times: mav@test:/test/hackbench# ./hackbench 30 process 1000 Running with 30*40 (== 1200) tasks. Time: 9.568 mav@test:/test/hackbench# sysctl kern.sched.interact=0 kern.sched.interact: 30 - 0 mav@test:/test/hackbench# ./hackbench 30 process 1000 Running with 30*40 (== 1200) tasks. Time: 5.163 mav@test:/test/hackbench# sysctl kern.sched.interact=100 kern.sched.interact: 0 - 100 mav@test:/test/hackbench# ./hackbench 30 process 1000 Running with 30*40 (== 1200) tasks. Time: 3.190 I think it affects balance between pipe latency and bandwidth, while test measures only the last. It is clear that conclusion from these numbers depends on what do we want to have. I don't really care on this point, I'm only testing default values, or more precisely, whatever developers though default values would be good. Btw, you are testing 3 differents configuration. Different results are expected. What worries me more is the rather the huge instability on the *same* configuration, say on a pipe/thread/70 groups/600 iterations run, where results range from 2.7s[0] to 7.4s, or a socket/thread/20 groups/1400 iterations run, where results range from 2.4s to 4.5s. - Arnaud [0]: numbers extracted from a recent run of 9.0-RELEASE on a Xeon E5-1650 platform. ___ 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: device_attach(9) and driver initialization
On Tuesday, April 10, 2012 10:38:35 am Konstantin Belousov wrote:
On Tue, Apr 10, 2012 at 09:56:06AM -0400, John Baldwin wrote:
On Monday, April 09, 2012 4:05:29 pm Konstantin Belousov wrote:
On Mon, Apr 09, 2012 at 03:36:08PM -0400, John Baldwin wrote:
On Monday, April 09, 2012 3:10:00 pm Konstantin Belousov wrote:
On Mon, Apr 09, 2012 at 11:01:03AM -0400, John Baldwin wrote:
On Saturday, April 07, 2012 11:08:41 pm Warner Losh wrote:
On Apr 7, 2012, at 8:46 AM, Ian Lepore wrote:
On Sat, 2012-04-07 at 15:50 +0300, Konstantin Belousov wrote:
Hello,
there seems to be a problem with device attach sequence
offered by
newbus.
Basically, when device attach method is executing, device is
not fully
initialized yet. Also the device state in the newbus part of
the world
is DS_ALIVE. There is definitely no shattering news in the
statements,
but drivers that e.g. create devfs node to communicate with
consumers
are prone to a race.
If /dev node is created inside device attach method, then
usermode
can start calling cdevsw methods before device fully
initialized itself.
Even more, if device tries to use newbus helpers in cdevsw
methods,
like device_busy(9), then panic occurs called for unatteched
device.
I get reports from users about this issues, to it is not
something
that only could happen.
I propose to add DEVICE_AFTER_ATTACH() driver method, to be
called
from newbus right after device attach finished and newbus
considers
the device fully initialized. Driver then could create devfs
node
in the after_attach method instead of attach. Please see the
patch below.
diff --git a/sys/kern/device_if.m b/sys/kern/device_if.m
index eb720eb..9db74e2 100644
--- a/sys/kern/device_if.m
+++ b/sys/kern/device_if.m
@@ -43,6 +43,10 @@ INTERFACE device;
# Default implementations of some methods.
#
CODE {
+ static void null_after_attach(device_t dev)
+ {
+ }
+
static int null_shutdown(device_t dev)
{
return 0;
@@ -199,6 +203,21 @@ METHOD int attach {
};
/**
+ * @brief Notify the driver that device is in attached state
+ *
+ * Called after driver is successfully attached to the device
and
+ * corresponding device_t is fully operational. Driver now
may expose
+ * the device to the consumers, e.g. create devfs nodes.
+ *
+ * @param dev the device to probe
+ *
+ * @see DEVICE_ATTACH()
+ */
+METHOD void after_attach {
+ device_t dev;
+} DEFAULT null_after_attach;
+
+/**
* @brief Detach a driver from a device.
*
* This can be called if the user is replacing the
diff --git a/sys/kern/subr_bus.c b/sys/kern/subr_bus.c
index d485b9f..6d849cb 100644
--- a/sys/kern/subr_bus.c
+++ b/sys/kern/subr_bus.c
@@ -2743,6 +2743,7 @@ device_attach(device_t dev)
dev-state = DS_ATTACHED;
dev-flags = ~DF_DONENOMATCH;
devadded(dev);
+ DEVICE_AFTER_ATTACH(dev);
return (0);
}
Does device_get_softc() work before attach is completed? (I
don't have
time to go look in the code right now). If so, then a mutex
initialized
and acquired early in the driver's attach routine, and also
acquired in
the driver's cdev implementation routines before using any
newbus
functions other than device_get_softc(), would solve the
problem without
a driver api change that would make it harder to backport/MFC
driver
changes.
Also, more generally, don't create the dev nodes before you are
ready to
deal with requests. Why do we need to uglify everything here? If
you can't
do that, you can check a bit in the softc and return EBUSY or ENXIO
on open if
that bit says that your driver isn't ready to accept requests.
I agree, this dosen't actually fix anything as the decision for
what to put
in your foo_attach() method rather than foo_after_attach() is
non-obvious and
very arbitrary.
The actual bug appears to only be with using 'device_busy()'. I
think
this should be fixed by making device_busy() better, not by adding
this type of obfuscation to attach. It should be trivial to make
device_busy() safe to use on
Re: [RFT][patch] Scheduling for HTT and not only
On 04/10/12 21:46, Arnaud Lacombe wrote: On Tue, Apr 10, 2012 at 1:53 PM, Alexander Motinm...@freebsd.org wrote: On 04/10/12 20:18, Alexander Motin wrote: On 04/10/12 19:58, Arnaud Lacombe wrote: 2012/4/9 Alexander Motinm...@freebsd.org: I have strong feeling that while this test may be interesting for profiling, it's own results in first place depend not from how fast scheduler is, but from the pipes capacity and other alike things. Can somebody hint me what except pipe capacity and context switch to unblocked receiver prevents sender from sending all data in batch and then receiver from receiving them all in batch? If different OSes have different policies there, I think results could be incomparable. Let me disagree on your conclusion. If OS A does a task in X seconds, and OS B does the same task in Y seconds, if Y X, then OS B is just not performing good enough. Internal implementation's difference for the task can not be waived as an excuse for result's comparability. Sure, numbers are always numbers, but the question is what are they showing? Understanding of the test results is even more important for purely synthetic tests like this. Especially when one test run gives 25 seconds, while another gives 50. This test is not completely clear to me and that is what I've told. Small illustration to my point. Simple scheduler tuning affects thread preemption policy and changes this test results in three times: mav@test:/test/hackbench# ./hackbench 30 process 1000 Running with 30*40 (== 1200) tasks. Time: 9.568 mav@test:/test/hackbench# sysctl kern.sched.interact=0 kern.sched.interact: 30 - 0 mav@test:/test/hackbench# ./hackbench 30 process 1000 Running with 30*40 (== 1200) tasks. Time: 5.163 mav@test:/test/hackbench# sysctl kern.sched.interact=100 kern.sched.interact: 0 - 100 mav@test:/test/hackbench# ./hackbench 30 process 1000 Running with 30*40 (== 1200) tasks. Time: 3.190 I think it affects balance between pipe latency and bandwidth, while test measures only the last. It is clear that conclusion from these numbers depends on what do we want to have. I don't really care on this point, I'm only testing default values, or more precisely, whatever developers though default values would be good. Btw, you are testing 3 differents configuration. Different results are expected. What worries me more is the rather the huge instability on the *same* configuration, say on a pipe/thread/70 groups/600 iterations run, where results range from 2.7s[0] to 7.4s, or a socket/thread/20 groups/1400 iterations run, where results range from 2.4s to 4.5s. Due to reason I've pointed in my first message this test is _extremely_ sensitive to context switch interval. The more aggressive scheduler switches threads, the smaller will be pipe latency, but the smaller will be also bandwidth. During test run scheduler all the time recalculates interactivity index for each thread, trying to balance between latency and switching overhead. With hundreds of threads running simultaneously and interfering with each other it is quite unpredictable process. -- 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: Changes to sbin/init/init.c (r233944) makes x11/xdm impossible to start from /etc/ttys
Hi Oliver, * O. Hartmann ohart...@mail.zedat.fu-berlin.de, 20120410 11:37: Reverting init.c back to its previous state seems to make the error go away. Sorry about that. I added the O_NONBLOCK to prevent init(8) from possibly getting stuck if the TTY used by /dev/console were to misbehave by not setting CLOCAL. It seems we can't do this reliably at all, so I guess I'd better just revert the code like so: http://80386.nl/pub/init.txt I'll commit the patch to SVN after I have discussed it wtih kib@. Thanks for reporting! -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ pgpIjmJRtiOFJ.pgp Description: PGP signature
Re: DTrace on FreeBSD
On 10/04/2012 02:45, Daichi GOTO wrote: Hi, From the DTrace tutorial at AsiaBSDCon 2012, it is a CDDL license issue. Hi Daichi, I wonder which clause/aspect of the license is a problem? We've been distributing dtrace as part of our source since FreeBSD 7.1 so the terms of license must have been acceptable for inclusion in our tree redistribution in source for each release since. I've been reading the CCDL license just now clause 3.5 on Distribution of executable vesions states You may distribute the Executable form of the Covered Software under the terms of this License or under the terms of a license of Your choice, which may contain terms different from this License, provided that You are in compliance with the terms of this License and that the license for the Executable form does not attempt to limit or alter the recipient’s rights in the Source Code form from the rights set forth in this License. If You distribute the Covered Software in Executable form under a different license, You must make it absolutely clear that any terms which differ from this License are offered by You alone, not by the Initial Developer or Contributor. You hereby agree to indemnify the Initial Developer and every Contributor for any liability incurred by the Initial Developer or such Contributor as a result of any such terms You offer. This shouldn't pose any legal problems for the project if DTrace was redistributed in binary form should it? Addition from my experiences, some applicaions can not be built on DTrace/UserlandDTrace-enabled system (VBox is) and Userland dtrace is still unstable. I see, was the virtual box issue recently, I'm pretty sure I was able to build virtual box on a DTrace enabled system in the past couple of months. Sevan ___ 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
strange ping response times...
I noticed this first on a 10G interface, but now there seems to be a similar issue on the loopback. Apparently a ping -f has a much lower RTT than one with non-zero delay between transmissions. Part of the story could be that the flood version invokes a non-blocking select. On the other hand, pinging on the loopback should make the response available right away, so what could be the reason for the additional 3..10us in the ping response time ? The following are numbers on an i7-2600k at 3400 MHz + turboboost, running stable/9 amd64. Note how the min ping time significantly increases moving from flood to 10ms to 1s. On an Intel 10G interface i am seeing a min of 14-16us with a ping flood, and up to 33-35us with the standard 1s interval (using -q probably trims another 2..5us) sudo ping -c 1000 -q -f 127.0.0.1 round-trip min/avg/max/stddev = 0.002/0.003/0.012/0.001 ms sudo ping -c 1000 -q -f 127.0.0.1 round-trip min/avg/max/stddev = 0.002/0.002/0.013/0.001 ms sudo ping -c 1000 -q -f 127.0.0.1 round-trip min/avg/max/stddev = 0.002/0.002/0.013/0.001 ms sudo ping -c 1 -q -f 127.0.0.1 round-trip min/avg/max/stddev = 0.002/0.002/0.011/0.001 ms sudo ping -c 1000 -q -i 0.01 127.0.0.1 round-trip min/avg/max/stddev = 0.005/0.012/0.017/0.001 ms sudo ping -c 1000 -q -i 0.01 127.0.0.1 round-trip min/avg/max/stddev = 0.004/0.012/0.016/0.001 ms sudo ping -c 200 -q -i 0.01 127.0.0.1 round-trip min/avg/max/stddev = 0.007/0.012/0.017/0.002 ms sudo ping -c 200 -q -i 0.01 127.0.0.1 round-trip min/avg/max/stddev = 0.005/0.012/0.018/0.002 ms sudo ping -c 200 -q -i 0.01 127.0.0.1 round-trip min/avg/max/stddev = 0.009/0.012/0.020/0.002 ms sudo ping -c 200 -q -i 0.01 127.0.0.1 round-trip min/avg/max/stddev = 0.006/0.012/0.016/0.001 ms sudo ping -c 200 -q -i 0.1 127.0.0.1 round-trip min/avg/max/stddev = 0.007/0.014/0.020/0.001 ms sudo ping -c 200 -q -i 0.1 127.0.0.1 round-trip min/avg/max/stddev = 0.006/0.014/0.019/0.002 ms sudo ping -c 200 -q -i 0.1 127.0.0.1 round-trip min/avg/max/stddev = 0.007/0.014/0.021/0.001 ms sudo ping -c 200 -q -i 0.1 127.0.0.1 round-trip min/avg/max/stddev = 0.007/0.014/0.020/0.001 ms sudo ping -c 200 -q -i 0.1 127.0.0.1 round-trip min/avg/max/stddev = 0.006/0.014/0.021/0.002 ms sudo ping -c 200 -q -i 0.1 127.0.0.1 round-trip min/avg/max/stddev = 0.010/0.014/0.022/0.001 ms sudo ping -c 20 -q -i 1 127.0.0.1 round-trip min/avg/max/stddev = 0.013/0.018/0.022/0.002 ms sudo ping -c 20 -q -i 1 127.0.0.1 round-trip min/avg/max/stddev = 0.012/0.018/0.021/0.002 ms sudo ping -c 20 -q -i 1 127.0.0.1 round-trip min/avg/max/stddev = 0.009/0.017/0.018/0.002 ms sudo ping -c 20 -q -i 1 127.0.0.1 round-trip min/avg/max/stddev = 0.011/0.017/0.021/0.002 ms sudo ping -c 20 -q -i 1 127.0.0.1 round-trip min/avg/max/stddev = 0.010/0.017/0.020/0.002 ms sudo ping -c 20 -q -i 1 127.0.0.1 round-trip min/avg/max/stddev = 0.009/0.017/0.028/0.004 ms cheers luigi ___ 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: strange ping response times...
On 4/10/12 3:52 PM, Luigi Rizzo wrote: I noticed this first on a 10G interface, but now there seems to be a similar issue on the loopback. Apparently a ping -f has a much lower RTT than one with non-zero delay between transmissions. Part of the story could be that the flood version invokes a non-blocking select. On the other hand, pinging on the loopback should make the response available right away, so what could be the reason for the additional 3..10us in the ping response time ? The following are numbers on an i7-2600k at 3400 MHz + turboboost, running stable/9 amd64. Note how the min ping time significantly increases moving from flood to 10ms to 1s. On an Intel 10G interface i am seeing a min of 14-16us with a ping flood, and up to 33-35us with the standard 1s interval (using -q probably trims another 2..5us) I'd suggest some ktr points around the loopback path.. sudo ping -c 1000 -q -f 127.0.0.1 round-trip min/avg/max/stddev = 0.002/0.003/0.012/0.001 ms sudo ping -c 1000 -q -f 127.0.0.1 round-trip min/avg/max/stddev = 0.002/0.002/0.013/0.001 ms sudo ping -c 1000 -q -f 127.0.0.1 round-trip min/avg/max/stddev = 0.002/0.002/0.013/0.001 ms sudo ping -c 1 -q -f 127.0.0.1 round-trip min/avg/max/stddev = 0.002/0.002/0.011/0.001 ms sudo ping -c 1000 -q -i 0.01 127.0.0.1 round-trip min/avg/max/stddev = 0.005/0.012/0.017/0.001 ms sudo ping -c 1000 -q -i 0.01 127.0.0.1 round-trip min/avg/max/stddev = 0.004/0.012/0.016/0.001 ms sudo ping -c 200 -q -i 0.01 127.0.0.1 round-trip min/avg/max/stddev = 0.007/0.012/0.017/0.002 ms sudo ping -c 200 -q -i 0.01 127.0.0.1 round-trip min/avg/max/stddev = 0.005/0.012/0.018/0.002 ms sudo ping -c 200 -q -i 0.01 127.0.0.1 round-trip min/avg/max/stddev = 0.009/0.012/0.020/0.002 ms sudo ping -c 200 -q -i 0.01 127.0.0.1 round-trip min/avg/max/stddev = 0.006/0.012/0.016/0.001 ms sudo ping -c 200 -q -i 0.1 127.0.0.1 round-trip min/avg/max/stddev = 0.007/0.014/0.020/0.001 ms sudo ping -c 200 -q -i 0.1 127.0.0.1 round-trip min/avg/max/stddev = 0.006/0.014/0.019/0.002 ms sudo ping -c 200 -q -i 0.1 127.0.0.1 round-trip min/avg/max/stddev = 0.007/0.014/0.021/0.001 ms sudo ping -c 200 -q -i 0.1 127.0.0.1 round-trip min/avg/max/stddev = 0.007/0.014/0.020/0.001 ms sudo ping -c 200 -q -i 0.1 127.0.0.1 round-trip min/avg/max/stddev = 0.006/0.014/0.021/0.002 ms sudo ping -c 200 -q -i 0.1 127.0.0.1 round-trip min/avg/max/stddev = 0.010/0.014/0.022/0.001 ms sudo ping -c 20 -q -i 1 127.0.0.1 round-trip min/avg/max/stddev = 0.013/0.018/0.022/0.002 ms sudo ping -c 20 -q -i 1 127.0.0.1 round-trip min/avg/max/stddev = 0.012/0.018/0.021/0.002 ms sudo ping -c 20 -q -i 1 127.0.0.1 round-trip min/avg/max/stddev = 0.009/0.017/0.018/0.002 ms sudo ping -c 20 -q -i 1 127.0.0.1 round-trip min/avg/max/stddev = 0.011/0.017/0.021/0.002 ms sudo ping -c 20 -q -i 1 127.0.0.1 round-trip min/avg/max/stddev = 0.010/0.017/0.020/0.002 ms sudo ping -c 20 -q -i 1 127.0.0.1 round-trip min/avg/max/stddev = 0.009/0.017/0.028/0.004 ms cheers luigi ___ 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 ___ 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: strange ping response times...
On Tue, Apr 10, 2012 at 07:05:00PM -0400, Barney Wolff wrote: CPU cache? Cx states? powerd? powerd is disabled, and i am going down to C1 at most sysctl -a | grep cx hw.acpi.cpu.cx_lowest: C1 dev.cpu.0.cx_supported: C1/1 C2/80 C3/104 which shouldn't take so much. Sure, cache matters, but the fact is, icmp processing on loopback should occur inline. unless there is a forced descheduling on a select with timeout 0 which would explain the extra few microseconds (and makes me worry on how expensive is a scheduling decision...) cheers luigi On Tue, Apr 10, 2012 at 03:40:27PM -0700, Julian Elischer wrote: On 4/10/12 3:52 PM, Luigi Rizzo wrote: I noticed this first on a 10G interface, but now there seems to be a similar issue on the loopback. Apparently a ping -f has a much lower RTT than one with non-zero delay between transmissions. Part of the story could be that the flood version invokes a non-blocking select. On the other hand, pinging on the loopback should make the response available right away, so what could be the reason for the additional 3..10us in the ping response time ? The following are numbers on an i7-2600k at 3400 MHz + turboboost, running stable/9 amd64. Note how the min ping time significantly increases moving from flood to 10ms to 1s. On an Intel 10G interface i am seeing a min of 14-16us with a ping flood, and up to 33-35us with the standard 1s interval (using -q probably trims another 2..5us) I'd suggest some ktr points around the loopback path.. ___ 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: strange ping response times...
CPU cache? Cx states? powerd? On Tue, Apr 10, 2012 at 03:40:27PM -0700, Julian Elischer wrote: On 4/10/12 3:52 PM, Luigi Rizzo wrote: I noticed this first on a 10G interface, but now there seems to be a similar issue on the loopback. Apparently a ping -f has a much lower RTT than one with non-zero delay between transmissions. Part of the story could be that the flood version invokes a non-blocking select. On the other hand, pinging on the loopback should make the response available right away, so what could be the reason for the additional 3..10us in the ping response time ? The following are numbers on an i7-2600k at 3400 MHz + turboboost, running stable/9 amd64. Note how the min ping time significantly increases moving from flood to 10ms to 1s. On an Intel 10G interface i am seeing a min of 14-16us with a ping flood, and up to 33-35us with the standard 1s interval (using -q probably trims another 2..5us) I'd suggest some ktr points around the loopback path.. ___ 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: DTrace on FreeBSD
On Tue, 10 Apr 2012 23:14:07 +0100 Sevan / Venture37 ventur...@gmail.com wrote: On 10/04/2012 02:45, Daichi GOTO wrote: Hi, From the DTrace tutorial at AsiaBSDCon 2012, it is a CDDL license issue. Hi Daichi, I wonder which clause/aspect of the license is a problem? I do not know well. And I think Tod McQuillin could help you. (http://2012.asiabsdcon.org/timetable.html#T1B) We've been distributing dtrace as part of our source since FreeBSD 7.1 so the terms of license must have been acceptable for inclusion in our tree redistribution in source for each release since. I've been reading the CCDL license just now clause 3.5 on Distribution of executable vesions states You may distribute the Executable form of the Covered Software under the terms of this License or under the terms of a license of Your choice, which may contain terms different from this License, provided that You are in compliance with the terms of this License and that the license for the Executable form does not attempt to limit or alter the recipient’s rights in the Source Code form from the rights set forth in this License. If You distribute the Covered Software in Executable form under a different license, You must make it absolutely clear that any terms which differ from this License are offered by You alone, not by the Initial Developer or Contributor. You hereby agree to indemnify the Initial Developer and every Contributor for any liability incurred by the Initial Developer or such Contributor as a result of any such terms You offer. This shouldn't pose any legal problems for the project if DTrace was redistributed in binary form should it? Addition from my experiences, some applicaions can not be built on DTrace/UserlandDTrace-enabled system (VBox is) and Userland dtrace is still unstable. I see, was the virtual box issue recently, I'm pretty sure I was able to build virtual box on a DTrace enabled system in the past couple of months. You did? I'm so jealous! Sevan ___ 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 -- Daichi GOTO (daichi) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ 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 sparc64/sparc64
TB --- 2012-04-10 23:34:24 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-04-10 23:34:24 - 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 --- 2012-04-10 23:34:24 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2012-04-10 23:34:25 - cleaning the object tree TB --- 2012-04-10 23:34:25 - cvsupping the source tree TB --- 2012-04-10 23:34:25 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2012-04-10 23:34:58 - building world TB --- 2012-04-10 23:34:58 - CROSS_BUILD_TESTING=YES TB --- 2012-04-10 23:34:58 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-10 23:34:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-10 23:34:58 - SRCCONF=/dev/null TB --- 2012-04-10 23:34:58 - TARGET=sparc64 TB --- 2012-04-10 23:34:58 - TARGET_ARCH=sparc64 TB --- 2012-04-10 23:34:58 - TZ=UTC TB --- 2012-04-10 23:34:58 - __MAKE_CONF=/dev/null TB --- 2012-04-10 23:34:58 - cd /src TB --- 2012-04-10 23:34:58 - /usr/bin/make -B buildworld World build started on Tue Apr 10 23:34:59 UTC 2012 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 stage 4.3: make dependencies stage 4.4: building everything World build completed on Wed Apr 11 00:35:18 UTC 2012 TB --- 2012-04-11 00:35:18 - generating LINT kernel config TB --- 2012-04-11 00:35:18 - cd /src/sys/sparc64/conf TB --- 2012-04-11 00:35:18 - /usr/bin/make -B LINT TB --- 2012-04-11 00:35:18 - cd /src/sys/sparc64/conf TB --- 2012-04-11 00:35:18 - /usr/sbin/config -m LINT TB --- 2012-04-11 00:35:18 - building LINT kernel TB --- 2012-04-11 00:35:18 - CROSS_BUILD_TESTING=YES TB --- 2012-04-11 00:35:18 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-11 00:35:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-11 00:35:18 - SRCCONF=/dev/null TB --- 2012-04-11 00:35:18 - TARGET=sparc64 TB --- 2012-04-11 00:35:18 - TARGET_ARCH=sparc64 TB --- 2012-04-11 00:35:18 - TZ=UTC TB --- 2012-04-11 00:35:18 - __MAKE_CONF=/dev/null TB --- 2012-04-11 00:35:18 - cd /src TB --- 2012-04-11 00:35:18 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Wed Apr 11 00:35:18 UTC 2012 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-serverworks.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-siliconimage.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-sis.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param
[head tinderbox] failure on powerpc/powerpc
TB --- 2012-04-10 22:29:05 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-04-10 22:29:05 - 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 --- 2012-04-10 22:29:05 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2012-04-10 22:29:05 - cleaning the object tree TB --- 2012-04-10 22:29:05 - cvsupping the source tree TB --- 2012-04-10 22:29:05 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2012-04-10 22:30:16 - building world TB --- 2012-04-10 22:30:16 - CROSS_BUILD_TESTING=YES TB --- 2012-04-10 22:30:16 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-10 22:30:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-10 22:30:16 - SRCCONF=/dev/null TB --- 2012-04-10 22:30:16 - TARGET=powerpc TB --- 2012-04-10 22:30:16 - TARGET_ARCH=powerpc TB --- 2012-04-10 22:30:16 - TZ=UTC TB --- 2012-04-10 22:30:16 - __MAKE_CONF=/dev/null TB --- 2012-04-10 22:30:16 - cd /src TB --- 2012-04-10 22:30:16 - /usr/bin/make -B buildworld World build started on Tue Apr 10 22:30:17 UTC 2012 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 stage 4.3: make dependencies stage 4.4: building everything World build completed on Wed Apr 11 00:36:31 UTC 2012 TB --- 2012-04-11 00:36:31 - generating LINT kernel config TB --- 2012-04-11 00:36:31 - cd /src/sys/powerpc/conf TB --- 2012-04-11 00:36:31 - /usr/bin/make -B LINT TB --- 2012-04-11 00:36:31 - cd /src/sys/powerpc/conf TB --- 2012-04-11 00:36:31 - /usr/sbin/config -m LINT TB --- 2012-04-11 00:36:31 - building LINT kernel TB --- 2012-04-11 00:36:31 - CROSS_BUILD_TESTING=YES TB --- 2012-04-11 00:36:31 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-11 00:36:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-11 00:36:31 - SRCCONF=/dev/null TB --- 2012-04-11 00:36:31 - TARGET=powerpc TB --- 2012-04-11 00:36:31 - TARGET_ARCH=powerpc TB --- 2012-04-11 00:36:31 - TZ=UTC TB --- 2012-04-11 00:36:31 - __MAKE_CONF=/dev/null TB --- 2012-04-11 00:36:31 - cd /src TB --- 2012-04-11 00:36:31 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Wed Apr 11 00:36:32 UTC 2012 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-serverworks.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-siliconimage.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-sis.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL
[head tinderbox] failure on powerpc64/powerpc
TB --- 2012-04-10 22:40:57 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-04-10 22:40:57 - 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 --- 2012-04-10 22:40:57 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2012-04-10 22:40:57 - cleaning the object tree TB --- 2012-04-10 22:40:57 - cvsupping the source tree TB --- 2012-04-10 22:40:57 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2012-04-10 22:41:49 - building world TB --- 2012-04-10 22:41:49 - CROSS_BUILD_TESTING=YES TB --- 2012-04-10 22:41:49 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-10 22:41:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-10 22:41:49 - SRCCONF=/dev/null TB --- 2012-04-10 22:41:49 - TARGET=powerpc TB --- 2012-04-10 22:41:49 - TARGET_ARCH=powerpc64 TB --- 2012-04-10 22:41:49 - TZ=UTC TB --- 2012-04-10 22:41:49 - __MAKE_CONF=/dev/null TB --- 2012-04-10 22:41:49 - cd /src TB --- 2012-04-10 22:41:49 - /usr/bin/make -B buildworld World build started on Tue Apr 10 22:41:50 UTC 2012 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 stage 4.3: make dependencies stage 4.4: building everything stage 5.1: building 32 bit shim libraries World build completed on Wed Apr 11 01:14:42 UTC 2012 TB --- 2012-04-11 01:14:42 - generating LINT kernel config TB --- 2012-04-11 01:14:42 - cd /src/sys/powerpc/conf TB --- 2012-04-11 01:14:42 - /usr/bin/make -B LINT TB --- 2012-04-11 01:14:42 - cd /src/sys/powerpc/conf TB --- 2012-04-11 01:14:42 - /usr/sbin/config -m LINT TB --- 2012-04-11 01:14:42 - building LINT kernel TB --- 2012-04-11 01:14:42 - CROSS_BUILD_TESTING=YES TB --- 2012-04-11 01:14:42 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-11 01:14:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-11 01:14:42 - SRCCONF=/dev/null TB --- 2012-04-11 01:14:42 - TARGET=powerpc TB --- 2012-04-11 01:14:42 - TARGET_ARCH=powerpc64 TB --- 2012-04-11 01:14:42 - TZ=UTC TB --- 2012-04-11 01:14:42 - __MAKE_CONF=/dev/null TB --- 2012-04-11 01:14:42 - cd /src TB --- 2012-04-11 01:14:42 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Wed Apr 11 01:14:42 UTC 2012 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-serverworks.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-siliconimage.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-sis.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs
[head tinderbox] failure on arm/arm
TB --- 2012-04-11 01:20:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-04-11 01:20:00 - 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 --- 2012-04-11 01:20:00 - starting HEAD tinderbox run for arm/arm TB --- 2012-04-11 01:20:00 - cleaning the object tree TB --- 2012-04-11 01:20:00 - cvsupping the source tree TB --- 2012-04-11 01:20:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2012-04-11 01:22:17 - building world TB --- 2012-04-11 01:22:17 - CROSS_BUILD_TESTING=YES TB --- 2012-04-11 01:22:17 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-11 01:22:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-11 01:22:17 - SRCCONF=/dev/null TB --- 2012-04-11 01:22:17 - TARGET=arm TB --- 2012-04-11 01:22:17 - TARGET_ARCH=arm TB --- 2012-04-11 01:22:17 - TZ=UTC TB --- 2012-04-11 01:22:17 - __MAKE_CONF=/dev/null TB --- 2012-04-11 01:22:17 - cd /src TB --- 2012-04-11 01:22:17 - /usr/bin/make -B buildworld World build started on Wed Apr 11 01:22:18 UTC 2012 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 stage 4.3: make dependencies stage 4.4: building everything World build completed on Wed Apr 11 02:21:21 UTC 2012 TB --- 2012-04-11 02:21:21 - cd /src/sys/arm/conf TB --- 2012-04-11 02:21:21 - /usr/sbin/config -m AVILA TB --- 2012-04-11 02:21:22 - building AVILA kernel TB --- 2012-04-11 02:21:22 - CROSS_BUILD_TESTING=YES TB --- 2012-04-11 02:21:22 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-11 02:21:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-11 02:21:22 - SRCCONF=/dev/null TB --- 2012-04-11 02:21:22 - TARGET=arm TB --- 2012-04-11 02:21:22 - TARGET_ARCH=arm TB --- 2012-04-11 02:21:22 - TZ=UTC TB --- 2012-04-11 02:21:22 - __MAKE_CONF=/dev/null TB --- 2012-04-11 02:21:22 - cd /src TB --- 2012-04-11 02:21:22 - /usr/bin/make -B buildkernel KERNCONF=AVILA Kernel build for AVILA started on Wed Apr 11 02:21:22 UTC 2012 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -mbig-endian -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=xscale -ffreestanding -Werror /src/sys/dev/ata/chipsets/ata-siliconimage.c cc -mbig-endian -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=xscale -ffreestanding -Werror /src/sys/dev/ata/chipsets/ata-sis.c cc -mbig-endian -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=xscale -ffreestanding -Werror /src/sys/dev/ata/chipsets/ata-via.c cc -mbig-endian -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=xscale -ffreestanding -Werror /src/sys/dev/ath/if_ath_pci.c -I/src/sys/dev/ath cc -mbig-endian -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef
[head tinderbox] failure on i386/pc98
TB --- 2012-04-11 01:20:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-04-11 01:20:00 - 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 --- 2012-04-11 01:20:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2012-04-11 01:20:00 - cleaning the object tree TB --- 2012-04-11 01:20:00 - cvsupping the source tree TB --- 2012-04-11 01:20:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2012-04-11 01:26:13 - building world TB --- 2012-04-11 01:26:13 - CROSS_BUILD_TESTING=YES TB --- 2012-04-11 01:26:13 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-11 01:26:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-11 01:26:13 - SRCCONF=/dev/null TB --- 2012-04-11 01:26:13 - TARGET=pc98 TB --- 2012-04-11 01:26:13 - TARGET_ARCH=i386 TB --- 2012-04-11 01:26:13 - TZ=UTC TB --- 2012-04-11 01:26:13 - __MAKE_CONF=/dev/null TB --- 2012-04-11 01:26:13 - cd /src TB --- 2012-04-11 01:26:13 - /usr/bin/make -B buildworld World build started on Wed Apr 11 01:26:14 UTC 2012 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 stage 4.3: make dependencies stage 4.4: building everything World build completed on Wed Apr 11 03:43:54 UTC 2012 TB --- 2012-04-11 03:43:54 - generating LINT kernel config TB --- 2012-04-11 03:43:54 - cd /src/sys/pc98/conf TB --- 2012-04-11 03:43:54 - /usr/bin/make -B LINT TB --- 2012-04-11 03:43:54 - cd /src/sys/pc98/conf TB --- 2012-04-11 03:43:54 - /usr/sbin/config -m LINT TB --- 2012-04-11 03:43:54 - building LINT kernel TB --- 2012-04-11 03:43:54 - CROSS_BUILD_TESTING=YES TB --- 2012-04-11 03:43:54 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-11 03:43:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-11 03:43:54 - SRCCONF=/dev/null TB --- 2012-04-11 03:43:54 - TARGET=pc98 TB --- 2012-04-11 03:43:54 - TARGET_ARCH=i386 TB --- 2012-04-11 03:43:54 - TZ=UTC TB --- 2012-04-11 03:43:54 - __MAKE_CONF=/dev/null TB --- 2012-04-11 03:43:54 - cd /src TB --- 2012-04-11 03:43:54 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Wed Apr 11 03:43:54 UTC 2012 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/chipsets/ata-serverworks.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/chipsets/ata-siliconimage.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/chipsets/ata-sis.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes
[head tinderbox] failure on i386/i386
TB --- 2012-04-11 01:20:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-04-11 01:20:00 - 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 --- 2012-04-11 01:20:00 - starting HEAD tinderbox run for i386/i386 TB --- 2012-04-11 01:20:00 - cleaning the object tree TB --- 2012-04-11 01:20:00 - cvsupping the source tree TB --- 2012-04-11 01:20:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2012-04-11 01:22:05 - building world TB --- 2012-04-11 01:22:05 - CROSS_BUILD_TESTING=YES TB --- 2012-04-11 01:22:05 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-11 01:22:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-11 01:22:05 - SRCCONF=/dev/null TB --- 2012-04-11 01:22:05 - TARGET=i386 TB --- 2012-04-11 01:22:05 - TARGET_ARCH=i386 TB --- 2012-04-11 01:22:05 - TZ=UTC TB --- 2012-04-11 01:22:05 - __MAKE_CONF=/dev/null TB --- 2012-04-11 01:22:05 - cd /src TB --- 2012-04-11 01:22:05 - /usr/bin/make -B buildworld World build started on Wed Apr 11 01:22:07 UTC 2012 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 stage 4.3: make dependencies stage 4.4: building everything World build completed on Wed Apr 11 03:42:49 UTC 2012 TB --- 2012-04-11 03:42:49 - generating LINT kernel config TB --- 2012-04-11 03:42:49 - cd /src/sys/i386/conf TB --- 2012-04-11 03:42:49 - /usr/bin/make -B LINT TB --- 2012-04-11 03:42:49 - cd /src/sys/i386/conf TB --- 2012-04-11 03:42:49 - /usr/sbin/config -m LINT TB --- 2012-04-11 03:42:49 - building LINT kernel TB --- 2012-04-11 03:42:49 - CROSS_BUILD_TESTING=YES TB --- 2012-04-11 03:42:49 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-11 03:42:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-11 03:42:49 - SRCCONF=/dev/null TB --- 2012-04-11 03:42:49 - TARGET=i386 TB --- 2012-04-11 03:42:49 - TARGET_ARCH=i386 TB --- 2012-04-11 03:42:49 - TZ=UTC TB --- 2012-04-11 03:42:49 - __MAKE_CONF=/dev/null TB --- 2012-04-11 03:42:49 - cd /src TB --- 2012-04-11 03:42:49 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Wed Apr 11 03:42:50 UTC 2012 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/chipsets/ata-serverworks.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/chipsets/ata-siliconimage.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/chipsets/ata-sis.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes
[head tinderbox] failure on ia64/ia64
TB --- 2012-04-11 02:21:59 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-04-11 02:21:59 - 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 --- 2012-04-11 02:21:59 - starting HEAD tinderbox run for ia64/ia64 TB --- 2012-04-11 02:21:59 - cleaning the object tree TB --- 2012-04-11 02:21:59 - cvsupping the source tree TB --- 2012-04-11 02:21:59 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2012-04-11 02:22:28 - building world TB --- 2012-04-11 02:22:28 - CROSS_BUILD_TESTING=YES TB --- 2012-04-11 02:22:28 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-11 02:22:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-11 02:22:28 - SRCCONF=/dev/null TB --- 2012-04-11 02:22:28 - TARGET=ia64 TB --- 2012-04-11 02:22:28 - TARGET_ARCH=ia64 TB --- 2012-04-11 02:22:28 - TZ=UTC TB --- 2012-04-11 02:22:28 - __MAKE_CONF=/dev/null TB --- 2012-04-11 02:22:28 - cd /src TB --- 2012-04-11 02:22:28 - /usr/bin/make -B buildworld World build started on Wed Apr 11 02:22:29 UTC 2012 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 stage 4.3: make dependencies stage 4.4: building everything World build completed on Wed Apr 11 04:02:03 UTC 2012 TB --- 2012-04-11 04:02:03 - generating LINT kernel config TB --- 2012-04-11 04:02:03 - cd /src/sys/ia64/conf TB --- 2012-04-11 04:02:03 - /usr/bin/make -B LINT TB --- 2012-04-11 04:02:03 - cd /src/sys/ia64/conf TB --- 2012-04-11 04:02:03 - /usr/sbin/config -m LINT TB --- 2012-04-11 04:02:03 - building LINT kernel TB --- 2012-04-11 04:02:03 - CROSS_BUILD_TESTING=YES TB --- 2012-04-11 04:02:03 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-11 04:02:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-11 04:02:03 - SRCCONF=/dev/null TB --- 2012-04-11 04:02:03 - TARGET=ia64 TB --- 2012-04-11 04:02:03 - TARGET_ARCH=ia64 TB --- 2012-04-11 04:02:03 - TZ=UTC TB --- 2012-04-11 04:02:03 - __MAKE_CONF=/dev/null TB --- 2012-04-11 04:02:03 - cd /src TB --- 2012-04-11 04:02:03 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Wed Apr 11 04:02:03 UTC 2012 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ata/chipsets/ata-serverworks.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ata/chipsets/ata-siliconimage.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ata/chipsets/ata-sis.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL
Re: strange ping response times...
On Wed, Apr 11, 2012 at 12:52:57AM +0200, Luigi Rizzo wrote: I noticed this first on a 10G interface, but now there seems to be a similar issue on the loopback. Apparently a ping -f has a much lower RTT than one with non-zero delay between transmissions. Part of the story could be that the flood version invokes a non-blocking select. On the other hand, pinging on the loopback should make the response available right away, so what could be the reason for the additional 3..10us in the ping response time ? The following are numbers on an i7-2600k at 3400 MHz + turboboost, running stable/9 amd64. Note how the min ping time significantly increases moving from flood to 10ms to 1s. On an Intel 10G interface i am seeing a min of 14-16us with Sorry but I am having trouble wrapping my head around this as the results below are only for the loopback address 127.0.0.1 that does not travel on the wire at all ? Did you assign this to the 10ge interface ? if so which result is which. ? In order to get any good results on my machine I had to tune the following. net.inet.icmp.reply_from_interface=1 net.inet.icmp.icmplim_output=0 net.inet.icmp.icmplim=0 net.inet.icmp.log_redirect=1 You may have other options if this is greater than stable/8 @ 234095 But yes the results seem skewed to some extent and being loopback I would think there should be a very near zero rx/tx time. a ping flood, and up to 33-35us with the standard 1s interval (using -q probably trims another 2..5us) sudo ping -c 1000 -q -f 127.0.0.1 round-trip min/avg/max/stddev = 0.002/0.003/0.012/0.001 ms sudo ping -c 1000 -q -f 127.0.0.1 round-trip min/avg/max/stddev = 0.002/0.002/0.013/0.001 ms sudo ping -c 1000 -q -f 127.0.0.1 round-trip min/avg/max/stddev = 0.002/0.002/0.013/0.001 ms sudo ping -c 1 -q -f 127.0.0.1 round-trip min/avg/max/stddev = 0.002/0.002/0.011/0.001 ms sudo ping -c 1000 -q -i 0.01 127.0.0.1 round-trip min/avg/max/stddev = 0.005/0.012/0.017/0.001 ms sudo ping -c 1000 -q -i 0.01 127.0.0.1 round-trip min/avg/max/stddev = 0.004/0.012/0.016/0.001 ms sudo ping -c 200 -q -i 0.01 127.0.0.1 round-trip min/avg/max/stddev = 0.007/0.012/0.017/0.002 ms sudo ping -c 200 -q -i 0.01 127.0.0.1 round-trip min/avg/max/stddev = 0.005/0.012/0.018/0.002 ms sudo ping -c 200 -q -i 0.01 127.0.0.1 round-trip min/avg/max/stddev = 0.009/0.012/0.020/0.002 ms sudo ping -c 200 -q -i 0.01 127.0.0.1 round-trip min/avg/max/stddev = 0.006/0.012/0.016/0.001 ms sudo ping -c 200 -q -i 0.1 127.0.0.1 round-trip min/avg/max/stddev = 0.007/0.014/0.020/0.001 ms sudo ping -c 200 -q -i 0.1 127.0.0.1 round-trip min/avg/max/stddev = 0.006/0.014/0.019/0.002 ms sudo ping -c 200 -q -i 0.1 127.0.0.1 round-trip min/avg/max/stddev = 0.007/0.014/0.021/0.001 ms sudo ping -c 200 -q -i 0.1 127.0.0.1 round-trip min/avg/max/stddev = 0.007/0.014/0.020/0.001 ms sudo ping -c 200 -q -i 0.1 127.0.0.1 round-trip min/avg/max/stddev = 0.006/0.014/0.021/0.002 ms sudo ping -c 200 -q -i 0.1 127.0.0.1 round-trip min/avg/max/stddev = 0.010/0.014/0.022/0.001 ms sudo ping -c 20 -q -i 1 127.0.0.1 round-trip min/avg/max/stddev = 0.013/0.018/0.022/0.002 ms sudo ping -c 20 -q -i 1 127.0.0.1 round-trip min/avg/max/stddev = 0.012/0.018/0.021/0.002 ms sudo ping -c 20 -q -i 1 127.0.0.1 round-trip min/avg/max/stddev = 0.009/0.017/0.018/0.002 ms sudo ping -c 20 -q -i 1 127.0.0.1 round-trip min/avg/max/stddev = 0.011/0.017/0.021/0.002 ms sudo ping -c 20 -q -i 1 127.0.0.1 round-trip min/avg/max/stddev = 0.010/0.017/0.020/0.002 ms sudo ping -c 20 -q -i 1 127.0.0.1 round-trip min/avg/max/stddev = 0.009/0.017/0.028/0.004 ms cheers luigi ___ freebsd-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org -- ;s =; ___ 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 amd64/amd64
TB --- 2012-04-11 01:20:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-04-11 01:20:00 - 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 --- 2012-04-11 01:20:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2012-04-11 01:20:00 - cleaning the object tree TB --- 2012-04-11 01:20:00 - cvsupping the source tree TB --- 2012-04-11 01:20:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2012-04-11 01:22:17 - building world TB --- 2012-04-11 01:22:17 - CROSS_BUILD_TESTING=YES TB --- 2012-04-11 01:22:17 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-11 01:22:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-11 01:22:17 - SRCCONF=/dev/null TB --- 2012-04-11 01:22:17 - TARGET=amd64 TB --- 2012-04-11 01:22:17 - TARGET_ARCH=amd64 TB --- 2012-04-11 01:22:17 - TZ=UTC TB --- 2012-04-11 01:22:17 - __MAKE_CONF=/dev/null TB --- 2012-04-11 01:22:17 - cd /src TB --- 2012-04-11 01:22:17 - /usr/bin/make -B buildworld World build started on Wed Apr 11 01:22:18 UTC 2012 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 stage 4.3: make dependencies stage 4.4: building everything stage 5.1: building 32 bit shim libraries World build completed on Wed Apr 11 04:17:46 UTC 2012 TB --- 2012-04-11 04:17:46 - generating LINT kernel config TB --- 2012-04-11 04:17:46 - cd /src/sys/amd64/conf TB --- 2012-04-11 04:17:46 - /usr/bin/make -B LINT TB --- 2012-04-11 04:17:46 - cd /src/sys/amd64/conf TB --- 2012-04-11 04:17:46 - /usr/sbin/config -m LINT TB --- 2012-04-11 04:17:46 - building LINT kernel TB --- 2012-04-11 04:17:46 - CROSS_BUILD_TESTING=YES TB --- 2012-04-11 04:17:46 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-11 04:17:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-11 04:17:46 - SRCCONF=/dev/null TB --- 2012-04-11 04:17:46 - TARGET=amd64 TB --- 2012-04-11 04:17:46 - TARGET_ARCH=amd64 TB --- 2012-04-11 04:17:46 - TZ=UTC TB --- 2012-04-11 04:17:46 - __MAKE_CONF=/dev/null TB --- 2012-04-11 04:17:46 - cd /src TB --- 2012-04-11 04:17:46 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Wed Apr 11 04:17:46 UTC 2012 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/chipsets/ata-serverworks.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/chipsets/ata-siliconimage.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding
Re: Changes to sbin/init/init.c (r233944) makes x11/xdm impossible to start from /etc/ttys
On Tue, Apr 10, 2012 at 10:36:45PM +0200, Ed Schouten wrote: Hi Oliver, * O. Hartmann ohart...@mail.zedat.fu-berlin.de, 20120410 11:37: Reverting init.c back to its previous state seems to make the error go away. Sorry about that. I added the O_NONBLOCK to prevent init(8) from possibly getting stuck if the TTY used by /dev/console were to misbehave by not setting CLOCAL. It seems we can't do this reliably at all, so I guess I'd better just revert the code like so: http://80386.nl/pub/init.txt I'll commit the patch to SVN after I have discussed it wtih kib@. Thanks for reporting! Ok, lets discuss. I do not understand why this patch makes any change at all. Esp. for xdm that is supposedly run on some vty and not on console. pgpv8gohHuBWK.pgp Description: PGP signature
