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 at scbus3 target 0 lun 0 (ada0,pass0) at scbus4 target 0 lun 0 (ada1,pass1) 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 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" 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 b
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 | __ < - 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:
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 c
Re: [RFT][patch] Scheduling for HTT and not only
Hi, 2012/4/9 Alexander Motin : > [...] > > 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 Motin: [...] 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 Motin: [...] 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 wrote: > On 04/10/12 20:18, Alexander Motin wrote: >> >> On 04/10/12 19:58, Arnaud Lacombe wrote: >>> >>> 2012/4/9 Alexander Motin: [...] 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 d
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 Motin wrote: On 04/10/12 20:18, Alexander Motin wrote: On 04/10/12 19:58, Arnaud Lacombe wrote: 2012/4/9 Alexander Motin: 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 , 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 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 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 --pa
[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 -
[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 -
[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-prototy
[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 -
[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 -
[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/a
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 -m
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 , 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
Re: device_attach(9) and driver initialization
On Tue, Apr 10, 2012 at 02:47:37PM -0400, John Baldwin wrote:
> 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
>
