From owner-freebsd-current@FreeBSD.ORG Sun Apr 8 01:27:36 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D8481106566B; Sun, 8 Apr 2012 01:27:36 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id A80ED8FC12; Sun, 8 Apr 2012 01:27:36 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q381RZE6004694; Sat, 7 Apr 2012 21:27:35 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q381RZTX004689; Sun, 8 Apr 2012 01:27:35 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 8 Apr 2012 01:27:35 GMT Message-Id: <201204080127.q381RZTX004689@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2012 01:27:37 -0000 TB --- 2012-04-08 00:37:11 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-04-08 00:37:11 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-04-08 00:37:11 - starting HEAD tinderbox run for mips/mips TB --- 2012-04-08 00:37:12 - cleaning the object tree TB --- 2012-04-08 00:37:55 - cvsupping the source tree TB --- 2012-04-08 00:37:55 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2012-04-08 00:38:42 - building world TB --- 2012-04-08 00:38:42 - CROSS_BUILD_TESTING=YES TB --- 2012-04-08 00:38:42 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-08 00:38:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-08 00:38:42 - SRCCONF=/dev/null TB --- 2012-04-08 00:38:42 - TARGET=mips TB --- 2012-04-08 00:38:42 - TARGET_ARCH=mips TB --- 2012-04-08 00:38:42 - TZ=UTC TB --- 2012-04-08 00:38:42 - __MAKE_CONF=/dev/null TB --- 2012-04-08 00:38:42 - cd /src TB --- 2012-04-08 00:38:42 - /usr/bin/make -B buildworld >>> World build started on Sun Apr 8 00:38:42 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 [...] cc -O -pipe -G0 -I/src/kerberos5/libexec/kfd/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/libexec/kfd/../../../crypto/heimdal/lib/roken -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kfd/../../include -std=gnu99 -c /src/kerberos5/libexec/kfd/../../../crypto/heimdal/appl/kf/kfd.c cc -O -pipe -G0 -I/src/kerberos5/libexec/kfd/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/libexec/kfd/../../../crypto/heimdal/lib/roken -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kfd/../../include -std=gnu99 -o kfd kfd.o -lkrb5 -lroken -lasn1 -lcrypto -lcrypt /obj/mips.mips/src/kerberos5/libexec/kfd/../../lib/libvers/libvers.a gzip -cn /src/kerberos5/libexec/kfd/../../../crypto/heimdal/appl/kf/kfd.8 > kfd.8.gz ===> kerberos5/libexec/kimpersonate (all) cc -O -pipe -G0 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/hx509 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/roken -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/sl -I. -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kimpersonate/../../include -std=gnu99 -c /src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/kuser/kimpersonate.c cc -O -pipe -G0 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/hx509 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/roken -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/sl -I. -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kimpersonate/../../include -std=gnu99 -o kimpersonate kimpersonate.o -lkafs5 -lkrb5 -lheimntlm -lroken -lasn1 -lcrypto -lcrypt /obj/mips.mips/src/kerberos5/libexec/kimpersonate/../../lib/libvers/libvers.a /obj/mips.mips/src/tmp/usr/bin/ld: /obj/mips.mips/src/tmp/usr/lib/libkafs5.so symbol number 13 references nonexistent SHT_SYMTAB_SHNDX section /obj/mips.mips/src/tmp/usr/lib/libkafs5.so: could not read symbols: File format not recognized *** Error code 1 Stop in /src/kerberos5/libexec/kimpersonate. *** Error code 1 Stop in /src/kerberos5/libexec. *** Error code 1 Stop in /src/kerberos5. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-04-08 01:27:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-04-08 01:27:35 - ERROR: failed to build world TB --- 2012-04-08 01:27:35 - 2030.22 user 433.86 system 3023.74 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Sun Apr 8 03:08:55 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C9E3C106564A; Sun, 8 Apr 2012 03:08:55 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 720C58FC0A; Sun, 8 Apr 2012 03:08:55 +0000 (UTC) Received: from 63.imp.bsdimp.com (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id q3838eQS076876 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sat, 7 Apr 2012 21:08:41 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <1333810001.1082.36.camel@revolution.hippie.lan> Date: Sat, 7 Apr 2012 21:08:41 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <7C5089DC-AB9B-458F-A606-B432505BD961@bsdimp.com> References: <20120407125056.GS2358@deviant.kiev.zoral.com.ua> <1333810001.1082.36.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Sat, 07 Apr 2012 21:08:42 -0600 (MDT) Cc: Konstantin Belousov , current@FreeBSD.org, drivers@FreeBSD.org Subject: Re: device_attach(9) and driver initialization X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2012 03:08:55 -0000 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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 { >> }; >>=20 >> /** >> + * @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 =3D DS_ATTACHED; >> dev->flags &=3D ~DF_DONENOMATCH; >> devadded(dev); >> + DEVICE_AFTER_ATTACH(dev); >> return (0); >> } >>=20 >=20 > 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. Warner= From owner-freebsd-current@FreeBSD.ORG Sun Apr 8 03:14:43 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5AE18106564A; Sun, 8 Apr 2012 03:14:43 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id EB7AD8FC08; Sun, 8 Apr 2012 03:14:42 +0000 (UTC) Received: from 63.imp.bsdimp.com (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id q383D76o076900 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sat, 7 Apr 2012 21:13:07 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <4F80579B.4040205@freebsd.org> Date: Sat, 7 Apr 2012 21:13:06 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120407125056.GS2358@deviant.kiev.zoral.com.ua> <4F80579B.4040205@freebsd.org> To: Nathan Whitehorn X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Sat, 07 Apr 2012 21:13:07 -0600 (MDT) Cc: Konstantin Belousov , current@FreeBSD.org, drivers@FreeBSD.org Subject: Re: device_attach(9) and driver initialization X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2012 03:14:43 -0000 On Apr 7, 2012, at 9:04 AM, Nathan Whitehorn wrote: > On 04/07/12 07:50, 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. >>=20 >> 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. >>=20 >> 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. >>=20 >=20 > Something like this would also be very useful for drivers that need to = interact across the device tree, if newbus called it only after all = drivers have been attached. Drivers that need to see other potentially = attached drivers now need to do some hacks with SYSINIT. Would it be = possible to do this? I don't think it changes the functionality you = need. Well, there's a problem here. You never know that you've attached = everything, so you could never really call it. Many busses enumerate = asynchronously, so it may be hard to get the semantics that you desire = unless the two devices you want to coordinate are in the static part of = the tree. Warner From owner-freebsd-current@FreeBSD.ORG Sun Apr 8 03:14:48 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4877A1065670; Sun, 8 Apr 2012 03:14:48 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id E8C138FC0A; Sun, 8 Apr 2012 03:14:47 +0000 (UTC) Received: from 63.imp.bsdimp.com (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id q383At8n076884 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sat, 7 Apr 2012 21:10:56 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20120407145728.GV2358@deviant.kiev.zoral.com.ua> Date: Sat, 7 Apr 2012 21:10:55 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120407125056.GS2358@deviant.kiev.zoral.com.ua> <1333810001.1082.36.camel@revolution.hippie.lan> <20120407145728.GV2358@deviant.kiev.zoral.com.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Sat, 07 Apr 2012 21:10:56 -0600 (MDT) Cc: Ian Lepore , current@FreeBSD.org, drivers@FreeBSD.org Subject: Re: device_attach(9) and driver initialization X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2012 03:14:48 -0000 On Apr 7, 2012, at 8:57 AM, Konstantin Belousov wrote: > On Sat, Apr 07, 2012 at 08:46:41AM -0600, 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. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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 { >>> }; >>>=20 >>> /** >>> + * @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 =3D DS_ATTACHED; >>> dev->flags &=3D ~DF_DONENOMATCH; >>> devadded(dev); >>> + DEVICE_AFTER_ATTACH(dev); >>> return (0); >>> } >>>=20 >>=20 >> 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. > No, 'a mutex' does not solve anything. It only adds enourmous burden > on the driver developers, because you cannot sleep under mutex. = Changing > the mutex to the sleepable lock also does not byy you much, since > you need to somehow solve the issues with some cdevsw call waking up > thread sleeping into another cdevsw call, just for example. >=20 > Singlethreading a driver due to this race is just silly. >=20 > And, what do you mean by 'making it harder to MFC' ? How ? driver_attach() { ... softc->flags =3D 0; // redundant, since softc is initialized to = 0. softc->cdev =3D device_create...(); ... softc->flags |=3D READY; } driver_open(...) { if (!(softc->flags & READY)) return ENXIO; ... } What's the big burden here? Warner= From owner-freebsd-current@FreeBSD.ORG Sun Apr 8 03:22:33 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 50892106564A; Sun, 8 Apr 2012 03:22:33 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id F21F78FC0A; Sun, 8 Apr 2012 03:22:32 +0000 (UTC) Received: from 63.imp.bsdimp.com (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id q383F4PK076923 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sat, 7 Apr 2012 21:15:05 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <4F80B2FE.1030007@freebsd.org> Date: Sat, 7 Apr 2012 21:15:04 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <13B344FC-AD72-4CF5-AA7A-4C1BDE9F0A7D@bsdimp.com> References: <20120407125056.GS2358@deviant.kiev.zoral.com.ua> <4F80579B.4040205@freebsd.org> <20120407151514.GW2358@deviant.kiev.zoral.com.ua> <4F80B2FE.1030007@freebsd.org> To: Julian Elischer X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Sat, 07 Apr 2012 21:15:05 -0600 (MDT) Cc: Konstantin Belousov , current@FreeBSD.org, Nathan Whitehorn , drivers@FreeBSD.org Subject: Re: device_attach(9) and driver initialization X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2012 03:22:33 -0000 On Apr 7, 2012, at 3:34 PM, Julian Elischer wrote: > On 4/7/12 8:15 AM, Konstantin Belousov wrote: >> On Sat, Apr 07, 2012 at 10:04:59AM -0500, Nathan Whitehorn wrote: >>> On 04/07/12 07:50, 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. >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>>=20 >>> Something like this would also be very useful for drivers that need = to >>> interact across the device tree, if newbus called it only after all >>> drivers have been attached. Drivers that need to see other = potentially >>> attached drivers now need to do some hacks with SYSINIT. Would it be >>> possible to do this? I don't think it changes the functionality you = need. >> I am definitely fine with postponing a call further, but I am not = sure >> how to define that point and how to implement your proposal. I am = mostly >> thinking of the case of kld being loaded, since for compiled-in = drivers, >> there is simply no usermode to make the havoc during attach. >=20 > no, Geom starts tasting disk devices as as soon as you make the = device. Which is why the typical way to cope with this is to not create the = device until you are ready to service requests for it. The other method = is to have a flag that's only set after you actually are ready that the = open routine can check and keep people out of the rest of the devsw = functions by returning ENXIO or similar error. Warner >> For the boot time attachments, I am not sure when to declare the end. >> E.g. USB does asynchronous device discovery. >>=20 >> Could you prototype a change that would do what you propose ? >=20 > _______________________________________________ > freebsd-drivers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-drivers > To unsubscribe, send any mail to = "freebsd-drivers-unsubscribe@freebsd.org" >=20 >=20 From owner-freebsd-current@FreeBSD.ORG Sun Apr 8 03:58:55 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1821106564A; Sun, 8 Apr 2012 03:58:55 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 66EA48FC08; Sun, 8 Apr 2012 03:58:54 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q383wd2B099237; Sun, 8 Apr 2012 06:58:39 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q383wcZE092081; Sun, 8 Apr 2012 06:58:38 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q383wch2092080; Sun, 8 Apr 2012 06:58:38 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 8 Apr 2012 06:58:38 +0300 From: Konstantin Belousov To: Warner Losh Message-ID: <20120408035838.GY2358@deviant.kiev.zoral.com.ua> References: <20120407125056.GS2358@deviant.kiev.zoral.com.ua> <1333810001.1082.36.camel@revolution.hippie.lan> <20120407145728.GV2358@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6u7EtAStsNhw5cUf" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Ian Lepore , current@freebsd.org, drivers@freebsd.org Subject: Re: device_attach(9) and driver initialization X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2012 03:58:56 -0000 --6u7EtAStsNhw5cUf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Apr 07, 2012 at 09:10:55PM -0600, Warner Losh wrote: >=20 > On Apr 7, 2012, at 8:57 AM, Konstantin Belousov wrote: >=20 > > On Sat, Apr 07, 2012 at 08:46:41AM -0600, 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 ne= wbus. > >>> 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. > >>>=20 > >>> If /dev node is created inside device attach method, then usermode > >>> can start calling cdevsw methods before device fully initialized itse= lf. > >>> 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. > >>>=20 > >>> 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 be= low. > >>>=20 > >>> 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 { > >>> }; > >>>=20 > >>> /** > >>> + * @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 =3D DS_ATTACHED; > >>> dev->flags &=3D ~DF_DONENOMATCH; > >>> devadded(dev); > >>> + DEVICE_AFTER_ATTACH(dev); > >>> return (0); > >>> } > >>>=20 > >>=20 > >> 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 initializ= ed > >> 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 witho= ut > >> a driver api change that would make it harder to backport/MFC driver > >> changes. > > No, 'a mutex' does not solve anything. It only adds enourmous burden > > on the driver developers, because you cannot sleep under mutex. Changing > > the mutex to the sleepable lock also does not byy you much, since > > you need to somehow solve the issues with some cdevsw call waking up > > thread sleeping into another cdevsw call, just for example. > >=20 > > Singlethreading a driver due to this race is just silly. > >=20 > > And, what do you mean by 'making it harder to MFC' ? How ? >=20 > driver_attach() > { > ... > softc->flags =3D 0; // redundant, since softc is initialized to 0. > softc->cdev =3D device_create...(); > ... > softc->flags |=3D READY; > } >=20 > driver_open(...) > { > if (!(softc->flags & READY)) > return ENXIO; > ... > } >=20 > What's the big burden here? The burden is that your proposal does not work. As I described above, device_busy() calls from cdevsw method panic if open() is called before DS_ATTACHED is set by newbus. And, DS_ATTACHED is only set after device attach() method returned, so no workarounds from attach() could solve this. --6u7EtAStsNhw5cUf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk+BDO4ACgkQC3+MBN1Mb4hckQCgsGf27T3LtF0hlsguyfG8JpPu 1rUAnjvjSYfLZ6uFkgGSKYrXPSokZ3w8 =AgpQ -----END PGP SIGNATURE----- --6u7EtAStsNhw5cUf-- From owner-freebsd-current@FreeBSD.ORG Sun Apr 8 09:29:04 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AA8D3106566B; Sun, 8 Apr 2012 09:29:04 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 55B458FC0A; Sun, 8 Apr 2012 09:29:04 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q389T3Mb051236; Sun, 8 Apr 2012 05:29:03 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q389T3Tm051231; Sun, 8 Apr 2012 09:29:03 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 8 Apr 2012 09:29:03 GMT Message-Id: <201204080929.q389T3Tm051231@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2012 09:29:04 -0000 TB --- 2012-04-08 09:00:29 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-04-08 09:00:29 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-04-08 09:00:29 - starting HEAD tinderbox run for mips/mips TB --- 2012-04-08 09:00:29 - cleaning the object tree TB --- 2012-04-08 09:01:10 - cvsupping the source tree TB --- 2012-04-08 09:01:10 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2012-04-08 09:01:58 - building world TB --- 2012-04-08 09:01:58 - CROSS_BUILD_TESTING=YES TB --- 2012-04-08 09:01:58 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-08 09:01:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-08 09:01:58 - SRCCONF=/dev/null TB --- 2012-04-08 09:01:58 - TARGET=mips TB --- 2012-04-08 09:01:58 - TARGET_ARCH=mips TB --- 2012-04-08 09:01:58 - TZ=UTC TB --- 2012-04-08 09:01:58 - __MAKE_CONF=/dev/null TB --- 2012-04-08 09:01:58 - cd /src TB --- 2012-04-08 09:01:58 - /usr/bin/make -B buildworld >>> World build started on Sun Apr 8 09:01: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 [...] ranlib libvers.a ===> kerberos5/lib/libkdc (all) cc -O -pipe -G0 -I/src/kerberos5/lib/libkdc/../../../crypto/heimdal/lib/roken -I/src/kerberos5/lib/libkdc/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libkdc/../../../crypto/heimdal/lib/hdb -I/src/kerberos5/lib/libkdc/../../../crypto/heimdal/kdc -DHAVE_CONFIG_H -I/src/kerberos5/lib/libkdc/../../include -std=gnu99 -c /src/kerberos5/lib/libkdc/../../../crypto/heimdal/kdc/default_config.c -o default_config.o cc -O -pipe -G0 -I/src/kerberos5/lib/libkdc/../../../crypto/heimdal/lib/roken -I/src/kerberos5/lib/libkdc/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libkdc/../../../crypto/heimdal/lib/hdb -I/src/kerberos5/lib/libkdc/../../../crypto/heimdal/kdc -DHAVE_CONFIG_H -I/src/kerberos5/lib/libkdc/../../include -std=gnu99 -c /src/kerberos5/lib/libkdc/../../../crypto/heimdal/kdc/set_dbinfo.c -o set_dbinfo.o cc -O -pipe -G0 -I/src/kerberos5/lib/libkdc/../../../crypto/heimdal/lib/roken -I/src/kerberos5/lib/libkdc/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libkdc/../../../crypto/heimdal/lib/hdb -I/src/kerberos5/lib/libkdc/../../../crypto/heimdal/kdc -DHAVE_CONFIG_H -I/src/kerberos5/lib/libkdc/../../include -std=gnu99 -c /src/kerberos5/lib/libkdc/../../../crypto/heimdal/kdc/digest.c -o digest.o cc -O -pipe -G0 -I/src/kerberos5/lib/libkdc/../../../crypto/heimdal/lib/roken -I/src/kerberos5/lib/libkdc/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libkdc/../../../crypto/heimdal/lib/hdb -I/src/kerberos5/lib/libkdc/../../../crypto/heimdal/kdc -DHAVE_CONFIG_H -I/src/kerberos5/lib/libkdc/../../include -std=gnu99 -c /src/kerberos5/lib/libkdc/../../../crypto/heimdal/kdc/kerberos5.c -o kerberos5.o /src/kerberos5/lib/libkdc/../../../crypto/heimdal/kdc/kerberos5.c: In function '_kdc_as_rep': /src/kerberos5/lib/libkdc/../../../crypto/heimdal/kdc/kerberos5.c:1097: error: 'krb5_kdc_configuration' has no member named 'as_use_strongest_session_key' *** Error code 1 Stop in /src/kerberos5/lib/libkdc. *** Error code 1 Stop in /src/kerberos5/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-04-08 09:29:03 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-04-08 09:29:03 - ERROR: failed to build world TB --- 2012-04-08 09:29:03 - 1146.01 user 245.73 system 1714.02 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Sun Apr 8 10:02:43 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7ED0D106566C; Sun, 8 Apr 2012 10:02:43 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 2F4DA8FC0A; Sun, 8 Apr 2012 10:02:43 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q38A2geX050671; Sun, 8 Apr 2012 06:02:42 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q38A2gOk050666; Sun, 8 Apr 2012 10:02:42 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 8 Apr 2012 10:02:42 GMT Message-Id: <201204081002.q38A2gOk050666@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2012 10:02:43 -0000 TB --- 2012-04-08 09:29:03 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-04-08 09:29:03 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-04-08 09:29:03 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2012-04-08 09:29:03 - cleaning the object tree TB --- 2012-04-08 09:29:03 - cvsupping the source tree TB --- 2012-04-08 09:29:03 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2012-04-08 09:29:44 - building world TB --- 2012-04-08 09:29:44 - CROSS_BUILD_TESTING=YES TB --- 2012-04-08 09:29:44 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-08 09:29:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-08 09:29:44 - SRCCONF=/dev/null TB --- 2012-04-08 09:29:44 - TARGET=powerpc TB --- 2012-04-08 09:29:44 - TARGET_ARCH=powerpc TB --- 2012-04-08 09:29:44 - TZ=UTC TB --- 2012-04-08 09:29:44 - __MAKE_CONF=/dev/null TB --- 2012-04-08 09:29:44 - cd /src TB --- 2012-04-08 09:29:44 - /usr/bin/make -B buildworld >>> World build started on Sun Apr 8 09:29:45 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 [...] ranlib libvers.a ===> kerberos5/lib/libkdc (all) cc -O2 -pipe -I/src/kerberos5/lib/libkdc/../../../crypto/heimdal/lib/roken -I/src/kerberos5/lib/libkdc/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libkdc/../../../crypto/heimdal/lib/hdb -I/src/kerberos5/lib/libkdc/../../../crypto/heimdal/kdc -DHAVE_CONFIG_H -I/src/kerberos5/lib/libkdc/../../include -std=gnu99 -fstack-protector -c /src/kerberos5/lib/libkdc/../../../crypto/heimdal/kdc/default_config.c -o default_config.o cc -O2 -pipe -I/src/kerberos5/lib/libkdc/../../../crypto/heimdal/lib/roken -I/src/kerberos5/lib/libkdc/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libkdc/../../../crypto/heimdal/lib/hdb -I/src/kerberos5/lib/libkdc/../../../crypto/heimdal/kdc -DHAVE_CONFIG_H -I/src/kerberos5/lib/libkdc/../../include -std=gnu99 -fstack-protector -c /src/kerberos5/lib/libkdc/../../../crypto/heimdal/kdc/set_dbinfo.c -o set_dbinfo.o cc -O2 -pipe -I/src/kerberos5/lib/libkdc/../../../crypto/heimdal/lib/roken -I/src/kerberos5/lib/libkdc/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libkdc/../../../crypto/heimdal/lib/hdb -I/src/kerberos5/lib/libkdc/../../../crypto/heimdal/kdc -DHAVE_CONFIG_H -I/src/kerberos5/lib/libkdc/../../include -std=gnu99 -fstack-protector -c /src/kerberos5/lib/libkdc/../../../crypto/heimdal/kdc/digest.c -o digest.o cc -O2 -pipe -I/src/kerberos5/lib/libkdc/../../../crypto/heimdal/lib/roken -I/src/kerberos5/lib/libkdc/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libkdc/../../../crypto/heimdal/lib/hdb -I/src/kerberos5/lib/libkdc/../../../crypto/heimdal/kdc -DHAVE_CONFIG_H -I/src/kerberos5/lib/libkdc/../../include -std=gnu99 -fstack-protector -c /src/kerberos5/lib/libkdc/../../../crypto/heimdal/kdc/kerberos5.c -o kerberos5.o /src/kerberos5/lib/libkdc/../../../crypto/heimdal/kdc/kerberos5.c: In function '_kdc_as_rep': /src/kerberos5/lib/libkdc/../../../crypto/heimdal/kdc/kerberos5.c:1097: error: 'krb5_kdc_configuration' has no member named 'as_use_strongest_session_key' *** Error code 1 Stop in /src/kerberos5/lib/libkdc. *** Error code 1 Stop in /src/kerberos5/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-04-08 10:02:42 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-04-08 10:02:42 - ERROR: failed to build world TB --- 2012-04-08 10:02:42 - 1476.20 user 249.34 system 2019.05 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sun Apr 8 11:29:46 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1CA7C1065674 for ; Sun, 8 Apr 2012 11:29:46 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id C5BD98FC16 for ; Sun, 8 Apr 2012 11:29:45 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1SGqJU-0000eX-6X>; Sun, 08 Apr 2012 13:29:44 +0200 Received: from e178031053.adsl.alicedsl.de ([85.178.31.53] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1SGqJU-00028T-13>; Sun, 08 Apr 2012 13:29:44 +0200 Message-ID: <4F8176A0.807@zedat.fu-berlin.de> Date: Sun, 08 Apr 2012 13:29:36 +0200 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120314 Thunderbird/10.0.3 MIME-Version: 1.0 To: Current FreeBSD X-Enigmail-Version: 1.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6D6710BC26CDB38C71E99B97" X-Originating-IP: 85.178.31.53 Subject: xdm failing to start on FBSD 10.0 r2340030 erratically X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2012 11:29:46 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6D6710BC26CDB38C71E99B97 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable I loose hair ... Since yesterady's "make world" (last make world: the day before yesterday), getting FreeBSD 10.0-CURRENT/amd64 to r234000 or so, the X11 system on all of our FreeBSD 10.0-CUR/amd64 boxes start rejecting the start of xdm display manager. xdm is started from /etc/ttys on ttyv7. This worked before flawless. At this very moment, I do have X11 started via xdm - but this is a erratic and non-reproduceable process! This morning, I update world and kernel to r234030. I recompiled many ports via "portmaster -f xorg xdm", hoping the new kernel/world could affect the ports, but this isn't. Starting Xorg X11 server works fine. xdm fails. The log in /var/log/xdm.log looks like: 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, (=3D=3D) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (=3D=3D) Log file: "/var/log/Xorg.0.log", Time: Sat Apr 7 18:38:24 2012 (=3D=3D) 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 When running properly, this occurs: 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, (=3D=3D) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (=3D=3D) Log file: "/var/log/Xorg.0.log", Time: Sun Apr 8 13:10:41 2012 (=3D=3D) Using config file: "/etc/X11/xorg.conf" xdm info (pid 18378): sourcing /usr/local/etc/X11/xdm/Xsetup_0 xdm info (pid 18378): sourcing /usr/local/etc/X11/xdm/GiveConsole xdm info (pid 19848): executing session /usr/local/etc/X11/xdm/Xsession Content of XSetup_0 is #!/bin/sh #xconsole -geometry 480x130-0-0 -daemon -notify -verbose -fn fixed -exitOnFail xsetroot -solid black I feel a bit helpless around here since I can not get close to what is happening. The erratic behaviour of starting xdm is frightening. Starting xdm via /etc/ttys doesn't work at all, but sometimes, with a bit luck, xdm starts when started from the console. Regards, Oliver --------------enig6D6710BC26CDB38C71E99B97 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJPgXanAAoJEOgBcD7A/5N8nrIIALoh0GaAQ5HoMQulQr/lRDbG jNEvqLhAMxkbjse+1XJsDvErzDb/Tn54J8ssz57JjRI+OP8DZiruNWMBt2JAX94A umZCz2Vt5xVaItzuHkHCklKPEr1WiGjPEF9rnNKg6VfwVMbviVvmmr6Qg8lxkw00 IQVlBqoSn0uLm10mOYF6+QLTsKadILcV3gfZL9jNqDum56H9gkcXLocsHiVks75I i2SfTBGw/CL1JpYv23ghfz10xuMAaJqLpp3JHlCfBlfetkxWDYhPs4KK2VWWTH3a aYAyx61XGHwr7Yb2BM6vuB+PhHSpe5b/3iDy3Sln39qQIGSVJ0AL35CzsD13M00= =X5c/ -----END PGP SIGNATURE----- --------------enig6D6710BC26CDB38C71E99B97-- From owner-freebsd-current@FreeBSD.ORG Sun Apr 8 13:00:33 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 22F671065677; Sun, 8 Apr 2012 13:00:32 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id D73C48FC08; Sun, 8 Apr 2012 13:00:22 +0000 (UTC) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 9219A2842D; Sun, 8 Apr 2012 14:53:16 +0200 (CEST) Received: from [192.168.1.2] (static-84-242-120-26.net.upcbroadband.cz [84.242.120.26]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id B8A8028426; Sun, 8 Apr 2012 14:53:15 +0200 (CEST) Message-ID: <4F818A3B.5040904@quip.cz> Date: Sun, 08 Apr 2012 14:53:15 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.19) Gecko/20110420 Lightning/1.0b1 SeaMonkey/2.0.14 MIME-Version: 1.0 To: Nikolay Denev References: <4F7ED7F4.5060509@zedat.fu-berlin.de> <687BFFD7-1456-4D7B-AFB2-356EE9B0D1DD@gmail.com> In-Reply-To: <687BFFD7-1456-4D7B-AFB2-356EE9B0D1DD@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-performance@freebsd.org, Current FreeBSD , "O. Hartmann" Subject: Re: ECC memory driver in FreeBSD 10? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2012 13:00:33 -0000 Nikolay Denev wrote: > On Apr 6, 2012, at 2:48 PM, O. Hartmann wrote: > >> I'm looking for a way to force FreeBSD 10 to maintain/watch ECC errors >> reported by UEFI (or BIOS). >> Since ECC is said to be essential for server systems both in buisness >> and science and I do not question this, I was wondering if I can not >> report ECC errors via a watchdog or UEFI (ACPI?) report to syslog >> facility on FreeBSD. >> FreeBSD is supposed to be a server operating system, as far as I know, >> so I believe there must be something which didn't have revealed itself >> to me, yet. > > If the hardware supports it, such errors should be logged as MCEs (Machine Check Exceptions). > I can say for sure it works pretty well with Dell servers, as I had one with failing RAM module, and > it reported the corrected ECC errors in dmesg. Memory ECC errors are logged in to messages and you can decode it by sysutils/mcelog. I did it in the past on one of our Sun Fire X2100 M2 with FreeBSD 8.x. Miroslav Lachman From owner-freebsd-current@FreeBSD.ORG Sun Apr 8 13:11:29 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 66B4D106564A for ; Sun, 8 Apr 2012 13:11:29 +0000 (UTC) (envelope-from daichi@freebsd.org) Received: from natial.ongs.co.jp (natial.ongs.co.jp [202.216.246.90]) by mx1.freebsd.org (Postfix) with ESMTP id E8B288FC21 for ; Sun, 8 Apr 2012 13:11:28 +0000 (UTC) Received: from parancell.ongs.co.jp (dullmdaler.ongs.co.jp [202.216.246.94]) by natial.ongs.co.jp (Postfix) with ESMTPSA id F1B7912543B; Sun, 8 Apr 2012 22:11:27 +0900 (JST) Date: Sun, 8 Apr 2012 22:11:27 +0900 From: Daichi GOTO To: kwhite@site.uottawa.ca Message-Id: <20120408221127.969e8e71.daichi@freebsd.org> In-Reply-To: <55056.74.51.53.177.1333762589.squirrel@courriel.site.uottawa.ca> References: <55056.74.51.53.177.1333762589.squirrel@courriel.site.uottawa.ca> Organization: FreeBSD Project X-Mailer: Sylpheed 3.1.3 (GTK+ 2.24.6; amd64-portbld-freebsd9.9) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Sun__8_Apr_2012_22_11_27_+0900_vV9ywsz9B6r/cR=/" Cc: freebsd-current@freebsd.org Subject: Re: (unionfs) panic: excl->share with r230341 and above X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2012 13:11:29 -0000 This is a multi-part message in MIME format. --Multipart=_Sun__8_Apr_2012_22_11_27_+0900_vV9ywsz9B6r/cR=/ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi Please try an attached patch that improves handlings of fs locks. I think that this patch can resolve this issue. If that works well, I'm going to refine and commit it to head. On Fri, 6 Apr 2012 21:36:29 -0400 (EDT) kwhite@site.uottawa.ca wrote: > Starting with r230341, I get the following panic when trying to run > an executable on a unionfs filesystem: > > exclusive lock of (lockmgr) ufs @ > /usr/src/sys/modules/unionfs/../../fs/unionfs/union_vnops.c:1843 > while share locked from > /usr/src/sys/modules/unionfs/../../fs/unionfs/union_vnops.c:1843 > panic: excl->share > cpuid = 0 > KDB: enter: panic > > Narrowing down with a binary search: r230340 (no panic), r230341 (panic). > > How to repeat: > # uuname -a > FreeBSD 10.0-CURRENT FreeBSD 10.0-CURRENT #5 r233946M: Fri Apr 6 > 21:09:32 EDT 2012 kwhite@demo:/usr/src/obj/usr/src/sys/GENERIC > i386 > > # mkdir /tmp/local > # mount -t unionfs -o noatime /tmp/local /usr/local > # cp /bin/ls /usr/local/bin/ls > # /usr/local/bin/ls > .... > exclusive lock of (lockmgr) ufs @ > /usr/src/sys/modules/unionfs/../../fs/unionfs/union_vnops.c:1843 > while share locked from > /usr/src/sys/modules/unionfs/../../fs/unionfs/union_vnops.c:1843 > panic: excl->share > cpuid = 0 > KDB: enter: panic > [ thread pid 68 tid 100054 ] > Stopped at kdb_enter+0x3b: movl $0,kdb_why > db> show all locks > Process 68 (ls) thread 0xc5780000 (100054) > exclusive sleep mutex vnode interlock (vnode interlock) r = 0 > (0xc57cec28) locked @ > /usr/src/sys/modules/unionfs/../../fs/unionfs/union_vnops.c:1835 > shared lockmgr ufs (ufs) r = 0 (0xc57cec08) locked @ > /usr/src/sys/modules/unionfs/../../fs/unionfs/union_vnops.c:1843 > db> > > Workaround? > After reverting the change from LK_EXCLUSIVE to LK_SHARED > in sys/kern/kern_exec.c, executables on union filesystems no > longer cause a panic. > > ...keith > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- Daichi GOTO (daichi) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve --Multipart=_Sun__8_Apr_2012_22_11_27_+0900_vV9ywsz9B6r/cR=/ Content-Type: text/x-diff; name="unionfs_patch.diff" Content-Disposition: attachment; filename="unionfs_patch.diff" Content-Transfer-Encoding: 7bit diff -urBN /usr/src.orig/sys/fs/unionfs/union_subr.c /usr/src/sys/fs/unionfs/union_subr.c --- /usr/src.orig/sys/fs/unionfs/union_subr.c 2012-04-08 12:31:30.000000000 +0900 +++ /usr/src/sys/fs/unionfs/union_subr.c 2012-04-08 12:43:04.000000000 +0900 @@ -350,19 +350,22 @@ uvp = unp->un_uppervp; dvp = unp->un_dvp; unp->un_lowervp = unp->un_uppervp = NULLVP; - vp->v_vnlock = &(vp->v_lock); vp->v_data = NULL; - lockmgr(vp->v_vnlock, LK_EXCLUSIVE | LK_INTERLOCK, VI_MTX(vp)); + vp->v_object = NULL; + VI_UNLOCK(vp); + if (lvp != NULLVP) - VOP_UNLOCK(lvp, 0); + VOP_UNLOCK(lvp, LK_RELEASE); if (uvp != NULLVP) - VOP_UNLOCK(uvp, 0); - vp->v_object = NULL; + VOP_UNLOCK(uvp, LK_RELEASE); if (dvp != NULLVP && unp->un_hash.le_prev != NULL) unionfs_rem_cached_vnode(unp, dvp); + if (lockmgr(vp->v_vnlock, LK_EXCLUSIVE, VI_MTX(vp)) != 0) + panic("the lock for deletion is unacquirable."); + if (lvp != NULLVP) { vfslocked = VFS_LOCK_GIANT(lvp->v_mount); vrele(lvp); @@ -550,7 +553,7 @@ cn->cn_flags |= (cnp->cn_flags & SAVESTART); vref(dvp); - VOP_UNLOCK(dvp, 0); + VOP_UNLOCK(dvp, LK_RELEASE); if ((error = relookup(dvp, vpp, cn))) { uma_zfree(namei_zone, cn->cn_pnbuf); @@ -957,7 +957,7 @@ *vpp = vp; unionfs_vn_create_on_upper_free_out1: - VOP_UNLOCK(udvp, 0); + VOP_UNLOCK(udvp, LK_RELEASE); unionfs_vn_create_on_upper_free_out2: if (cn.cn_flags & HASBUF) { diff -urBN /usr/src.orig/sys/fs/unionfs/union_vfsops.c /usr/src/sys/fs/unionfs/union_vfsops.c --- /usr/src.orig/sys/fs/unionfs/union_vfsops.c 2012-04-08 12:31:30.000000000 +0900 +++ /usr/src/sys/fs/unionfs/union_vfsops.c 2012-04-08 12:43:04.000000000 +0900 @@ -165,7 +165,7 @@ uid = va.va_uid; gid = va.va_gid; } - VOP_UNLOCK(mp->mnt_vnodecovered, 0); + VOP_UNLOCK(mp->mnt_vnodecovered, LK_RELEASE); if (error) return (error); @@ -250,7 +250,7 @@ * Save reference */ if (below) { - VOP_UNLOCK(upperrootvp, 0); + VOP_UNLOCK(upperrootvp, LK_RELEASE); vn_lock(lowerrootvp, LK_EXCLUSIVE | LK_RETRY); ump->um_lowervp = upperrootvp; ump->um_uppervp = lowerrootvp; @@ -281,7 +281,7 @@ /* * Unlock the node */ - VOP_UNLOCK(ump->um_uppervp, 0); + VOP_UNLOCK(ump->um_uppervp, LK_RELEASE); /* * Get the unionfs root vnode. diff -urBN /usr/src.orig/sys/fs/unionfs/union_vnops.c /usr/src/sys/fs/unionfs/union_vnops.c --- /usr/src.orig/sys/fs/unionfs/union_vnops.c 2012-04-08 12:31:30.000000000 +0900 +++ /usr/src/sys/fs/unionfs/union_vnops.c 2012-04-08 12:43:04.000000000 +0900 @@ -75,21 +75,6 @@ KASSERT(((vp)->v_op == &unionfs_vnodeops), \ ("unionfs: it is not unionfs-vnode")) -/* lockmgr lock <-> reverse table */ -struct lk_lr_table { - int lock; - int revlock; -}; - -static struct lk_lr_table un_llt[] = { - {LK_SHARED, LK_RELEASE}, - {LK_EXCLUSIVE, LK_RELEASE}, - {LK_UPGRADE, LK_DOWNGRADE}, - {LK_DOWNGRADE, LK_UPGRADE}, - {0, 0} -}; - - static int unionfs_lookup(struct vop_cachedlookup_args *ap) { @@ -141,7 +126,7 @@ if (udvp != NULLVP) { dtmpvp = udvp; if (ldvp != NULLVP) - VOP_UNLOCK(ldvp, 0); + VOP_UNLOCK(ldvp, LK_RELEASE); } else dtmpvp = ldvp; @@ -149,7 +134,7 @@ error = VOP_LOOKUP(dtmpvp, &vp, cnp); if (dtmpvp == udvp && ldvp != NULLVP) { - VOP_UNLOCK(udvp, 0); + VOP_UNLOCK(udvp, LK_RELEASE); vn_lock(dvp, LK_EXCLUSIVE | LK_RETRY); } @@ -161,10 +146,10 @@ */ if (nameiop == DELETE || nameiop == RENAME || (cnp->cn_lkflags & LK_TYPE_MASK)) - VOP_UNLOCK(vp, 0); + VOP_UNLOCK(vp, LK_RELEASE); vrele(vp); - VOP_UNLOCK(dvp, 0); + VOP_UNLOCK(dvp, LK_RELEASE); *(ap->a_vpp) = dunp->un_dvp; vref(dunp->un_dvp); @@ -202,7 +187,7 @@ } if (nameiop == DELETE || nameiop == RENAME || (cnp->cn_lkflags & LK_TYPE_MASK)) - VOP_UNLOCK(uvp, 0); + VOP_UNLOCK(uvp, LK_RELEASE); } /* check whiteout */ @@ -246,7 +231,7 @@ return (lerror); } if (cnp->cn_lkflags & LK_TYPE_MASK) - VOP_UNLOCK(lvp, 0); + VOP_UNLOCK(lvp, LK_RELEASE); } } @@ -281,7 +266,7 @@ goto unionfs_lookup_out; if (LK_SHARED == (cnp->cn_lkflags & LK_TYPE_MASK)) - VOP_UNLOCK(vp, 0); + VOP_UNLOCK(vp, LK_RELEASE); if (LK_EXCLUSIVE != VOP_ISLOCKED(vp)) { vn_lock(vp, LK_EXCLUSIVE | LK_RETRY); lockflag = 1; @@ -289,7 +274,7 @@ error = unionfs_mkshadowdir(MOUNTTOUNIONFSMOUNT(dvp->v_mount), udvp, VTOUNIONFS(vp), cnp, td); if (lockflag != 0) - VOP_UNLOCK(vp, 0); + VOP_UNLOCK(vp, LK_RELEASE); if (error != 0) { UNIONFSDEBUG("unionfs_lookup: Unable to create shadow dir."); if ((cnp->cn_lkflags & LK_TYPE_MASK) == LK_EXCLUSIVE) @@ -386,7 +371,7 @@ if (vp->v_type == VSOCK) *(ap->a_vpp) = vp; else { - VOP_UNLOCK(vp, 0); + VOP_UNLOCK(vp, LK_RELEASE); error = unionfs_nodeget(ap->a_dvp->v_mount, vp, NULLVP, ap->a_dvp, ap->a_vpp, cnp, curthread); vrele(vp); @@ -460,7 +445,7 @@ if (vp->v_type == VSOCK) *(ap->a_vpp) = vp; else { - VOP_UNLOCK(vp, 0); + VOP_UNLOCK(vp, LK_RELEASE); error = unionfs_nodeget(ap->a_dvp->v_mount, vp, NULLVP, ap->a_dvp, ap->a_vpp, cnp, curthread); vrele(vp); @@ -619,7 +604,7 @@ unionfs_tryrem_node_status(unp, unsp); if (locked != 0) - VOP_UNLOCK(ap->a_vp, 0); + VOP_UNLOCK(ap->a_vp, LK_RELEASE); UNIONFS_INTERNAL_DEBUG("unionfs_close: leave (%d)\n", error); @@ -914,7 +899,7 @@ unionfs_get_node_status(unp, ap->a_td, &unsp); ovp = (unsp->uns_upper_opencnt ? unp->un_uppervp : unp->un_lowervp); unionfs_tryrem_node_status(unp, unsp); - VOP_UNLOCK(ap->a_vp, 0); + VOP_UNLOCK(ap->a_vp, LK_RELEASE); if (ovp == NULLVP) return (EBADF); @@ -941,7 +926,7 @@ unionfs_get_node_status(unp, ap->a_td, &unsp); ovp = (unsp->uns_upper_opencnt ? unp->un_uppervp : unp->un_lowervp); unionfs_tryrem_node_status(unp, unsp); - VOP_UNLOCK(ap->a_vp, 0); + VOP_UNLOCK(ap->a_vp, LK_RELEASE); if (ovp == NULLVP) return (EBADF); @@ -1001,7 +986,7 @@ ump = NULL; vp = uvp = lvp = NULLVP; /* search vnode */ - VOP_UNLOCK(ap->a_vp, 0); + VOP_UNLOCK(ap->a_vp, LK_RELEASE); error = unionfs_relookup(udvp, &vp, cnp, &cn, td, cnp->cn_nameptr, strlen(cnp->cn_nameptr), DELETE); if (error != 0 && error != ENOENT) { @@ -1204,7 +1189,7 @@ if ((error = vn_lock(fvp, LK_EXCLUSIVE)) != 0) goto unionfs_rename_abort; error = unionfs_copyfile(unp, 1, fcnp->cn_cred, td); - VOP_UNLOCK(fvp, 0); + VOP_UNLOCK(fvp, LK_RELEASE); if (error != 0) goto unionfs_rename_abort; break; @@ -1212,7 +1197,7 @@ if ((error = vn_lock(fvp, LK_EXCLUSIVE)) != 0) goto unionfs_rename_abort; error = unionfs_mkshadowdir(ump, rfdvp, unp, fcnp, td); - VOP_UNLOCK(fvp, 0); + VOP_UNLOCK(fvp, LK_RELEASE); if (error != 0) goto unionfs_rename_abort; break; @@ -1269,13 +1254,13 @@ if ((error = vn_lock(fdvp, LK_EXCLUSIVE)) != 0) goto unionfs_rename_abort; error = unionfs_relookup_for_delete(fdvp, fcnp, td); - VOP_UNLOCK(fdvp, 0); + VOP_UNLOCK(fdvp, LK_RELEASE); if (error != 0) goto unionfs_rename_abort; /* Locke of tvp is canceled in order to avoid recursive lock. */ if (tvp != NULLVP && tvp != tdvp) - VOP_UNLOCK(tvp, 0); + VOP_UNLOCK(tvp, LK_RELEASE); error = unionfs_relookup_for_rename(tdvp, tcnp, td); if (tvp != NULLVP && tvp != tdvp) vn_lock(tvp, LK_EXCLUSIVE | LK_RETRY); @@ -1293,11 +1278,11 @@ } if (ltdvp != NULLVP) - VOP_UNLOCK(ltdvp, 0); + VOP_UNLOCK(ltdvp, LK_RELEASE); if (tdvp != rtdvp) vrele(tdvp); if (ltvp != NULLVP) - VOP_UNLOCK(ltvp, 0); + VOP_UNLOCK(ltvp, LK_RELEASE); if (tvp != rtvp && tvp != NULLVP) { if (rtvp == NULLVP) vput(tvp); @@ -1371,7 +1356,7 @@ } if ((error = VOP_MKDIR(udvp, &uvp, cnp, ap->a_vap)) == 0) { - VOP_UNLOCK(uvp, 0); + VOP_UNLOCK(uvp, LK_RELEASE); cnp->cn_lkflags = LK_EXCLUSIVE; error = unionfs_nodeget(ap->a_dvp->v_mount, uvp, NULLVP, ap->a_dvp, ap->a_vpp, cnp, td); @@ -1467,7 +1452,7 @@ if (udvp != NULLVP) { error = VOP_SYMLINK(udvp, &uvp, cnp, ap->a_vap, ap->a_target); if (error == 0) { - VOP_UNLOCK(uvp, 0); + VOP_UNLOCK(uvp, LK_RELEASE); cnp->cn_lkflags = LK_EXCLUSIVE; error = unionfs_nodeget(ap->a_dvp->v_mount, uvp, NULLVP, ap->a_dvp, ap->a_vpp, cnp, td); @@ -1490,6 +1475,7 @@ struct unionfs_node *unp; struct unionfs_node_status *unsp; struct uio *uio; + struct vnode *vp; struct vnode *uvp; struct vnode *lvp; struct thread *td; @@ -1505,41 +1491,49 @@ error = 0; eofflag = 0; locked = 0; - unp = VTOUNIONFS(ap->a_vp); uio = ap->a_uio; - uvp = unp->un_uppervp; - lvp = unp->un_lowervp; + uvp = NULLVP; + lvp = NULLVP; td = uio->uio_td; ncookies_bk = 0; cookies_bk = NULL; - if (ap->a_vp->v_type != VDIR) + vp = ap->a_vp; + if (vp->v_type != VDIR) return (ENOTDIR); - /* check opaque */ - if (uvp != NULLVP && lvp != NULLVP) { - if ((error = VOP_GETATTR(uvp, &va, ap->a_cred)) != 0) - goto unionfs_readdir_exit; - if (va.va_flags & OPAQUE) - lvp = NULLVP; - } - /* check the open count. unionfs needs to open before readdir. */ - if (VOP_ISLOCKED(ap->a_vp) != LK_EXCLUSIVE) { - vn_lock(ap->a_vp, LK_UPGRADE | LK_RETRY); + if (VOP_ISLOCKED(vp) != LK_EXCLUSIVE) { + if (vn_lock(vp, LK_UPGRADE) != 0) + vn_lock(vp, LK_EXCLUSIVE | LK_RETRY); locked = 1; } - unionfs_get_node_status(unp, td, &unsp); - if ((uvp != NULLVP && unsp->uns_upper_opencnt <= 0) || - (lvp != NULLVP && unsp->uns_lower_opencnt <= 0)) { - unionfs_tryrem_node_status(unp, unsp); + unp = VTOUNIONFS(vp); + if (unp == NULL) error = EBADF; + else { + uvp = unp->un_uppervp; + lvp = unp->un_lowervp; + unionfs_get_node_status(unp, td, &unsp); + if ((uvp != NULLVP && unsp->uns_upper_opencnt <= 0) || + (lvp != NULLVP && unsp->uns_lower_opencnt <= 0)) { + unionfs_tryrem_node_status(unp, unsp); + error = EBADF; + } } - if (locked == 1) - vn_lock(ap->a_vp, LK_DOWNGRADE | LK_RETRY); + if (locked) + vn_lock(vp, LK_DOWNGRADE | LK_RETRY); if (error != 0) goto unionfs_readdir_exit; + /* check opaque */ + if (uvp != NULLVP && lvp != NULLVP) { + if ((error = VOP_GETATTR(uvp, &va, ap->a_cred)) != 0) + goto unionfs_readdir_exit; + if (va.va_flags & OPAQUE) + lvp = NULLVP; + } + /* upper only */ if (uvp != NULLVP && lvp == NULLVP) { error = VOP_READDIR(uvp, uio, ap->a_cred, ap->a_eofflag, @@ -1743,18 +1737,66 @@ } static int -unionfs_get_llt_revlock(int flags) +unionfs_islocked(struct vop_islocked_args *ap) { - int count; + struct unionfs_node *unp; - flags &= LK_TYPE_MASK; - for (count = 0; un_llt[count].lock != 0; count++) { - if (flags == un_llt[count].lock) { - return un_llt[count].revlock; - } + KASSERT_UNIONFS_VNODE(ap->a_vp); + + unp = VTOUNIONFS(ap->a_vp); + if (unp == NULL) + return (vop_stdislocked(ap)); + + if (unp->un_uppervp != NULLVP) + return (VOP_ISLOCKED(unp->un_uppervp)); + if (unp->un_lowervp != NULLVP) + return (VOP_ISLOCKED(unp->un_lowervp)); + return (vop_stdislocked(ap)); +} + +static int +unionfs_get_llt_revlock(struct vnode *vp, int flags) +{ + int revlock; + + revlock = 0; + + switch (flags & LK_TYPE_MASK) { + case LK_SHARED: + if (VOP_ISLOCKED(vp) == LK_EXCLUSIVE) + revlock = LK_UPGRADE; + else + revlock = LK_RELEASE; + break; + case LK_EXCLUSIVE: + case LK_UPGRADE: + revlock = LK_RELEASE; + break; + case LK_DOWNGRADE: + revlock = LK_UPGRADE; + break; + default: + break; } - return 0; + return (revlock); +} + +/* + * The state of an acquired lock is adjusted similarly to + * the time of error generating. + * flags: LK_RELEASE or LK_UPGRADE + */ +static void +unionfs_revlock(struct vnode *vp, int flags) +{ + if (flags & LK_RELEASE) + VOP_UNLOCK(vp, flags); + else { + /* UPGRADE */ + if (vn_lock(vp, flags) != 0) + vn_lock(vp, LK_EXCLUSIVE | LK_RETRY); + } } static int @@ -1763,6 +1805,7 @@ int error; int flags; int revlock; + int interlock; int uhold; struct mount *mp; struct unionfs_mount *ump; @@ -1774,15 +1817,13 @@ KASSERT_UNIONFS_VNODE(ap->a_vp); error = 0; + interlock = 1; uhold = 0; flags = ap->a_flags; vp = ap->a_vp; if (LK_RELEASE == (flags & LK_TYPE_MASK) || !(flags & LK_TYPE_MASK)) - return (VOP_UNLOCK(vp, flags)); - - if ((revlock = unionfs_get_llt_revlock(flags)) == 0) - panic("unknown lock type: 0x%x", flags & LK_TYPE_MASK); + return (VOP_UNLOCK(vp, flags | LK_RELEASE)); if ((flags & LK_INTERLOCK) == 0) VI_LOCK(vp); @@ -1798,6 +1839,9 @@ lvp = unp->un_lowervp; uvp = unp->un_uppervp; + if ((revlock = unionfs_get_llt_revlock(vp, flags)) == 0) + panic("unknown lock type: 0x%x", flags & LK_TYPE_MASK); + if ((mp->mnt_kern_flag & MNTK_MPSAFE) != 0 && (vp->v_iflag & VI_OWEINACT) != 0) flags |= LK_NOWAIT; @@ -1823,12 +1867,22 @@ VI_LOCK(vp); unp = VTOUNIONFS(vp); if (unp == NULL) { + /* vnode is released. */ VI_UNLOCK(vp); if (error == 0) - VOP_UNLOCK(lvp, 0); + VOP_UNLOCK(lvp, LK_RELEASE); vdrop(lvp); return (vop_stdlock(ap)); } + if (error != 0 && flags & LK_UPGRADE && uvp != NULLVP) { + /* if upgrade failed, the lock needs release. */ + VI_LOCK_FLAGS(uvp, MTX_DUPOK); + vholdl(uvp); + uhold = 1; + VI_UNLOCK(vp); + VOP_UNLOCK(uvp, LK_RELEASE | LK_INTERLOCK); + interlock = 0; + } } if (error == 0 && uvp != NULLVP) { @@ -1845,30 +1899,27 @@ VI_LOCK(vp); unp = VTOUNIONFS(vp); if (unp == NULL) { + /* vnode is released. */ VI_UNLOCK(vp); - if (error == 0) { - VOP_UNLOCK(uvp, 0); - if (lvp != NULLVP) - VOP_UNLOCK(lvp, 0); - } - if (lvp != NULLVP) - vdrop(lvp); + if (error == 0) + VOP_UNLOCK(uvp, LK_RELEASE); vdrop(uvp); + if (lvp != NULLVP) { + VOP_UNLOCK(lvp, LK_RELEASE); + vdrop(lvp); + } return (vop_stdlock(ap)); } - if (error != 0 && lvp != NULLVP) { + /* rollback */ VI_UNLOCK(vp); - if ((revlock & LK_TYPE_MASK) == LK_RELEASE) - VOP_UNLOCK(lvp, revlock); - else - vn_lock(lvp, revlock | LK_RETRY); - goto unionfs_lock_abort; + unionfs_revlock(lvp, revlock); + interlock = 0; } } - VI_UNLOCK(vp); -unionfs_lock_abort: + if (interlock) + VI_UNLOCK(vp); if (lvp != NULLVP) vdrop(lvp); if (uhold != 0) @@ -2013,7 +2064,7 @@ unionfs_tryrem_node_status(unp, unsp); } - VOP_UNLOCK(vp, 0); + VOP_UNLOCK(vp, LK_RELEASE); error = VOP_ADVLOCK(uvp, ap->a_id, ap->a_op, ap->a_fl, ap->a_flags); @@ -2022,7 +2073,7 @@ return error; unionfs_advlock_abort: - VOP_UNLOCK(vp, 0); + VOP_UNLOCK(vp, LK_RELEASE); UNIONFS_INTERNAL_DEBUG("unionfs_advlock: leave (%d)\n", error); @@ -2435,6 +2486,7 @@ .vop_getextattr = unionfs_getextattr, .vop_getwritemount = unionfs_getwritemount, .vop_inactive = unionfs_inactive, + .vop_islocked = unionfs_islocked, .vop_ioctl = unionfs_ioctl, .vop_link = unionfs_link, .vop_listextattr = unionfs_listextattr, --Multipart=_Sun__8_Apr_2012_22_11_27_+0900_vV9ywsz9B6r/cR=/-- From owner-freebsd-current@FreeBSD.ORG Sun Apr 8 15:29:22 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 605D31065672 for ; Sun, 8 Apr 2012 15:29:22 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id 2B9388FC0C for ; Sun, 8 Apr 2012 15:29:22 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.5/8.14.5) with ESMTP id q38FTGn1074009; Sun, 8 Apr 2012 08:29:16 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.5/8.14.5/Submit) id q38FTFBr074008; Sun, 8 Apr 2012 08:29:15 -0700 (PDT) (envelope-from david) Date: Sun, 8 Apr 2012 08:29:15 -0700 From: David Wolfskill To: "O. Hartmann" Message-ID: <20120408152915.GU1420@albert.catwhisker.org> References: <4F8176A0.807@zedat.fu-berlin.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2y/feSa6JmJqKeZ6" Content-Disposition: inline In-Reply-To: <4F8176A0.807@zedat.fu-berlin.de> User-Agent: Mutt/1.4.2.3i Cc: Current FreeBSD Subject: Re: xdm failing to start on FBSD 10.0 r2340030 erratically X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2012 15:29:22 -0000 --2y/feSa6JmJqKeZ6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 08, 2012 at 01:29:36PM +0200, O. Hartmann wrote: > I loose hair ... > Since yesterady's "make world" (last make world: the day before > yesterday), getting FreeBSD 10.0-CURRENT/amd64 to r234000 or so, the X11 > system on all of our FreeBSD 10.0-CUR/amd64 boxes start rejecting the > start of xdm display manager. xdm is started from /etc/ttys on ttyv7. > This worked before flawless. >=20 > At this very moment, I do have X11 started via xdm - but this is a > erratic and non-reproduceable process! >=20 > This morning, I update world and kernel to r234030. I recompiled many > ports via "portmaster -f xorg xdm", hoping the new kernel/world could > affect the ports, but this isn't. >=20 > Starting Xorg X11 server works fine. xdm fails. The log in > /var/log/xdm.log looks like: >=20 > Build Date: 07 April 2012 04:51:08PM > ... >=20 >=20 > I feel a bit helpless around here since I can not get close to what is > happening. The erratic behaviour of starting xdm is frightening. > Starting xdm via /etc/ttys doesn't work at all, but sometimes, with a > bit luck, xdm starts when started from the console. > .... I am not having trouble starting xdm via /etc/ttys; my environment is known to differ from yours in the following ways: * My ports (save for x11/nvidia-driver and misc/compat8x) are built under stable/8. (I track stable/8, stable/9, and head on a daily basis, and have a common /usr/local among them. I also update any installed ports that have updates available daily.) * I am running FreeBSD/i386, vs. FreeBSD/amd64. * My last 2 updates were r233994 (yesterday) and r234031 (today). * I have a mildly hacked-up startup script for xdm. I doubt this is an issue -- I've been doing this since 2006/03/05 19:04:03 (according to the RCS log), though I have modified the script a few times since its inception. But the point here is that I'm not directly invoking the xdm executable from /etc/ttys. * I don't know that this is different, but it may well be: my xorg.conf includes a stanza: Section "ServerFlags" Option "AutoAddDevices" "False" EndSection because my experiences with hald & dbus were so unpleasant. I don't use them; I don't even try to start them. Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --2y/feSa6JmJqKeZ6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk+BrsoACgkQmprOCmdXAD26jwCdEdq1qGQDbjLeXe9+1vA/YtFn HTQAnieBBtdh93aGLIUlt/tm1mnM+wnL =wLms -----END PGP SIGNATURE----- --2y/feSa6JmJqKeZ6-- From owner-freebsd-current@FreeBSD.ORG Sun Apr 8 21:41:59 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E158D106564A for ; Sun, 8 Apr 2012 21:41:58 +0000 (UTC) (envelope-from kp@sigsegv.be) Received: from mercury.codepro.be (mercury.codepro.be [IPv6:2001:4b98:dc0:51:216:3eff:feb7:3147]) by mx1.freebsd.org (Postfix) with ESMTP id 33A138FC08 for ; Sun, 8 Apr 2012 21:41:57 +0000 (UTC) Received: from adrastea.jupiter.sigsegv.be (adrastea.jupiter.sigsegv.be [IPv6:2001:6f8:1498:1::3]) by mercury.codepro.be (Postfix) with ESMTP id CAB48AD for ; Sun, 8 Apr 2012 23:41:55 +0200 (CEST) Received: from thebe.jupiter.sigsegv.be (thebe.jupiter.sigsegv.be [172.16.1.5]) by adrastea.jupiter.sigsegv.be (Postfix) with ESMTP id 2AA531754 for ; Sun, 8 Apr 2012 23:41:25 +0200 (CEST) Received: by thebe.jupiter.sigsegv.be (Postfix, from userid 1000) id D4F9B1C5DD; Sun, 8 Apr 2012 23:41:24 +0200 (CEST) Date: Sun, 8 Apr 2012 23:41:24 +0200 From: Kristof Provost To: current@freebsd.org Message-ID: <20120408214124.GA9622@thebe.jupiter.sigsegv.be> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-PGP-Fingerprint: E114 D9EA 909E D469 8F57 17A5 7D15 91C6 9EFA F286 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: OpenRD-CL support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2012 21:41:59 -0000 Hi, Based on the work from arm/156814 I've got a working config and device tree for the OpenRD-CL. It successfully boots over NFS, both network interfaces as well as the cesa (crypto accelerator) work. The patch: diff --git a/sys/arm/conf/OPENRD-CL b/sys/arm/conf/OPENRD-CL new file mode 100644 index 0000000..25707ed --- /dev/null +++ b/sys/arm/conf/OPENRD-CL @@ -0,0 +1,81 @@ +# +# Custom kernel for OpenRD Client/Ultimate devices. +# +# $FreeBSD$ +# + +ident OPENRD-CL +include "../mv/kirkwood/std.sheevaplug" + +options SOC_MV_KIRKWOOD +makeoptions MODULES_OVERRIDE="" + +makeoptions DEBUG=-g #Build kernel with gdb(1) debug symbols +makeoptions WERROR="-Werror" +makeoptions INVARIANTS + +options SCHED_4BSD #4BSD scheduler +options INET #InterNETworking +options INET6 #IPv6 communications protocols +options FFS #Berkeley Fast Filesystem +options NFSCL #New Network Filesystem Client +options NFSLOCKD #Network Lock Manager +options NFS_ROOT #NFS usable as /, requires NFSCL +options BOOTP +options BOOTP_NFSROOT +options BOOTP_NFSV3 +options BOOTP_WIRED_TO=mge0 + +# Root fs on USB device +#options ROOTDEVNAME=\"ufs:/dev/da0a\" + +options SYSVSHM #SYSV-style shared memory +options SYSVMSG #SYSV-style message queues +options SYSVSEM #SYSV-style semaphores +options _KPOSIX_PRIORITY_SCHEDULING #Posix P1003_1B real-time extensions +options MUTEX_NOINLINE +options RWLOCK_NOINLINE +options NO_FFS_SNAPSHOT +options NO_SWAPPING + +# Debugging +options ALT_BREAK_TO_DEBUGGER +options DDB +options KDB + +# Pseudo devices +device random +device pty +device loop + +# Serial ports +device uart + +# Networking +device ether +device mge # Marvell Gigabit Ethernet controller +device mii +device e1000phy +device bpf +options HZ=1000 +options DEVICE_POLLING +device vlan + +device cesa # Marvell security engine +device crypto +device cryptodev + +# USB +options USB_DEBUG # enable debug msgs +device usb +device ehci +device umass +device scbus +device pass +device da + +# Flattened Device Tree +options FDT +options FDT_DTB_STATIC +makeoptions FDT_DTS_FILE=openrd-cl.dts + diff --git a/sys/boot/fdt/dts/openrd-cl.dts b/sys/boot/fdt/dts/openrd-cl.dts new file mode 100644 index 0000000..6d11779 --- /dev/null +++ b/sys/boot/fdt/dts/openrd-cl.dts @@ -0,0 +1,340 @@ +/* + * Copyright (c) 2009-2010 The FreeBSD Foundation + * All rights reserved. + * + * This software was developed by Semihalf under sponsorship from + * the FreeBSD Foundation. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * OpenRD-Client/Ultimate Device Tree Source. + * + * $FreeBSD$ + */ + +/dts-v1/; + +/ { + model = "mrvl,OpenRD-CL"; + compatible = "OpenRD-CL"; + #address-cells = <1>; + #size-cells = <1>; + + aliases { + ethernet0 = &enet0; + ethernet1 = &enet1; + mpp = &MPP; + pci0 = &pci0; + serial0 = &serial0; + serial1 = &serial1; + soc = &SOC; + sram = &SRAM; + }; + + cpus { + #address-cells = <1>; + #size-cells = <0>; + + cpu@0 { + device_type = "cpu"; + compatible = "ARM,88FR131"; + reg = <0x0>; + d-cache-line-size = <32>; // 32 bytes + i-cache-line-size = <32>; // 32 bytes + d-cache-size = <0x4000>; // L1, 16K + i-cache-size = <0x4000>; // L1, 16K + timebase-frequency = <0>; + bus-frequency = <0>; + clock-frequency = <0>; + }; + }; + + memory { + device_type = "memory"; + reg = <0x0 0x20000000>; // 512M at 0x0 + }; + + localbus@f1000000 { + #address-cells = <2>; + #size-cells = <1>; + compatible = "mrvl,lbc"; + + /* This reflects CPU decode windows setup. */ + ranges = <0x0 0x0f 0xf9300000 0x00100000 + 0x1 0x1e 0xfa000000 0x00100000 + 0x2 0x1d 0xfa100000 0x02000000 + 0x3 0x1b 0xfc100000 0x00000400>; + + nor@0,0 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "cfi-flash"; + reg = <0x0 0x0 0x00100000>; + bank-width = <2>; + device-width = <1>; + }; + + led@1,0 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "led"; + reg = <0x1 0x0 0x00100000>; + }; + + nor@2,0 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "cfi-flash"; + reg = <0x2 0x0 0x02000000>; + bank-width = <2>; + device-width = <1>; + }; + + nand@3,0 { + #address-cells = <1>; + #size-cells = <1>; + reg = <0x3 0x0 0x00100000>; + bank-width = <2>; + device-width = <1>; + }; + }; + + SOC: soc88f6281@f1000000 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "simple-bus"; + ranges = <0x0 0xf1000000 0x00100000>; + bus-frequency = <0>; + + PIC: pic@20200 { + interrupt-controller; + #address-cells = <0>; + #interrupt-cells = <1>; + reg = <0x20200 0x3c>; + compatible = "mrvl,pic"; + }; + + timer@20300 { + compatible = "mrvl,timer"; + reg = <0x20300 0x30>; + interrupts = <1>; + interrupt-parent = <&PIC>; + mrvl,has-wdt; + }; + + MPP: mpp@10000 { + #pin-cells = <2>; + compatible = "mrvl,mpp"; + reg = <0x10000 0x34>; + pin-count = <50>; + pin-map = < + 0 1 /* MPP[0]: NF_IO[2] */ + 1 1 /* MPP[1]: NF_IO[3] */ + 2 1 /* MPP[2]: NF_IO[4] */ + 3 1 /* MPP[3]: NF_IO[5] */ + 4 1 /* MPP[4]: NF_IO[6] */ + 5 1 /* MPP[5]: NF_IO[7] */ + 6 1 /* MPP[6]: SYSRST_OUTn */ + 8 2 /* MPP[8]: UA0_RTS */ + 9 2 /* MPP[9]: UA0_CTS */ + 10 3 /* MPP[10]: UA0_TXD */ + 11 3 /* MPP[11]: UA0_RXD */ + 12 1 /* MPP[12]: SD_CLK */ + 13 1 /* MPP[13]: SD_CMD */ + 14 1 /* MPP[14]: SD_D[0] */ + 15 1 /* MPP[15]: SD_D[1] */ + 16 1 /* MPP[16]: SD_D[2] */ + 17 1 /* MPP[17]: SD_D[3] */ + 20 3 /* MPP[20]: GE1_CPU_RX0 */ + 21 3 /* MPP[21]: GE1_CPU_RX1 */ + 22 3 /* MPP[22]: GE1_CPU_RX2 */ + 23 3 /* MPP[23]: GE1_CPU_RX3 */ + 24 3 /* MPP[24]: GE1_CPU_TX0 */ + 25 3 /* MPP[25]: GE1_CPU_TX1 */ + 26 3 /* MPP[26]: GE1_CPU_TX2 */ + 27 3 /* MPP[27]: GE1_CPU_RD3 */ + 28 0 /* MPP[28]: GPIO */ + 29 0 /* MPP[29]: GPIO */ + 30 3 /* GE1_RXCTL */ + 31 3 /* GE1_RXCLK */ + 32 3 /* GE1_TXCLK */ + 33 3 /* GE1_TXCTL */ + 34 0 >; /* MPP[34]: GPIO */ + }; + + GPIO: gpio@10100 { + #gpio-cells = <3>; + compatible = "mrvl,gpio"; + reg = <0x10100 0x20>; + gpio-controller; + interrupts = <35 36 37 38 39 40 41>; + interrupt-parent = <&PIC>; + }; + + rtc@10300 { + compatible = "mrvl,rtc"; + reg = <0x10300 0x08>; + }; + + twsi@11000 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "mrvl,twsi"; + reg = <0x11000 0x20>; + interrupts = <43>; + interrupt-parent = <&PIC>; + }; + + enet0: ethernet@72000 { + #address-cells = <1>; + #size-cells = <1>; + model = "V2"; + compatible = "mrvl,ge"; + reg = <0x72000 0x2000>; + ranges = <0x0 0x72000 0x2000>; + local-mac-address = [ 00 00 00 00 00 00 ]; + interrupts = <12 13 14 11 46>; + interrupt-parent = <&PIC>; + phy-handle = <&phy0>; + + mdio@0 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "mrvl,mdio"; + + phy0: ethernet-phy@0 { + reg = <0x0>; + }; + phy1: ethernet-phy@1 { + reg = <0x1>; + }; + }; + }; + + enet1: ethernet@76000 { + #address-cells = <1>; + #size-cells = <1>; + model = "V2"; + compatible = "mrvl,ge"; + reg = <0x76000 0x2000>; + ranges = <0x0 0x76000 0x2000>; + local-mac-address = [ 00 00 00 00 00 00 ]; + interrupts = <16 17 18 15 47>; + interrupt-parent = <&PIC>; + phy-handle = <&phy1>; + }; + + serial0: serial@12000 { + compatible = "ns16550"; + reg = <0x12000 0x20>; + reg-shift = <2>; + clock-frequency = <0>; + interrupts = <33>; + interrupt-parent = <&PIC>; + }; + + serial1: serial@12100 { + compatible = "ns16550"; + reg = <0x12100 0x20>; + reg-shift = <2>; + clock-frequency = <0>; + interrupts = <34>; + interrupt-parent = <&PIC>; + }; + + crypto@30000 { + compatible = "mrvl,cesa"; + reg = <0x30000 0x10000>; + interrupts = <22>; + interrupt-parent = <&PIC>; + sram-handle = <&SRAM>; + }; + + usb@50000 { + compatible = "mrvl,usb-ehci", "usb-ehci"; + reg = <0x50000 0x1000>; + interrupts = <48 19>; + interrupt-parent = <&PIC>; + }; + + xor@60000 { + compatible = "mrvl,xor"; + reg = <0x60000 0x1000>; + interrupts = <5 6 7 8>; + interrupt-parent = <&PIC>; + }; + + sata@80000 { + compatible = "mrvl,sata"; + reg = <0x80000 0x6000>; + interrupts = <21>; + interrupt-parent = <&PIC>; + }; + }; + + SRAM: sram@fd000000 { + compatible = "mrvl,cesa-sram"; + reg = <0xfd000000 0x00100000>; + }; + + chosen { + stdin = "serial0"; + stdout = "serial0"; + }; + + pci0: pcie@f1040000 { + compatible = "mrvl,pcie"; + device_type = "pci"; + #interrupt-cells = <1>; + #size-cells = <2>; + #address-cells = <3>; + reg = <0xf1040000 0x2000>; + bus-range = <0 255>; + ranges = <0x02000000 0x0 0xf4000000 0xf4000000 0x0 0x04000000 + 0x01000000 0x0 0x00000000 0xf1100000 0x0 0x00100000>; + clock-frequency = <33333333>; + interrupt-parent = <&PIC>; + interrupts = <44>; + interrupt-map-mask = <0xf800 0x0 0x0 0x7>; + interrupt-map = < + /* IDSEL 0x1 */ + 0x0800 0x0 0x0 0x1 &PIC 0x9 + 0x0800 0x0 0x0 0x2 &PIC 0x9 + 0x0800 0x0 0x0 0x3 &PIC 0x9 + 0x0800 0x0 0x0 0x4 &PIC 0x9 + >; + pcie@0 { + reg = <0x0 0x0 0x0 0x0 0x0>; + #size-cells = <2>; + #address-cells = <3>; + device_type = "pci"; + ranges = <0x02000000 0x0 0xf4000000 + 0x02000000 0x0 0xf4000000 + 0x0 0x04040000 + + 0x01000000 0x0 0x0 + 0x01000000 0x0 0x0 + 0x0 0x00100000>; + }; + }; +}; + From owner-freebsd-current@FreeBSD.ORG Mon Apr 9 06:28:00 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D36B4106564A for ; Mon, 9 Apr 2012 06:28:00 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from mx.lissyara.su (mx.lissyara.su [91.227.18.11]) by mx1.freebsd.org (Postfix) with ESMTP id 873378FC08 for ; Mon, 9 Apr 2012 06:28:00 +0000 (UTC) Received: from [195.93.240.5] (port=9580 helo=lissyara.moskb.local) by mx.lissyara.su with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SH84u-000LHB-99 for current@freebsd.org; Mon, 09 Apr 2012 10:27:52 +0400 Message-ID: <4F828168.2030709@lissyara.su> Date: Mon, 09 Apr 2012 10:27:52 +0400 From: Alex Keda User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; ru-RU; rv:1.8.1.23) Gecko/20091202 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit X-White-List: YES X-Spam-Description: if spam count > 60 - this is spam X-Spam-Count: 0 X-Descriptions: powered by www.lissyara.su X-Bounce-ID: mx.lissyara.su Cc: Subject: r234000: i386 freeze when HT enabled X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 06:28:00 -0000 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 From owner-freebsd-current@FreeBSD.ORG Mon Apr 9 08:54:21 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0E2531065673 for ; Mon, 9 Apr 2012 08:54:21 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id B612A8FC17 for ; Mon, 9 Apr 2012 08:54:20 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1SHAMY-0007xu-By>; Mon, 09 Apr 2012 10:54:14 +0200 Received: from e178034252.adsl.alicedsl.de ([85.178.34.252] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1SHAMY-0002tg-6E>; Mon, 09 Apr 2012 10:54:14 +0200 Message-ID: <4F82A3AF.3050207@zedat.fu-berlin.de> Date: Mon, 09 Apr 2012 10:54:07 +0200 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120314 Thunderbird/10.0.3 MIME-Version: 1.0 To: David Wolfskill References: <4F8176A0.807@zedat.fu-berlin.de> <20120408152915.GU1420@albert.catwhisker.org> In-Reply-To: <20120408152915.GU1420@albert.catwhisker.org> X-Enigmail-Version: 1.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD4CE7B7E49B209A3FD9D4820" X-Originating-IP: 85.178.34.252 Cc: Current FreeBSD Subject: Re: xdm failing to start on FBSD 10.0 r2340030 erratically X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 08:54:21 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD4CE7B7E49B209A3FD9D4820 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Am 04/08/12 17:29, schrieb David Wolfskill: > On Sun, Apr 08, 2012 at 01:29:36PM +0200, O. Hartmann wrote: >> I loose hair ... >> Since yesterady's "make world" (last make world: the day before >> yesterday), getting FreeBSD 10.0-CURRENT/amd64 to r234000 or so, the X= 11 >> system on all of our FreeBSD 10.0-CUR/amd64 boxes start rejecting the >> start of xdm display manager. xdm is started from /etc/ttys on ttyv7. >> This worked before flawless. >> >> At this very moment, I do have X11 started via xdm - but this is a >> erratic and non-reproduceable process! >> >> This morning, I update world and kernel to r234030. I recompiled many >> ports via "portmaster -f xorg xdm", hoping the new kernel/world could >> affect the ports, but this isn't. >> >> Starting Xorg X11 server works fine. xdm fails. The log in >> /var/log/xdm.log looks like: >> >> Build Date: 07 April 2012 04:51:08PM >> ... >> >> >> I feel a bit helpless around here since I can not get close to what is= >> happening. The erratic behaviour of starting xdm is frightening. >> Starting xdm via /etc/ttys doesn't work at all, but sometimes, with a >> bit luck, xdm starts when started from the console. >> .... >=20 > I am not having trouble starting xdm via /etc/ttys; my environment is > known to differ from yours in the following ways: >=20 > * My ports (save for x11/nvidia-driver and misc/compat8x) are built > under stable/8. (I track stable/8, stable/9, and head on a daily > basis, and have a common /usr/local among them. I also update > any installed ports that have updates available daily.) >=20 > * I am running FreeBSD/i386, vs. FreeBSD/amd64. >=20 > * My last 2 updates were r233994 (yesterday) and r234031 (today). >=20 > * I have a mildly hacked-up startup script for xdm. I doubt this is an= > issue -- I've been doing this since 2006/03/05 19:04:03 (according to= > the RCS log), though I have modified the script a few times > since its inception. But the point here is that I'm not directly > invoking the xdm executable from /etc/ttys. When I start xdm via console, it starts up, but only with a "Xservers" file that contains nothing but comments. If there are the lines localhost 127.0.0.1 192.168.0.128 !* it will will probably start not. Since xdm does not show this behaviour in a reproducible manner I susepct a bug. >=20 > * I don't know that this is different, but it may well be: my xorg.con= f > includes a stanza: >=20 > Section "ServerFlags" > Option "AutoAddDevices" "False" > EndSection I should go with this and try. But as far as I know, since I have USB devices (mouse, keyboard), unpluggin and pluggin them is then, without hal and dbus, not recognized anymore, isn't it? There was a discussion once going one for this subject. Either way, at this very moment I do not know whether the OS or the X11 is faulty and I'd like to report this as a bug. >=20 > because my experiences with hald & dbus were so unpleasant. I don't > use them; I don't even try to start them. >=20 > Peace, > david Regards, Oliver --------------enigD4CE7B7E49B209A3FD9D4820 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJPgqO1AAoJEOgBcD7A/5N8/sUH/3v8yz+6fKMcTgHypPugRW3k 1DIHPANEXkrn8af10uZlNPxIr9PX95CBNZDDvQ7R8gfRcmu5nM5i+hZ9PbDv0Tp4 1jatoiEnV9UUDhrlSyzjpHNNiM2rti4uyXjxOiLzsUtd0Nz4966XBws90GUUj+0r 2AaIEC/jkf80V9dV3kz4ZghKJRv8IgP2WyaOpnNun9nr0ucL2N3m/mpz3dQcxdz7 IloAyOy10Jskq2hL3NSUIrv+c0/jVuvS6Xnzi0BAnpwTA4vrDxyjqCT1rECFmYcs KZZnwxYOH72CAZNnY46Q0/dkNWxkgqDBixPTGD8BNvqyrmkbQn72yVqOLeQ67QI= =9Twu -----END PGP SIGNATURE----- --------------enigD4CE7B7E49B209A3FD9D4820-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 9 09:32:42 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 20D351065674 for ; Mon, 9 Apr 2012 09:32:42 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirg.bris.ac.uk (dirg.bris.ac.uk [137.222.10.102]) by mx1.freebsd.org (Postfix) with ESMTP id C97898FC0A for ; Mon, 9 Apr 2012 09:32:41 +0000 (UTC) Received: from ncsd.bris.ac.uk ([137.222.10.59] helo=ncs.bris.ac.uk) by dirg.bris.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1SHAhR-000731-E0; Mon, 09 Apr 2012 10:15:57 +0100 Received: from mech-cluster241.men.bris.ac.uk ([137.222.187.241]) by ncs.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1SHAgm-0004nO-BD; Mon, 09 Apr 2012 10:15:08 +0100 Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.5/8.14.5) with ESMTP id q399F80J055856; Mon, 9 Apr 2012 10:15:08 +0100 (BST) (envelope-from mexas@bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.5/8.14.5/Submit) id q399F8OD055855; Mon, 9 Apr 2012 10:15:08 +0100 (BST) (envelope-from mexas@bris.ac.uk) X-Authentication-Warning: mech-cluster241.men.bris.ac.uk: mexas set sender to mexas@bris.ac.uk using -f Date: Mon, 9 Apr 2012 10:15:07 +0100 From: Anton Shterenlikht To: "O. Hartmann" Message-ID: <20120409091507.GA55822@mech-cluster241.men.bris.ac.uk> Mail-Followup-To: "O. Hartmann" , David Wolfskill , Current FreeBSD References: <4F8176A0.807@zedat.fu-berlin.de> <20120408152915.GU1420@albert.catwhisker.org> <4F82A3AF.3050207@zedat.fu-berlin.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F82A3AF.3050207@zedat.fu-berlin.de> User-Agent: Mutt/1.4.2.3i Cc: Current FreeBSD Subject: Re: xdm failing to start on FBSD 10.0 r2340030 erratically X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 09:32:42 -0000 On Mon, Apr 09, 2012 at 10:54:07AM +0200, O. Hartmann wrote: > Am 04/08/12 17:29, schrieb David Wolfskill: > > On Sun, Apr 08, 2012 at 01:29:36PM +0200, O. Hartmann wrote: > >> I loose hair ... > >> Since yesterady's "make world" (last make world: the day before > >> yesterday), getting FreeBSD 10.0-CURRENT/amd64 to r234000 or so, the X11 > >> system on all of our FreeBSD 10.0-CUR/amd64 boxes start rejecting the > >> start of xdm display manager. xdm is started from /etc/ttys on ttyv7. > >> This worked before flawless. > >> > >> At this very moment, I do have X11 started via xdm - but this is a > >> erratic and non-reproduceable process! > >> > >> This morning, I update world and kernel to r234030. I recompiled many > >> ports via "portmaster -f xorg xdm", hoping the new kernel/world could > >> affect the ports, but this isn't. > >> > >> Starting Xorg X11 server works fine. xdm fails. The log in > >> /var/log/xdm.log looks like: > >> > >> Build Date: 07 April 2012 04:51:08PM > >> ... > >> > >> > >> I feel a bit helpless around here since I can not get close to what is > >> happening. The erratic behaviour of starting xdm is frightening. > >> Starting xdm via /etc/ttys doesn't work at all, but sometimes, with a > >> bit luck, xdm starts when started from the console. > >> .... > > > > I am not having trouble starting xdm via /etc/ttys; my environment is > > known to differ from yours in the following ways: > > > > * My ports (save for x11/nvidia-driver and misc/compat8x) are built > > under stable/8. (I track stable/8, stable/9, and head on a daily > > basis, and have a common /usr/local among them. I also update > > any installed ports that have updates available daily.) > > > > * I am running FreeBSD/i386, vs. FreeBSD/amd64. > > > > * My last 2 updates were r233994 (yesterday) and r234031 (today). > > > > * I have a mildly hacked-up startup script for xdm. I doubt this is an > > issue -- I've been doing this since 2006/03/05 19:04:03 (according to > > the RCS log), though I have modified the script a few times > > since its inception. But the point here is that I'm not directly > > invoking the xdm executable from /etc/ttys. > > When I start xdm via console, it starts up, but only with a "Xservers" > file that contains nothing but comments. If there are the lines > > localhost > 127.0.0.1 > 192.168.0.128 > !* > > it will will probably start not. Since xdm does not show this behaviour > in a reproducible manner I susepct a bug. > > > > > * I don't know that this is different, but it may well be: my xorg.conf > > includes a stanza: > > > > Section "ServerFlags" > > Option "AutoAddDevices" "False" > > EndSection > > I should go with this and try. But as far as I know, since I have USB > devices (mouse, keyboard), unpluggin and pluggin them is then, without > hal and dbus, not recognized anymore, isn't it? > > There was a discussion once going one for this subject. > > > Either way, at this very moment I do not know whether the OS or the X11 > is faulty and I'd like to report this as a bug. > > > > > because my experiences with hald & dbus were so unpleasant. I don't > > use them; I don't even try to start them. > > > > Peace, > > david > > Regards, > Oliver > I see the same (or similar) behavior on r231158M amd64 Compaq 6715s laptop. I've: BUZI> pkg info xdm xdm-1.1.11: X.Org X display manager BUZI> Starting xdm from /etc/ttys: BUZI> grep bin/xdm /etc/ttys ttyv8 "/usr/local/bin/xdm -nodaemon" xterm on secure BUZI> causes the screen to flicker a few, maybe 3-5 times, between the graphical and the text console, and then I'm back to the text console. However, starting xdm manually seems to work fine every time. The log file is no help: BUZI> cat /var/log/xdm.log xdm error (pid 1464): Can't lock pid file /var/run/xdm.pid, another xdm is running (pid 939) BUZI> -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 From owner-freebsd-current@FreeBSD.ORG Mon Apr 9 09:59:57 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5BB4E106564A; Mon, 9 Apr 2012 09:59:57 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id F191A8FC08; Mon, 9 Apr 2012 09:59:56 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1SHBO8-0005z3-1i>; Mon, 09 Apr 2012 11:59:56 +0200 Received: from e178034252.adsl.alicedsl.de ([85.178.34.252] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1SHBO7-0005l4-R8>; Mon, 09 Apr 2012 11:59:56 +0200 Message-ID: <4F82B315.3010408@zedat.fu-berlin.de> Date: Mon, 09 Apr 2012 11:59:49 +0200 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120314 Thunderbird/10.0.3 MIME-Version: 1.0 To: David Wolfskill , Current FreeBSD , mexas@bristol.ac.uk, freebsd-x11@freebsd.org References: <4F8176A0.807@zedat.fu-berlin.de> <20120408152915.GU1420@albert.catwhisker.org> <4F82A3AF.3050207@zedat.fu-berlin.de> <20120409091507.GA55822@mech-cluster241.men.bris.ac.uk> In-Reply-To: <20120409091507.GA55822@mech-cluster241.men.bris.ac.uk> X-Enigmail-Version: 1.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8A4D187F5A5A320FB21A0A80" X-Originating-IP: 85.178.34.252 Cc: Subject: Re: xdm failing to start on FBSD 10.0 r2340030 erratically X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 09:59:57 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8A4D187F5A5A320FB21A0A80 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 04/09/12 11:15, schrieb Anton Shterenlikht: > On Mon, Apr 09, 2012 at 10:54:07AM +0200, O. Hartmann wrote: >> Am 04/08/12 17:29, schrieb David Wolfskill: >>> On Sun, Apr 08, 2012 at 01:29:36PM +0200, O. Hartmann wrote: >>>> I loose hair ... >>>> Since yesterady's "make world" (last make world: the day before >>>> yesterday), getting FreeBSD 10.0-CURRENT/amd64 to r234000 or so, the= X11 >>>> system on all of our FreeBSD 10.0-CUR/amd64 boxes start rejecting th= e >>>> start of xdm display manager. xdm is started from /etc/ttys on ttyv7= =2E >>>> This worked before flawless. >>>> >>>> At this very moment, I do have X11 started via xdm - but this is a >>>> erratic and non-reproduceable process! >>>> >>>> This morning, I update world and kernel to r234030. I recompiled man= y >>>> ports via "portmaster -f xorg xdm", hoping the new kernel/world coul= d >>>> affect the ports, but this isn't. >>>> >>>> Starting Xorg X11 server works fine. xdm fails. The log in >>>> /var/log/xdm.log looks like: >>>> >>>> Build Date: 07 April 2012 04:51:08PM >>>> ... >>>> >>>> >>>> I feel a bit helpless around here since I can not get close to what = is >>>> happening. The erratic behaviour of starting xdm is frightening. >>>> Starting xdm via /etc/ttys doesn't work at all, but sometimes, with = a >>>> bit luck, xdm starts when started from the console. >>>> .... >>> >>> I am not having trouble starting xdm via /etc/ttys; my environment is= >>> known to differ from yours in the following ways: >>> >>> * My ports (save for x11/nvidia-driver and misc/compat8x) are built >>> under stable/8. (I track stable/8, stable/9, and head on a daily >>> basis, and have a common /usr/local among them. I also update >>> any installed ports that have updates available daily.) >>> >>> * I am running FreeBSD/i386, vs. FreeBSD/amd64. >>> >>> * My last 2 updates were r233994 (yesterday) and r234031 (today). >>> >>> * I have a mildly hacked-up startup script for xdm. I doubt this is = an >>> issue -- I've been doing this since 2006/03/05 19:04:03 (according = to >>> the RCS log), though I have modified the script a few times >>> since its inception. But the point here is that I'm not directly >>> invoking the xdm executable from /etc/ttys. >> >> When I start xdm via console, it starts up, but only with a "Xservers"= >> file that contains nothing but comments. If there are the lines >> >> localhost >> 127.0.0.1 >> 192.168.0.128 >> !* >> >> it will will probably start not. Since xdm does not show this behaviou= r >> in a reproducible manner I susepct a bug. >> >>> >>> * I don't know that this is different, but it may well be: my xorg.c= onf >>> includes a stanza: >>> >>> Section "ServerFlags" >>> Option "AutoAddDevices" "False" >>> EndSection >> >> I should go with this and try. But as far as I know, since I have USB >> devices (mouse, keyboard), unpluggin and pluggin them is then, without= >> hal and dbus, not recognized anymore, isn't it? >> >> There was a discussion once going one for this subject. >> >> >> Either way, at this very moment I do not know whether the OS or the X1= 1 >> is faulty and I'd like to report this as a bug. >> >>> >>> because my experiences with hald & dbus were so unpleasant. I don'= t >>> use them; I don't even try to start them. >>> >>> Peace, >>> david >> >> Regards, >> Oliver >> >=20 > I see the same (or similar) behavior on r231158M amd64 > Compaq 6715s laptop. >=20 > I've: >=20 > BUZI> pkg info xdm > xdm-1.1.11: X.Org X display manager > BUZI>=20 pkohartmann@thor: [~] g_info |grep xdm xdm-1.1.11 X.Org X display manager >=20 > Starting xdm from /etc/ttys: >=20 > BUZI> grep bin/xdm /etc/ttys > ttyv8 "/usr/local/bin/xdm -nodaemon" xterm on secure > BUZI> ohartmann@thor: [~] grep bin/xdm /etc/ttys ttyv7 "/usr/local/bin/xdm -nodaemon" xterm on insecure >=20 > causes the screen to flicker a few, maybe 3-5 times, > between the graphical and the text console, and then > I'm back to the text console. Sometimes I also recognize a "flicker" and I see the xdm login requester popping up, but only for a fraction of a second - and then vanishing. >=20 > However, starting xdm manually seems to work fine > every time. Not every time for me. Manipulating Xservers or Xaccess, even opening, changing a char in the commented out portions and saving them, can change the luck of starting or not - as I said, I can not reproduce this behaviour in a predicted manner. Starting xdm manually via console also does not work any time. If you would kill xdm, removing the /var/run/xdm.pid file and try again - I my case, this ending up in the error reported by xdm's /var/log/xdm.log: 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, (=3D=3D) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (=3D=3D) Log file: "/var/log/Xorg.0.log", Time: Sat Apr 7 18:38:24 2012 (=3D=3D) 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 >=20 > The log file is no help: >=20 > BUZI> cat /var/log/xdm.log=20 > xdm error (pid 1464): Can't lock pid file /var/run/xdm.pid, another xdm= is running (pid 939) > BUZI>=20 >=20 >=20 Try to restart xdm via /etc/ttys and then watch the content of your /var/log/xdm.log. By the way: My graphics card is a nVidia GPU GTX560Ti, running with the lates nvidia-driver: ohartmann@thor: [~] pkg_info | grep nvidia nvidia-driver-295.33 NVidia graphics card binary drivers for hardware OpenGL rendering My world and kernel are at: FreeBSD 10.0-CURRENT #5 r234046: Mon Apr 9 01:22:35 CEST 2012 As I reported before, this behaviour was introduced around r234000 and came out of the blue, since I didn't change anything of the configuration nor did I recompile anything else but the OS and kernel that day. A reboot left me floating as described. The only change I saw that day in the source updates was something with init.c. This could be a hint, but I'm a noob in terms of OS techniques, so this is only an observation, not a conclusion. Regards, Oliver --------------enig8A4D187F5A5A320FB21A0A80 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJPgrMbAAoJEOgBcD7A/5N87K0H/25o33cONdMjtlTc+UKwpHd2 QVJVIPcLjKipMsoMIl4XEMKsB2pcjiSJ+AkzvHbzqwyAN9JPs30ZTmbI3cYQPH67 4A9LBCCvzPudMidrIH3ue9kKn97ASU2bGB8encjjM0FHDyqObIWebphW//W85hEJ 5aWU+8XzS+LmpiRP6wy3AnXhPQvGzVCA2DG/un6o3G4L5FnJdtaJoehWfB5+f7Xc TbaSJtAHLwByCZjEi56c+/a2D8DXmRw3FAmGSEIQckPOq4NOezVUg+er1H1uLKlu NuHKNBPDhqXnaVOWMVcMDwiO5itjoe06A67fqF5FwcvbDbNk8N++dMmJSVXQUOo= =X5ab -----END PGP SIGNATURE----- --------------enig8A4D187F5A5A320FB21A0A80-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 9 10:04:29 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EF925106566B; Mon, 9 Apr 2012 10:04:29 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id A19068FC14; Mon, 9 Apr 2012 10:04:29 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1SHBSW-0006Ru-Ft>; Mon, 09 Apr 2012 12:04:28 +0200 Received: from e178034252.adsl.alicedsl.de ([85.178.34.252] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1SHBSW-0005xp-AU>; Mon, 09 Apr 2012 12:04:28 +0200 Message-ID: <4F82B42B.1050900@zedat.fu-berlin.de> Date: Mon, 09 Apr 2012 12:04:27 +0200 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120314 Thunderbird/10.0.3 MIME-Version: 1.0 To: Miroslav Lachman <000.fbsd@quip.cz> References: <4F7ED7F4.5060509@zedat.fu-berlin.de> <687BFFD7-1456-4D7B-AFB2-356EE9B0D1DD@gmail.com> <4F818A3B.5040904@quip.cz> In-Reply-To: <4F818A3B.5040904@quip.cz> X-Enigmail-Version: 1.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig910C6AD7A324B09C21B3649A" X-Originating-IP: 85.178.34.252 Cc: Nikolay Denev , freebsd-performance@freebsd.org, Current FreeBSD Subject: Re: ECC memory driver in FreeBSD 10? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 10:04:30 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig910C6AD7A324B09C21B3649A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 04/08/12 14:53, schrieb Miroslav Lachman: > Nikolay Denev wrote: >> On Apr 6, 2012, at 2:48 PM, O. Hartmann wrote: >> >>> I'm looking for a way to force FreeBSD 10 to maintain/watch ECC error= s >>> reported by UEFI (or BIOS). >>> Since ECC is said to be essential for server systems both in buisness= >>> and science and I do not question this, I was wondering if I can not >>> report ECC errors via a watchdog or UEFI (ACPI?) report to syslog >>> facility on FreeBSD. >>> FreeBSD is supposed to be a server operating system, as far as I know= , >>> so I believe there must be something which didn't have revealed itsel= f >>> to me, yet. >=20 >> >> If the hardware supports it, such errors should be logged as MCEs >> (Machine Check Exceptions). >> I can say for sure it works pretty well with Dell servers, as I had=20 >> one with failing RAM module, and >> it reported the corrected ECC errors in dmesg. >=20 > Memory ECC errors are logged in to messages and you can decode it by > sysutils/mcelog. I did it in the past on one of our Sun Fire X2100 M2 > with FreeBSD 8.x. >=20 > Miroslav Lachman Seems that I have been blessed with non-faulty memory over tha past three or four years. Last time I saw errors was around 2000. All of our 24/7 servers do have ECC RAM. So, your replies all implies if I log the system's messages via syslog properly (as we do remotely on a centralized server), then ECC errors should be reported by FreeBSD/kernel in a canonical way as the UEFI/BIOS reports them? Without special drivers/tools, scripts which scans for those errors should report occurences? Since my (FreeBSD) boxes didn't show up errors of that kind - Linux boxes of a colleague did once! - doesn't imply missing capabilities. This is nice to hear/read. Thanks a lot, Oliver --------------enig910C6AD7A324B09C21B3649A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJPgrQrAAoJEOgBcD7A/5N8cF8H/1nYRUFkgGBpmOaMyS5ED1ij 7wqM4s0OiCsW7bzFxTj3/C3dushNefBcesdTSDmU/I8nks0197J8PPy7PSldqffB OvlpxxNKEJwO+kp8+iO3oAdu0QNKK8pLhoAaDeXPq8N/e0M2DpcjE6j2rnC0td/l sppKb9cKZKEoWBZ/3dc5DjyzO3oVxTrnxSwIFolF7EINHkADb80ka8vtjOHSqXIP M0CkQZA+hJPL+iHRK1Ab5Kw4Wq6/7tljPlo560U/nr9gW7XoPGH0lTXzcjGOMVuX FepjT6D7r1kf+k0zrmi/AyJy6NuLEqKXWprmEoYTXQZBqv6NdM+zcHImiwJNvds= =UYjv -----END PGP SIGNATURE----- --------------enig910C6AD7A324B09C21B3649A-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 9 12:27:50 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 35F6A106564A; Mon, 9 Apr 2012 12:27:50 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7D3F98FC15; Mon, 9 Apr 2012 12:27:49 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so4257075bkc.13 for ; Mon, 09 Apr 2012 05:27:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=E2Rl2azNtyZapf9zlpvKe8VtXCjFZO2oI5iTSm9lnoA=; b=D2Y+zgxboyJAHy0ITDRx8hfhKmjhsMtJ7Y5YRsh/NR+2llB5U6V6sCdTG7hXPLMAfZ DlkZW17tTPnmJZEJB5kR7I5QQXM3Za29FfVXpXhzi3k/VwBBnhQ0STkFF6INiP4gskVZ ChHsQR4ZO3DdtK9rK4gzZNhSDOQ9ffUMh/OSZqA+MV2xzO8j/t5PbmeBPzA6teMo8ipz FlLAru6WkSBWgfacoA4XPaRuY9MRAhL+YF0S2vbxjYN8YfdL+3vosMPOyLMAqN5RkbN9 E+FeAfo3eGsd05n2J8YtWXO5BKriB1qOqshHR89GRaJvMtm/p+WYjeNtn57dqzLxzYvA ATMg== MIME-Version: 1.0 Received: by 10.205.117.15 with SMTP id fk15mr2933529bkc.133.1333974468332; Mon, 09 Apr 2012 05:27:48 -0700 (PDT) Received: by 10.204.202.142 with HTTP; Mon, 9 Apr 2012 05:27:48 -0700 (PDT) Received: by 10.204.202.142 with HTTP; Mon, 9 Apr 2012 05:27:48 -0700 (PDT) In-Reply-To: <4F82B315.3010408@zedat.fu-berlin.de> References: <4F8176A0.807@zedat.fu-berlin.de> <20120408152915.GU1420@albert.catwhisker.org> <4F82A3AF.3050207@zedat.fu-berlin.de> <20120409091507.GA55822@mech-cluster241.men.bris.ac.uk> <4F82B315.3010408@zedat.fu-berlin.de> Date: Mon, 9 Apr 2012 12:27:48 +0000 Message-ID: From: Chris Rees To: "O. Hartmann" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-x11@freebsd.org, Current FreeBSD , mexas@bristol.ac.uk Subject: Re: xdm failing to start on FBSD 10.0 r2340030 erratically X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 12:27:50 -0000 On 9 Apr 2012 11:00, "O. Hartmann" wrote: > > Am 04/09/12 11:15, schrieb Anton Shterenlikht: > > On Mon, Apr 09, 2012 at 10:54:07AM +0200, O. Hartmann wrote: > >> Am 04/08/12 17:29, schrieb David Wolfskill: > >>> On Sun, Apr 08, 2012 at 01:29:36PM +0200, O. Hartmann wrote: > >>>> I loose hair ... > >>>> Since yesterady's "make world" (last make world: the day before > >>>> yesterday), getting FreeBSD 10.0-CURRENT/amd64 to r234000 or so, the X11 > >>>> system on all of our FreeBSD 10.0-CUR/amd64 boxes start rejecting the > >>>> start of xdm display manager. xdm is started from /etc/ttys on ttyv7. > >>>> This worked before flawless. > >>>> > >>>> At this very moment, I do have X11 started via xdm - but this is a > >>>> erratic and non-reproduceable process! > >>>> > >>>> This morning, I update world and kernel to r234030. I recompiled many > >>>> ports via "portmaster -f xorg xdm", hoping the new kernel/world could > >>>> affect the ports, but this isn't. > >>>> > >>>> Starting Xorg X11 server works fine. xdm fails. The log in > >>>> /var/log/xdm.log looks like: > >>>> > >>>> Build Date: 07 April 2012 04:51:08PM > >>>> ... > >>>> > >>>> > >>>> I feel a bit helpless around here since I can not get close to what is > >>>> happening. The erratic behaviour of starting xdm is frightening. > >>>> Starting xdm via /etc/ttys doesn't work at all, but sometimes, with a > >>>> bit luck, xdm starts when started from the console. > >>>> .... > >>> > >>> I am not having trouble starting xdm via /etc/ttys; my environment is > >>> known to differ from yours in the following ways: > >>> > >>> * My ports (save for x11/nvidia-driver and misc/compat8x) are built > >>> under stable/8. (I track stable/8, stable/9, and head on a daily > >>> basis, and have a common /usr/local among them. I also update > >>> any installed ports that have updates available daily.) > >>> > >>> * I am running FreeBSD/i386, vs. FreeBSD/amd64. > >>> > >>> * My last 2 updates were r233994 (yesterday) and r234031 (today). > >>> > >>> * I have a mildly hacked-up startup script for xdm. I doubt this is an > >>> issue -- I've been doing this since 2006/03/05 19:04:03 (according to > >>> the RCS log), though I have modified the script a few times > >>> since its inception. But the point here is that I'm not directly > >>> invoking the xdm executable from /etc/ttys. > >> > >> When I start xdm via console, it starts up, but only with a "Xservers" > >> file that contains nothing but comments. If there are the lines > >> > >> localhost > >> 127.0.0.1 > >> 192.168.0.128 > >> !* > >> > >> it will will probably start not. Since xdm does not show this behaviour > >> in a reproducible manner I susepct a bug. > >> > >>> > >>> * I don't know that this is different, but it may well be: my xorg.conf > >>> includes a stanza: > >>> > >>> Section "ServerFlags" > >>> Option "AutoAddDevices" "False" > >>> EndSection > >> > >> I should go with this and try. But as far as I know, since I have USB > >> devices (mouse, keyboard), unpluggin and pluggin them is then, without > >> hal and dbus, not recognized anymore, isn't it? > >> > >> There was a discussion once going one for this subject. > >> > >> > >> Either way, at this very moment I do not know whether the OS or the X11 > >> is faulty and I'd like to report this as a bug. > >> > >>> > >>> because my experiences with hald & dbus were so unpleasant. I don't > >>> use them; I don't even try to start them. > >>> > >>> Peace, > >>> david > >> > >> Regards, > >> Oliver > >> > > > > I see the same (or similar) behavior on r231158M amd64 > > Compaq 6715s laptop. > > > > I've: > > > > BUZI> pkg info xdm > > xdm-1.1.11: X.Org X display manager > > BUZI> > > pkohartmann@thor: [~] g_info |grep xdm > xdm-1.1.11 X.Org X display manager > > > > > Starting xdm from /etc/ttys: > > > > BUZI> grep bin/xdm /etc/ttys > > ttyv8 "/usr/local/bin/xdm -nodaemon" xterm on secure > > BUZI> > > ohartmann@thor: [~] grep bin/xdm /etc/ttys > ttyv7 "/usr/local/bin/xdm -nodaemon" xterm on insecure Hm, you know setting insecure on xdm still lets root login? Chris From owner-freebsd-current@FreeBSD.ORG Mon Apr 9 13:42:04 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 270081065783; Mon, 9 Apr 2012 13:42:04 +0000 (UTC) (envelope-from aboyer@averesystems.com) Received: from zimbra.averesystems.com (75-149-8-245-Pennsylvania.hfc.comcastbusiness.net [75.149.8.245]) by mx1.freebsd.org (Postfix) with ESMTP id C98138FC12; Mon, 9 Apr 2012 13:42:03 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zimbra.averesystems.com (Postfix) with ESMTP id 30F39446006; Mon, 9 Apr 2012 09:31:28 -0400 (EDT) X-Virus-Scanned: amavisd-new at averesystems.com Received: from zimbra.averesystems.com ([127.0.0.1]) by localhost (zimbra.averesystems.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R1lVzEGRrzHd; Mon, 9 Apr 2012 09:31:23 -0400 (EDT) Received: from riven.arriad.com (fw.arriad.com [10.0.0.16]) by zimbra.averesystems.com (Postfix) with ESMTPSA id 914EC446003; Mon, 9 Apr 2012 09:31:23 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Andrew Boyer In-Reply-To: <4F82B42B.1050900@zedat.fu-berlin.de> Date: Mon, 9 Apr 2012 09:32:01 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F7ED7F4.5060509@zedat.fu-berlin.de> <687BFFD7-1456-4D7B-AFB2-356EE9B0D1DD@gmail.com> <4F818A3B.5040904@quip.cz> <4F82B42B.1050900@zedat.fu-berlin.de> To: O. Hartmann X-Mailer: Apple Mail (2.1084) Cc: Nikolay Denev , freebsd-performance@freebsd.org, Current FreeBSD , Miroslav Lachman <000.fbsd@quip.cz> Subject: Re: ECC memory driver in FreeBSD 10? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 13:42:04 -0000 On Apr 9, 2012, at 6:04 AM, O. Hartmann wrote: > Am 04/08/12 14:53, schrieb Miroslav Lachman: >> Nikolay Denev wrote: >>> On Apr 6, 2012, at 2:48 PM, O. Hartmann wrote: >>>=20 >>>> I'm looking for a way to force FreeBSD 10 to maintain/watch ECC = errors >>>> reported by UEFI (or BIOS). >>>> Since ECC is said to be essential for server systems both in = buisness >>>> and science and I do not question this, I was wondering if I can = not >>>> report ECC errors via a watchdog or UEFI (ACPI?) report to syslog >>>> facility on FreeBSD. >>>> FreeBSD is supposed to be a server operating system, as far as I = know, >>>> so I believe there must be something which didn't have revealed = itself >>>> to me, yet. >>=20 >>>=20 >>> If the hardware supports it, such errors should be logged as MCEs >>> (Machine Check Exceptions). >>> I can say for sure it works pretty well with Dell servers, as I had=20= >>> one with failing RAM module, and >>> it reported the corrected ECC errors in dmesg. >>=20 >> Memory ECC errors are logged in to messages and you can decode it by >> sysutils/mcelog. I did it in the past on one of our Sun Fire X2100 M2 >> with FreeBSD 8.x. >>=20 >> Miroslav Lachman >=20 > Seems that I have been blessed with non-faulty memory over tha past > three or four years. Last time I saw errors was around 2000. All of = our > 24/7 servers do have ECC RAM. >=20 > So, your replies all implies if I log the system's messages via syslog > properly (as we do remotely on a centralized server), then ECC errors > should be reported by FreeBSD/kernel in a canonical way as the = UEFI/BIOS > reports them? > Without special drivers/tools, scripts which scans for those errors > should report occurences? >=20 > Since my (FreeBSD) boxes didn't show up errors of that kind - Linux > boxes of a colleague did once! - doesn't imply missing capabilities. > This is nice to hear/read. >=20 > Thanks a lot, >=20 > Oliver >=20 This is what you see in syslog when sys/x86/x86/mca.c detects a memory = error: > Mar 16 12:37:33 hostname kernel: MCA: Bank 8, Status = 0x8c0000400001009f > Mar 16 12:37:33 hostname kernel: MCA: Global Cap 0x0000000000001c09, = Status 0x0000000000000000 > Mar 16 12:37:33 hostname kernel: MCA: Vendor "GenuineIntel", ID = 0x206c2, APIC ID 0 > Mar 16 12:37:33 hostname kernel: MCA: CPU 0 COR (1) RD channel ?? = memory error > Mar 16 12:37:33 hostname kernel: MCA: Address 0xb43ca6240 > Mar 16 12:37:33 hostname kernel: MCA: Misc 0x4ac8111000064808 mcelog will help you figure out which DIMM is affected. Also, if your server includes an IPMI controller, the BIOS should be set = up to log memory errors to the IPMI system event log (SEL). You can = look at the SEL with ipmitool from the ports collection. 'ipmitool sel = list' will show you if any errors have been reported. -Andrew -------------------------------------------------- Andrew Boyer aboyer@averesystems.com From owner-freebsd-current@FreeBSD.ORG Mon Apr 9 14:08:04 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 452C71065672 for ; Mon, 9 Apr 2012 14:08:04 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [76.96.27.227]) by mx1.freebsd.org (Postfix) with ESMTP id 24DC48FC18 for ; Mon, 9 Apr 2012 14:08:04 +0000 (UTC) Received: from omta07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by qmta12.emeryville.ca.mail.comcast.net with comcast id vq0D1i0031GXsucACq7yf8; Mon, 09 Apr 2012 14:07:58 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta07.emeryville.ca.mail.comcast.net with comcast id vq7w1i00f4NgCEG8Uq7xFb; Mon, 09 Apr 2012 14:07:58 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q39E7ta8057088; Mon, 9 Apr 2012 08:07:55 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Konstantin Belousov In-Reply-To: <20120407145728.GV2358@deviant.kiev.zoral.com.ua> References: <20120407125056.GS2358@deviant.kiev.zoral.com.ua> <1333810001.1082.36.camel@revolution.hippie.lan> <20120407145728.GV2358@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset="us-ascii" Date: Mon, 09 Apr 2012 08:07:55 -0600 Message-ID: <1333980475.1082.47.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: current@freebsd.org, drivers@freebsd.org Subject: Re: device_attach(9) and driver initialization X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 14:08:04 -0000 On Sat, 2012-04-07 at 17:57 +0300, Konstantin Belousov wrote: > On Sat, Apr 07, 2012 at 08:46:41AM -0600, 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. > No, 'a mutex' does not solve anything. It only adds enourmous burden > on the driver developers, because you cannot sleep under mutex. Changing > the mutex to the sleepable lock also does not byy you much, since > you need to somehow solve the issues with some cdevsw call waking up > thread sleeping into another cdevsw call, just for example. > > Singlethreading a driver due to this race is just silly. > > And, what do you mean by 'making it harder to MFC' ? How ? I frequently find myself having to backport driver changes further back than any currently-supported FreeBSD release, and something like a new function in newbus can make that pretty hard to do. That often makes me think of how accomplish something with a minimally-invasive change. (So it's really more of a selfish personal goal more than a FreeBSD-project goal.) -- Ian From owner-freebsd-current@FreeBSD.ORG Mon Apr 9 14:41:25 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B106106566B for ; Mon, 9 Apr 2012 14:41:25 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [76.96.27.211]) by mx1.freebsd.org (Postfix) with ESMTP id 28A608FC18 for ; Mon, 9 Apr 2012 14:41:25 +0000 (UTC) Received: from omta23.emeryville.ca.mail.comcast.net ([76.96.30.90]) by qmta11.emeryville.ca.mail.comcast.net with comcast id vqcR1i0031wfjNsABqhKrt; Mon, 09 Apr 2012 14:41:19 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta23.emeryville.ca.mail.comcast.net with comcast id vqhH1i01H4NgCEG8jqhJWa; Mon, 09 Apr 2012 14:41:19 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q39EfF4X057102; Mon, 9 Apr 2012 08:41:15 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Konstantin Belousov In-Reply-To: <20120408035838.GY2358@deviant.kiev.zoral.com.ua> References: <20120407125056.GS2358@deviant.kiev.zoral.com.ua> <1333810001.1082.36.camel@revolution.hippie.lan> <20120407145728.GV2358@deviant.kiev.zoral.com.ua> <20120408035838.GY2358@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset="us-ascii" Date: Mon, 09 Apr 2012 08:41:15 -0600 Message-ID: <1333982475.1082.61.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: current@freebsd.org, Warner Losh , drivers@freebsd.org Subject: Re: device_attach(9) and driver initialization X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 14:41:25 -0000 On Sun, 2012-04-08 at 06:58 +0300, Konstantin Belousov wrote: > On Sat, Apr 07, 2012 at 09:10:55PM -0600, Warner Losh wrote: > > > > On Apr 7, 2012, at 8:57 AM, Konstantin Belousov wrote: > > > > > On Sat, Apr 07, 2012 at 08:46:41AM -0600, 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. > > > No, 'a mutex' does not solve anything. It only adds enourmous burden > > > on the driver developers, because you cannot sleep under mutex. Changing > > > the mutex to the sleepable lock also does not byy you much, since > > > you need to somehow solve the issues with some cdevsw call waking up > > > thread sleeping into another cdevsw call, just for example. > > > > > > Singlethreading a driver due to this race is just silly. > > > > > > And, what do you mean by 'making it harder to MFC' ? How ? > > > > driver_attach() > > { > > ... > > softc->flags = 0; // redundant, since softc is initialized to 0. > > softc->cdev = device_create...(); > > ... > > softc->flags |= READY; > > } > > > > driver_open(...) > > { > > if (!(softc->flags & READY)) > > return ENXIO; > > ... > > } > > > > What's the big burden here? > The burden is that your proposal does not work. As I described above, > device_busy() calls from cdevsw method panic if open() is called before > DS_ATTACHED is set by newbus. And, DS_ATTACHED is only set after device > attach() method returned, so no workarounds from attach() could solve > this. One thing that keeps floating to the front of my brain is that all the proposals so far (including my not-well-thought-out mutex suggestion) requires changing every existing driver to get the new safe behavior. Hmmm. Looking at the code, not very many drivers call device_busy(). Why is that? I agree that calling device_create() should be deferred until the driver is ready to handle requests. That's only part of the fix if the newbus support routines are still going to have a window where they can panic because the internal state variables haven't yet transitioned to the correct state. Also, the implementation of device_busy() looks to be unsafe unless it's being implicitly protected by some locking in a call chain that isn't jumping out at me with simple grepping of the code. For example, concurrent callers in a device's open() and close() methods for a driver that calls busy/unbusy from cdev open/close could leave the parent device's busy count in an indeterminate state. Could fixing this by enforcing single threading through busy/unbusy provide an opportunity to fix the original problem by having the attach code acquire the same lock, so that an early call to a cdev method that invokes device_busy() ends up sleeping until the attach routine returns? That way you don't single-thread the whole cdev open/close handling, just the part that's currently causing a problem. -- Ian From owner-freebsd-current@FreeBSD.ORG Mon Apr 9 14:59:39 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B4698106564A; Mon, 9 Apr 2012 14:59:39 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 0930B8FC14; Mon, 9 Apr 2012 14:59:38 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q39ExFE3063752; Mon, 9 Apr 2012 17:59:15 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q39ExEP9050552; Mon, 9 Apr 2012 17:59:14 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q39ExDuv050551; Mon, 9 Apr 2012 17:59:13 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 9 Apr 2012 17:59:13 +0300 From: Konstantin Belousov To: Ian Lepore Message-ID: <20120409145913.GR2358@deviant.kiev.zoral.com.ua> References: <20120407125056.GS2358@deviant.kiev.zoral.com.ua> <1333810001.1082.36.camel@revolution.hippie.lan> <20120407145728.GV2358@deviant.kiev.zoral.com.ua> <20120408035838.GY2358@deviant.kiev.zoral.com.ua> <1333982475.1082.61.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aLNv5lbzIJDYDUXB" Content-Disposition: inline In-Reply-To: <1333982475.1082.61.camel@revolution.hippie.lan> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: current@freebsd.org, Warner Losh , drivers@freebsd.org Subject: Re: device_attach(9) and driver initialization X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 14:59:39 -0000 --aLNv5lbzIJDYDUXB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 09, 2012 at 08:41:15AM -0600, Ian Lepore wrote: > On Sun, 2012-04-08 at 06:58 +0300, Konstantin Belousov wrote: > > On Sat, Apr 07, 2012 at 09:10:55PM -0600, Warner Losh wrote: > > >=20 > > > On Apr 7, 2012, at 8:57 AM, Konstantin Belousov wrote: > > >=20 > > > > On Sat, Apr 07, 2012 at 08:46:41AM -0600, 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 b= y 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 statem= ents, > > > >>> but drivers that e.g. create devfs node to communicate with consu= mers > > > >>> are prone to a race. > > > >>>=20 > > > >>> 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 method= s, > > > >>> like device_busy(9), then panic occurs "called for unatteched dev= ice". > > > >>> I get reports from users about this issues, to it is not something > > > >>> that only could happen. > > > >>>=20 > > > >>> I propose to add DEVICE_AFTER_ATTACH() driver method, to be called > > > >>> from newbus right after device attach finished and newbus conside= rs > > > >>> the device fully initialized. Driver then could create devfs node > > > >>> in the after_attach method instead of attach. Please see the patc= h below. > > > >>>=20 > > > >>> 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 { > > > >>> }; > > > >>>=20 > > > >>> /** > > > >>> + * @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 e= xpose > > > >>> + * 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 =3D DS_ATTACHED; > > > >>> dev->flags &=3D ~DF_DONENOMATCH; > > > >>> devadded(dev); > > > >>> + DEVICE_AFTER_ATTACH(dev); > > > >>> return (0); > > > >>> } > > > >>>=20 > > > >>=20 > > > >> 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 initi= alized > > > >> and acquired early in the driver's attach routine, and also acquir= ed in > > > >> the driver's cdev implementation routines before using any newbus > > > >> functions other than device_get_softc(), would solve the problem w= ithout > > > >> a driver api change that would make it harder to backport/MFC driv= er > > > >> changes. > > > > No, 'a mutex' does not solve anything. It only adds enourmous burden > > > > on the driver developers, because you cannot sleep under mutex. Cha= nging > > > > the mutex to the sleepable lock also does not byy you much, since > > > > you need to somehow solve the issues with some cdevsw call waking up > > > > thread sleeping into another cdevsw call, just for example. > > > >=20 > > > > Singlethreading a driver due to this race is just silly. > > > >=20 > > > > And, what do you mean by 'making it harder to MFC' ? How ? > > >=20 > > > driver_attach() > > > { > > > ... > > > softc->flags =3D 0; // redundant, since softc is initialized to 0. > > > softc->cdev =3D device_create...(); > > > ... > > > softc->flags |=3D READY; > > > } > > >=20 > > > driver_open(...) > > > { > > > if (!(softc->flags & READY)) > > > return ENXIO; > > > ... > > > } > > >=20 > > > What's the big burden here? > > The burden is that your proposal does not work. As I described above, > > device_busy() calls from cdevsw method panic if open() is called before > > DS_ATTACHED is set by newbus. And, DS_ATTACHED is only set after device > > attach() method returned, so no workarounds from attach() could solve > > this. >=20 > One thing that keeps floating to the front of my brain is that all the > proposals so far (including my not-well-thought-out mutex suggestion) > requires changing every existing driver to get the new safe behavior. >=20 > Hmmm. Looking at the code, not very many drivers call device_busy(). > Why is that? =20 >=20 > I agree that calling device_create() should be deferred until the driver You mean make_dev(9), I assume. > is ready to handle requests. That's only part of the fix if the newbus > support routines are still going to have a window where they can panic > because the internal state variables haven't yet transitioned to the > correct state. =20 >=20 > Also, the implementation of device_busy() looks to be unsafe unless it's > being implicitly protected by some locking in a call chain that isn't > jumping out at me with simple grepping of the code. For example, > concurrent callers in a device's open() and close() methods for a driver > that calls busy/unbusy from cdev open/close could leave the parent > device's busy count in an indeterminate state. Could fixing this by > enforcing single threading through busy/unbusy provide an opportunity to > fix the original problem by having the attach code acquire the same > lock, so that an early call to a cdev method that invokes device_busy() > ends up sleeping until the attach routine returns? That way you don't > single-thread the whole cdev open/close handling, just the part that's > currently causing a problem. I think device_busy() calls require Giant, the same as the whole newbus. The absence of GIANT_REQUIRED assertions in device_busy() and device_unbusy= () looks like overlook. --aLNv5lbzIJDYDUXB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk+C+UEACgkQC3+MBN1Mb4jyyQCfVT7lHgGeiLMsjUFMCQIgzM9e 6lMAniYIyja/0aayMj78aYDJgAfpU6WC =HEjq -----END PGP SIGNATURE----- --aLNv5lbzIJDYDUXB-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 9 15:01:20 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F0721065688; Mon, 9 Apr 2012 15:01:20 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 022678FC08; Mon, 9 Apr 2012 15:01:20 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 40F82B911; Mon, 9 Apr 2012 11:01:19 -0400 (EDT) From: John Baldwin To: freebsd-drivers@freebsd.org Date: Mon, 9 Apr 2012 11:01:03 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <20120407125056.GS2358@deviant.kiev.zoral.com.ua> <1333810001.1082.36.camel@revolution.hippie.lan> <7C5089DC-AB9B-458F-A606-B432505BD961@bsdimp.com> In-Reply-To: <7C5089DC-AB9B-458F-A606-B432505BD961@bsdimp.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201204091101.03956.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 09 Apr 2012 11:01:19 -0400 (EDT) Cc: Ian Lepore , current@freebsd.org, Warner Losh , drivers@freebsd.org Subject: Re: device_attach(9) and driver initialization X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 15:01:20 -0000 On Saturday, April 07, 2012 11:08:41 pm Warner Losh wrote: > > On Apr 7, 2012, at 8:46 AM, Ian Lepore wrote: > > > On Sat, 2012-04-07 at 15:50 +0300, Konstantin Belousov wrote: > >> Hello, > >> there seems to be a problem with device attach sequence offered by newbus. > >> Basically, when device attach method is executing, device is not fully > >> initialized yet. Also the device state in the newbus part of the world > >> is DS_ALIVE. There is definitely no shattering news in the statements, > >> but drivers that e.g. create devfs node to communicate with consumers > >> are prone to a race. > >> > >> If /dev node is created inside device attach method, then usermode > >> can start calling cdevsw methods before device fully initialized itself. > >> Even more, if device tries to use newbus helpers in cdevsw methods, > >> like device_busy(9), then panic occurs "called for unatteched device". > >> I get reports from users about this issues, to it is not something > >> that only could happen. > >> > >> I propose to add DEVICE_AFTER_ATTACH() driver method, to be called > >> from newbus right after device attach finished and newbus considers > >> the device fully initialized. Driver then could create devfs node > >> in the after_attach method instead of attach. Please see the patch below. > >> > >> diff --git a/sys/kern/device_if.m b/sys/kern/device_if.m > >> index eb720eb..9db74e2 100644 > >> --- a/sys/kern/device_if.m > >> +++ b/sys/kern/device_if.m > >> @@ -43,6 +43,10 @@ INTERFACE device; > >> # Default implementations of some methods. > >> # > >> CODE { > >> + static void null_after_attach(device_t dev) > >> + { > >> + } > >> + > >> static int null_shutdown(device_t dev) > >> { > >> return 0; > >> @@ -199,6 +203,21 @@ METHOD int attach { > >> }; > >> > >> /** > >> + * @brief Notify the driver that device is in attached state > >> + * > >> + * Called after driver is successfully attached to the device and > >> + * corresponding device_t is fully operational. Driver now may expose > >> + * the device to the consumers, e.g. create devfs nodes. > >> + * > >> + * @param dev the device to probe > >> + * > >> + * @see DEVICE_ATTACH() > >> + */ > >> +METHOD void after_attach { > >> + device_t dev; > >> +} DEFAULT null_after_attach; > >> + > >> +/** > >> * @brief Detach a driver from a device. > >> * > >> * This can be called if the user is replacing the > >> diff --git a/sys/kern/subr_bus.c b/sys/kern/subr_bus.c > >> index d485b9f..6d849cb 100644 > >> --- a/sys/kern/subr_bus.c > >> +++ b/sys/kern/subr_bus.c > >> @@ -2743,6 +2743,7 @@ device_attach(device_t dev) > >> dev->state = DS_ATTACHED; > >> dev->flags &= ~DF_DONENOMATCH; > >> devadded(dev); > >> + DEVICE_AFTER_ATTACH(dev); > >> return (0); > >> } > >> > > > > Does device_get_softc() work before attach is completed? (I don't have > > time to go look in the code right now). If so, then a mutex initialized > > and acquired early in the driver's attach routine, and also acquired in > > the driver's cdev implementation routines before using any newbus > > functions other than device_get_softc(), would solve the problem without > > a driver api change that would make it harder to backport/MFC driver > > changes. > > Also, more generally, don't create the dev nodes before you are ready to deal with requests. Why do we need to uglify everything here? If you can't do that, you can check a bit in the softc and return EBUSY or ENXIO on open if that bit says that your driver isn't ready to accept requests. I agree, this dosen't actually fix anything as the decision for what to put in your foo_attach() method rather than foo_after_attach() is non-obvious and very arbitrary. The actual bug appears to only be with using 'device_busy()'. I think this should be fixed by making device_busy() better, not by adding this type of obfuscation to attach. It should be trivial to make device_busy() safe to use on a device that is currently being attached which will not require any changes to drivers. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Apr 9 15:37:41 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5FFBE106564A for ; Mon, 9 Apr 2012 15:37:41 +0000 (UTC) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from mail-gw13.york.ac.uk (mail-gw13.york.ac.uk [144.32.129.163]) by mx1.freebsd.org (Postfix) with ESMTP id 1D0968FC1C for ; Mon, 9 Apr 2012 15:37:41 +0000 (UTC) Received: from ury.york.ac.uk ([144.32.108.81]:39307) by mail-gw13.york.ac.uk with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1SHGex-0005T0-Or; Mon, 09 Apr 2012 16:37:39 +0100 Received: from gavin (helo=localhost) by ury.york.ac.uk with local-esmtp (Exim 4.77) (envelope-from ) id 1SHGex-0007MJ-IQ; Mon, 09 Apr 2012 16:37:39 +0100 Date: Mon, 9 Apr 2012 16:37:39 +0100 (BST) From: Gavin Atkinson X-X-Sender: gavin@ury.york.ac.uk To: Alex Keda In-Reply-To: <4F828168.2030709@lissyara.su> Message-ID: References: <4F828168.2030709@lissyara.su> User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Cc: current@freebsd.org Subject: Re: r234000: i386 freeze when HT enabled X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 15:37:41 -0000 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? Gavin From owner-freebsd-current@FreeBSD.ORG Mon Apr 9 15:43:27 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6B85A1065674 for ; Mon, 9 Apr 2012 15:43:27 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by mx1.freebsd.org (Postfix) with ESMTP id 456F68FC08 for ; Mon, 9 Apr 2012 15:43:27 +0000 (UTC) Received: from omta02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by qmta10.emeryville.ca.mail.comcast.net with comcast id vriF1i0050QkzPwAAriMem; Mon, 09 Apr 2012 15:42:21 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta02.emeryville.ca.mail.comcast.net with comcast id vriL1i0064NgCEG8NriLrS; Mon, 09 Apr 2012 15:42:21 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q39FgIbg057154; Mon, 9 Apr 2012 09:42:18 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Konstantin Belousov In-Reply-To: <20120409145913.GR2358@deviant.kiev.zoral.com.ua> References: <20120407125056.GS2358@deviant.kiev.zoral.com.ua> <1333810001.1082.36.camel@revolution.hippie.lan> <20120407145728.GV2358@deviant.kiev.zoral.com.ua> <20120408035838.GY2358@deviant.kiev.zoral.com.ua> <1333982475.1082.61.camel@revolution.hippie.lan> <20120409145913.GR2358@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset="us-ascii" Date: Mon, 09 Apr 2012 09:42:18 -0600 Message-ID: <1333986138.1082.71.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: current@freebsd.org, Warner Losh , drivers@freebsd.org Subject: Re: device_attach(9) and driver initialization X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 15:43:27 -0000 On Mon, 2012-04-09 at 17:59 +0300, Konstantin Belousov wrote: > On Mon, Apr 09, 2012 at 08:41:15AM -0600, Ian Lepore wrote: > > On Sun, 2012-04-08 at 06:58 +0300, Konstantin Belousov wrote: > > > On Sat, Apr 07, 2012 at 09:10:55PM -0600, Warner Losh wrote: > > > > > > > > On Apr 7, 2012, at 8:57 AM, Konstantin Belousov wrote: > > > > > > > > > On Sat, Apr 07, 2012 at 08:46:41AM -0600, 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. > > > > > No, 'a mutex' does not solve anything. It only adds enourmous burden > > > > > on the driver developers, because you cannot sleep under mutex. Changing > > > > > the mutex to the sleepable lock also does not byy you much, since > > > > > you need to somehow solve the issues with some cdevsw call waking up > > > > > thread sleeping into another cdevsw call, just for example. > > > > > > > > > > Singlethreading a driver due to this race is just silly. > > > > > > > > > > And, what do you mean by 'making it harder to MFC' ? How ? > > > > > > > > driver_attach() > > > > { > > > > ... > > > > softc->flags = 0; // redundant, since softc is initialized to 0. > > > > softc->cdev = device_create...(); > > > > ... > > > > softc->flags |= READY; > > > > } > > > > > > > > driver_open(...) > > > > { > > > > if (!(softc->flags & READY)) > > > > return ENXIO; > > > > ... > > > > } > > > > > > > > What's the big burden here? > > > The burden is that your proposal does not work. As I described above, > > > device_busy() calls from cdevsw method panic if open() is called before > > > DS_ATTACHED is set by newbus. And, DS_ATTACHED is only set after device > > > attach() method returned, so no workarounds from attach() could solve > > > this. > > > > One thing that keeps floating to the front of my brain is that all the > > proposals so far (including my not-well-thought-out mutex suggestion) > > requires changing every existing driver to get the new safe behavior. > > > > Hmmm. Looking at the code, not very many drivers call device_busy(). > > Why is that? > > > > I agree that calling device_create() should be deferred until the driver > You mean make_dev(9), I assume. > Yes, of course, sorry (I was looking at a call to a local convenience routine in a private driver). > > is ready to handle requests. That's only part of the fix if the newbus > > support routines are still going to have a window where they can panic > > because the internal state variables haven't yet transitioned to the > > correct state. > > > > Also, the implementation of device_busy() looks to be unsafe unless it's > > being implicitly protected by some locking in a call chain that isn't > > jumping out at me with simple grepping of the code. For example, > > concurrent callers in a device's open() and close() methods for a driver > > that calls busy/unbusy from cdev open/close could leave the parent > > device's busy count in an indeterminate state. Could fixing this by > > enforcing single threading through busy/unbusy provide an opportunity to > > fix the original problem by having the attach code acquire the same > > lock, so that an early call to a cdev method that invokes device_busy() > > ends up sleeping until the attach routine returns? That way you don't > > single-thread the whole cdev open/close handling, just the part that's > > currently causing a problem. > I think device_busy() calls require Giant, the same as the whole newbus. > The absence of GIANT_REQUIRED assertions in device_busy() and device_unbusy() > looks like overlook. Hmmm. Shouldn't device_attach() then require Giant as well? I see that device_detach() and device_probe_and_attach() contains GIANT_REQUIRED but device_attach() does not. Of the few devices calling device_busy(), some use D_NEEDGIANT and some do not (the do-nots include drm, fdc, rp -- I stopped looking at this point). Only the fdc code specifically calls mtx_lock(&Giant), but it appears that it does not do so around the device_busy/unbusy() calls. If you're supposed to hold Giant during calls to device_busy/unbusy, and assuming it should be held by whomever calls device_attach(), wouldn't that fix the panic? I don't know if that's a good assumption, because I'm not seeing anything in the manpages or architecture handbook about holding Giant during newbus calls. -- Ian From owner-freebsd-current@FreeBSD.ORG Mon Apr 9 16:04:29 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D649C106566C; Mon, 9 Apr 2012 16:04:29 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 62B7C8FC08; Mon, 9 Apr 2012 16:04:29 +0000 (UTC) Received: from [10.30.101.53] ([209.117.142.2]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id q39FwJbv093309 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Mon, 9 Apr 2012 09:58:21 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <1333986138.1082.71.camel@revolution.hippie.lan> Date: Mon, 9 Apr 2012 09:58:14 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120407125056.GS2358@deviant.kiev.zoral.com.ua> <1333810001.1082.36.camel@revolution.hippie.lan> <20120407145728.GV2358@deviant.kiev.zoral.com.ua> <20120408035838.GY2358@deviant.kiev.zoral.com.ua> <1333982475.1082.61.camel@revolution.hippie.lan> <20120409145913.GR2358@deviant.kiev.zoral.com.ua> <1333986138.1082.71.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Mon, 09 Apr 2012 09:58:22 -0600 (MDT) Cc: Konstantin Belousov , current@FreeBSD.org, drivers@FreeBSD.org Subject: Re: device_attach(9) and driver initialization X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 16:04:29 -0000 On Apr 9, 2012, at 9:42 AM, Ian Lepore wrote: > On Mon, 2012-04-09 at 17:59 +0300, Konstantin Belousov wrote: >> On Mon, Apr 09, 2012 at 08:41:15AM -0600, Ian Lepore wrote: >>> On Sun, 2012-04-08 at 06:58 +0300, Konstantin Belousov wrote: >>>> On Sat, Apr 07, 2012 at 09:10:55PM -0600, Warner Losh wrote: >>>>>=20 >>>>> On Apr 7, 2012, at 8:57 AM, Konstantin Belousov wrote: >>>>>=20 >>>>>> On Sat, Apr 07, 2012 at 08:46:41AM -0600, 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. >>>>>>>>=20 >>>>>>>> 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. >>>>>>>>=20 >>>>>>>> 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. >>>>>>>>=20 >>>>>>>> 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 { >>>>>>>> }; >>>>>>>>=20 >>>>>>>> /** >>>>>>>> + * @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 =3D DS_ATTACHED; >>>>>>>> dev->flags &=3D ~DF_DONENOMATCH; >>>>>>>> devadded(dev); >>>>>>>> + DEVICE_AFTER_ATTACH(dev); >>>>>>>> return (0); >>>>>>>> } >>>>>>>>=20 >>>>>>>=20 >>>>>>> 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. >>>>>> No, 'a mutex' does not solve anything. It only adds enourmous = burden >>>>>> on the driver developers, because you cannot sleep under mutex. = Changing >>>>>> the mutex to the sleepable lock also does not byy you much, since >>>>>> you need to somehow solve the issues with some cdevsw call waking = up >>>>>> thread sleeping into another cdevsw call, just for example. >>>>>>=20 >>>>>> Singlethreading a driver due to this race is just silly. >>>>>>=20 >>>>>> And, what do you mean by 'making it harder to MFC' ? How ? >>>>>=20 >>>>> driver_attach() >>>>> { >>>>> ... >>>>> softc->flags =3D 0; // redundant, since softc is initialized to = 0. >>>>> softc->cdev =3D device_create...(); >>>>> ... >>>>> softc->flags |=3D READY; >>>>> } >>>>>=20 >>>>> driver_open(...) >>>>> { >>>>> if (!(softc->flags & READY)) >>>>> return ENXIO; >>>>> ... >>>>> } >>>>>=20 >>>>> What's the big burden here? >>>> The burden is that your proposal does not work. As I described = above, >>>> device_busy() calls from cdevsw method panic if open() is called = before >>>> DS_ATTACHED is set by newbus. And, DS_ATTACHED is only set after = device >>>> attach() method returned, so no workarounds from attach() could = solve >>>> this. >>>=20 >>> One thing that keeps floating to the front of my brain is that all = the >>> proposals so far (including my not-well-thought-out mutex = suggestion) >>> requires changing every existing driver to get the new safe = behavior. >>>=20 >>> Hmmm. Looking at the code, not very many drivers call = device_busy(). >>> Why is that? =20 >>>=20 >>> I agree that calling device_create() should be deferred until the = driver >> You mean make_dev(9), I assume. >>=20 >=20 > Yes, of course, sorry (I was looking at a call to a local convenience > routine in a private driver). >=20 >>> is ready to handle requests. That's only part of the fix if the = newbus >>> support routines are still going to have a window where they can = panic >>> because the internal state variables haven't yet transitioned to the >>> correct state. =20 >>>=20 >>> Also, the implementation of device_busy() looks to be unsafe unless = it's >>> being implicitly protected by some locking in a call chain that = isn't >>> jumping out at me with simple grepping of the code. For example, >>> concurrent callers in a device's open() and close() methods for a = driver >>> that calls busy/unbusy from cdev open/close could leave the parent >>> device's busy count in an indeterminate state. Could fixing this by >>> enforcing single threading through busy/unbusy provide an = opportunity to >>> fix the original problem by having the attach code acquire the same >>> lock, so that an early call to a cdev method that invokes = device_busy() >>> ends up sleeping until the attach routine returns? That way you = don't >>> single-thread the whole cdev open/close handling, just the part = that's >>> currently causing a problem. >> I think device_busy() calls require Giant, the same as the whole = newbus. >> The absence of GIANT_REQUIRED assertions in device_busy() and = device_unbusy() >> looks like overlook. >=20 > Hmmm. Shouldn't device_attach() then require Giant as well? I see = that > device_detach() and device_probe_and_attach() contains GIANT_REQUIRED > but device_attach() does not. =20 They both require Giant because the device tree is only locked via = Giant. Pretty much all newbus functions require Giant to be held when = you call them. This is poorly enforced in the code, however. And also = poorly documented. The reasons this wasn't well documented was the = promise of newbus locking that never made it into the tree, but also = blocked efforts to improve the documentation here, as well as adding = additional needs giant stuff. > Of the few devices calling device_busy(), some use D_NEEDGIANT and = some > do not (the do-nots include drm, fdc, rp -- I stopped looking at this > point). Only the fdc code specifically calls mtx_lock(&Giant), but it > appears that it does not do so around the device_busy/unbusy() calls. >=20 > If you're supposed to hold Giant during calls to device_busy/unbusy, = and > assuming it should be held by whomever calls device_attach(), wouldn't > that fix the panic? I don't know if that's a good assumption, because > I'm not seeing anything in the manpages or architecture handbook about > holding Giant during newbus calls Since we're recursively traveling up the tree, we need some topology = lock in order to ensure tree consistency. Giant is that lock, for = better or worse. At one point, and I'm not sure if this is still true, = the rule was either Giant being held, or interrupts haven't been enabled = yet. Now that we enable interrupts earlier, I think this has become = 'Giant has to be held'. That's one reason I rarely use device_busy and prefer to use other = methods of blocking unload and early entrance to cdevsw in drivers I've = written that I care about these cases. Warner= From owner-freebsd-current@FreeBSD.ORG Mon Apr 9 14:31:47 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F779106564A; Mon, 9 Apr 2012 14:31:47 +0000 (UTC) (envelope-from kwhite@site.uottawa.ca) Received: from courriel.site.uottawa.ca (eecsmail.engineering.uottawa.ca [137.122.24.224]) by mx1.freebsd.org (Postfix) with ESMTP id 164418FC17; Mon, 9 Apr 2012 14:31:46 +0000 (UTC) Received: from courriel.site.uottawa.ca (localhost [127.0.0.1]) by courriel.site.uottawa.ca (8.14.4/8.14.4) with ESMTP id q39EVdme023402; Mon, 9 Apr 2012 10:31:39 -0400 (EDT) (envelope-from kwhite@site.uottawa.ca) Received: from 74.51.53.177 (SquirrelMail authenticated user kwhite) by courriel.site.uottawa.ca with HTTP; Mon, 9 Apr 2012 10:31:39 -0400 (EDT) Message-ID: <14043.74.51.53.177.1333981899.squirrel@courriel.site.uottawa.ca> In-Reply-To: <20120408221127.969e8e71.daichi@freebsd.org> References: <55056.74.51.53.177.1333762589.squirrel@courriel.site.uottawa.ca> <20120408221127.969e8e71.daichi@freebsd.org> Date: Mon, 9 Apr 2012 10:31:39 -0400 (EDT) From: kwhite@site.uottawa.ca To: "Daichi GOTO" User-Agent: SquirrelMail/1.4.5 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mailman-Approved-At: Mon, 09 Apr 2012 16:24:29 +0000 Cc: kwhite@site.uottawa.ca, freebsd-current@freebsd.org Subject: Re: (unionfs) panic: excl->share with r230341 and above X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 14:31:47 -0000 > Hi > > Please try an attached patch that improves handlings of fs locks. > I think that this patch can resolve this issue. If that works well, > I'm going to refine and commit it to head. > Thanks! I tried your patch but get the same panic: FreeBSD 10.0-CURRENT #6 r233856M: Mon Apr 9 09:47:42 EDT 2012 ... exclusive lock of (lockmgr) ufs @ /usr/src/sys/modules/unionfs/../../fs/unionfs/union_vnops.c:1897 while share locked from /usr/src/sys/modules/unionfs/../../fs/unionfs/ union_vnops.c:1897 panic: excl->share cpuid = 0 KDB: enter: panic [ thread pid 38 tid 100050 ] Stopped at kdb_enter+0x3b: movl $0,kdb_why db> show all locks Process 38 (ls) thread 0xc56dd2e0 (100050) exclusive sleep mutex vnode interlock (vnode interlock) r = 0 (0xc5797d38) locked @ /usr/src/sys/modules/unionfs/../../fs/unionfs/union_vnops.c:1889 shared lockmgr ufs (ufs) r = 0 (0xc5797d18) locked @ /usr/src/sys/modules/unionfs/../../fs/unionfs/union_vnops.c:1897 db> > On Fri, 6 Apr 2012 21:36:29 -0400 (EDT) > kwhite@site.uottawa.ca wrote: >> Starting with r230341, I get the following panic when trying to run >> an executable on a unionfs filesystem: >> >> exclusive lock of (lockmgr) ufs @ >> /usr/src/sys/modules/unionfs/../../fs/unionfs/union_vnops.c:1843 >> while share locked from >> /usr/src/sys/modules/unionfs/../../fs/unionfs/union_vnops.c:1843 >> panic: excl->share >> cpuid = 0 >> KDB: enter: panic >> >> Narrowing down with a binary search: r230340 (no panic), r230341 >> (panic). >> >> How to repeat: >> # uuname -a >> FreeBSD 10.0-CURRENT FreeBSD 10.0-CURRENT #5 r233946M: Fri Apr >> 6 >> 21:09:32 EDT 2012 kwhite@demo:/usr/src/obj/usr/src/sys/GENERIC >> i386 >> >> # mkdir /tmp/local >> # mount -t unionfs -o noatime /tmp/local /usr/local >> # cp /bin/ls /usr/local/bin/ls >> # /usr/local/bin/ls >> .... >> exclusive lock of (lockmgr) ufs @ >> /usr/src/sys/modules/unionfs/../../fs/unionfs/union_vnops.c:1843 >> while share locked from >> /usr/src/sys/modules/unionfs/../../fs/unionfs/union_vnops.c:1843 >> panic: excl->share >> cpuid = 0 >> KDB: enter: panic >> [ thread pid 68 tid 100054 ] >> Stopped at kdb_enter+0x3b: movl $0,kdb_why >> db> show all locks >> Process 68 (ls) thread 0xc5780000 (100054) >> exclusive sleep mutex vnode interlock (vnode interlock) r = 0 >> (0xc57cec28) locked @ >> /usr/src/sys/modules/unionfs/../../fs/unionfs/union_vnops.c:1835 >> shared lockmgr ufs (ufs) r = 0 (0xc57cec08) locked @ >> /usr/src/sys/modules/unionfs/../../fs/unionfs/union_vnops.c:1843 >> db> >> >> Workaround? >> After reverting the change from LK_EXCLUSIVE to LK_SHARED >> in sys/kern/kern_exec.c, executables on union filesystems no >> longer cause a panic. >> >> ...keith >> >> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to >> "freebsd-current-unsubscribe@freebsd.org" > > > -- > Daichi GOTO (daichi) > FreeBSD Committer, http://www.FreeBSD.org The Power To Serve > From owner-freebsd-current@FreeBSD.ORG Mon Apr 9 16:07:38 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 631AE106566C for ; Mon, 9 Apr 2012 16:07:38 +0000 (UTC) (envelope-from vidwer@gmail.com) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx1.freebsd.org (Postfix) with ESMTP id 3BF008FC08 for ; Mon, 9 Apr 2012 16:07:38 +0000 (UTC) Received: by dadz14 with SMTP id z14so18606895dad.17 for ; Mon, 09 Apr 2012 09:07:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=emmZgploHsttajzwpZq7idv00WpDv/ARY2CUuuj8ps0=; b=PbCBeOGTQ1Ljv+HHDzNBUkdIGzOp0DfGFuGsRtqYRBezpV7kGdMGnSk1Do/5V0cW9A k7OYHh/8ZvcdrviREgzeb4rYLLya7vnlXc5PssrTz0pnGGzsWBqw6/Q7XAC2Mm9neMXs 1mfmKcWEmFbT/UrTJ+anXS7tt4h315z8ojRM8OKXrN/QUrUu5XJF8AOpghCLenBoZYKS /5zBFeHy9tLQZH5tsiRzg+wRJsItRmbAlOnQoNXi5+Lxe8COeBNyYy+HP7jeDrNrWwhP Zk95Ze4Ed+sQ0kJNEcb26bTcCn0Kdr9+FHQnQyWNY9i/2R4Z0JNwSjBHpei5KYhBO4sd 1meg== MIME-Version: 1.0 Received: by 10.68.201.169 with SMTP id kb9mr20284421pbc.146.1333987657814; Mon, 09 Apr 2012 09:07:37 -0700 (PDT) Received: by 10.68.4.198 with HTTP; Mon, 9 Apr 2012 09:07:37 -0700 (PDT) Date: Mon, 9 Apr 2012 18:07:37 +0200 Message-ID: From: Idwer Vollering To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Mon, 09 Apr 2012 16:38:52 +0000 Subject: Re: r234000: i386 freeze when HT enabled X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 16:07:38 -0000 Reverting to r233960 works for me. From owner-freebsd-current@FreeBSD.ORG Mon Apr 9 18:58:36 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6A482106564A for ; Mon, 9 Apr 2012 18:58:36 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from nm22.bullet.mail.bf1.yahoo.com (nm22.bullet.mail.bf1.yahoo.com [98.139.212.181]) by mx1.freebsd.org (Postfix) with SMTP id 1BA878FC0A for ; Mon, 9 Apr 2012 18:58:36 +0000 (UTC) Received: from [98.139.212.150] by nm22.bullet.mail.bf1.yahoo.com with NNFMP; 09 Apr 2012 18:58:28 -0000 Received: from [98.139.213.10] by tm7.bullet.mail.bf1.yahoo.com with NNFMP; 09 Apr 2012 18:58:28 -0000 Received: from [127.0.0.1] by smtp110.mail.bf1.yahoo.com with NNFMP; 09 Apr 2012 18:58:28 -0000 X-Yahoo-Newman-Id: 939099.63958.bm@smtp110.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: kcova7oVM1medNqL8P3_bpXB8I9KFdQNgGBHO6uOU4Zbdib MjWi3s9YFoeoid7teBG427nI.idzSR_b5SvYYt8F0pD_nIYq5e0HY4VNRKmf yyKSZTfkkO8sTaRVMw.gy7huWBYdNlPm0d4F2udB0kj_zzklzszWo.VB0P3W REFoNqJfBVfBUuqrr3c_oF8GHwL9fjjB5JOvWTvBd5xK6vn27lZJdb2iB0CK GnX6GUQlQntSYqCZKgbpB72jfN7EOCvTmfJKuXpvJDBI6YIRF3U9wn6MEmPC Ksdx6XaAtzMdbR.Tk.xKhKIFj5q0UjgPi0GzWSnZ6trhBXOYN3zW.8TJFYuo 8V8LCQbi19Fh0iavasBIc0ZI9kyqagRN.YUR4ta22De_EjHmOPOFeivmNaTk GOwHSwy7sHaF4w2OlHTe_TmCG2cf7tAS92dK6UDmZK15C67hfgMPaaFt2iL7 2kHTW7SwpKyBy3omSooZfiO30UBMmpm4Mo_U5bmBccuP6Jtr7DvGJSYfLht4 BXf076JQTZCzM2L6Oulyo7J3VVSdERQf_6YNWmxOK5cuGLE0bUA-- X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf Received: from [192.168.10.106] (pfg@200.118.157.7 with plain) by smtp110.mail.bf1.yahoo.com with SMTP; 09 Apr 2012 11:58:28 -0700 PDT Message-ID: <4F833153.9050603@FreeBSD.org> Date: Mon, 09 Apr 2012 13:58:27 -0500 From: Pedro Giffuni User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.2) Gecko/20120226 Thunderbird/10.0.2 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: [CFT]: libedit update (NetBSD CVS 2009-12-28) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 18:58:36 -0000 Hi; I noticed that libedit is seriously outdated so I tried to sync it with the upstream (NetBSD) tree. For the time being I avoided the international support and related changes since they move some files and, in general, complicates getting things merged properly. The resulting patch is here: http://people.freebsd.org/~pfg/patches/patch-libedit-cvs20091228 With this update GNU readline support should work better and we will be more in line with what is shipped in both NetBSD and Darwin. I also submitted some of our changes upstream but some things like file completion and the code in tty.c have diverged on NetBSD. Please do let me know if there is anything strange. I think for the next update we may probably just merge the vendor branch directly. best regards, Pedro. From owner-freebsd-current@FreeBSD.ORG Mon Apr 9 19:10:14 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CEE6E106564A; Mon, 9 Apr 2012 19:10:14 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 0EC598FC08; Mon, 9 Apr 2012 19:10:13 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q39JA2Zj015198; Mon, 9 Apr 2012 22:10:02 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q39JA1SR051583; Mon, 9 Apr 2012 22:10:01 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q39JA0mH051582; Mon, 9 Apr 2012 22:10:01 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 9 Apr 2012 22:10:00 +0300 From: Konstantin Belousov To: John Baldwin Message-ID: <20120409191000.GS2358@deviant.kiev.zoral.com.ua> References: <20120407125056.GS2358@deviant.kiev.zoral.com.ua> <1333810001.1082.36.camel@revolution.hippie.lan> <7C5089DC-AB9B-458F-A606-B432505BD961@bsdimp.com> <201204091101.03956.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pC/tHwOGf8AW2ISZ" Content-Disposition: inline In-Reply-To: <201204091101.03956.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Ian Lepore , drivers@freebsd.org, freebsd-drivers@freebsd.org, current@freebsd.org Subject: Re: device_attach(9) and driver initialization X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 19:10:14 -0000 --pC/tHwOGf8AW2ISZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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: > >=20 > > On Apr 7, 2012, at 8:46 AM, Ian Lepore wrote: > >=20 > > > 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= =20 > newbus. > > >> Basically, when device attach method is executing, device is not ful= ly > > >> initialized yet. Also the device state in the newbus part of the wor= ld > > >> is DS_ALIVE. There is definitely no shattering news in the statement= s, > > >> but drivers that e.g. create devfs node to communicate with consumers > > >> are prone to a race. > > >>=20 > > >> If /dev node is created inside device attach method, then usermode > > >> can start calling cdevsw methods before device fully initialized its= elf. > > >> 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. > > >>=20 > > >> 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 b= elow. > > >>=20 > > >> 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 { > > >> }; > > >>=20 > > >> /** > > >> + * @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 expo= se > > >> + * 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 =3D DS_ATTACHED; > > >> dev->flags &=3D ~DF_DONENOMATCH; > > >> devadded(dev); > > >> + DEVICE_AFTER_ATTACH(dev); > > >> return (0); > > >> } > > >>=20 > > >=20 > > > Does device_get_softc() work before attach is completed? (I don't ha= ve > > > time to go look in the code right now). If so, then a mutex initiali= zed > > > 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 with= out > > > a driver api change that would make it harder to backport/MFC driver > > > changes. > >=20 > > Also, more generally, don't create the dev nodes before you are ready t= o=20 > deal with requests. Why do we need to uglify everything here? If you ca= n't=20 > do that, you can check a bit in the softc and return EBUSY or ENXIO on op= en if=20 > that bit says that your driver isn't ready to accept requests. >=20 > I agree, this dosen't actually fix anything as the decision for what to p= ut > in your foo_attach() method rather than foo_after_attach() is non-obvious= and=20 > very arbitrary. >=20 > The actual bug appears to only be with using 'device_busy()'. I think > this should be fixed by making device_busy() better, not by adding > this type of obfuscation to attach. It should be trivial to make > device_busy() safe to use on a device that is currently being attached > which will not require any changes to drivers. Could you, please, elaborate your proposal ? How do you think device_busy() can be enchanced ? Obvious idea to sleep inside device_busy() until dev->state becomes !=3D DS_ATTACHED is no go, IMO. The issue is that this causes immediate deadlocks if device_attach() method needs to call destroy_dev() to rollback. Pointing driver authors to destroy_dev_sched() for this purpose is overkill, since average driver author, me included, could not use destroy_dev_sched() properly, at least without lot of works. --pC/tHwOGf8AW2ISZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk+DNAgACgkQC3+MBN1Mb4iFywCg7rSjfbyQaBeVRxgyn5c23OJf tSQAn1RNLlJnVXxklIrOxfJrXFaiSyk7 =I1pD -----END PGP SIGNATURE----- --pC/tHwOGf8AW2ISZ-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 9 19:36:09 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B37C8106566C; Mon, 9 Apr 2012 19:36:09 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 75A368FC0A; Mon, 9 Apr 2012 19:36:09 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E25FDB95F; Mon, 9 Apr 2012 15:36:08 -0400 (EDT) From: John Baldwin To: Konstantin Belousov Date: Mon, 9 Apr 2012 15:36:08 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <20120407125056.GS2358@deviant.kiev.zoral.com.ua> <201204091101.03956.jhb@freebsd.org> <20120409191000.GS2358@deviant.kiev.zoral.com.ua> In-Reply-To: <20120409191000.GS2358@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201204091536.08399.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 09 Apr 2012 15:36:09 -0400 (EDT) Cc: Ian Lepore , freebsd-drivers@freebsd.org, current@freebsd.org Subject: Re: device_attach(9) and driver initialization X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 19:36:09 -0000 On Monday, April 09, 2012 3:10:00 pm Konstantin Belousov wrote: > On Mon, Apr 09, 2012 at 11:01:03AM -0400, John Baldwin wrote: > > On Saturday, April 07, 2012 11:08:41 pm Warner Losh wrote: > > > > > > On Apr 7, 2012, at 8:46 AM, Ian Lepore wrote: > > > > > > > On Sat, 2012-04-07 at 15:50 +0300, Konstantin Belousov wrote: > > > >> Hello, > > > >> there seems to be a problem with device attach sequence offered by > > newbus. > > > >> Basically, when device attach method is executing, device is not fully > > > >> initialized yet. Also the device state in the newbus part of the world > > > >> is DS_ALIVE. There is definitely no shattering news in the statements, > > > >> but drivers that e.g. create devfs node to communicate with consumers > > > >> are prone to a race. > > > >> > > > >> If /dev node is created inside device attach method, then usermode > > > >> can start calling cdevsw methods before device fully initialized itself. > > > >> Even more, if device tries to use newbus helpers in cdevsw methods, > > > >> like device_busy(9), then panic occurs "called for unatteched device". > > > >> I get reports from users about this issues, to it is not something > > > >> that only could happen. > > > >> > > > >> I propose to add DEVICE_AFTER_ATTACH() driver method, to be called > > > >> from newbus right after device attach finished and newbus considers > > > >> the device fully initialized. Driver then could create devfs node > > > >> in the after_attach method instead of attach. Please see the patch below. > > > >> > > > >> diff --git a/sys/kern/device_if.m b/sys/kern/device_if.m > > > >> index eb720eb..9db74e2 100644 > > > >> --- a/sys/kern/device_if.m > > > >> +++ b/sys/kern/device_if.m > > > >> @@ -43,6 +43,10 @@ INTERFACE device; > > > >> # Default implementations of some methods. > > > >> # > > > >> CODE { > > > >> + static void null_after_attach(device_t dev) > > > >> + { > > > >> + } > > > >> + > > > >> static int null_shutdown(device_t dev) > > > >> { > > > >> return 0; > > > >> @@ -199,6 +203,21 @@ METHOD int attach { > > > >> }; > > > >> > > > >> /** > > > >> + * @brief Notify the driver that device is in attached state > > > >> + * > > > >> + * Called after driver is successfully attached to the device and > > > >> + * corresponding device_t is fully operational. Driver now may expose > > > >> + * the device to the consumers, e.g. create devfs nodes. > > > >> + * > > > >> + * @param dev the device to probe > > > >> + * > > > >> + * @see DEVICE_ATTACH() > > > >> + */ > > > >> +METHOD void after_attach { > > > >> + device_t dev; > > > >> +} DEFAULT null_after_attach; > > > >> + > > > >> +/** > > > >> * @brief Detach a driver from a device. > > > >> * > > > >> * This can be called if the user is replacing the > > > >> diff --git a/sys/kern/subr_bus.c b/sys/kern/subr_bus.c > > > >> index d485b9f..6d849cb 100644 > > > >> --- a/sys/kern/subr_bus.c > > > >> +++ b/sys/kern/subr_bus.c > > > >> @@ -2743,6 +2743,7 @@ device_attach(device_t dev) > > > >> dev->state = DS_ATTACHED; > > > >> dev->flags &= ~DF_DONENOMATCH; > > > >> devadded(dev); > > > >> + DEVICE_AFTER_ATTACH(dev); > > > >> return (0); > > > >> } > > > >> > > > > > > > > Does device_get_softc() work before attach is completed? (I don't have > > > > time to go look in the code right now). If so, then a mutex initialized > > > > and acquired early in the driver's attach routine, and also acquired in > > > > the driver's cdev implementation routines before using any newbus > > > > functions other than device_get_softc(), would solve the problem without > > > > a driver api change that would make it harder to backport/MFC driver > > > > changes. > > > > > > Also, more generally, don't create the dev nodes before you are ready to > > deal with requests. Why do we need to uglify everything here? If you can't > > do that, you can check a bit in the softc and return EBUSY or ENXIO on open if > > that bit says that your driver isn't ready to accept requests. > > > > I agree, this dosen't actually fix anything as the decision for what to put > > in your foo_attach() method rather than foo_after_attach() is non-obvious and > > very arbitrary. > > > > The actual bug appears to only be with using 'device_busy()'. I think > > this should be fixed by making device_busy() better, not by adding > > this type of obfuscation to attach. It should be trivial to make > > device_busy() safe to use on a device that is currently being attached > > which will not require any changes to drivers. > > Could you, please, elaborate your proposal ? How do you think device_busy() > can be enchanced ? > > Obvious idea to sleep inside device_busy() until dev->state becomes != > DS_ATTACHED is no go, IMO. The issue is that this causes immediate deadlocks > if device_attach() method needs to call destroy_dev() to rollback. I think you could have a DS_ATTACHING state and allow device_busy() to work for DS_ATTACHING. The idea being that it is a bug for a driver to invoke device_busy() if it is going to fail attach. You may then need to do a fixup in device_attach() to promote the state from DS_ATTACHED to DS_BUSY when it returns if there is a non-zero busy count. Something like this: Index: kern/subr_bus.c =================================================================== --- kern/subr_bus.c (revision 234057) +++ kern/subr_bus.c (working copy) @@ -2472,12 +2472,13 @@ void device_busy(device_t dev) { - if (dev->state < DS_ATTACHED) + if (dev->state < DS_ATTACHING) panic("device_busy: called for unattached device"); if (dev->busy == 0 && dev->parent) device_busy(dev->parent); dev->busy++; - dev->state = DS_BUSY; + if (dev->state == DS_ATTACHED) + dev->state = DS_BUSY; } /** @@ -2486,14 +2487,16 @@ void device_unbusy(device_t dev) { - if (dev->state != DS_BUSY) + if (dev->busy != 0 && dev->state != DS_BUSY && + dev->state != DS_ATTACHING) panic("device_unbusy: called for non-busy device %s", device_get_nameunit(dev)); dev->busy--; if (dev->busy == 0) { if (dev->parent) device_unbusy(dev->parent); - dev->state = DS_ATTACHED; + if (dev->state == DS_BUSY) + dev->state = DS_ATTACHED; } } @@ -2729,6 +2732,7 @@ device_sysctl_init(dev); if (!device_is_quiet(dev)) device_print_child(dev->parent, dev); + dev->state = DS_ATTACHING; if ((error = DEVICE_ATTACH(dev)) != 0) { printf("device_attach: %s%d attach returned %d\n", dev->driver->name, dev->unit, error); @@ -2736,11 +2740,15 @@ devclass_delete_device(dev->devclass, dev); (void)device_set_driver(dev, NULL); device_sysctl_fini(dev); + KASSERT(dev->busy == 0, ("attach failed but busy")); dev->state = DS_NOTPRESENT; return (error); } device_sysctl_update(dev); - dev->state = DS_ATTACHED; + if (dev->busy) + dev->state = DS_BUSY; + else + dev->state = DS_ATTACHED; dev->flags &= ~DF_DONENOMATCH; devadded(dev); return (0); Index: sys/bus.h =================================================================== --- sys/bus.h (revision 234057) +++ sys/bus.h (working copy) @@ -52,6 +52,7 @@ typedef enum device_state { DS_NOTPRESENT = 10, /**< @brief not probed or probe failed */ DS_ALIVE = 20, /**< @brief probe succeeded */ + DS_ATTACHING = 25, /**< @brief currently attaching */ DS_ATTACHED = 30, /**< @brief attach method called */ DS_BUSY = 40 /**< @brief device is open */ } device_state_t; -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Apr 9 19:57:55 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 558E2106564A; Mon, 9 Apr 2012 19:57:55 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by mx1.freebsd.org (Postfix) with ESMTP id 4DF9D8FC1A; Mon, 9 Apr 2012 19:57:54 +0000 (UTC) Received: by wibhq7 with SMTP id hq7so2376372wib.13 for ; Mon, 09 Apr 2012 12:57:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=+IC9CNuGZVF2mumVmoZ1bSYKcoJNFcVTU4eVVZXzD5o=; b=kvryoOnAepCtahugH1FM/pLQ2jOnWfgEcumc+bSSIM6fk5cPOyLI5u8NvfomJNInZ8 T7D9PT/WteQkb7STKQoqO3OzVV06c8ynSBEm5GcxEdLQ/a2cK6rACaptv6zlWDPrJSgm E40i375AgDICu9jhDhhxZMZYqrE0n8K3VFjLJBHuHFJp0SgxZ3kK6ER9Di2EXnligbiI 5dHACBxAQiO+6oDbx8nMzfAz9XGzxULGHXUIsHenGACR+j+iUA2YLpw0kNStgTlzn3Fr j792cqmCH3tLCDlau+v0/O3DUOc6hR6N7458vx8R6V2maR6PMRfQabrokySEnT0M207S K9jQ== Received: by 10.180.92.228 with SMTP id cp4mr694239wib.2.1334001472964; Mon, 09 Apr 2012 12:57:52 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id h8sm52635643wix.4.2012.04.09.12.57.50 (version=SSLv3 cipher=OTHER); Mon, 09 Apr 2012 12:57:51 -0700 (PDT) Sender: Alexander Motin Message-ID: <4F833F3D.7070106@FreeBSD.org> Date: Mon, 09 Apr 2012 22:57:49 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.2) Gecko/20120226 Thunderbird/10.0.2 MIME-Version: 1.0 To: Arnaud Lacombe References: <4F2F7B7F.40508@FreeBSD.org> <4F366E8F.9060207@FreeBSD.org> <4F367965.6000602@FreeBSD.org> <4F396B24.5090602@FreeBSD.org> <4F3978BC.6090608@FreeBSD.org> <4F3990EA.1080002@FreeBSD.org> <4F3C0BB9.6050101@FreeBSD.org> <4F3E807A.60103@FreeBSD.org> <4F3E8858.4000001@FreeBSD.org> <4F7DE863.6080607@FreeBSD.org> In-Reply-To: <4F7DE863.6080607@FreeBSD.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Jeff Roberson , Andriy Gapon , FreeBSD current Subject: Re: [RFT][patch] Scheduling for HTT and not only X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 19:57:55 -0000 On 04/05/12 21:45, Alexander Motin wrote: > On 05.04.2012 21:12, Arnaud Lacombe wrote: >> Hi, >> >> [Sorry for the delay, I got a bit sidetrack'ed...] >> >> 2012/2/17 Alexander Motin: >>> On 17.02.2012 18:53, Arnaud Lacombe wrote: >>>> >>>> On Fri, Feb 17, 2012 at 11:29 AM, Alexander Motin >>>> wrote: >>>>> >>>>> On 02/15/12 21:54, Jeff Roberson wrote: >>>>>> >>>>>> On Wed, 15 Feb 2012, Alexander Motin wrote: >>>>>>> >>>>>>> I've decided to stop those cache black magic practices and focus on >>>>>>> things that really exist in this world -- SMT and CPU load. I've >>>>>>> dropped most of cache related things from the patch and made the >>>>>>> rest >>>>>>> of things more strict and predictable: >>>>>>> http://people.freebsd.org/~mav/sched.htt34.patch >>>>>> >>>>>> >>>>>> This looks great. I think there is value in considering the other >>>>>> approach further but I would like to do this part first. It would be >>>>>> nice to also add priority as a greater influence in the load >>>>>> balancing >>>>>> as well. >>>>> >>>>> >>>>> I haven't got good idea yet about balancing priorities, but I've >>>>> rewritten >>>>> balancer itself. As soon as sched_lowest() / sched_highest() are more >>>>> intelligent now, they allowed to remove topology traversing from the >>>>> balancer itself. That should fix double-swapping problem, allow to >>>>> keep >>>>> some >>>>> affinity while moving threads and make balancing more fair. I did >>>>> number >>>>> of >>>>> tests running 4, 8, 9 and 16 CPU-bound threads on 8 CPUs. With 4, 8 >>>>> and >>>>> 16 >>>>> threads everything is stationary as it should. With 9 threads I see >>>>> regular >>>>> and random load move between all 8 CPUs. Measurements on 5 minutes run >>>>> show >>>>> deviation of only about 5 seconds. It is the same deviation as I see >>>>> caused >>>>> by only scheduling of 16 threads on 8 cores without any balancing >>>>> needed >>>>> at >>>>> all. So I believe this code works as it should. >>>>> >>>>> Here is the patch: http://people.freebsd.org/~mav/sched.htt40.patch >>>>> >>>>> I plan this to be a final patch of this series (more to come :)) >>>>> and if >>>>> there will be no problems or objections, I am going to commit it >>>>> (except >>>>> some debugging KTRs) in about ten days. So now it's a good time for >>>>> reviews >>>>> and testing. :) >>>>> >>>> is there a place where all the patches are available ? >>> >>> >>> All my scheduler patches are cumulative, so all you need is only the >>> last >>> mentioned here sched.htt40.patch. >>> >> You may want to have a look to the result I collected in the >> `runs/freebsd-experiments' branch of: >> >> https://github.com/lacombar/hackbench/ >> >> and compare them with vanilla FreeBSD 9.0 and -CURRENT results >> available in `runs/freebsd'. On the dual package platform, your patch >> is not a definite win. >> >>> But in some cases, especially for multi-socket systems, to let it >>> show its >>> best, you may want to apply additional patch from avg@ to better >>> detect CPU >>> topology: >>> https://gitorious.org/~avg/freebsd/avgbsd/commit/6bca4a2e4854ea3fc275946a023db65c483cb9dd >>> >>> >> test I conducted specifically for this patch did not showed much >> improvement... > > If I understand right, this test runs thousands of threads sending and > receiving data over the pipes. It is quite likely that all CPUs will be > always busy and so load balancing is not really important in this test, > What looks good is that more complicated new code is not slower then old > one. > > While this test seems very scheduler-intensive, it may depend on many > other factors, such as syscall performance, context switch, etc. I'll > try to play more with it. My profiling on 8-core Core i7 system shows that code from sched_ule.c staying on first places consumes still only 13% of kernel CPU time, while doing million of context switches per second. cpu_search(), affected by this patch, even less -- only 8%. The rest of time is spread between many small other functions. I did some optimizations at r234066 to reduce cpu_search(0 time to 6%, but looking on how unstable results of this test are, hardly any difference there can be really measured by it. 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. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Mon Apr 9 20:05:40 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 35A66106564A; Mon, 9 Apr 2012 20:05:40 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 7C8F28FC15; Mon, 9 Apr 2012 20:05:39 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q39K5Uw3026896; Mon, 9 Apr 2012 23:05:30 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q39K5Tpn051849; Mon, 9 Apr 2012 23:05:29 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q39K5Tc4051848; Mon, 9 Apr 2012 23:05:29 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 9 Apr 2012 23:05:29 +0300 From: Konstantin Belousov To: John Baldwin Message-ID: <20120409200529.GT2358@deviant.kiev.zoral.com.ua> References: <20120407125056.GS2358@deviant.kiev.zoral.com.ua> <201204091101.03956.jhb@freebsd.org> <20120409191000.GS2358@deviant.kiev.zoral.com.ua> <201204091536.08399.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3e+tHtSlmys++yUp" Content-Disposition: inline In-Reply-To: <201204091536.08399.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Ian Lepore , freebsd-drivers@freebsd.org, current@freebsd.org Subject: Re: device_attach(9) and driver initialization X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 20:05:40 -0000 --3e+tHtSlmys++yUp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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: > > > >=20 > > > > On Apr 7, 2012, at 8:46 AM, Ian Lepore wrote: > > > >=20 > > > > > 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=20 > > > 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 state= ments, > > > > >> but drivers that e.g. create devfs node to communicate with cons= umers > > > > >> are prone to a race. > > > > >>=20 > > > > >> If /dev node is created inside device attach method, then usermo= de > > > > >> can start calling cdevsw methods before device fully initialized= itself. > > > > >> Even more, if device tries to use newbus helpers in cdevsw metho= ds, > > > > >> like device_busy(9), then panic occurs "called for unatteched de= vice". > > > > >> I get reports from users about this issues, to it is not somethi= ng > > > > >> that only could happen. > > > > >>=20 > > > > >> I propose to add DEVICE_AFTER_ATTACH() driver method, to be call= ed > > > > >> from newbus right after device attach finished and newbus consid= ers > > > > >> the device fully initialized. Driver then could create devfs node > > > > >> in the after_attach method instead of attach. Please see the pat= ch below. > > > > >>=20 > > > > >> 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 { > > > > >> }; > > > > >>=20 > > > > >> /** > > > > >> + * @brief Notify the driver that device is in attached state > > > > >> + * > > > > >> + * Called after driver is successfully attached to the device a= nd > > > > >> + * 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 =3D DS_ATTACHED; > > > > >> dev->flags &=3D ~DF_DONENOMATCH; > > > > >> devadded(dev); > > > > >> + DEVICE_AFTER_ATTACH(dev); > > > > >> return (0); > > > > >> } > > > > >>=20 > > > > >=20 > > > > > 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 init= ialized > > > > > and acquired early in the driver's attach routine, and also acqui= red 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 dri= ver > > > > > changes. > > > >=20 > > > > Also, more generally, don't create the dev nodes before you are rea= dy to=20 > > > deal with requests. Why do we need to uglify everything here? If yo= u can't=20 > > > do that, you can check a bit in the softc and return EBUSY or ENXIO o= n open if=20 > > > that bit says that your driver isn't ready to accept requests. > > >=20 > > > 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-obv= ious and=20 > > > very arbitrary. > > >=20 > > > The actual bug appears to only be with using 'device_busy()'. I think > > > this should be fixed by making device_busy() better, not by adding > > > this type of obfuscation to attach. It should be trivial to make > > > device_busy() safe to use on a device that is currently being attached > > > which will not require any changes to drivers. > >=20 > > Could you, please, elaborate your proposal ? How do you think device_bu= sy() > > can be enchanced ? > >=20 > > Obvious idea to sleep inside device_busy() until dev->state becomes !=3D > > DS_ATTACHED is no go, IMO. The issue is that this causes immediate dead= locks > > if device_attach() method needs to call destroy_dev() to rollback. >=20 > I think you could have a DS_ATTACHING state and allow device_busy() to wo= rk > for DS_ATTACHING. The idea being that it is a bug for a driver to invoke > device_busy() if it is going to fail attach. You may then need to do a f= ixup > in device_attach() to promote the state from DS_ATTACHED to DS_BUSY when = it > returns if there is a non-zero busy count. This is quite good idea, but it still adds burden to device author, although I agree that this is manageable. A scenario I have in mind now is the following: assume that driver needs to create two devfs nodes, lets name them dri/card0 and dri/forcewake0. Driver would perform two make_dev_p(9) calls, and while creation of dri/card0 succeed, consequent creation of dri/forcewake0 could fail for numerous reasons. Now, the driver needs to ensure that cdesvw->d_open() on dri/card0 would return ENXIO until dri/forcewake0 is created. This can be implemented with flag, indeed. But still somewhat muddy, and probably leads to user-visible errors (I mostly worry about graphical login managers). But for single-node drivers it is indeed a nice solution. >=20 > Something like this: >=20 > Index: kern/subr_bus.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- kern/subr_bus.c (revision 234057) > +++ kern/subr_bus.c (working copy) > @@ -2472,12 +2472,13 @@ > void > device_busy(device_t dev) > { > - if (dev->state < DS_ATTACHED) > + if (dev->state < DS_ATTACHING) > panic("device_busy: called for unattached device"); > if (dev->busy =3D=3D 0 && dev->parent) > device_busy(dev->parent); > dev->busy++; > - dev->state =3D DS_BUSY; > + if (dev->state =3D=3D DS_ATTACHED) > + dev->state =3D DS_BUSY; > } > =20 > /** > @@ -2486,14 +2487,16 @@ > void > device_unbusy(device_t dev) > { > - if (dev->state !=3D DS_BUSY) > + if (dev->busy !=3D 0 && dev->state !=3D DS_BUSY && > + dev->state !=3D DS_ATTACHING) > panic("device_unbusy: called for non-busy device %s", > device_get_nameunit(dev)); > dev->busy--; > if (dev->busy =3D=3D 0) { > if (dev->parent) > device_unbusy(dev->parent); > - dev->state =3D DS_ATTACHED; > + if (dev->state =3D=3D DS_BUSY) > + dev->state =3D DS_ATTACHED; > } > } > =20 > @@ -2729,6 +2732,7 @@ > device_sysctl_init(dev); > if (!device_is_quiet(dev)) > device_print_child(dev->parent, dev); > + dev->state =3D DS_ATTACHING; > if ((error =3D DEVICE_ATTACH(dev)) !=3D 0) { > printf("device_attach: %s%d attach returned %d\n", > dev->driver->name, dev->unit, error); > @@ -2736,11 +2740,15 @@ > devclass_delete_device(dev->devclass, dev); > (void)device_set_driver(dev, NULL); > device_sysctl_fini(dev); > + KASSERT(dev->busy =3D=3D 0, ("attach failed but busy")); > dev->state =3D DS_NOTPRESENT; > return (error); > } > device_sysctl_update(dev); > - dev->state =3D DS_ATTACHED; > + if (dev->busy) > + dev->state =3D DS_BUSY; > + else > + dev->state =3D DS_ATTACHED; > dev->flags &=3D ~DF_DONENOMATCH; > devadded(dev); > return (0); > Index: sys/bus.h > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/bus.h (revision 234057) > +++ sys/bus.h (working copy) > @@ -52,6 +52,7 @@ > typedef enum device_state { > DS_NOTPRESENT =3D 10, /**< @brief not probed or probe failed */ > DS_ALIVE =3D 20, /**< @brief probe succeeded */ > + DS_ATTACHING =3D 25, /**< @brief currently attaching */ > DS_ATTACHED =3D 30, /**< @brief attach method called */ > DS_BUSY =3D 40 /**< @brief device is open */ > } device_state_t; >=20 > --=20 > John Baldwin --3e+tHtSlmys++yUp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk+DQQkACgkQC3+MBN1Mb4gq+wCgmVOauphI9rfoDe0vN+/yPiK1 XH4An2S95rMdXjh59SBwTNiu64r1fvQO =Sjwn -----END PGP SIGNATURE----- --3e+tHtSlmys++yUp-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 9 20:50:55 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6CE53106566B for ; Mon, 9 Apr 2012 20:50:55 +0000 (UTC) (envelope-from emaste@freebsd.org) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by mx1.freebsd.org (Postfix) with ESMTP id 16EB78FC14 for ; Mon, 9 Apr 2012 20:50:55 +0000 (UTC) Received: from labgw2.phaedrus.sandvine.com (192.168.222.22) by WTL-EXCH-1.sandvine.com (192.168.196.31) with Microsoft SMTP Server id 14.1.339.1; Mon, 9 Apr 2012 16:50:54 -0400 Received: by labgw2.phaedrus.sandvine.com (Postfix, from userid 10332) id E088D33C02; Mon, 9 Apr 2012 16:50:51 -0400 (EDT) Date: Mon, 9 Apr 2012 16:50:51 -0400 From: Ed Maste To: Message-ID: <20120409205051.GA27392@sandvine.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="NDin8bjvE/0mNLFQ" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: [PATCH] percent-encoding for libfetch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 20:50:55 -0000 --NDin8bjvE/0mNLFQ Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Libfetch supports a username and password in a FTP or HTTP URL, but lacks a method to specify '@' or ':' there, as they're used as URL component separators. I discovered this issue because I have an FTP server that uses an email address as the username, and I can't use fetch(1) or libfetch against it. The attached patch adds decoding of percent-encoded usernames and passwords, in order to use a URL like ftp://foo%40example.com:password@host:port/file.bar . Please review. I plan to commit in the next few days. -Ed --NDin8bjvE/0mNLFQ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="fetch.diff" Index: fetch.c =================================================================== --- fetch.c (revision 233584) +++ fetch.c (working copy) @@ -289,6 +289,49 @@ } /* + * Return value of the given hex digit. + */ +static int +fetch_hexval(char ch) +{ + + if (ch >= '0' && ch <= '9') + return (ch - '0'); + else if (ch >= 'a' && ch <= 'f') + return (ch - 'a' + 10); + else if (ch >= 'A' && ch <= 'F') + return (ch - 'A' + 10); + return (-1); +} + +/* + * Decode percent-encoded URL component from src into dst, stopping at end + * of string, or at @ or : separators. Returns a pointer to the unhandled + * part of the input string (null terminator, @, or :). No terminator is + * written to dst (it is the caller's responsibility). + */ +static const char * +fetch_pctdecode(char *dst, const char *src, size_t dlen) +{ + int d1, d2; + char c; + const char *s; + + for (s = src; *s != '\0' && *s != '@' && *s != ':'; s++) { + if (s[0] == '%' && (d1 = fetch_hexval(s[1])) >= 0 && + (d2 = fetch_hexval(s[2])) >= 0) { + c = d1 << 4 | d2; + s += 2; + } else { + c = *s; + } + if (dlen-- > 0) + *dst++ = c; + } + return (s); +} + +/* * Split an URL into components. URL syntax is: * [method:/][/[user[:pwd]@]host[:port]/][document] * This almost, but not quite, RFC1738 URL syntax. @@ -329,15 +372,11 @@ p = strpbrk(URL, "/@"); if (p && *p == '@') { /* username */ - for (q = URL, i = 0; (*q != ':') && (*q != '@'); q++) - if (i < URL_USERLEN) - u->user[i++] = *q; + q = fetch_pctdecode(u->user, URL, URL_USERLEN); /* password */ if (*q == ':') - for (q++, i = 0; (*q != ':') && (*q != '@'); q++) - if (i < URL_PWDLEN) - u->pwd[i++] = *q; + q = fetch_pctdecode(u->pwd, ++q, URL_PWDLEN); p++; } else { --NDin8bjvE/0mNLFQ-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 9 22:23:49 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 835DB106566C; Mon, 9 Apr 2012 22:23:49 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 4A6798FC0C; Mon, 9 Apr 2012 22:23:49 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id q39MNlPb029771 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 9 Apr 2012 15:23:48 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4F83619E.5060607@freebsd.org> Date: Mon, 09 Apr 2012 15:24:30 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20 MIME-Version: 1.0 To: Ed Maste References: <20120409205051.GA27392@sandvine.com> In-Reply-To: <20120409205051.GA27392@sandvine.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: [PATCH] percent-encoding for libfetch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 22:23:49 -0000 On 4/9/12 1:50 PM, Ed Maste wrote: > Libfetch supports a username and password in a FTP or HTTP URL, but lacks > a method to specify '@' or ':' there, as they're used as URL component > separators. I discovered this issue because I have an FTP server that > uses an email address as the username, and I can't use fetch(1) or > libfetch against it. > > The attached patch adds decoding of percent-encoded usernames and > passwords, in order to use a URL like > ftp://foo%40example.com:password@host:port/file.bar . > > Please review. I plan to commit in the next few days. could you not parse the @ differently depending upon where it is? others must have covered this problem.. > -Ed > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Mon Apr 9 23:26:40 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1426F1065670; Mon, 9 Apr 2012 23:26:39 +0000 (UTC) (envelope-from emaste@freebsd.org) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by mx1.freebsd.org (Postfix) with ESMTP id C833F8FC17; Mon, 9 Apr 2012 23:26:38 +0000 (UTC) Received: from labgw2.phaedrus.sandvine.com (192.168.222.22) by WTL-EXCH-1.sandvine.com (192.168.196.31) with Microsoft SMTP Server id 14.1.339.1; Mon, 9 Apr 2012 19:26:38 -0400 Received: by labgw2.phaedrus.sandvine.com (Postfix, from userid 10332) id E807E33C02; Mon, 9 Apr 2012 19:26:35 -0400 (EDT) Date: Mon, 9 Apr 2012 19:26:35 -0400 From: Ed Maste To: Julian Elischer Message-ID: <20120409232635.GA51176@sandvine.com> References: <20120409205051.GA27392@sandvine.com> <4F83619E.5060607@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <4F83619E.5060607@freebsd.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: [PATCH] percent-encoding for libfetch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 23:26:40 -0000 On Mon, Apr 09, 2012 at 03:24:30PM -0700, Julian Elischer wrote: > could you not parse the @ differently depending upon where it is? > > others must have covered this problem.. Indeed others have - none other than T. Berners-Lee, in RFC 1738 where the format of a URL is specified: In addition, octets may be encoded by a character triplet consisting of the character "%" followed by the two hexadecimal digits (from "0123456789ABCDEF") which forming the hexadecimal value of the octet. (The characters "abcdef" may also be used in hexadecimal encodings.) ... The user name (and password), if present, are followed by a commercial at-sign "@". Within the user and password field, any ":", "@", or "/" must be encoded. -Ed From owner-freebsd-current@FreeBSD.ORG Tue Apr 10 01:18:43 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 64529106566B for ; Tue, 10 Apr 2012 01:18:43 +0000 (UTC) (envelope-from venture37@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id EA1488FC0A for ; Tue, 10 Apr 2012 01:18:42 +0000 (UTC) Received: by wern13 with SMTP id n13so3862016wer.13 for ; Mon, 09 Apr 2012 18:18:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:from:content-type:x-mailer:message-id:date:to :content-transfer-encoding:mime-version; bh=nuZkX7j8WFIHrLf3G5Ifg2EBB2huFCFdgxKGMTtbZDQ=; b=L2uRdVt8Bc/QaIKbJfJQiGT5ciUyTcdu+nwvwfdq+jjjDBrmrTspkOeAElV6FFLDjp P4b0ksTyh0N3Mxp0+7yxa40CsMxs0agB6t+9iSnybDPTrQbrYcDdS0xpZbwoCz6qtQGB yBOG9v5oqltInrEbGIfjzAKvSLPlzvEiSp2B+Hoh6J3uEg42hXoZ+AIDqRTgVuC9+sao r6sPB/Bv9F/nWff3G+1lJHO1eZDTKS9jKyrlJnvM6xp622g4ZRkorvFopzfc/o1J4Mj5 vqP1S9IjR+j2phOVK1RBzMBF0DoZzy3Duqtzc+X/ameDnisblPf+efTAL/lOlqiXneMZ swfA== Received: by 10.180.88.67 with SMTP id be3mr2333568wib.20.1334020722131; Mon, 09 Apr 2012 18:18:42 -0700 (PDT) Received: from [192.168.14.103] (cpc2-brig17-2-0-cust527.3-3.cable.virginmedia.com. [81.101.198.16]) by mx.google.com with ESMTPS id l5sm34225900wia.11.2012.04.09.18.18.40 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 Apr 2012 18:18:41 -0700 (PDT) From: Sevan / Venture37 Content-Type: text/plain; charset=us-ascii X-Mailer: iPhone Mail (9B176) Message-Id: <566771C2-84CA-4824-AE99-38EB5DE1F786@gmail.com> Date: Tue, 10 Apr 2012 02:18:38 +0100 To: "freebsd-current@freebsd.org" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Subject: DTrace on FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 01:18:43 -0000 Hi, Ryan Stone got a chance to give a brief talk at the dtrace.conf last week wh= ere he covered the status of support on FreeBSD. http://smartos.org/2012/04/09/dtrace-conf-2012-dtrace-on-freebsd/ I was wondering if the reason outlined by Ryan for why it DTrace isn't switc= hed on by default still hold true (licensing issue) or is it just the case t= hat it was forgotten about? I ask as It would be nice to have DTrace on FreeBSD by default. Sevan= From owner-freebsd-current@FreeBSD.ORG Tue Apr 10 01:45:23 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E4248106566B for ; Tue, 10 Apr 2012 01:45:23 +0000 (UTC) (envelope-from daichi@freebsd.org) Received: from natial.ongs.co.jp (natial.ongs.co.jp [202.216.246.90]) by mx1.freebsd.org (Postfix) with ESMTP id A708A8FC17 for ; Tue, 10 Apr 2012 01:45:23 +0000 (UTC) Received: from parancell.ongs.co.jp (dullmdaler.ongs.co.jp [202.216.246.94]) by natial.ongs.co.jp (Postfix) with ESMTPSA id CEA9012543B; Tue, 10 Apr 2012 10:45:21 +0900 (JST) Date: Tue, 10 Apr 2012 10:45:21 +0900 From: Daichi GOTO To: Sevan / Venture37 Message-Id: <20120410104521.ba15b1c3.daichi@freebsd.org> In-Reply-To: <566771C2-84CA-4824-AE99-38EB5DE1F786@gmail.com> References: <566771C2-84CA-4824-AE99-38EB5DE1F786@gmail.com> Organization: FreeBSD Project X-Mailer: Sylpheed 3.1.3 (GTK+ 2.24.6; amd64-portbld-freebsd9.9) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "freebsd-current@freebsd.org" Subject: Re: DTrace on FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 01:45:24 -0000 Hi, >From the DTrace tutorial at AsiaBSDCon 2012, it is a CDDL license issue. Addition from my experiences, some applicaions can not be built on DTrace/UserlandDTrace-enabled system (VBox is) and Userland dtrace is still unstable. On Tue, 10 Apr 2012 02:18:38 +0100 Sevan / Venture37 wrote: > Hi, > Ryan Stone got a chance to give a brief talk at the dtrace.conf last week where he covered the status of support on FreeBSD. > http://smartos.org/2012/04/09/dtrace-conf-2012-dtrace-on-freebsd/ > > I was wondering if the reason outlined by Ryan for why it DTrace isn't switched on by default still hold true (licensing issue) or is it just the case that it was forgotten about? > I ask as It would be nice to have DTrace on FreeBSD by default. > > > Sevan_______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- Daichi GOTO (daichi) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Tue Apr 10 02:28:36 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1FD091065670 for ; Tue, 10 Apr 2012 02:28:36 +0000 (UTC) (envelope-from daichi@freebsd.org) Received: from natial.ongs.co.jp (natial.ongs.co.jp [202.216.246.90]) by mx1.freebsd.org (Postfix) with ESMTP id 9BA9F8FC0A for ; Tue, 10 Apr 2012 02:28:35 +0000 (UTC) Received: from parancell.ongs.co.jp (dullmdaler.ongs.co.jp [202.216.246.94]) by natial.ongs.co.jp (Postfix) with ESMTPSA id 1033412543B; Tue, 10 Apr 2012 11:28:35 +0900 (JST) Date: Tue, 10 Apr 2012 11:28:34 +0900 From: Daichi GOTO To: kwhite@site.uottawa.ca Message-Id: <20120410112834.56bb2d02.daichi@freebsd.org> In-Reply-To: <14043.74.51.53.177.1333981899.squirrel@courriel.site.uottawa.ca> References: <55056.74.51.53.177.1333762589.squirrel@courriel.site.uottawa.ca> <20120408221127.969e8e71.daichi@freebsd.org> <14043.74.51.53.177.1333981899.squirrel@courriel.site.uottawa.ca> Organization: FreeBSD Project X-Mailer: Sylpheed 3.1.3 (GTK+ 2.24.6; amd64-portbld-freebsd9.9) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Tue__10_Apr_2012_11_28_34_+0900_0_mygCSu_TA36cPV" Cc: freebsd-current@freebsd.org Subject: Re: (unionfs) panic: excl->share with r230341 and above X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 02:28:36 -0000 This is a multi-part message in MIME format. --Multipart=_Tue__10_Apr_2012_11_28_34_+0900_0_mygCSu_TA36cPV Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Thanks kwhite, I found an another lock issue. Please try a patch included. On Mon, 9 Apr 2012 10:31:39 -0400 (EDT) kwhite@site.uottawa.ca wrote: > > Hi > > > > Please try an attached patch that improves handlings of fs locks. > > I think that this patch can resolve this issue. If that works well, > > I'm going to refine and commit it to head. > > > > Thanks! > > I tried your patch but get the same panic: > > FreeBSD 10.0-CURRENT #6 r233856M: Mon Apr 9 09:47:42 EDT 2012 > ... > exclusive lock of (lockmgr) ufs @ > /usr/src/sys/modules/unionfs/../../fs/unionfs/union_vnops.c:1897 > while share locked from /usr/src/sys/modules/unionfs/../../fs/unionfs/ > union_vnops.c:1897 > panic: excl->share > cpuid = 0 > KDB: enter: panic > [ thread pid 38 tid 100050 ] > Stopped at kdb_enter+0x3b: movl $0,kdb_why > db> show all locks > Process 38 (ls) thread 0xc56dd2e0 (100050) > exclusive sleep mutex vnode interlock (vnode interlock) r = 0 > (0xc5797d38) locked @ > /usr/src/sys/modules/unionfs/../../fs/unionfs/union_vnops.c:1889 > shared lockmgr ufs (ufs) r = 0 (0xc5797d18) locked @ > /usr/src/sys/modules/unionfs/../../fs/unionfs/union_vnops.c:1897 > db> > > > On Fri, 6 Apr 2012 21:36:29 -0400 (EDT) > > kwhite@site.uottawa.ca wrote: > >> Starting with r230341, I get the following panic when trying to run > >> an executable on a unionfs filesystem: > >> > >> exclusive lock of (lockmgr) ufs @ > >> /usr/src/sys/modules/unionfs/../../fs/unionfs/union_vnops.c:1843 > >> while share locked from > >> /usr/src/sys/modules/unionfs/../../fs/unionfs/union_vnops.c:1843 > >> panic: excl->share > >> cpuid = 0 > >> KDB: enter: panic > >> > >> Narrowing down with a binary search: r230340 (no panic), r230341 > >> (panic). > >> > >> How to repeat: > >> # uuname -a > >> FreeBSD 10.0-CURRENT FreeBSD 10.0-CURRENT #5 r233946M: Fri Apr > >> 6 > >> 21:09:32 EDT 2012 kwhite@demo:/usr/src/obj/usr/src/sys/GENERIC > >> i386 > >> > >> # mkdir /tmp/local > >> # mount -t unionfs -o noatime /tmp/local /usr/local > >> # cp /bin/ls /usr/local/bin/ls > >> # /usr/local/bin/ls > >> .... > >> exclusive lock of (lockmgr) ufs @ > >> /usr/src/sys/modules/unionfs/../../fs/unionfs/union_vnops.c:1843 > >> while share locked from > >> /usr/src/sys/modules/unionfs/../../fs/unionfs/union_vnops.c:1843 > >> panic: excl->share > >> cpuid = 0 > >> KDB: enter: panic > >> [ thread pid 68 tid 100054 ] > >> Stopped at kdb_enter+0x3b: movl $0,kdb_why > >> db> show all locks > >> Process 68 (ls) thread 0xc5780000 (100054) > >> exclusive sleep mutex vnode interlock (vnode interlock) r = 0 > >> (0xc57cec28) locked @ > >> /usr/src/sys/modules/unionfs/../../fs/unionfs/union_vnops.c:1835 > >> shared lockmgr ufs (ufs) r = 0 (0xc57cec08) locked @ > >> /usr/src/sys/modules/unionfs/../../fs/unionfs/union_vnops.c:1843 > >> db> > >> > >> Workaround? > >> After reverting the change from LK_EXCLUSIVE to LK_SHARED > >> in sys/kern/kern_exec.c, executables on union filesystems no > >> longer cause a panic. > >> > >> ...keith > >> > >> > >> _______________________________________________ > >> freebsd-current@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-current > >> To unsubscribe, send any mail to > >> "freebsd-current-unsubscribe@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-unsubscribe@freebsd.org" -- Daichi GOTO (daichi) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve --Multipart=_Tue__10_Apr_2012_11_28_34_+0900_0_mygCSu_TA36cPV Content-Type: text/x-diff; name="unionfs_20120410.diff" Content-Disposition: attachment; filename="unionfs_20120410.diff" Content-Transfer-Encoding: 7bit diff -urBN /usr/src.orig/sys/fs/unionfs/union_subr.c /usr/src/sys/fs/unionfs/union_subr.c --- /usr/src.orig/sys/fs/unionfs/union_subr.c 2012-04-08 14:01:23.000000000 +0900 +++ /usr/src/sys/fs/unionfs/union_subr.c 2012-04-10 02:22:38.000000000 +0900 @@ -350,19 +350,22 @@ uvp = unp->un_uppervp; dvp = unp->un_dvp; unp->un_lowervp = unp->un_uppervp = NULLVP; - vp->v_vnlock = &(vp->v_lock); vp->v_data = NULL; - lockmgr(vp->v_vnlock, LK_EXCLUSIVE | LK_INTERLOCK, VI_MTX(vp)); + vp->v_object = NULL; + VI_UNLOCK(vp); + if (lvp != NULLVP) - VOP_UNLOCK(lvp, 0); + VOP_UNLOCK(lvp, LK_RELEASE); if (uvp != NULLVP) - VOP_UNLOCK(uvp, 0); - vp->v_object = NULL; + VOP_UNLOCK(uvp, LK_RELEASE); if (dvp != NULLVP && unp->un_hash.le_prev != NULL) unionfs_rem_cached_vnode(unp, dvp); + if (lockmgr(vp->v_vnlock, LK_EXCLUSIVE, VI_MTX(vp)) != 0) + panic("the lock for deletion is unacquirable."); + if (lvp != NULLVP) { vfslocked = VFS_LOCK_GIANT(lvp->v_mount); vrele(lvp); @@ -550,7 +553,7 @@ cn->cn_flags |= (cnp->cn_flags & SAVESTART); vref(dvp); - VOP_UNLOCK(dvp, 0); + VOP_UNLOCK(dvp, LK_RELEASE); if ((error = relookup(dvp, vpp, cn))) { uma_zfree(namei_zone, cn->cn_pnbuf); @@ -957,7 +960,7 @@ *vpp = vp; unionfs_vn_create_on_upper_free_out1: - VOP_UNLOCK(udvp, 0); + VOP_UNLOCK(udvp, LK_RELEASE); unionfs_vn_create_on_upper_free_out2: if (cn.cn_flags & HASBUF) { diff -urBN /usr/src.orig/sys/fs/unionfs/union_vfsops.c /usr/src/sys/fs/unionfs/union_vfsops.c --- /usr/src.orig/sys/fs/unionfs/union_vfsops.c 2012-04-08 14:01:23.000000000 +0900 +++ /usr/src/sys/fs/unionfs/union_vfsops.c 2012-04-10 02:22:38.000000000 +0900 @@ -165,7 +165,7 @@ uid = va.va_uid; gid = va.va_gid; } - VOP_UNLOCK(mp->mnt_vnodecovered, 0); + VOP_UNLOCK(mp->mnt_vnodecovered, LK_RELEASE); if (error) return (error); @@ -250,7 +250,7 @@ * Save reference */ if (below) { - VOP_UNLOCK(upperrootvp, 0); + VOP_UNLOCK(upperrootvp, LK_RELEASE); vn_lock(lowerrootvp, LK_EXCLUSIVE | LK_RETRY); ump->um_lowervp = upperrootvp; ump->um_uppervp = lowerrootvp; @@ -281,7 +281,7 @@ /* * Unlock the node */ - VOP_UNLOCK(ump->um_uppervp, 0); + VOP_UNLOCK(ump->um_uppervp, LK_RELEASE); /* * Get the unionfs root vnode. diff -urBN /usr/src.orig/sys/fs/unionfs/union_vnops.c /usr/src/sys/fs/unionfs/union_vnops.c --- /usr/src.orig/sys/fs/unionfs/union_vnops.c 2012-04-08 14:01:23.000000000 +0900 +++ /usr/src/sys/fs/unionfs/union_vnops.c 2012-04-10 02:22:38.000000000 +0900 @@ -75,21 +75,6 @@ KASSERT(((vp)->v_op == &unionfs_vnodeops), \ ("unionfs: it is not unionfs-vnode")) -/* lockmgr lock <-> reverse table */ -struct lk_lr_table { - int lock; - int revlock; -}; - -static struct lk_lr_table un_llt[] = { - {LK_SHARED, LK_RELEASE}, - {LK_EXCLUSIVE, LK_RELEASE}, - {LK_UPGRADE, LK_DOWNGRADE}, - {LK_DOWNGRADE, LK_UPGRADE}, - {0, 0} -}; - - static int unionfs_lookup(struct vop_cachedlookup_args *ap) { @@ -141,7 +126,7 @@ if (udvp != NULLVP) { dtmpvp = udvp; if (ldvp != NULLVP) - VOP_UNLOCK(ldvp, 0); + VOP_UNLOCK(ldvp, LK_RELEASE); } else dtmpvp = ldvp; @@ -149,7 +134,7 @@ error = VOP_LOOKUP(dtmpvp, &vp, cnp); if (dtmpvp == udvp && ldvp != NULLVP) { - VOP_UNLOCK(udvp, 0); + VOP_UNLOCK(udvp, LK_RELEASE); vn_lock(dvp, LK_EXCLUSIVE | LK_RETRY); } @@ -161,10 +146,10 @@ */ if (nameiop == DELETE || nameiop == RENAME || (cnp->cn_lkflags & LK_TYPE_MASK)) - VOP_UNLOCK(vp, 0); + VOP_UNLOCK(vp, LK_RELEASE); vrele(vp); - VOP_UNLOCK(dvp, 0); + VOP_UNLOCK(dvp, LK_RELEASE); *(ap->a_vpp) = dunp->un_dvp; vref(dunp->un_dvp); @@ -202,7 +187,7 @@ } if (nameiop == DELETE || nameiop == RENAME || (cnp->cn_lkflags & LK_TYPE_MASK)) - VOP_UNLOCK(uvp, 0); + VOP_UNLOCK(uvp, LK_RELEASE); } /* check whiteout */ @@ -246,7 +231,7 @@ return (lerror); } if (cnp->cn_lkflags & LK_TYPE_MASK) - VOP_UNLOCK(lvp, 0); + VOP_UNLOCK(lvp, LK_RELEASE); } } @@ -281,7 +266,7 @@ goto unionfs_lookup_out; if (LK_SHARED == (cnp->cn_lkflags & LK_TYPE_MASK)) - VOP_UNLOCK(vp, 0); + VOP_UNLOCK(vp, LK_RELEASE); if (LK_EXCLUSIVE != VOP_ISLOCKED(vp)) { vn_lock(vp, LK_EXCLUSIVE | LK_RETRY); lockflag = 1; @@ -289,7 +274,7 @@ error = unionfs_mkshadowdir(MOUNTTOUNIONFSMOUNT(dvp->v_mount), udvp, VTOUNIONFS(vp), cnp, td); if (lockflag != 0) - VOP_UNLOCK(vp, 0); + VOP_UNLOCK(vp, LK_RELEASE); if (error != 0) { UNIONFSDEBUG("unionfs_lookup: Unable to create shadow dir."); if ((cnp->cn_lkflags & LK_TYPE_MASK) == LK_EXCLUSIVE) @@ -386,7 +371,7 @@ if (vp->v_type == VSOCK) *(ap->a_vpp) = vp; else { - VOP_UNLOCK(vp, 0); + VOP_UNLOCK(vp, LK_RELEASE); error = unionfs_nodeget(ap->a_dvp->v_mount, vp, NULLVP, ap->a_dvp, ap->a_vpp, cnp, curthread); vrele(vp); @@ -460,7 +445,7 @@ if (vp->v_type == VSOCK) *(ap->a_vpp) = vp; else { - VOP_UNLOCK(vp, 0); + VOP_UNLOCK(vp, LK_RELEASE); error = unionfs_nodeget(ap->a_dvp->v_mount, vp, NULLVP, ap->a_dvp, ap->a_vpp, cnp, curthread); vrele(vp); @@ -564,6 +549,7 @@ struct unionfs_node_status *unsp; struct ucred *cred; struct thread *td; + struct vnode *vp; struct vnode *ovp; UNIONFS_INTERNAL_DEBUG("unionfs_close: enter\n"); @@ -571,12 +557,14 @@ KASSERT_UNIONFS_VNODE(ap->a_vp); locked = 0; - unp = VTOUNIONFS(ap->a_vp); + vp = ap->a_vp; + unp = VTOUNIONFS(vp); cred = ap->a_cred; td = ap->a_td; - if (VOP_ISLOCKED(ap->a_vp) != LK_EXCLUSIVE) { - vn_lock(ap->a_vp, LK_EXCLUSIVE | LK_RETRY); + if (VOP_ISLOCKED(vp) != LK_EXCLUSIVE) { + if (vn_lock(vp, LK_UPGRADE) != 0) + vn_lock(vp, LK_EXCLUSIVE | LK_RETRY); locked = 1; } unionfs_get_node_status(unp, td, &unsp); @@ -599,7 +587,7 @@ if (error != 0) goto unionfs_close_abort; - ap->a_vp->v_object = ovp->v_object; + vp->v_object = ovp->v_object; if (ovp == unp->un_uppervp) { unsp->uns_upper_opencnt--; @@ -610,7 +598,7 @@ unsp->uns_lower_opencnt--; } if (unsp->uns_lower_opencnt > 0) - ap->a_vp->v_object = unp->un_lowervp->v_object; + vp->v_object = unp->un_lowervp->v_object; } } else unsp->uns_lower_opencnt--; @@ -619,7 +607,7 @@ unionfs_tryrem_node_status(unp, unsp); if (locked != 0) - VOP_UNLOCK(ap->a_vp, 0); + vn_lock(vp, LK_DOWNGRADE | LK_RETRY); UNIONFS_INTERNAL_DEBUG("unionfs_close: leave (%d)\n", error); @@ -914,7 +902,7 @@ unionfs_get_node_status(unp, ap->a_td, &unsp); ovp = (unsp->uns_upper_opencnt ? unp->un_uppervp : unp->un_lowervp); unionfs_tryrem_node_status(unp, unsp); - VOP_UNLOCK(ap->a_vp, 0); + VOP_UNLOCK(ap->a_vp, LK_RELEASE); if (ovp == NULLVP) return (EBADF); @@ -941,7 +929,7 @@ unionfs_get_node_status(unp, ap->a_td, &unsp); ovp = (unsp->uns_upper_opencnt ? unp->un_uppervp : unp->un_lowervp); unionfs_tryrem_node_status(unp, unsp); - VOP_UNLOCK(ap->a_vp, 0); + VOP_UNLOCK(ap->a_vp, LK_RELEASE); if (ovp == NULLVP) return (EBADF); @@ -1001,7 +989,7 @@ ump = NULL; vp = uvp = lvp = NULLVP; /* search vnode */ - VOP_UNLOCK(ap->a_vp, 0); + VOP_UNLOCK(ap->a_vp, LK_RELEASE); error = unionfs_relookup(udvp, &vp, cnp, &cn, td, cnp->cn_nameptr, strlen(cnp->cn_nameptr), DELETE); if (error != 0 && error != ENOENT) { @@ -1204,7 +1192,7 @@ if ((error = vn_lock(fvp, LK_EXCLUSIVE)) != 0) goto unionfs_rename_abort; error = unionfs_copyfile(unp, 1, fcnp->cn_cred, td); - VOP_UNLOCK(fvp, 0); + VOP_UNLOCK(fvp, LK_RELEASE); if (error != 0) goto unionfs_rename_abort; break; @@ -1212,7 +1200,7 @@ if ((error = vn_lock(fvp, LK_EXCLUSIVE)) != 0) goto unionfs_rename_abort; error = unionfs_mkshadowdir(ump, rfdvp, unp, fcnp, td); - VOP_UNLOCK(fvp, 0); + VOP_UNLOCK(fvp, LK_RELEASE); if (error != 0) goto unionfs_rename_abort; break; @@ -1269,13 +1257,13 @@ if ((error = vn_lock(fdvp, LK_EXCLUSIVE)) != 0) goto unionfs_rename_abort; error = unionfs_relookup_for_delete(fdvp, fcnp, td); - VOP_UNLOCK(fdvp, 0); + VOP_UNLOCK(fdvp, LK_RELEASE); if (error != 0) goto unionfs_rename_abort; /* Locke of tvp is canceled in order to avoid recursive lock. */ if (tvp != NULLVP && tvp != tdvp) - VOP_UNLOCK(tvp, 0); + VOP_UNLOCK(tvp, LK_RELEASE); error = unionfs_relookup_for_rename(tdvp, tcnp, td); if (tvp != NULLVP && tvp != tdvp) vn_lock(tvp, LK_EXCLUSIVE | LK_RETRY); @@ -1293,11 +1281,11 @@ } if (ltdvp != NULLVP) - VOP_UNLOCK(ltdvp, 0); + VOP_UNLOCK(ltdvp, LK_RELEASE); if (tdvp != rtdvp) vrele(tdvp); if (ltvp != NULLVP) - VOP_UNLOCK(ltvp, 0); + VOP_UNLOCK(ltvp, LK_RELEASE); if (tvp != rtvp && tvp != NULLVP) { if (rtvp == NULLVP) vput(tvp); @@ -1371,7 +1359,7 @@ } if ((error = VOP_MKDIR(udvp, &uvp, cnp, ap->a_vap)) == 0) { - VOP_UNLOCK(uvp, 0); + VOP_UNLOCK(uvp, LK_RELEASE); cnp->cn_lkflags = LK_EXCLUSIVE; error = unionfs_nodeget(ap->a_dvp->v_mount, uvp, NULLVP, ap->a_dvp, ap->a_vpp, cnp, td); @@ -1467,7 +1455,7 @@ if (udvp != NULLVP) { error = VOP_SYMLINK(udvp, &uvp, cnp, ap->a_vap, ap->a_target); if (error == 0) { - VOP_UNLOCK(uvp, 0); + VOP_UNLOCK(uvp, LK_RELEASE); cnp->cn_lkflags = LK_EXCLUSIVE; error = unionfs_nodeget(ap->a_dvp->v_mount, uvp, NULLVP, ap->a_dvp, ap->a_vpp, cnp, td); @@ -1490,6 +1478,7 @@ struct unionfs_node *unp; struct unionfs_node_status *unsp; struct uio *uio; + struct vnode *vp; struct vnode *uvp; struct vnode *lvp; struct thread *td; @@ -1505,41 +1494,49 @@ error = 0; eofflag = 0; locked = 0; - unp = VTOUNIONFS(ap->a_vp); uio = ap->a_uio; - uvp = unp->un_uppervp; - lvp = unp->un_lowervp; + uvp = NULLVP; + lvp = NULLVP; td = uio->uio_td; ncookies_bk = 0; cookies_bk = NULL; - if (ap->a_vp->v_type != VDIR) + vp = ap->a_vp; + if (vp->v_type != VDIR) return (ENOTDIR); - /* check opaque */ - if (uvp != NULLVP && lvp != NULLVP) { - if ((error = VOP_GETATTR(uvp, &va, ap->a_cred)) != 0) - goto unionfs_readdir_exit; - if (va.va_flags & OPAQUE) - lvp = NULLVP; - } - /* check the open count. unionfs needs to open before readdir. */ - if (VOP_ISLOCKED(ap->a_vp) != LK_EXCLUSIVE) { - vn_lock(ap->a_vp, LK_UPGRADE | LK_RETRY); + if (VOP_ISLOCKED(vp) != LK_EXCLUSIVE) { + if (vn_lock(vp, LK_UPGRADE) != 0) + vn_lock(vp, LK_EXCLUSIVE | LK_RETRY); locked = 1; } - unionfs_get_node_status(unp, td, &unsp); - if ((uvp != NULLVP && unsp->uns_upper_opencnt <= 0) || - (lvp != NULLVP && unsp->uns_lower_opencnt <= 0)) { - unionfs_tryrem_node_status(unp, unsp); + unp = VTOUNIONFS(vp); + if (unp == NULL) error = EBADF; + else { + uvp = unp->un_uppervp; + lvp = unp->un_lowervp; + unionfs_get_node_status(unp, td, &unsp); + if ((uvp != NULLVP && unsp->uns_upper_opencnt <= 0) || + (lvp != NULLVP && unsp->uns_lower_opencnt <= 0)) { + unionfs_tryrem_node_status(unp, unsp); + error = EBADF; + } } - if (locked == 1) - vn_lock(ap->a_vp, LK_DOWNGRADE | LK_RETRY); + if (locked) + vn_lock(vp, LK_DOWNGRADE | LK_RETRY); if (error != 0) goto unionfs_readdir_exit; + /* check opaque */ + if (uvp != NULLVP && lvp != NULLVP) { + if ((error = VOP_GETATTR(uvp, &va, ap->a_cred)) != 0) + goto unionfs_readdir_exit; + if (va.va_flags & OPAQUE) + lvp = NULLVP; + } + /* upper only */ if (uvp != NULLVP && lvp == NULLVP) { error = VOP_READDIR(uvp, uio, ap->a_cred, ap->a_eofflag, @@ -1743,18 +1740,66 @@ } static int -unionfs_get_llt_revlock(int flags) +unionfs_islocked(struct vop_islocked_args *ap) { - int count; + struct unionfs_node *unp; - flags &= LK_TYPE_MASK; - for (count = 0; un_llt[count].lock != 0; count++) { - if (flags == un_llt[count].lock) { - return un_llt[count].revlock; - } + KASSERT_UNIONFS_VNODE(ap->a_vp); + + unp = VTOUNIONFS(ap->a_vp); + if (unp == NULL) + return (vop_stdislocked(ap)); + + if (unp->un_uppervp != NULLVP) + return (VOP_ISLOCKED(unp->un_uppervp)); + if (unp->un_lowervp != NULLVP) + return (VOP_ISLOCKED(unp->un_lowervp)); + return (vop_stdislocked(ap)); +} + +static int +unionfs_get_llt_revlock(struct vnode *vp, int flags) +{ + int revlock; + + revlock = 0; + + switch (flags & LK_TYPE_MASK) { + case LK_SHARED: + if (VOP_ISLOCKED(vp) == LK_EXCLUSIVE) + revlock = LK_UPGRADE; + else + revlock = LK_RELEASE; + break; + case LK_EXCLUSIVE: + case LK_UPGRADE: + revlock = LK_RELEASE; + break; + case LK_DOWNGRADE: + revlock = LK_UPGRADE; + break; + default: + break; } - return 0; + return (revlock); +} + +/* + * The state of an acquired lock is adjusted similarly to + * the time of error generating. + * flags: LK_RELEASE or LK_UPGRADE + */ +static void +unionfs_revlock(struct vnode *vp, int flags) +{ + if (flags & LK_RELEASE) + VOP_UNLOCK(vp, flags); + else { + /* UPGRADE */ + if (vn_lock(vp, flags) != 0) + vn_lock(vp, LK_EXCLUSIVE | LK_RETRY); + } } static int @@ -1763,6 +1808,7 @@ int error; int flags; int revlock; + int interlock; int uhold; struct mount *mp; struct unionfs_mount *ump; @@ -1774,15 +1820,13 @@ KASSERT_UNIONFS_VNODE(ap->a_vp); error = 0; + interlock = 1; uhold = 0; flags = ap->a_flags; vp = ap->a_vp; if (LK_RELEASE == (flags & LK_TYPE_MASK) || !(flags & LK_TYPE_MASK)) - return (VOP_UNLOCK(vp, flags)); - - if ((revlock = unionfs_get_llt_revlock(flags)) == 0) - panic("unknown lock type: 0x%x", flags & LK_TYPE_MASK); + return (VOP_UNLOCK(vp, flags | LK_RELEASE)); if ((flags & LK_INTERLOCK) == 0) VI_LOCK(vp); @@ -1798,6 +1842,9 @@ lvp = unp->un_lowervp; uvp = unp->un_uppervp; + if ((revlock = unionfs_get_llt_revlock(vp, flags)) == 0) + panic("unknown lock type: 0x%x", flags & LK_TYPE_MASK); + if ((mp->mnt_kern_flag & MNTK_MPSAFE) != 0 && (vp->v_iflag & VI_OWEINACT) != 0) flags |= LK_NOWAIT; @@ -1811,6 +1858,23 @@ flags |= LK_CANRECURSE; if (lvp != NULLVP) { + if (uvp != NULLVP && flags & LK_UPGRADE) { + /* Share Lock is once released and a deadlock is avoided. */ + VI_LOCK_FLAGS(uvp, MTX_DUPOK); + vholdl(uvp); + uhold = 1; + VI_UNLOCK(vp); + VOP_UNLOCK(uvp, LK_RELEASE | LK_INTERLOCK); + VI_LOCK(vp); + unp = VTOUNIONFS(vp); + if (unp == NULL) { + /* vnode is released. */ + VI_UNLOCK(vp); + VOP_UNLOCK(lvp, LK_RELEASE); + vdrop(uvp); + return (EBUSY); + } + } VI_LOCK_FLAGS(lvp, MTX_DUPOK); flags |= LK_INTERLOCK; vholdl(lvp); @@ -1823,19 +1887,28 @@ VI_LOCK(vp); unp = VTOUNIONFS(vp); if (unp == NULL) { + /* vnode is released. */ VI_UNLOCK(vp); if (error == 0) - VOP_UNLOCK(lvp, 0); + VOP_UNLOCK(lvp, LK_RELEASE); vdrop(lvp); + if (uhold != 0) + vdrop(uvp); return (vop_stdlock(ap)); } } if (error == 0 && uvp != NULLVP) { + if (uhold && flags & LK_UPGRADE) { + flags &= ~LK_TYPE_MASK; + flags |= LK_EXCLUSIVE; + } VI_LOCK_FLAGS(uvp, MTX_DUPOK); flags |= LK_INTERLOCK; - vholdl(uvp); - uhold = 1; + if (uhold == 0) { + vholdl(uvp); + uhold = 1; + } VI_UNLOCK(vp); ap->a_flags &= ~LK_INTERLOCK; @@ -1845,30 +1918,27 @@ VI_LOCK(vp); unp = VTOUNIONFS(vp); if (unp == NULL) { + /* vnode is released. */ VI_UNLOCK(vp); - if (error == 0) { - VOP_UNLOCK(uvp, 0); - if (lvp != NULLVP) - VOP_UNLOCK(lvp, 0); - } - if (lvp != NULLVP) - vdrop(lvp); + if (error == 0) + VOP_UNLOCK(uvp, LK_RELEASE); vdrop(uvp); + if (lvp != NULLVP) { + VOP_UNLOCK(lvp, LK_RELEASE); + vdrop(lvp); + } return (vop_stdlock(ap)); } - if (error != 0 && lvp != NULLVP) { + /* rollback */ VI_UNLOCK(vp); - if ((revlock & LK_TYPE_MASK) == LK_RELEASE) - VOP_UNLOCK(lvp, revlock); - else - vn_lock(lvp, revlock | LK_RETRY); - goto unionfs_lock_abort; + unionfs_revlock(lvp, revlock); + interlock = 0; } } - VI_UNLOCK(vp); -unionfs_lock_abort: + if (interlock) + VI_UNLOCK(vp); if (lvp != NULLVP) vdrop(lvp); if (uhold != 0) @@ -2013,7 +2083,7 @@ unionfs_tryrem_node_status(unp, unsp); } - VOP_UNLOCK(vp, 0); + VOP_UNLOCK(vp, LK_RELEASE); error = VOP_ADVLOCK(uvp, ap->a_id, ap->a_op, ap->a_fl, ap->a_flags); @@ -2022,7 +2092,7 @@ return error; unionfs_advlock_abort: - VOP_UNLOCK(vp, 0); + VOP_UNLOCK(vp, LK_RELEASE); UNIONFS_INTERNAL_DEBUG("unionfs_advlock: leave (%d)\n", error); @@ -2150,7 +2220,8 @@ error = VOP_OPENEXTATTR(tvp, ap->a_cred, ap->a_td); if (error == 0) { - vn_lock(vp, LK_UPGRADE | LK_RETRY); + if (vn_lock(vp, LK_UPGRADE) != 0) + vn_lock(vp, LK_EXCLUSIVE | LK_RETRY); if (tvp == unp->un_uppervp) unp->un_flag |= UNIONFS_OPENEXTU; else @@ -2186,7 +2257,8 @@ error = VOP_CLOSEEXTATTR(tvp, ap->a_commit, ap->a_cred, ap->a_td); if (error == 0) { - vn_lock(vp, LK_UPGRADE | LK_RETRY); + if (vn_lock(vp, LK_UPGRADE) != 0) + vn_lock(vp, LK_EXCLUSIVE | LK_RETRY); if (tvp == unp->un_uppervp) unp->un_flag &= ~UNIONFS_OPENEXTU; else @@ -2435,6 +2507,7 @@ .vop_getextattr = unionfs_getextattr, .vop_getwritemount = unionfs_getwritemount, .vop_inactive = unionfs_inactive, + .vop_islocked = unionfs_islocked, .vop_ioctl = unionfs_ioctl, .vop_link = unionfs_link, .vop_listextattr = unionfs_listextattr, --Multipart=_Tue__10_Apr_2012_11_28_34_+0900_0_mygCSu_TA36cPV-- From owner-freebsd-current@FreeBSD.ORG Tue Apr 10 05:44:08 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A43C8106567E; Tue, 10 Apr 2012 05:44:08 +0000 (UTC) (envelope-from andy@neu.net) Received: from mail.neu.net (unknown [IPv6:2607:fc50:0:d300:216:3eff:fe54:f1c6]) by mx1.freebsd.org (Postfix) with ESMTP id 2B8558FC1F; Tue, 10 Apr 2012 05:44:08 +0000 (UTC) Received: from neu.net (neu.net [199.48.129.194]) by mail.neu.net (8.14.5/8.14.5) with ESMTP id q3A5i29A087662; Tue, 10 Apr 2012 01:44:07 -0400 (EDT) (envelope-from andy@neu.net) Date: Tue, 10 Apr 2012 01:44:02 -0400 (EDT) From: AN To: freebsd-current@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Spam-Status: No, score=-0.0 required=5.0 tests=T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mail.neu.net Cc: gnome@freebsd.org Subject: recent update breaks some ports X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 05:44:08 -0000 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. Thanks in advance From owner-freebsd-current@FreeBSD.ORG Tue Apr 10 05:57:09 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CCF071065670; Tue, 10 Apr 2012 05:57:09 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 626118FC12; Tue, 10 Apr 2012 05:57:09 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q3A5v3qN096441; Tue, 10 Apr 2012 01:57:03 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q3A5v34s096432; Tue, 10 Apr 2012 05:57:03 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 10 Apr 2012 05:57:03 GMT Message-Id: <201204100557.q3A5v34s096432@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 05:57:10 -0000 TB --- 2012-04-10 00:20:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-04-10 00:20:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-04-10 00:20:00 - starting HEAD tinderbox run for i386/i386 TB --- 2012-04-10 00:20:00 - cleaning the object tree TB --- 2012-04-10 00:20:00 - cvsupping the source tree TB --- 2012-04-10 00:20:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2012-04-10 00:21:58 - building world TB --- 2012-04-10 00:21:58 - CROSS_BUILD_TESTING=YES TB --- 2012-04-10 00:21:58 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-10 00:21:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-10 00:21:58 - SRCCONF=/dev/null TB --- 2012-04-10 00:21:58 - TARGET=i386 TB --- 2012-04-10 00:21:58 - TARGET_ARCH=i386 TB --- 2012-04-10 00:21:58 - TZ=UTC TB --- 2012-04-10 00:21:58 - __MAKE_CONF=/dev/null TB --- 2012-04-10 00:21:58 - cd /src TB --- 2012-04-10 00:21:58 - /usr/bin/make -B buildworld >>> World build started on Tue Apr 10 00:21: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 Tue Apr 10 02:40:24 UTC 2012 TB --- 2012-04-10 02:40:24 - generating LINT kernel config TB --- 2012-04-10 02:40:24 - cd /src/sys/i386/conf TB --- 2012-04-10 02:40:24 - /usr/bin/make -B LINT TB --- 2012-04-10 02:40:25 - cd /src/sys/i386/conf TB --- 2012-04-10 02:40:25 - /usr/sbin/config -m LINT TB --- 2012-04-10 02:40:25 - building LINT kernel TB --- 2012-04-10 02:40:25 - CROSS_BUILD_TESTING=YES TB --- 2012-04-10 02:40:25 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-10 02:40:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-10 02:40:25 - SRCCONF=/dev/null TB --- 2012-04-10 02:40:25 - TARGET=i386 TB --- 2012-04-10 02:40:25 - TARGET_ARCH=i386 TB --- 2012-04-10 02:40:25 - TZ=UTC TB --- 2012-04-10 02:40:25 - __MAKE_CONF=/dev/null TB --- 2012-04-10 02:40:25 - cd /src TB --- 2012-04-10 02:40:25 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Apr 10 02:40:25 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 03:15:12 UTC 2012 TB --- 2012-04-10 03:15:12 - cd /src/sys/i386/conf TB --- 2012-04-10 03:15:12 - /usr/sbin/config -m LINT-NOINET TB --- 2012-04-10 03:15:12 - building LINT-NOINET kernel TB --- 2012-04-10 03:15:12 - CROSS_BUILD_TESTING=YES TB --- 2012-04-10 03:15:12 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-10 03:15:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-10 03:15:12 - SRCCONF=/dev/null TB --- 2012-04-10 03:15:12 - TARGET=i386 TB --- 2012-04-10 03:15:12 - TARGET_ARCH=i386 TB --- 2012-04-10 03:15:12 - TZ=UTC TB --- 2012-04-10 03:15:12 - __MAKE_CONF=/dev/null TB --- 2012-04-10 03:15:12 - cd /src TB --- 2012-04-10 03:15:12 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Tue Apr 10 03:15:12 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 03:47:40 UTC 2012 TB --- 2012-04-10 03:47:40 - cd /src/sys/i386/conf TB --- 2012-04-10 03:47:40 - /usr/sbin/config -m LINT-NOINET6 TB --- 2012-04-10 03:47:40 - building LINT-NOINET6 kernel TB --- 2012-04-10 03:47:40 - CROSS_BUILD_TESTING=YES TB --- 2012-04-10 03:47:40 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-10 03:47:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-10 03:47:40 - SRCCONF=/dev/null TB --- 2012-04-10 03:47:40 - TARGET=i386 TB --- 2012-04-10 03:47:40 - TARGET_ARCH=i386 TB --- 2012-04-10 03:47:40 - TZ=UTC TB --- 2012-04-10 03:47:40 - __MAKE_CONF=/dev/null TB --- 2012-04-10 03:47:40 - cd /src TB --- 2012-04-10 03:47:40 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Tue Apr 10 03:47:40 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 04:19:21 UTC 2012 TB --- 2012-04-10 04:19:21 - cd /src/sys/i386/conf TB --- 2012-04-10 04:19:21 - /usr/sbin/config -m LINT-NOIP TB --- 2012-04-10 04:19:21 - building LINT-NOIP kernel TB --- 2012-04-10 04:19:21 - CROSS_BUILD_TESTING=YES TB --- 2012-04-10 04:19:21 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-10 04:19:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-10 04:19:21 - SRCCONF=/dev/null TB --- 2012-04-10 04:19:21 - TARGET=i386 TB --- 2012-04-10 04:19:21 - TARGET_ARCH=i386 TB --- 2012-04-10 04:19:21 - TZ=UTC TB --- 2012-04-10 04:19:21 - __MAKE_CONF=/dev/null TB --- 2012-04-10 04:19:21 - cd /src TB --- 2012-04-10 04:19:21 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOIP >>> Kernel build for LINT-NOIP started on Tue Apr 10 04:19:21 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-NOIP completed on Tue Apr 10 04:48:35 UTC 2012 TB --- 2012-04-10 04:48:35 - cd /src/sys/i386/conf TB --- 2012-04-10 04:48:35 - /usr/sbin/config -m LINT-VIMAGE TB --- 2012-04-10 04:48:35 - building LINT-VIMAGE kernel TB --- 2012-04-10 04:48:35 - CROSS_BUILD_TESTING=YES TB --- 2012-04-10 04:48:35 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-10 04:48:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-10 04:48:35 - SRCCONF=/dev/null TB --- 2012-04-10 04:48:35 - TARGET=i386 TB --- 2012-04-10 04:48:35 - TARGET_ARCH=i386 TB --- 2012-04-10 04:48:35 - TZ=UTC TB --- 2012-04-10 04:48:35 - __MAKE_CONF=/dev/null TB --- 2012-04-10 04:48:35 - cd /src TB --- 2012-04-10 04:48:35 - /usr/bin/make -B buildkernel KERNCONF=LINT-VIMAGE >>> Kernel build for LINT-VIMAGE started on Tue Apr 10 04:48:35 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-VIMAGE completed on Tue Apr 10 05:21:05 UTC 2012 TB --- 2012-04-10 05:21:05 - cd /src/sys/i386/conf TB --- 2012-04-10 05:21:05 - /usr/sbin/config -m GENERIC TB --- 2012-04-10 05:21:05 - building GENERIC kernel TB --- 2012-04-10 05:21:05 - CROSS_BUILD_TESTING=YES TB --- 2012-04-10 05:21:05 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-10 05:21:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-10 05:21:05 - SRCCONF=/dev/null TB --- 2012-04-10 05:21:05 - TARGET=i386 TB --- 2012-04-10 05:21:05 - TARGET_ARCH=i386 TB --- 2012-04-10 05:21:05 - TZ=UTC TB --- 2012-04-10 05:21:05 - __MAKE_CONF=/dev/null TB --- 2012-04-10 05:21:05 - cd /src TB --- 2012-04-10 05:21:05 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Tue Apr 10 05:21:05 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 GENERIC completed on Tue Apr 10 05:46:57 UTC 2012 TB --- 2012-04-10 05:46:57 - cd /src/sys/i386/conf TB --- 2012-04-10 05:46:57 - /usr/sbin/config -m PAE TB --- 2012-04-10 05:46:57 - building PAE kernel TB --- 2012-04-10 05:46:57 - CROSS_BUILD_TESTING=YES TB --- 2012-04-10 05:46:57 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-10 05:46:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-10 05:46:57 - SRCCONF=/dev/null TB --- 2012-04-10 05:46:57 - TARGET=i386 TB --- 2012-04-10 05:46:57 - TARGET_ARCH=i386 TB --- 2012-04-10 05:46:57 - TZ=UTC TB --- 2012-04-10 05:46:57 - __MAKE_CONF=/dev/null TB --- 2012-04-10 05:46:57 - cd /src TB --- 2012-04-10 05:46:57 - /usr/bin/make -B buildkernel KERNCONF=PAE >>> Kernel build for PAE started on Tue Apr 10 05:46:57 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 PAE completed on Tue Apr 10 05:53:49 UTC 2012 TB --- 2012-04-10 05:53:49 - cd /src/sys/i386/conf TB --- 2012-04-10 05:53:49 - /usr/sbin/config -m XBOX TB --- 2012-04-10 05:53:49 - building XBOX kernel TB --- 2012-04-10 05:53:49 - CROSS_BUILD_TESTING=YES TB --- 2012-04-10 05:53:49 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-10 05:53:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-10 05:53:49 - SRCCONF=/dev/null TB --- 2012-04-10 05:53:49 - TARGET=i386 TB --- 2012-04-10 05:53:49 - TARGET_ARCH=i386 TB --- 2012-04-10 05:53:49 - TZ=UTC TB --- 2012-04-10 05:53:49 - __MAKE_CONF=/dev/null TB --- 2012-04-10 05:53:49 - cd /src TB --- 2012-04-10 05:53:49 - /usr/bin/make -B buildkernel KERNCONF=XBOX >>> Kernel build for XBOX started on Tue Apr 10 05:53:49 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 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/i386/i386/initcpu.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 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/i386/i386/io.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 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/i386/i386/k6_mem.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 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/i386/i386/machdep.c cc1: warnings being treated as errors /src/sys/i386/i386/machdep.c: In function 'cpu_startup': /src/sys/i386/i386/machdep.c:343: warning: implicit declaration of function 'intr_add_cpu' /src/sys/i386/i386/machdep.c:343: warning: nested extern declaration of 'intr_add_cpu' [-Wnested-externs] *** Error code 1 Stop in /obj/i386.i386/src/sys/XBOX. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-04-10 05:57:03 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-04-10 05:57:03 - ERROR: failed to build XBOX kernel TB --- 2012-04-10 05:57:03 - 15627.28 user 2150.67 system 20222.85 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Tue Apr 10 06:31:57 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09406106566B; Tue, 10 Apr 2012 06:31:57 +0000 (UTC) (envelope-from stefan@fafoe.narf.at) Received: from fep16.mx.upcmail.net (fep16.mx.upcmail.net [62.179.121.36]) by mx1.freebsd.org (Postfix) with ESMTP id 2620D8FC1F; Tue, 10 Apr 2012 06:31:55 +0000 (UTC) Received: from edge01.upcmail.net ([192.168.13.236]) by viefep16-int.chello.at (InterMail vM.8.01.05.05 201-2260-151-110-20120111) with ESMTP id <20120410063154.HOCJ15021.viefep16-int.chello.at@edge01.upcmail.net>; Tue, 10 Apr 2012 08:31:54 +0200 Received: from mole.fafoe.narf.at ([80.109.55.137]) by edge01.upcmail.net with edge id w6Xt1i03L2xdvHc016XuPr; Tue, 10 Apr 2012 08:31:54 +0200 X-SourceIP: 80.109.55.137 Received: by mole.fafoe.narf.at (Postfix, from userid 1001) id CB07C6D458; Tue, 10 Apr 2012 08:31:53 +0200 (CEST) Date: Tue, 10 Apr 2012 08:31:53 +0200 From: Stefan Farfeleder To: AN Message-ID: <20120410063153.GA1458@mole.fafoe.narf.at> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: gnome@freebsd.org, freebsd-current@freebsd.org Subject: Re: recent update breaks some ports X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 06:31:57 -0000 On Tue, Apr 10, 2012 at 01:44:02AM -0400, AN wrote: > FreeBSD FBSD10 10.0-CURRENT FreeBSD 10.0-CURRENT #7 r234042: Sun Apr 8 > 17:36:38 EDT 2012 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL amd64 > > After a recent update on Sunday to r234042 I am having a problem with 2 > ports: > > gedit > evince > (using Gnome2 - ports tree up to date) > > My last update (before this past Sun build/install world) was 2 weeks ago, > so it was definitely a change made in the last 2 weeks. > > Gedit will not start from the command line, or the applications menu. > There is no error message on the command line. Evince will start, however > when you try to open a document the program freezes. > > I have tried to: > make deinstall > make clean > make install clean > > for both ports but they are still broken. I would appreciate any help. I'm experiencing that too (r234038), xine also no longer starts (hangs at splash screen). Stefan From owner-freebsd-current@FreeBSD.ORG Tue Apr 10 07:31:14 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C760A1065686 for ; Tue, 10 Apr 2012 07:31:14 +0000 (UTC) (envelope-from atz@ukr.net) Received: from ffe16.ukr.net (ffe16.ukr.net [195.214.192.51]) by mx1.freebsd.org (Postfix) with ESMTP id 705388FC14 for ; Tue, 10 Apr 2012 07:31:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Date:Message-Id:From:To:Subject:Content-Type:Content-Transfer-Encoding:MIME-Version; bh=XjheGF0TcDW6nd7+85UDocnzxd6mtZccrrymPwTs07I=; b=DIdHQsyaWBMOE9RCf3KaHtmhc/zSEPmyebL/rdAKpkCnLZvLQOgyzqMD5dTopOJu+SyVRFd9xKG1O7bSJoDbI8HMJyckq/cOXcR76voG0G9pc9adZVZTb50kXsJAWpT2Ojrr4G6PBO34320xncWVx0jZ+iZ8Y7JgFjtO7cU+zho=; Received: from mail by ffe16.ukr.net with local ID 1SHVIn-0001al-Ia for freebsd-current@freebsd.org; Tue, 10 Apr 2012 10:15:45 +0300 MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: binary Content-Type: text/plain; charset="windows-1251" To: freebsd-current@freebsd.org From: "Vladimir Sharun" X-Mailer: freemail.ukr.net 4.0 X-Originating-Ip: [212.42.67.66] Message-Id: <2935.1334042145.9972356356118413312@ffe16.ukr.net> X-Browser: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120409 Firefox/14.0a1 Date: Tue, 10 Apr 2012 10:15:45 +0300 Subject: Recent changes in libthr broke base bind package tools and named on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 07:31:14 -0000 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 0x000000080123ae4c in kevent () from /lib/libc.so.7 #1 0x000000000052a250 in ?? () #2 0x0000000800d64cdd in pthread_create () from /lib/libthr.so.3 #3 0x0000000000000000 in ?? () Error accessing memory address 0x7fffff7fc000 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 From owner-freebsd-current@FreeBSD.ORG Tue Apr 10 08:49:20 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 87D69106564A for ; Tue, 10 Apr 2012 08:49:20 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from mx.lissyara.su (mx.lissyara.su [91.227.18.11]) by mx1.freebsd.org (Postfix) with ESMTP id 355338FC19 for ; Tue, 10 Apr 2012 08:49:20 +0000 (UTC) Received: from [195.93.240.5] (port=27476 helo=lissyara.moskb.local) by mx.lissyara.su with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SHWlE-000KwS-QX for freebsd-current@freebsd.org; Tue, 10 Apr 2012 12:49:12 +0400 Message-ID: <4F83F408.3080204@lissyara.su> Date: Tue, 10 Apr 2012 12:49:12 +0400 From: Alex Keda User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; ru-RU; rv:1.8.1.23) Gecko/20091202 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4F828168.2030709@lissyara.su> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-White-List: YES X-Spam-Description: if spam count > 60 - this is spam X-Spam-Count: 0 X-Descriptions: powered by www.lissyara.su X-Bounce-ID: mx.lissyara.su Subject: Re: r234000: i386 freeze when HT enabled X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 08:49:20 -0000 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- From owner-freebsd-current@FreeBSD.ORG Tue Apr 10 09:17:35 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E75D106566B for ; Tue, 10 Apr 2012 09:17:35 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 750B18FC14 for ; Tue, 10 Apr 2012 09:17:34 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA08441; Tue, 10 Apr 2012 12:17:25 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1SHXCX-000HiH-CN; Tue, 10 Apr 2012 12:17:25 +0300 Message-ID: <4F83FAA2.2010505@FreeBSD.org> Date: Tue, 10 Apr 2012 12:17:22 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120317 Thunderbird/10.0.3 MIME-Version: 1.0 To: Alex Keda References: <4F828168.2030709@lissyara.su> <4F83F408.3080204@lissyara.su> In-Reply-To: <4F83F408.3080204@lissyara.su> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-current@FreeBSD.org Subject: Re: r234000: i386 freeze when HT enabled X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 09:17:35 -0000 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 From owner-freebsd-current@FreeBSD.ORG Tue Apr 10 09:37:33 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E9CDC1065679 for ; Tue, 10 Apr 2012 09:37:32 +0000 (UTC) (envelope-from ohartman@mail.zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 9DA278FC0A for ; Tue, 10 Apr 2012 09:37:32 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1SHXVu-00087R-IP>; Tue, 10 Apr 2012 11:37:26 +0200 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1SHXVu-00072n-ET>; Tue, 10 Apr 2012 11:37:26 +0200 Message-ID: <4F83FF50.1010404@mail.zedat.fu-berlin.de> Date: Tue, 10 Apr 2012 11:37:20 +0200 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120314 Thunderbird/10.0.3 MIME-Version: 1.0 To: Current FreeBSD X-Enigmail-Version: 1.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0599FA1487E4C8AD44885D07" X-Originating-IP: 130.133.86.198 X-Mailman-Approved-At: Tue, 10 Apr 2012 11:13:43 +0000 Subject: Changes to sbin/init/init.c (r233944) makes x11/xdm impossible to start from /etc/ttys X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 09:37:33 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0599FA1487E4C8AD44885D07 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable 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: =3D=3D=3D Index: sbin/init/init.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- 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 =3D open(_PATH_CONSOLE, O_RDWR | O_NONBLOCK)) !=3D -1) { + (void)fcntl(fd, F_SETFL, fcntl(fd, F_GETFL) & ~O_NONBLOCK= ); if (login_tty(fd) =3D=3D 0) return; close(fd); =3D=3D=3D Reverting init.c back to its previous state seems to make the error go aw= ay. The error xdm is loggin is: =3D=3D=3D 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, (=3D=3D) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (=3D=3D) Log file: "/var/log/Xorg.0.log", Time: Sat Apr 7 18:38:24 2012 (=3D=3D) 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 =3D=3D=3D 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 --------------enig0599FA1487E4C8AD44885D07 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJPg/9WAAoJEOgBcD7A/5N8rJ4IAIKw+drQXSBKO6JyfMZ7I787 0/RIAvdvxNyFzRgPgy2hTMRIhVtAJ03KuxVXOhcQKWbsY/qqu7xTwaLOpHdsBPo2 rSu4wA0RldYHGS8PcdL5sCZCVapFlVAszC6kGcopmDjtgNvQml/r10j9uOWGfAgw mHaXxSqFj0gSdBp84Et7mDiIE20A/dIznoGz5k8mOy4w9Bq204l43iORGsyA3rt0 a/gSU1lDmUBe56CUtPlZO3luk8fVrbKwSCVub1u3FlDkkLZDXNWt1G36XQ10FAM7 J2vz4waOa+Eek1Kgw1E+NRfajewGd3Ls94w9yZWz5vYjKcnuMB1NWlXT7wnEjJA= =tHPP -----END PGP SIGNATURE----- --------------enig0599FA1487E4C8AD44885D07-- From owner-freebsd-current@FreeBSD.ORG Tue Apr 10 11:20:00 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ED023106564A for ; Tue, 10 Apr 2012 11:20:00 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id A1E0C8FC0C for ; Tue, 10 Apr 2012 11:20:00 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1SHZ70-0005SR-E2 for freebsd-current@freebsd.org; Tue, 10 Apr 2012 13:19:50 +0200 Received: from office-nat.spylog.net ([193.169.234.6]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Apr 2012 13:19:50 +0200 Received: from citrin by office-nat.spylog.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Apr 2012 13:19:50 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Anton Yuzhaninov Date: Tue, 10 Apr 2012 11:19:37 +0000 (UTC) Organization: Vega Lines: 23 Sender: Anton Yuzhaninov Message-ID: X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: office-nat.spylog.net User-Agent: tin/1.9.6-20101126 ("Burnside") (UNIX) (FreeBSD/10.0-CURRENT (i386)) Subject: gstat don't work after update to 10.0-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 11:20:01 -0000 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/s r/s kBps ms/r w/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 From owner-freebsd-current@FreeBSD.ORG Tue Apr 10 11:50:42 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 41AEF1065670 for ; Tue, 10 Apr 2012 11:50:42 +0000 (UTC) (envelope-from sg2342@googlemail.com) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by mx1.freebsd.org (Postfix) with ESMTP id C4DB18FC08 for ; Tue, 10 Apr 2012 11:50:41 +0000 (UTC) Received: by wibhq7 with SMTP id hq7so2895562wib.13 for ; Tue, 10 Apr 2012 04:50:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; bh=46SFzYChAKZhmS7N7BT9IhuimF3OI5kk5Cb1+GPwVEM=; b=SuohaJUlZJYpjLsyKdxsften7akiz91hQh9Gbn9RImZoopLPwBFvyiTCEakYGvvmtt rCtHkwTQIyKHcT8MaWfo1JK5B5iZbSv7SwECjYD04CopOCFw5/X1fEnS0nYAPL8P4UNn /VoPMfx8/2J2LGy/VANjAVaD0bEM2Jz74QccRGuPwPcX3RHm5zreQsH3YcNgDEKFNQlt wDTzxgyoLbYdQWZZFzy4GSXGM8FNqjLpZvu/mKqLLmo1Eedh2E4o+sdq0OCF2n1FhAL3 LoQcJVTVrPpFjS0PAhJ9ZFWIwBIwKzGJj1zvfW3CpNBK2+pj3V0g6z7XQL6N8wrVp2X1 eKHg== Received: by 10.180.81.166 with SMTP id b6mr6386589wiy.0.1334058635608; Tue, 10 Apr 2012 04:50:35 -0700 (PDT) Received: from localhost (i59F739CA.versanet.de. [89.247.57.202]) by mx.google.com with ESMTPS id n20sm60344254wiw.5.2012.04.10.04.50.34 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 10 Apr 2012 04:50:35 -0700 (PDT) Date: Tue, 10 Apr 2012 11:50:29 +0000 From: Stefan Grundmann To: freebsd-current@freebsd.org Message-ID: <20120410115029.63a70bb6@googlemail.com> In-Reply-To: <20120410063153.GA1458@mole.fafoe.narf.at> References: <20120410063153.GA1458@mole.fafoe.narf.at> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: recent update breaks some ports X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 11:50:42 -0000 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 From owner-freebsd-current@FreeBSD.ORG Tue Apr 10 11:53:07 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DE6B7106566C for ; Tue, 10 Apr 2012 11:53:07 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 98FBD8FC1C for ; Tue, 10 Apr 2012 11:53:07 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1SHZdC-0002cS-KK for freebsd-current@freebsd.org; Tue, 10 Apr 2012 13:53:06 +0200 Received: from office-nat.spylog.net ([193.169.234.6]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Apr 2012 13:53:06 +0200 Received: from citrin by office-nat.spylog.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Apr 2012 13:53:06 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Anton Yuzhaninov Date: Tue, 10 Apr 2012 11:52:57 +0000 (UTC) Organization: Vega Lines: 28 Sender: Anton Yuzhaninov Message-ID: References: X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: office-nat.spylog.net X-Comment-To: Anton Yuzhaninov User-Agent: tin/1.9.6-20101126 ("Burnside") (UNIX) (FreeBSD/10.0-CURRENT (i386)) Subject: Re: gstat don't work after update to 10.0-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 11:53:07 -0000 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/s r/s kBps ms/r w/s kBps ms/w %busy Name AY> # After reverting r233646 gstat show: dT: 1.001s w: 1.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name 0 0 0 0 0.0 0 0 0.0 0.0 ada0 0 0 0 0 0.0 0 0 0.0 0.0 ada0s1 0 0 0 0 0.0 0 0 0.0 0.0 ada1 1 392 392 1903 2.3 0 0 0.0 91.6 ada2 0 0 0 0 0.0 0 0 0.0 0.0 ada1s1 1 392 392 1903 2.4 0 0 0.0 92.5 ufs/backup 0 0 0 0 0.0 0 0 0.0 0.0 mirror/gm0 0 0 0 0 0.0 0 0 0.0 0.0 mirror/gm0a 0 0 0 0 0.0 0 0 0.0 0.0 mirror/gm0b 0 0 0 0 0.0 0 0 0.0 0.0 mirror/gm0d so problem somewhere in http://svn.freebsd.org/changeset/base/233646 -- Anton Yuzhaninov From owner-freebsd-current@FreeBSD.ORG Tue Apr 10 12:27:09 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3FE621065672 for ; Tue, 10 Apr 2012 12:27:09 +0000 (UTC) (envelope-from andriy@irbisnet.com) Received: from nm1-vm0.bullet.mail.sp2.yahoo.com (nm1-vm0.bullet.mail.sp2.yahoo.com [98.139.91.202]) by mx1.freebsd.org (Postfix) with SMTP id E7E998FC18 for ; Tue, 10 Apr 2012 12:27:08 +0000 (UTC) Received: from [98.139.91.62] by nm1.bullet.mail.sp2.yahoo.com with NNFMP; 10 Apr 2012 12:27:08 -0000 Received: from [98.139.44.82] by tm2.bullet.mail.sp2.yahoo.com with NNFMP; 10 Apr 2012 12:27:08 -0000 Received: from [127.0.0.1] by omp1019.access.mail.sp2.yahoo.com with NNFMP; 10 Apr 2012 12:27:08 -0000 X-Yahoo-Newman-Id: 645921.88528.bm@omp1019.access.mail.sp2.yahoo.com Received: (qmail 28850 invoked from network); 10 Apr 2012 12:27:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1334060828; bh=ckZ3csC0apNE2KZfxSghD0m+3nGBbW3fgULRNRJr2qQ=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Received:References:In-Reply-To:Mime-Version:Content-Transfer-Encoding:Content-Type:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=ATHZiqgr1xRf8f6pG+FMvuKFI2C1v2VOi3SiWvpnRwUaVhwpdCybkR5IukRaRfjxjX2bsqD0aIDP04vMlZV0NoSJHwBSmJwD9yuFXNanv2ant3/7wSMUia+BmimtUmeIj0hTRGndXu2YTn4lUBCwqOVatb5bghYkHQ+AMHXA0rM= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: ew_8sgwVM1kyP7aYFPOAV7fE1jS4Z25gEbrwWWvYZLKc6PC Z3RhuvCyICn66I.C6ldaFt2nxROvJ5u5RPrlLfScGbT4ma07umTDgUXen9us rJE2hmz2HALkixcXdMK1zUFF4kZ5NRc89vn_Dwrdwyow2PDap591GqnrioDi 66JITerAEoLooF8DX80aNnNzaG8xerAsTIQouVfeO9uklrM4u7.nv5fvrY_O Bh8F7f8bQovP.IT0UIGFJeC4OzHecTtlFF2PSQvuz8jrwQe.2_693lFWiMRE PvXjdaO9qEjBW3WUUHKb2RAGGOMFi9AsE5Lie228ERJ6DOjs38eXxtq8lXUS _u3WQGvHkWAiCQRKR9Mmyr5JamWWGnmNGe.XxcsLv44RGF38dd1nbI0yUF5Y 6Q8cUh_I9sml8U6LN12f4WKphxoaZVTJV9dr1yawRPDDP5L3pkf.guE1qhgn q.2Rb61hcKn5Y5HTUSrR_yimYnb8GL9vYS6OPYegxMq23OVM33z0- X-Yahoo-SMTP: dz9sigaswBA5kWoYWVTZrGHmIs2vaKgG1w-- Received: from smtp.irbisnet.com (andriy@174.113.73.248 with login) by smtp108.rog.mail.gq1.yahoo.com with SMTP; 10 Apr 2012 05:27:07 -0700 PDT Received: from [192.168.0.9] (Andriy-Bakays-iPhone.local [192.168.0.9]) by smtp.irbisnet.com (Postfix) with ESMTPSA id 705902F62C; Tue, 10 Apr 2012 08:27:06 -0400 (EDT) References: <4F69A3C1.7040305@omnilan.de> <20120321100905.GN5886@equilibrium.bsdes.net> <4F69B1B0.3040005@FreeBSD.org> In-Reply-To: <4F69B1B0.3040005@FreeBSD.org> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Message-Id: <44AFA6EF-D29A-4F50-B3F7-E543AEC81416@irbisnet.com> X-Mailer: iPhone Mail (9B176) From: Andriy Bakay Date: Tue, 10 Apr 2012 08:27:03 -0400 To: "Andrey V. Elsukov" X-Mailman-Approved-At: Tue, 10 Apr 2012 12:46:45 +0000 Cc: Victor Balada Diaz , FreeBSD current , "fs@freebsd.org" , Harald Schmalzbauer Subject: Re: Idea for GEOM and policy based file encryption X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 12:27:09 -0000 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-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" Or you can check PEFS kernel module for FreeBSD. It is in the ports. From owner-freebsd-current@FreeBSD.ORG Tue Apr 10 13:01:37 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D3A261065670; Tue, 10 Apr 2012 13:01:37 +0000 (UTC) (envelope-from kwhite@site.uottawa.ca) Received: from courriel.site.uottawa.ca (eecsmail.engineering.uottawa.ca [137.122.24.224]) by mx1.freebsd.org (Postfix) with ESMTP id 6F5E68FC15; Tue, 10 Apr 2012 13:01:37 +0000 (UTC) Received: from demo (dsl-74-51-53-177.vianet.ca [74.51.53.177]) (authenticated bits=0) by courriel.site.uottawa.ca (8.14.4/8.14.4) with ESMTP id q3AD1XAg093764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 10 Apr 2012 09:01:34 -0400 (EDT) (envelope-from kwhite@site.uottawa.ca) Date: Tue, 10 Apr 2012 09:01:35 -0400 (EDT) From: Keith White X-X-Sender: kwhite@demo To: Daichi GOTO In-Reply-To: <20120410112834.56bb2d02.daichi@freebsd.org> Message-ID: References: <55056.74.51.53.177.1333762589.squirrel@courriel.site.uottawa.ca> <20120408221127.969e8e71.daichi@freebsd.org> <14043.74.51.53.177.1333981899.squirrel@courriel.site.uottawa.ca> <20120410112834.56bb2d02.daichi@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Tue, 10 Apr 2012 13:44:55 +0000 Cc: freebsd-current@freebsd.org Subject: Re: (unionfs) panic: excl->share with r230341 and above X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 13:01:37 -0000 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 From owner-freebsd-current@FreeBSD.ORG Tue Apr 10 13:58:29 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0CB5106567B; Tue, 10 Apr 2012 13:58:29 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id B2D348FC16; Tue, 10 Apr 2012 13:58:29 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id F1125B9BB; Tue, 10 Apr 2012 09:58:28 -0400 (EDT) From: John Baldwin To: Konstantin Belousov Date: Tue, 10 Apr 2012 09:56:06 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <20120407125056.GS2358@deviant.kiev.zoral.com.ua> <201204091536.08399.jhb@freebsd.org> <20120409200529.GT2358@deviant.kiev.zoral.com.ua> In-Reply-To: <20120409200529.GT2358@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201204100956.06750.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 10 Apr 2012 09:58:29 -0400 (EDT) Cc: Ian Lepore , freebsd-drivers@freebsd.org, current@freebsd.org Subject: Re: device_attach(9) and driver initialization X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 13:58:30 -0000 On Monday, April 09, 2012 4:05:29 pm Konstantin Belousov wrote: > On Mon, Apr 09, 2012 at 03:36:08PM -0400, John Baldwin wrote: > > On Monday, April 09, 2012 3:10:00 pm Konstantin Belousov wrote: > > > On Mon, Apr 09, 2012 at 11:01:03AM -0400, John Baldwin wrote: > > > > On Saturday, April 07, 2012 11:08:41 pm Warner Losh wrote: > > > > > > > > > > On Apr 7, 2012, at 8:46 AM, Ian Lepore wrote: > > > > > > > > > > > On Sat, 2012-04-07 at 15:50 +0300, Konstantin Belousov wrote: > > > > > >> Hello, > > > > > >> there seems to be a problem with device attach sequence offered by > > > > newbus. > > > > > >> Basically, when device attach method is executing, device is not fully > > > > > >> initialized yet. Also the device state in the newbus part of the world > > > > > >> is DS_ALIVE. There is definitely no shattering news in the statements, > > > > > >> but drivers that e.g. create devfs node to communicate with consumers > > > > > >> are prone to a race. > > > > > >> > > > > > >> If /dev node is created inside device attach method, then usermode > > > > > >> can start calling cdevsw methods before device fully initialized itself. > > > > > >> Even more, if device tries to use newbus helpers in cdevsw methods, > > > > > >> like device_busy(9), then panic occurs "called for unatteched device". > > > > > >> I get reports from users about this issues, to it is not something > > > > > >> that only could happen. > > > > > >> > > > > > >> I propose to add DEVICE_AFTER_ATTACH() driver method, to be called > > > > > >> from newbus right after device attach finished and newbus considers > > > > > >> the device fully initialized. Driver then could create devfs node > > > > > >> in the after_attach method instead of attach. Please see the patch below. > > > > > >> > > > > > >> diff --git a/sys/kern/device_if.m b/sys/kern/device_if.m > > > > > >> index eb720eb..9db74e2 100644 > > > > > >> --- a/sys/kern/device_if.m > > > > > >> +++ b/sys/kern/device_if.m > > > > > >> @@ -43,6 +43,10 @@ INTERFACE device; > > > > > >> # Default implementations of some methods. > > > > > >> # > > > > > >> CODE { > > > > > >> + static void null_after_attach(device_t dev) > > > > > >> + { > > > > > >> + } > > > > > >> + > > > > > >> static int null_shutdown(device_t dev) > > > > > >> { > > > > > >> return 0; > > > > > >> @@ -199,6 +203,21 @@ METHOD int attach { > > > > > >> }; > > > > > >> > > > > > >> /** > > > > > >> + * @brief Notify the driver that device is in attached state > > > > > >> + * > > > > > >> + * Called after driver is successfully attached to the device and > > > > > >> + * corresponding device_t is fully operational. Driver now may expose > > > > > >> + * the device to the consumers, e.g. create devfs nodes. > > > > > >> + * > > > > > >> + * @param dev the device to probe > > > > > >> + * > > > > > >> + * @see DEVICE_ATTACH() > > > > > >> + */ > > > > > >> +METHOD void after_attach { > > > > > >> + device_t dev; > > > > > >> +} DEFAULT null_after_attach; > > > > > >> + > > > > > >> +/** > > > > > >> * @brief Detach a driver from a device. > > > > > >> * > > > > > >> * This can be called if the user is replacing the > > > > > >> diff --git a/sys/kern/subr_bus.c b/sys/kern/subr_bus.c > > > > > >> index d485b9f..6d849cb 100644 > > > > > >> --- a/sys/kern/subr_bus.c > > > > > >> +++ b/sys/kern/subr_bus.c > > > > > >> @@ -2743,6 +2743,7 @@ device_attach(device_t dev) > > > > > >> dev->state = DS_ATTACHED; > > > > > >> dev->flags &= ~DF_DONENOMATCH; > > > > > >> devadded(dev); > > > > > >> + DEVICE_AFTER_ATTACH(dev); > > > > > >> return (0); > > > > > >> } > > > > > >> > > > > > > > > > > > > Does device_get_softc() work before attach is completed? (I don't have > > > > > > time to go look in the code right now). If so, then a mutex initialized > > > > > > and acquired early in the driver's attach routine, and also acquired in > > > > > > the driver's cdev implementation routines before using any newbus > > > > > > functions other than device_get_softc(), would solve the problem without > > > > > > a driver api change that would make it harder to backport/MFC driver > > > > > > changes. > > > > > > > > > > Also, more generally, don't create the dev nodes before you are ready to > > > > deal with requests. Why do we need to uglify everything here? If you can't > > > > do that, you can check a bit in the softc and return EBUSY or ENXIO on open if > > > > that bit says that your driver isn't ready to accept requests. > > > > > > > > I agree, this dosen't actually fix anything as the decision for what to put > > > > in your foo_attach() method rather than foo_after_attach() is non-obvious and > > > > very arbitrary. > > > > > > > > The actual bug appears to only be with using 'device_busy()'. I think > > > > this should be fixed by making device_busy() better, not by adding > > > > this type of obfuscation to attach. It should be trivial to make > > > > device_busy() safe to use on a device that is currently being attached > > > > which will not require any changes to drivers. > > > > > > Could you, please, elaborate your proposal ? How do you think device_busy() > > > can be enchanced ? > > > > > > Obvious idea to sleep inside device_busy() until dev->state becomes != > > > DS_ATTACHED is no go, IMO. The issue is that this causes immediate deadlocks > > > if device_attach() method needs to call destroy_dev() to rollback. > > > > I think you could have a DS_ATTACHING state and allow device_busy() to work > > for DS_ATTACHING. The idea being that it is a bug for a driver to invoke > > device_busy() if it is going to fail attach. You may then need to do a fixup > > in device_attach() to promote the state from DS_ATTACHED to DS_BUSY when it > > returns if there is a non-zero busy count. > This is quite good idea, but it still adds burden to device author, > although I agree that this is manageable. A scenario I have in mind now > is the following: > assume that driver needs to create two devfs nodes, lets name them > dri/card0 and dri/forcewake0. Driver would perform two make_dev_p(9) > calls, and while creation of dri/card0 succeed, consequent creation > of dri/forcewake0 could fail for numerous reasons. > > Now, the driver needs to ensure that cdesvw->d_open() on dri/card0 > would return ENXIO until dri/forcewake0 is created. This can be implemented > with flag, indeed. But still somewhat muddy, and probably leads to > user-visible errors (I mostly worry about graphical login managers). You could also sleep on the flag in d_open() (you can imagine a two-step process where you set a "adding cdev's flag", then all d_open() calls block on it). Then when finished adding cdev's, you set a flag if an error occurred and wake up all the waiters. If no error occured the waiters can have the first open() work fine. But even with other proposals you still have to deal with this problem if you want to fail out entirely if you have problems creating cdevs. > But for single-node drivers it is indeed a nice solution. I think we are somewhat stuck with this for other reasons as well. Note that device_busy() propagates up the tree to parent devices, so imagine kldloading a driver that creates a tree (e.g. a bus with a few consumers) where the leaf devices are attached by a call to bus_generic_attach() from the device_attach() method for the parent device. Even if you add a DEVICE_AFTER_ATTACH() hook, while it may allow device_busy() to be invoked on the leaf device, when it tries to propagate device_busy() up to the parent device it would still be in the middle of attach and blow up anyway. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Apr 10 14:05:56 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F3B6F106566B for ; Tue, 10 Apr 2012 14:05:55 +0000 (UTC) (envelope-from taku@tackymt.homeip.net) Received: from basalt.tackymt.homeip.net (unknown [IPv6:2001:3e0:577:0:20d:61ff:fecc:2253]) by mx1.freebsd.org (Postfix) with ESMTP id 96F5A8FC12 for ; Tue, 10 Apr 2012 14:05:55 +0000 (UTC) Received: from basalt.tackymt.homeip.net (localhost [127.0.0.1]) by basalt.tackymt.homeip.net (Postfix) with ESMTP id A867E83A0; Tue, 10 Apr 2012 23:05:54 +0900 (JST) X-Virus-Scanned: amavisd-new at tackymt.homeip.net Received: from localhost by basalt.tackymt.homeip.net (amavisd-new, unix socket) with ESMTP id VPiiHAWrjOdf; Tue, 10 Apr 2012 23:05:52 +0900 (JST) Received: from basalt.tackymt.homeip.net (basalt.tackymt.homeip.net [IPv6:2001:3e0:577:0:20d:61ff:fecc:2253]) by basalt.tackymt.homeip.net (Postfix) with ESMTPSA; Tue, 10 Apr 2012 23:05:52 +0900 (JST) Date: Tue, 10 Apr 2012 23:05:52 +0900 From: Taku YAMAMOTO To: "O. Hartmann" Message-Id: <20120410230552.32898234.taku@tackymt.homeip.net> In-Reply-To: <4F83FF50.1010404@mail.zedat.fu-berlin.de> References: <4F83FF50.1010404@mail.zedat.fu-berlin.de> X-Mailer: Sylpheed 3.0.3 (GTK+ 2.24.6; i386-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Current FreeBSD Subject: Re: Changes to sbin/init/init.c (r233944) makes x11/xdm impossible to start from /etc/ttys X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 14:05:56 -0000 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. From owner-freebsd-current@FreeBSD.ORG Tue Apr 10 14:38:01 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6B01D106566C; Tue, 10 Apr 2012 14:38:01 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id EE9E98FC12; Tue, 10 Apr 2012 14:38:00 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q3AEc0cw081034; Tue, 10 Apr 2012 10:38:00 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q3AEbxYw081021; Tue, 10 Apr 2012 14:37:59 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 10 Apr 2012 14:37:59 GMT Message-Id: <201204101437.q3AEbxYw081021@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 14:38:01 -0000 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 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-04-10 09:00:01 - starting HEAD tinderbox run for i386/i386 TB --- 2012-04-10 09:00:01 - cleaning the object tree TB --- 2012-04-10 09:04:36 - cvsupping the source tree TB --- 2012-04-10 09:04:36 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2012-04-10 09:05:42 - building world TB --- 2012-04-10 09:05:42 - CROSS_BUILD_TESTING=YES TB --- 2012-04-10 09:05:42 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-10 09:05:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-10 09:05:42 - SRCCONF=/dev/null TB --- 2012-04-10 09:05:42 - TARGET=i386 TB --- 2012-04-10 09:05:42 - TARGET_ARCH=i386 TB --- 2012-04-10 09:05:42 - TZ=UTC TB --- 2012-04-10 09:05:42 - __MAKE_CONF=/dev/null TB --- 2012-04-10 09:05:42 - cd /src TB --- 2012-04-10 09:05:42 - /usr/bin/make -B buildworld >>> World build started on Tue Apr 10 09:05:43 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Apr 10 11:23:21 UTC 2012 TB --- 2012-04-10 11:23:21 - generating LINT kernel config TB --- 2012-04-10 11:23:21 - cd /src/sys/i386/conf TB --- 2012-04-10 11:23:21 - /usr/bin/make -B LINT TB --- 2012-04-10 11:23:23 - cd /src/sys/i386/conf TB --- 2012-04-10 11:23:23 - /usr/sbin/config -m LINT TB --- 2012-04-10 11:23:23 - building LINT kernel TB --- 2012-04-10 11:23:23 - CROSS_BUILD_TESTING=YES TB --- 2012-04-10 11:23:23 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-10 11:23:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-10 11:23:23 - SRCCONF=/dev/null TB --- 2012-04-10 11:23:23 - TARGET=i386 TB --- 2012-04-10 11:23:23 - TARGET_ARCH=i386 TB --- 2012-04-10 11:23:23 - TZ=UTC TB --- 2012-04-10 11:23:23 - __MAKE_CONF=/dev/null TB --- 2012-04-10 11:23:23 - cd /src TB --- 2012-04-10 11:23:23 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Apr 10 11:23:23 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Tue Apr 10 11:56:58 UTC 2012 TB --- 2012-04-10 11:56:58 - cd /src/sys/i386/conf TB --- 2012-04-10 11:56:58 - /usr/sbin/config -m LINT-NOINET TB --- 2012-04-10 11:56:58 - building LINT-NOINET kernel TB --- 2012-04-10 11:56:58 - CROSS_BUILD_TESTING=YES TB --- 2012-04-10 11:56:58 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-10 11:56:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-10 11:56:58 - SRCCONF=/dev/null TB --- 2012-04-10 11:56:58 - TARGET=i386 TB --- 2012-04-10 11:56:58 - TARGET_ARCH=i386 TB --- 2012-04-10 11:56:58 - TZ=UTC TB --- 2012-04-10 11:56:58 - __MAKE_CONF=/dev/null TB --- 2012-04-10 11:56:58 - cd /src TB --- 2012-04-10 11:56:58 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Tue Apr 10 11:56:58 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET completed on Tue Apr 10 12:28:13 UTC 2012 TB --- 2012-04-10 12:28:13 - cd /src/sys/i386/conf TB --- 2012-04-10 12:28:13 - /usr/sbin/config -m LINT-NOINET6 TB --- 2012-04-10 12:28:13 - building LINT-NOINET6 kernel TB --- 2012-04-10 12:28:13 - CROSS_BUILD_TESTING=YES TB --- 2012-04-10 12:28:13 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-10 12:28:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-10 12:28:13 - SRCCONF=/dev/null TB --- 2012-04-10 12:28:13 - TARGET=i386 TB --- 2012-04-10 12:28:13 - TARGET_ARCH=i386 TB --- 2012-04-10 12:28:13 - TZ=UTC TB --- 2012-04-10 12:28:13 - __MAKE_CONF=/dev/null TB --- 2012-04-10 12:28:13 - cd /src TB --- 2012-04-10 12:28:13 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Tue Apr 10 12:28:14 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET6 completed on Tue Apr 10 13:00:04 UTC 2012 TB --- 2012-04-10 13:00:04 - cd /src/sys/i386/conf TB --- 2012-04-10 13:00:04 - /usr/sbin/config -m LINT-NOIP TB --- 2012-04-10 13:00:04 - building LINT-NOIP kernel TB --- 2012-04-10 13:00:04 - CROSS_BUILD_TESTING=YES TB --- 2012-04-10 13:00:04 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-10 13:00:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-10 13:00:04 - SRCCONF=/dev/null TB --- 2012-04-10 13:00:04 - TARGET=i386 TB --- 2012-04-10 13:00:04 - TARGET_ARCH=i386 TB --- 2012-04-10 13:00:04 - TZ=UTC TB --- 2012-04-10 13:00:04 - __MAKE_CONF=/dev/null TB --- 2012-04-10 13:00:04 - cd /src TB --- 2012-04-10 13:00:04 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOIP >>> Kernel build for LINT-NOIP started on Tue Apr 10 13:00:04 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-NOIP completed on Tue Apr 10 13:29:32 UTC 2012 TB --- 2012-04-10 13:29:32 - cd /src/sys/i386/conf TB --- 2012-04-10 13:29:32 - /usr/sbin/config -m LINT-VIMAGE TB --- 2012-04-10 13:29:32 - building LINT-VIMAGE kernel TB --- 2012-04-10 13:29:32 - CROSS_BUILD_TESTING=YES TB --- 2012-04-10 13:29:32 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-10 13:29:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-10 13:29:32 - SRCCONF=/dev/null TB --- 2012-04-10 13:29:32 - TARGET=i386 TB --- 2012-04-10 13:29:32 - TARGET_ARCH=i386 TB --- 2012-04-10 13:29:32 - TZ=UTC TB --- 2012-04-10 13:29:32 - __MAKE_CONF=/dev/null TB --- 2012-04-10 13:29:32 - cd /src TB --- 2012-04-10 13:29:32 - /usr/bin/make -B buildkernel KERNCONF=LINT-VIMAGE >>> Kernel build for LINT-VIMAGE started on Tue Apr 10 13:29: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 >>> Kernel build for LINT-VIMAGE completed on Tue Apr 10 14:02:25 UTC 2012 TB --- 2012-04-10 14:02:25 - cd /src/sys/i386/conf TB --- 2012-04-10 14:02:25 - /usr/sbin/config -m GENERIC TB --- 2012-04-10 14:02:25 - building GENERIC kernel TB --- 2012-04-10 14:02:25 - CROSS_BUILD_TESTING=YES TB --- 2012-04-10 14:02:25 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-10 14:02:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-10 14:02:25 - SRCCONF=/dev/null TB --- 2012-04-10 14:02:25 - TARGET=i386 TB --- 2012-04-10 14:02:25 - TARGET_ARCH=i386 TB --- 2012-04-10 14:02:25 - TZ=UTC TB --- 2012-04-10 14:02:25 - __MAKE_CONF=/dev/null TB --- 2012-04-10 14:02:25 - cd /src TB --- 2012-04-10 14:02:25 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Tue Apr 10 14:02:25 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 GENERIC completed on Tue Apr 10 14:27:49 UTC 2012 TB --- 2012-04-10 14:27:49 - cd /src/sys/i386/conf TB --- 2012-04-10 14:27:49 - /usr/sbin/config -m PAE TB --- 2012-04-10 14:27:49 - building PAE kernel TB --- 2012-04-10 14:27:49 - CROSS_BUILD_TESTING=YES TB --- 2012-04-10 14:27:49 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-10 14:27:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-10 14:27:49 - SRCCONF=/dev/null TB --- 2012-04-10 14:27:49 - TARGET=i386 TB --- 2012-04-10 14:27:49 - TARGET_ARCH=i386 TB --- 2012-04-10 14:27:49 - TZ=UTC TB --- 2012-04-10 14:27:49 - __MAKE_CONF=/dev/null TB --- 2012-04-10 14:27:49 - cd /src TB --- 2012-04-10 14:27:49 - /usr/bin/make -B buildkernel KERNCONF=PAE >>> Kernel build for PAE started on Tue Apr 10 14:27:49 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 PAE completed on Tue Apr 10 14:34:45 UTC 2012 TB --- 2012-04-10 14:34:45 - cd /src/sys/i386/conf TB --- 2012-04-10 14:34:45 - /usr/sbin/config -m XBOX TB --- 2012-04-10 14:34:45 - building XBOX kernel TB --- 2012-04-10 14:34:45 - CROSS_BUILD_TESTING=YES TB --- 2012-04-10 14:34:45 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-10 14:34:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-10 14:34:45 - SRCCONF=/dev/null TB --- 2012-04-10 14:34:45 - TARGET=i386 TB --- 2012-04-10 14:34:45 - TARGET_ARCH=i386 TB --- 2012-04-10 14:34:45 - TZ=UTC TB --- 2012-04-10 14:34:45 - __MAKE_CONF=/dev/null TB --- 2012-04-10 14:34:45 - cd /src TB --- 2012-04-10 14:34:45 - /usr/bin/make -B buildkernel KERNCONF=XBOX >>> Kernel build for XBOX started on Tue Apr 10 14:34:45 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 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/i386/i386/initcpu.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 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/i386/i386/io.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 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/i386/i386/k6_mem.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 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/i386/i386/machdep.c cc1: warnings being treated as errors /src/sys/i386/i386/machdep.c: In function 'cpu_startup': /src/sys/i386/i386/machdep.c:343: warning: implicit declaration of function 'intr_add_cpu' /src/sys/i386/i386/machdep.c:343: warning: nested extern declaration of 'intr_add_cpu' [-Wnested-externs] *** Error code 1 Stop in /obj/i386.i386/src/sys/XBOX. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-04-10 14:37:59 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-04-10 14:37:59 - ERROR: failed to build XBOX kernel TB --- 2012-04-10 14:37:59 - 15608.45 user 2157.20 system 20278.83 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Tue Apr 10 14:38:55 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 34132106564A; Tue, 10 Apr 2012 14:38:55 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 901BE8FC18; Tue, 10 Apr 2012 14:38:54 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q3AEcZkK056263; Tue, 10 Apr 2012 17:38:35 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q3AEcZ2x095469; Tue, 10 Apr 2012 17:38:35 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q3AEcZxs095468; Tue, 10 Apr 2012 17:38:35 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 10 Apr 2012 17:38:35 +0300 From: Konstantin Belousov To: John Baldwin Message-ID: <20120410143835.GZ2358@deviant.kiev.zoral.com.ua> References: <20120407125056.GS2358@deviant.kiev.zoral.com.ua> <201204091536.08399.jhb@freebsd.org> <20120409200529.GT2358@deviant.kiev.zoral.com.ua> <201204100956.06750.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1KpuWNmRW3f9lK5a" Content-Disposition: inline In-Reply-To: <201204100956.06750.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Ian Lepore , freebsd-drivers@freebsd.org, current@freebsd.org Subject: Re: device_attach(9) and driver initialization X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 14:38:55 -0000 --1KpuWNmRW3f9lK5a Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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: > > > > > >=20 > > > > > > On Apr 7, 2012, at 8:46 AM, Ian Lepore wrote: > > > > > >=20 > > > > > > > On Sat, 2012-04-07 at 15:50 +0300, Konstantin Belousov wrote: > > > > > > >> Hello, > > > > > > >> there seems to be a problem with device attach sequence offe= red by=20 > > > > > 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 s= tatements, > > > > > > >> but drivers that e.g. create devfs node to communicate with = consumers > > > > > > >> are prone to a race. > > > > > > >>=20 > > > > > > >> If /dev node is created inside device attach method, then us= ermode > > > > > > >> can start calling cdevsw methods before device fully initial= ized itself. > > > > > > >> Even more, if device tries to use newbus helpers in cdevsw m= ethods, > > > > > > >> like device_busy(9), then panic occurs "called for unatteche= d device". > > > > > > >> I get reports from users about this issues, to it is not som= ething > > > > > > >> that only could happen. > > > > > > >>=20 > > > > > > >> I propose to add DEVICE_AFTER_ATTACH() driver method, to be = called > > > > > > >> from newbus right after device attach finished and newbus co= nsiders > > > > > > >> the device fully initialized. Driver then could create devfs= node > > > > > > >> in the after_attach method instead of attach. Please see the= patch below. > > > > > > >>=20 > > > > > > >> 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 { > > > > > > >> }; > > > > > > >>=20 > > > > > > >> /** > > > > > > >> + * @brief Notify the driver that device is in attached state > > > > > > >> + * > > > > > > >> + * Called after driver is successfully attached to the devi= ce 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 =3D DS_ATTACHED; > > > > > > >> dev->flags &=3D ~DF_DONENOMATCH; > > > > > > >> devadded(dev); > > > > > > >> + DEVICE_AFTER_ATTACH(dev); > > > > > > >> return (0); > > > > > > >> } > > > > > > >>=20 > > > > > > >=20 > > > > > > > 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 a= cquired in > > > > > > > the driver's cdev implementation routines before using any ne= wbus > > > > > > > functions other than device_get_softc(), would solve the prob= lem without > > > > > > > a driver api change that would make it harder to backport/MFC= driver > > > > > > > changes. > > > > > >=20 > > > > > > Also, more generally, don't create the dev nodes before you are= ready to=20 > > > > > deal with requests. Why do we need to uglify everything here? I= f you can't=20 > > > > > do that, you can check a bit in the softc and return EBUSY or ENX= IO on open if=20 > > > > > that bit says that your driver isn't ready to accept requests. > > > > >=20 > > > > > I agree, this dosen't actually fix anything as the decision for w= hat to put > > > > > in your foo_attach() method rather than foo_after_attach() is non= -obvious and=20 > > > > > very arbitrary. > > > > >=20 > > > > > The actual bug appears to only be with using 'device_busy()'. I t= hink > > > > > this should be fixed by making device_busy() better, not by adding > > > > > this type of obfuscation to attach. It should be trivial to make > > > > > device_busy() safe to use on a device that is currently being att= ached > > > > > which will not require any changes to drivers. > > > >=20 > > > > Could you, please, elaborate your proposal ? How do you think devic= e_busy() > > > > can be enchanced ? > > > >=20 > > > > Obvious idea to sleep inside device_busy() until dev->state becomes= !=3D > > > > DS_ATTACHED is no go, IMO. The issue is that this causes immediate = deadlocks > > > > if device_attach() method needs to call destroy_dev() to rollback. > > >=20 > > > I think you could have a DS_ATTACHING state and allow device_busy() t= o work > > > for DS_ATTACHING. The idea being that it is a bug for a driver to in= voke > > > device_busy() if it is going to fail attach. You may then need to do= a fixup > > > in device_attach() to promote the state from DS_ATTACHED to DS_BUSY w= hen it > > > returns if there is a non-zero busy count. > > This is quite good idea, but it still adds burden to device author, > > although I agree that this is manageable. A scenario I have in mind now > > is the following: > > assume that driver needs to create two devfs nodes, lets name them > > dri/card0 and dri/forcewake0. Driver would perform two make_dev_p(9) > > calls, and while creation of dri/card0 succeed, consequent creation > > of dri/forcewake0 could fail for numerous reasons. > >=20 > > Now, the driver needs to ensure that cdesvw->d_open() on dri/card0 > > would return ENXIO until dri/forcewake0 is created. This can be impleme= nted > > with flag, indeed. But still somewhat muddy, and probably leads to > > user-visible errors (I mostly worry about graphical login managers). >=20 > You could also sleep on the flag in d_open() (you can imagine a two-step > process where you set a "adding cdev's flag", then all d_open() calls blo= ck > on it). Then when finished adding cdev's, you set a flag if an error > occurred and wake up all the waiters. If no error occured the waiters can > have the first open() work fine. But even with other proposals you still > have to deal with this problem if you want to fail out entirely if you > have problems creating cdevs. >=20 > > But for single-node drivers it is indeed a nice solution. >=20 > I think we are somewhat stuck with this for other reasons as well. Note > that device_busy() propagates up the tree to parent devices, so imagine > kldloading a driver that creates a tree (e.g. a bus with a few consumers) > where the leaf devices are attached by a call to bus_generic_attach() from > the device_attach() method for the parent device. Even if you add a > DEVICE_AFTER_ATTACH() hook, while it may allow device_busy() to be invoked > on the leaf device, when it tries to propagate device_busy() up to the > parent device it would still be in the middle of attach and blow up anywa= y. This looks like a bug in my implementation of after_attach, which apparently should be called for new tree after the top level attach finished. Anyway, would you commit your change ? I definitely can work out the driver change after. But this seems to be a large amount of work for driver authors. --1KpuWNmRW3f9lK5a Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk+EReoACgkQC3+MBN1Mb4g2oACg5H8O707oiuR1k1MaptmwgEJQ gM4An2WDMk7DX3F8qFaA2HzvGTPLJeXs =R09x -----END PGP SIGNATURE----- --1KpuWNmRW3f9lK5a-- From owner-freebsd-current@FreeBSD.ORG Tue Apr 10 16:58:08 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3380106566B; Tue, 10 Apr 2012 16:58:08 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id C65FB8FC15; Tue, 10 Apr 2012 16:58:07 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so3262108wgb.1 for ; Tue, 10 Apr 2012 09:58:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Q59w+zPOdamhK5KD4i7+Met1rRSz08k2Hp9St4xYIsk=; b=tusW4L9pAPzw8AKA2Bt4Nz0xRlFhnOXOKM8VxgSBzRFMbVYwGPBHzs3TnaQP/fz3d+ HhL2rK6TN6b/uGRb6rfvv6BfKMdjS5V8+UJ7xnZ1cB/e6dWF9QE5AEz910zR2ofcTBFO 94Dx0euDJ0EolEx7A0lM7XUI8q07cvBW1dZeDIU1MURqlVUgrtmFeHaUU5nWQ1ovvWIG qPVc1MlNTTQKunWQeX0MNYKEwy9jkpaGFi8mbGhd1FlOUAEJ9WQ6alUqY6TM0SSVwwT2 EwMbzhahnMo3QoYbul7a5kWpAPi0DM8ygA1oudXBQSJhIOuemd655IH/h4CHgM+gDFbZ 33Cg== MIME-Version: 1.0 Received: by 10.180.105.194 with SMTP id go2mr8674414wib.22.1334077081135; Tue, 10 Apr 2012 09:58:01 -0700 (PDT) Received: by 10.216.49.81 with HTTP; Tue, 10 Apr 2012 09:58:00 -0700 (PDT) In-Reply-To: <4F833F3D.7070106@FreeBSD.org> References: <4F2F7B7F.40508@FreeBSD.org> <4F366E8F.9060207@FreeBSD.org> <4F367965.6000602@FreeBSD.org> <4F396B24.5090602@FreeBSD.org> <4F3978BC.6090608@FreeBSD.org> <4F3990EA.1080002@FreeBSD.org> <4F3C0BB9.6050101@FreeBSD.org> <4F3E807A.60103@FreeBSD.org> <4F3E8858.4000001@FreeBSD.org> <4F7DE863.6080607@FreeBSD.org> <4F833F3D.7070106@FreeBSD.org> Date: Tue, 10 Apr 2012 12:58:00 -0400 Message-ID: From: Arnaud Lacombe To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, Jeff Roberson , Andriy Gapon , FreeBSD current Subject: Re: [RFT][patch] Scheduling for HTT and not only X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 16:58:09 -0000 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 From owner-freebsd-current@FreeBSD.ORG Tue Apr 10 17:18:51 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 744A0106564A; Tue, 10 Apr 2012 17:18:51 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5BCFC8FC08; Tue, 10 Apr 2012 17:18:50 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so26764bkc.13 for ; Tue, 10 Apr 2012 10:18:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=sfxBaRLiTNEGpdNHeefap/2DUvIvlLnDr1GFdM3chFg=; b=I4RcuaAM+kOlF68rSHIs7DO1YVtX9Hz4nqSWE0dGRfnGEqSVG8yDsR7Oo1HYS5KrJ3 CdZDi8tTEyJenuwhKPiUwiyRj/u1LrRnvvApWQh+OBJSo6wgSFSEgZzoeTpMnIBzVwJZ 17SrTW1LZTOLFwUrSANTwbvKXgWKrv3Q4eVrpPvzVfPpbIwKh5TvRoDKZ3qxx3lwWkoo WYNz5Pec8TB6MVCKoRHO3ZCVH+ZpQWX9qyWEXPnvbZrMGeYv2t+bF6VQCcLdrMvtsBvH CwSewb1got7r/2hcZP6b+0zRxJUx848EHSSiVqwFKWIf38nIo6CV5qzhWRrOLVjocAmI 074w== Received: by 10.205.130.12 with SMTP id hk12mr5201606bkc.76.1334078329126; Tue, 10 Apr 2012 10:18:49 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id iv11sm33330488bkc.16.2012.04.10.10.18.45 (version=SSLv3 cipher=OTHER); Tue, 10 Apr 2012 10:18:47 -0700 (PDT) Sender: Alexander Motin Message-ID: <4F846B74.9080504@FreeBSD.org> Date: Tue, 10 Apr 2012 20:18:44 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.2) Gecko/20120226 Thunderbird/10.0.2 MIME-Version: 1.0 To: Arnaud Lacombe References: <4F2F7B7F.40508@FreeBSD.org> <4F366E8F.9060207@FreeBSD.org> <4F367965.6000602@FreeBSD.org> <4F396B24.5090602@FreeBSD.org> <4F3978BC.6090608@FreeBSD.org> <4F3990EA.1080002@FreeBSD.org> <4F3C0BB9.6050101@FreeBSD.org> <4F3E807A.60103@FreeBSD.org> <4F3E8858.4000001@FreeBSD.org> <4F7DE863.6080607@FreeBSD.org> <4F833F3D.7070106@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Jeff Roberson , Andriy Gapon , FreeBSD current Subject: Re: [RFT][patch] Scheduling for HTT and not only X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 17:18:51 -0000 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 From owner-freebsd-current@FreeBSD.ORG Tue Apr 10 17:54:05 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E47301065672; Tue, 10 Apr 2012 17:54:04 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id CD77F8FC0A; Tue, 10 Apr 2012 17:54:03 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so62269bkc.13 for ; Tue, 10 Apr 2012 10:54:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=w9e/XgRJ3FTzoNhcbo6H0mrdvrDyCVpcWzvKgqWYpC4=; b=nEyTHXKnQ/zWvo5vY4TL9hXlL/v5hpJ8iK6RlAFXf1JMqLkPo26UgKEU2gvC66gLO2 gDB4JAIn7uKclOsknsEWkCeyFPSHdbW1/CLJ0bNivpg+a5JwqMzQuB2O6VXkON6vfe4v BhEQLOG+2QP/ty3uUa82miLzpewQNe+Nk0DpVPUAn/4Ne9MMNv7wboFsh3yF3Zx+EReq q0Xym5/+lZMK0vlvxSp31+ejP9I2WbPjSlyVGve3aNkoKgze2lavGsN9ZwCjd9Q2PHB+ au6cpZ8NTfA8xBMCHusPi0g/PbmQ4TaejRWUMHB2eoJWF3cvvHOhpi0XWVwaj8wp4Lws jm5Q== Received: by 10.205.139.77 with SMTP id iv13mr5022765bkc.91.1334080442881; Tue, 10 Apr 2012 10:54:02 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id f11sm50845bkw.6.2012.04.10.10.54.00 (version=SSLv3 cipher=OTHER); Tue, 10 Apr 2012 10:54:01 -0700 (PDT) Sender: Alexander Motin Message-ID: <4F8473B7.9080000@FreeBSD.org> Date: Tue, 10 Apr 2012 20:53:59 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.2) Gecko/20120226 Thunderbird/10.0.2 MIME-Version: 1.0 To: Arnaud Lacombe References: <4F2F7B7F.40508@FreeBSD.org> <4F366E8F.9060207@FreeBSD.org> <4F367965.6000602@FreeBSD.org> <4F396B24.5090602@FreeBSD.org> <4F3978BC.6090608@FreeBSD.org> <4F3990EA.1080002@FreeBSD.org> <4F3C0BB9.6050101@FreeBSD.org> <4F3E807A.60103@FreeBSD.org> <4F3E8858.4000001@FreeBSD.org> <4F7DE863.6080607@FreeBSD.org> <4F833F3D.7070106@FreeBSD.org> <4F846B74.9080504@FreeBSD.org> In-Reply-To: <4F846B74.9080504@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Jeff Roberson , Andriy Gapon , FreeBSD current Subject: Re: [RFT][patch] Scheduling for HTT and not only X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 17:54:05 -0000 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 From owner-freebsd-current@FreeBSD.ORG Tue Apr 10 18:46:13 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 07692106566C; Tue, 10 Apr 2012 18:46:13 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id C64AB8FC1B; Tue, 10 Apr 2012 18:46:11 +0000 (UTC) Received: by wibhj6 with SMTP id hj6so3197055wib.13 for ; Tue, 10 Apr 2012 11:46:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uyANYuAOOuvJOODLHG0VXES5rpeIfoiYAu3bRUI3ZC4=; b=Wea4h6iP3sClRs8fPlupqAI6d1iHzQA/2gbd1f9gQYFfxe4VTlJYmw/19dLjwLKOGI Q/VIwfoaBaULXYHg9FkNTsYl2mL/9/a87oVQiUuV+MdXIudq3TWFxbaJHbwJ/ZXCoR9F 641877BTSNemyPqCQSeKKYhAb5R2h9PWFnpaQT9XiCi/xDNk4eFT4yeHuDPvbKMpapyR 1gGgMHmZf2dUceRfuXrZxP1UQUlD2AFken0L560q2/b36Sr92BgeguRvH19IUejs6ayK Ajnl9kxiKp/CfV5nZac/gj4+wxZSApNIChCMLvWnKhsG3jYx3b9SFx0KvmUWW1z45Jbm M39Q== MIME-Version: 1.0 Received: by 10.180.88.164 with SMTP id bh4mr9343064wib.22.1334083570443; Tue, 10 Apr 2012 11:46:10 -0700 (PDT) Received: by 10.216.49.81 with HTTP; Tue, 10 Apr 2012 11:46:10 -0700 (PDT) In-Reply-To: <4F8473B7.9080000@FreeBSD.org> References: <4F2F7B7F.40508@FreeBSD.org> <4F366E8F.9060207@FreeBSD.org> <4F367965.6000602@FreeBSD.org> <4F396B24.5090602@FreeBSD.org> <4F3978BC.6090608@FreeBSD.org> <4F3990EA.1080002@FreeBSD.org> <4F3C0BB9.6050101@FreeBSD.org> <4F3E807A.60103@FreeBSD.org> <4F3E8858.4000001@FreeBSD.org> <4F7DE863.6080607@FreeBSD.org> <4F833F3D.7070106@FreeBSD.org> <4F846B74.9080504@FreeBSD.org> <4F8473B7.9080000@FreeBSD.org> Date: Tue, 10 Apr 2012 14:46:10 -0400 Message-ID: From: Arnaud Lacombe To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, Jeff Roberson , Andriy Gapon , FreeBSD current Subject: Re: [RFT][patch] Scheduling for HTT and not only X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 18:46:13 -0000 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. From owner-freebsd-current@FreeBSD.ORG Tue Apr 10 18:56:30 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F7931065678; Tue, 10 Apr 2012 18:56:30 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 616088FC12; Tue, 10 Apr 2012 18:56:30 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D22D1B95A; Tue, 10 Apr 2012 14:56:29 -0400 (EDT) From: John Baldwin To: Konstantin Belousov Date: Tue, 10 Apr 2012 14:47:37 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <20120407125056.GS2358@deviant.kiev.zoral.com.ua> <201204100956.06750.jhb@freebsd.org> <20120410143835.GZ2358@deviant.kiev.zoral.com.ua> In-Reply-To: <20120410143835.GZ2358@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201204101447.37988.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 10 Apr 2012 14:56:29 -0400 (EDT) Cc: Ian Lepore , freebsd-drivers@freebsd.org, current@freebsd.org Subject: Re: device_attach(9) and driver initialization X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 18:56:30 -0000 On Tuesday, April 10, 2012 10:38:35 am Konstantin Belousov wrote: > On Tue, Apr 10, 2012 at 09:56:06AM -0400, John Baldwin wrote: > > On Monday, April 09, 2012 4:05:29 pm Konstantin Belousov wrote: > > > On Mon, Apr 09, 2012 at 03:36:08PM -0400, John Baldwin wrote: > > > > On Monday, April 09, 2012 3:10:00 pm Konstantin Belousov wrote: > > > > > On Mon, Apr 09, 2012 at 11:01:03AM -0400, John Baldwin wrote: > > > > > > On Saturday, April 07, 2012 11:08:41 pm Warner Losh wrote: > > > > > > > > > > > > > > On Apr 7, 2012, at 8:46 AM, Ian Lepore wrote: > > > > > > > > > > > > > > > On Sat, 2012-04-07 at 15:50 +0300, Konstantin Belousov wrote: > > > > > > > >> Hello, > > > > > > > >> there seems to be a problem with device attach sequence offered by > > > > > > newbus. > > > > > > > >> Basically, when device attach method is executing, device is not fully > > > > > > > >> initialized yet. Also the device state in the newbus part of the world > > > > > > > >> is DS_ALIVE. There is definitely no shattering news in the statements, > > > > > > > >> but drivers that e.g. create devfs node to communicate with consumers > > > > > > > >> are prone to a race. > > > > > > > >> > > > > > > > >> If /dev node is created inside device attach method, then usermode > > > > > > > >> can start calling cdevsw methods before device fully initialized itself. > > > > > > > >> Even more, if device tries to use newbus helpers in cdevsw methods, > > > > > > > >> like device_busy(9), then panic occurs "called for unatteched device". > > > > > > > >> I get reports from users about this issues, to it is not something > > > > > > > >> that only could happen. > > > > > > > >> > > > > > > > >> I propose to add DEVICE_AFTER_ATTACH() driver method, to be called > > > > > > > >> from newbus right after device attach finished and newbus considers > > > > > > > >> the device fully initialized. Driver then could create devfs node > > > > > > > >> in the after_attach method instead of attach. Please see the patch below. > > > > > > > >> > > > > > > > >> diff --git a/sys/kern/device_if.m b/sys/kern/device_if.m > > > > > > > >> index eb720eb..9db74e2 100644 > > > > > > > >> --- a/sys/kern/device_if.m > > > > > > > >> +++ b/sys/kern/device_if.m > > > > > > > >> @@ -43,6 +43,10 @@ INTERFACE device; > > > > > > > >> # Default implementations of some methods. > > > > > > > >> # > > > > > > > >> CODE { > > > > > > > >> + static void null_after_attach(device_t dev) > > > > > > > >> + { > > > > > > > >> + } > > > > > > > >> + > > > > > > > >> static int null_shutdown(device_t dev) > > > > > > > >> { > > > > > > > >> return 0; > > > > > > > >> @@ -199,6 +203,21 @@ METHOD int attach { > > > > > > > >> }; > > > > > > > >> > > > > > > > >> /** > > > > > > > >> + * @brief Notify the driver that device is in attached state > > > > > > > >> + * > > > > > > > >> + * Called after driver is successfully attached to the device and > > > > > > > >> + * corresponding device_t is fully operational. Driver now may expose > > > > > > > >> + * the device to the consumers, e.g. create devfs nodes. > > > > > > > >> + * > > > > > > > >> + * @param dev the device to probe > > > > > > > >> + * > > > > > > > >> + * @see DEVICE_ATTACH() > > > > > > > >> + */ > > > > > > > >> +METHOD void after_attach { > > > > > > > >> + device_t dev; > > > > > > > >> +} DEFAULT null_after_attach; > > > > > > > >> + > > > > > > > >> +/** > > > > > > > >> * @brief Detach a driver from a device. > > > > > > > >> * > > > > > > > >> * This can be called if the user is replacing the > > > > > > > >> diff --git a/sys/kern/subr_bus.c b/sys/kern/subr_bus.c > > > > > > > >> index d485b9f..6d849cb 100644 > > > > > > > >> --- a/sys/kern/subr_bus.c > > > > > > > >> +++ b/sys/kern/subr_bus.c > > > > > > > >> @@ -2743,6 +2743,7 @@ device_attach(device_t dev) > > > > > > > >> dev->state = DS_ATTACHED; > > > > > > > >> dev->flags &= ~DF_DONENOMATCH; > > > > > > > >> devadded(dev); > > > > > > > >> + DEVICE_AFTER_ATTACH(dev); > > > > > > > >> return (0); > > > > > > > >> } > > > > > > > >> > > > > > > > > > > > > > > > > Does device_get_softc() work before attach is completed? (I don't have > > > > > > > > time to go look in the code right now). If so, then a mutex initialized > > > > > > > > and acquired early in the driver's attach routine, and also acquired in > > > > > > > > the driver's cdev implementation routines before using any newbus > > > > > > > > functions other than device_get_softc(), would solve the problem without > > > > > > > > a driver api change that would make it harder to backport/MFC driver > > > > > > > > changes. > > > > > > > > > > > > > > Also, more generally, don't create the dev nodes before you are ready to > > > > > > deal with requests. Why do we need to uglify everything here? If you can't > > > > > > do that, you can check a bit in the softc and return EBUSY or ENXIO on open if > > > > > > that bit says that your driver isn't ready to accept requests. > > > > > > > > > > > > I agree, this dosen't actually fix anything as the decision for what to put > > > > > > in your foo_attach() method rather than foo_after_attach() is non-obvious and > > > > > > very arbitrary. > > > > > > > > > > > > The actual bug appears to only be with using 'device_busy()'. I think > > > > > > this should be fixed by making device_busy() better, not by adding > > > > > > this type of obfuscation to attach. It should be trivial to make > > > > > > device_busy() safe to use on a device that is currently being attached > > > > > > which will not require any changes to drivers. > > > > > > > > > > Could you, please, elaborate your proposal ? How do you think device_busy() > > > > > can be enchanced ? > > > > > > > > > > Obvious idea to sleep inside device_busy() until dev->state becomes != > > > > > DS_ATTACHED is no go, IMO. The issue is that this causes immediate deadlocks > > > > > if device_attach() method needs to call destroy_dev() to rollback. > > > > > > > > I think you could have a DS_ATTACHING state and allow device_busy() to work > > > > for DS_ATTACHING. The idea being that it is a bug for a driver to invoke > > > > device_busy() if it is going to fail attach. You may then need to do a fixup > > > > in device_attach() to promote the state from DS_ATTACHED to DS_BUSY when it > > > > returns if there is a non-zero busy count. > > > This is quite good idea, but it still adds burden to device author, > > > although I agree that this is manageable. A scenario I have in mind now > > > is the following: > > > assume that driver needs to create two devfs nodes, lets name them > > > dri/card0 and dri/forcewake0. Driver would perform two make_dev_p(9) > > > calls, and while creation of dri/card0 succeed, consequent creation > > > of dri/forcewake0 could fail for numerous reasons. > > > > > > Now, the driver needs to ensure that cdesvw->d_open() on dri/card0 > > > would return ENXIO until dri/forcewake0 is created. This can be implemented > > > with flag, indeed. But still somewhat muddy, and probably leads to > > > user-visible errors (I mostly worry about graphical login managers). > > > > You could also sleep on the flag in d_open() (you can imagine a two-step > > process where you set a "adding cdev's flag", then all d_open() calls block > > on it). Then when finished adding cdev's, you set a flag if an error > > occurred and wake up all the waiters. If no error occured the waiters can > > have the first open() work fine. But even with other proposals you still > > have to deal with this problem if you want to fail out entirely if you > > have problems creating cdevs. > > > > > But for single-node drivers it is indeed a nice solution. > > > > I think we are somewhat stuck with this for other reasons as well. Note > > that device_busy() propagates up the tree to parent devices, so imagine > > kldloading a driver that creates a tree (e.g. a bus with a few consumers) > > where the leaf devices are attached by a call to bus_generic_attach() from > > the device_attach() method for the parent device. Even if you add a > > DEVICE_AFTER_ATTACH() hook, while it may allow device_busy() to be invoked > > on the leaf device, when it tries to propagate device_busy() up to the > > parent device it would still be in the middle of attach and blow up anyway. > > This looks like a bug in my implementation of after_attach, which > apparently should be called for new tree after the top level attach > finished. Hmm, I think this is a bit less trivial as it involves an entire pass over the tree (and you'd probably not want to invoke it more than once on a device, so you'd have to track that, etc.). > Anyway, would you commit your change ? I definitely can work out the > driver change after. But this seems to be a large amount of work for > driver authors. Oh, sure. Have you tried it out? I have not tested it yet, so I will need to do that first unless you can do so easily. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Apr 10 19:13:47 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F13E5106564A; Tue, 10 Apr 2012 19:13:47 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id D57CD8FC08; Tue, 10 Apr 2012 19:13:46 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so138770bkc.13 for ; Tue, 10 Apr 2012 12:13:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=8ZWDssOPUTIzmiGTu/VNGj/gU8fSY+gG7N3Vg9PLcuo=; b=yTcvgifT7Hagq6FIPBUvAQuzSyDeae1MNXHhywmB96czUClyI41D0Neau65R1lOW/t bxF1eKoypAzIm3xBayCZvpoWEz2klHMfh9qy1rMyyZSmlxfbm92cAw3NSqo+00j+S4uR DMTQ6PSp1pNRQgHzE0X38zjPnF+FrO9MxQclY9DB7WXKto8J0pPO+v53htFMH21JSBMQ tu/eBTI2PErQthzzmcmsgJQxMOYsh/iocjGi3Xcc7z93vSUzMGnTsvqQDJxTtSlAX2Ck qVfPb1CCm+HKpG593FY2QoV8/SYbBwhEMDNJMq5uh1yI/PdmZNaWijogd4Z7uVJCVWLU LKYw== Received: by 10.204.156.216 with SMTP id y24mr5154693bkw.60.1334085225856; Tue, 10 Apr 2012 12:13:45 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id c4sm408768bkh.0.2012.04.10.12.13.43 (version=SSLv3 cipher=OTHER); Tue, 10 Apr 2012 12:13:44 -0700 (PDT) Sender: Alexander Motin Message-ID: <4F848666.8030308@FreeBSD.org> Date: Tue, 10 Apr 2012 22:13:42 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.2) Gecko/20120226 Thunderbird/10.0.2 MIME-Version: 1.0 To: Arnaud Lacombe References: <4F2F7B7F.40508@FreeBSD.org> <4F366E8F.9060207@FreeBSD.org> <4F367965.6000602@FreeBSD.org> <4F396B24.5090602@FreeBSD.org> <4F3978BC.6090608@FreeBSD.org> <4F3990EA.1080002@FreeBSD.org> <4F3C0BB9.6050101@FreeBSD.org> <4F3E807A.60103@FreeBSD.org> <4F3E8858.4000001@FreeBSD.org> <4F7DE863.6080607@FreeBSD.org> <4F833F3D.7070106@FreeBSD.org> <4F846B74.9080504@FreeBSD.org> <4F8473B7.9080000@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Jeff Roberson , Andriy Gapon , FreeBSD current Subject: Re: [RFT][patch] Scheduling for HTT and not only X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 19:13:48 -0000 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 From owner-freebsd-current@FreeBSD.ORG Tue Apr 10 20:36:53 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3CB44106564A for ; Tue, 10 Apr 2012 20:36:53 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (mx0.hoeg.nl [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id C58358FC14 for ; Tue, 10 Apr 2012 20:36:52 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id 639402A28CC9; Tue, 10 Apr 2012 22:36:45 +0200 (CEST) Date: Tue, 10 Apr 2012 22:36:45 +0200 From: Ed Schouten To: "O. Hartmann" Message-ID: <20120410203645.GI62756@hoeg.nl> References: <4F83FF50.1010404@mail.zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IbVRjBtIbJdbeK1C" Content-Disposition: inline In-Reply-To: <4F83FF50.1010404@mail.zedat.fu-berlin.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Current FreeBSD Subject: Re: Changes to sbin/init/init.c (r233944) makes x11/xdm impossible to start from /etc/ttys X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 20:36:53 -0000 --IbVRjBtIbJdbeK1C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Oliver, * O. Hartmann , 20120410 11:37: > Reverting init.c back to its previous state seems to make the error go aw= ay. 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! --=20 Ed Schouten WWW: http://80386.nl/ --IbVRjBtIbJdbeK1C Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iQIcBAEBAgAGBQJPhJndAAoJEG5e2P40kaK7n88P/0E2LVVvJpzn0YfOxxlWW7/N 1+Fyee3vIroxu0R33UBuDCWbFy2u0tn4BvraQqjkPTrAC4m3OSx7288o6fA+9WFg 4JrATV/17luATKucv06Bqo5fShy+jADH6O85FIgKsodWoVt15itI0LqXz6PsiJHv q/gS7c8uns6Ey5zAiLSGASPjidWcxLebWCUmxwKvs/+HfFDr7pfPmWYPYnCZ4rk4 mOASStofv41ED/wlRMugjDHbT6obVLGWB8zk5KyEedSdhVIcCBGs0HQBMIDu+dP5 4VOIt1gPoks42WJ2KFbUsDuudrrPmJ4r5hKulEMcNc8I3vvgHf5nnXasZuwQWoly RP/i9hsMzGWSXkbI9+ORQVlRntto7iBhwDkhN9EarXx4ym5EVoVZGJJHj5p9XXAP D4NYgwOjV1AmgcZZkiESViqv47AvlVUv/UjgVShellGjP6K55mmnQdMBsox27UhA uNfMEoWnNdLr/jRqJtn0TZZdTlS3SuOlJbRXZtDI1M66ENAjPo8eOEZRZkPTi4eP VzSojmCu8SiY8/KUG5aYOQniQdg+HNLt2Mpek3x4X5yPqsQ4NT73tnJtS4u8Vhf0 tKOLkFCHX4Fu5EwKZ/6HRirNWkcQQiLEb7YVN4Rjq5iLAyKQSg4XKtUQKdUk1gnG yb52g3nou20Ie0hntfW5 =tbhK -----END PGP SIGNATURE----- --IbVRjBtIbJdbeK1C-- From owner-freebsd-current@FreeBSD.ORG Tue Apr 10 22:14:17 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E06A106564A; Tue, 10 Apr 2012 22:14:17 +0000 (UTC) (envelope-from venture37@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id A2DCA8FC08; Tue, 10 Apr 2012 22:14:16 +0000 (UTC) Received: by wern13 with SMTP id n13so231094wer.13 for ; Tue, 10 Apr 2012 15:14:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=BH8zH60FVI9cu+dnZMxOcML2R4b2fVWQ4lG5I5hYDA8=; b=TFb0+lFXuyLbngBXYsvI12S8tXeHyhg+GNQPArNE7S9j0kMicOki1Qerc+KaLqZ67V h+JvJAIYkN79BCGXpk/POghQoF4E+VT/6RRTiZZQGk97YCTPBZz7tAvXTQk1lhB5hdE1 1kRh0sAk+b2IqAIuHItrWTrKSOlipYAXjaNvefiJfAQSficq7YJcZnPLCUm6jcEyBFAL WFYWz791i/MN3Te1DZTRUQ7gEwsLT6VY4ARJniGHiAHMPSm2GrtZakCKTvjE0snMwF4u yQwDYwjbdmqjo0ZpZBoI93LJhANXItYMob4n9VnVAWMO/1CtLWEyxWiHTl331XKDCo8j W4sw== Received: by 10.216.201.104 with SMTP id a82mr7068455weo.100.1334096055644; Tue, 10 Apr 2012 15:14:15 -0700 (PDT) Received: from Sevans-MacBook-Pro.local (cpc2-brig17-2-0-cust527.3-3.cable.virginmedia.com. [81.101.198.16]) by mx.google.com with ESMTPS id h8sm2343419wix.4.2012.04.10.15.14.13 (version=SSLv3 cipher=OTHER); Tue, 10 Apr 2012 15:14:14 -0700 (PDT) Message-ID: <4F84B0AF.7010401@gmail.com> Date: Tue, 10 Apr 2012 23:14:07 +0100 From: Sevan / Venture37 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Daichi GOTO References: <566771C2-84CA-4824-AE99-38EB5DE1F786@gmail.com> <20120410104521.ba15b1c3.daichi@freebsd.org> In-Reply-To: <20120410104521.ba15b1c3.daichi@freebsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "freebsd-current@freebsd.org" Subject: Re: DTrace on FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 22:14:17 -0000 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 From owner-freebsd-current@FreeBSD.ORG Tue Apr 10 22:33:47 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 15817106566C; Tue, 10 Apr 2012 22:33:47 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id C81E38FC08; Tue, 10 Apr 2012 22:33:45 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 9AF9B7300A; Wed, 11 Apr 2012 00:52:57 +0200 (CEST) Date: Wed, 11 Apr 2012 00:52:57 +0200 From: Luigi Rizzo To: current@freebsd.org, net@freebsd.org Message-ID: <20120410225257.GB53350@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: strange ping response times... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 22:33:47 -0000 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 10000 -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 From owner-freebsd-current@FreeBSD.ORG Tue Apr 10 22:39:46 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81B201065674; Tue, 10 Apr 2012 22:39:46 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 5C96C8FC0A; Tue, 10 Apr 2012 22:39:46 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id q3AMdcnO035453 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 10 Apr 2012 15:39:40 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4F84B6DB.5040904@freebsd.org> Date: Tue, 10 Apr 2012 15:40:27 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20 MIME-Version: 1.0 To: Luigi Rizzo References: <20120410225257.GB53350@onelab2.iet.unipi.it> In-Reply-To: <20120410225257.GB53350@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org, net@freebsd.org Subject: Re: strange ping response times... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 22:39:46 -0000 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 10000 -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-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Tue Apr 10 23:12:53 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B95E71065675; Tue, 10 Apr 2012 23:12:53 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 77EE78FC08; Tue, 10 Apr 2012 23:12:53 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 534117300A; Wed, 11 Apr 2012 01:32:11 +0200 (CEST) Date: Wed, 11 Apr 2012 01:32:11 +0200 From: Luigi Rizzo To: Barney Wolff Message-ID: <20120410233211.GA53829@onelab2.iet.unipi.it> References: <20120410225257.GB53350@onelab2.iet.unipi.it> <4F84B6DB.5040904@freebsd.org> <20120410230500.GA22829@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120410230500.GA22829@pit.databus.com> User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org, net@freebsd.org Subject: Re: strange ping response times... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 23:12:53 -0000 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.. From owner-freebsd-current@FreeBSD.ORG Tue Apr 10 23:14:27 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DC89B106566C; Tue, 10 Apr 2012 23:14:27 +0000 (UTC) (envelope-from barney@pit.databus.com) Received: from out.smtp-auth.no-ip.com (smtp-auth.no-ip.com [8.23.224.61]) by mx1.freebsd.org (Postfix) with ESMTP id B0DB18FC1A; Tue, 10 Apr 2012 23:14:27 +0000 (UTC) X-No-IP: databus.com@noip-smtp X-No-IP: databus.com@noip-smtp X-No-IP: databus.com@noip-smtp X-No-IP: databus.com@noip-smtp X-Report-Spam-To: abuse@no-ip.com Received: from smtp-auth.no-ip.com (unknown [172.20.20.61]) (Authenticated sender: databus.com@noip-smtp) by smtp-auth.no-ip.com (Postfix) with ESMTPA id D8BC1400AE5; Tue, 10 Apr 2012 16:05:03 -0700 (PDT) Received: from pit.databus.com (localhost [127.0.0.1]) by pit.databus.com (8.14.5/8.14.5) with ESMTP id q3AN50cV032034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Apr 2012 19:05:01 -0400 (EDT) (envelope-from barney@pit.databus.com) X-DKIM: OpenDKIM Filter v2.4.3 pit.databus.com q3AN50cV032034 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=databus.com; s=20091218; t=1334099101; bh=EPhSfPa8ORbA+mlrPRKHrzJxWo4cwxc1v8Bnulkjs+k=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=m6O+edhSB2YaEA4sHQAUzjMBcuadBmVtc9gZM6Uo5kxhZ5h/U0UJGFONeEvmuvIhn nhAu/7UNKN5JgZOx2owgnis/WgBPT2REHRu/jGqSmBPhjTxhWthHn3WcSQVmNUkv20 hF5i0WzE3jaG3hmljBTn8MwZglyXtl05D6IilCcc= Received: (from barney@localhost) by pit.databus.com (8.14.5/8.14.5/Submit) id q3AN5028032033; Tue, 10 Apr 2012 19:05:00 -0400 (EDT) (envelope-from barney) Date: Tue, 10 Apr 2012 19:05:00 -0400 From: Barney Wolff To: Julian Elischer Message-ID: <20120410230500.GA22829@pit.databus.com> References: <20120410225257.GB53350@onelab2.iet.unipi.it> <4F84B6DB.5040904@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F84B6DB.5040904@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Luigi Rizzo , current@freebsd.org, net@freebsd.org Subject: Re: strange ping response times... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 23:14:28 -0000 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.. From owner-freebsd-current@FreeBSD.ORG Wed Apr 11 00:21:53 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 80D7D106566C for ; Wed, 11 Apr 2012 00:21:53 +0000 (UTC) (envelope-from daichi@freebsd.org) Received: from natial.ongs.co.jp (natial.ongs.co.jp [202.216.246.90]) by mx1.freebsd.org (Postfix) with ESMTP id 4A7488FC08 for ; Wed, 11 Apr 2012 00:21:53 +0000 (UTC) Received: from parancell.ongs.co.jp (dullmdaler.ongs.co.jp [202.216.246.94]) by natial.ongs.co.jp (Postfix) with ESMTPSA id E9E24125422; Wed, 11 Apr 2012 09:21:45 +0900 (JST) Date: Wed, 11 Apr 2012 09:21:45 +0900 From: Daichi GOTO To: Sevan / Venture37 Message-Id: <20120411092145.3eccb9e4.daichi@freebsd.org> In-Reply-To: <4F84B0AF.7010401@gmail.com> References: <566771C2-84CA-4824-AE99-38EB5DE1F786@gmail.com> <20120410104521.ba15b1c3.daichi@freebsd.org> <4F84B0AF.7010401@gmail.com> Organization: FreeBSD Project X-Mailer: Sylpheed 3.1.3 (GTK+ 2.24.6; amd64-portbld-freebsd9.9) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: "freebsd-current@freebsd.org" Subject: Re: DTrace on FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 00:21:53 -0000 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$B!G(Bs 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-unsubscribe@freebsd.org" -- Daichi GOTO (daichi) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Wed Apr 11 00:39:43 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4E177106564A; Wed, 11 Apr 2012 00:39:43 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 132EB8FC0A; Wed, 11 Apr 2012 00:39:42 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q3B0dgea062291; Tue, 10 Apr 2012 20:39:42 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q3B0dgxm062286; Wed, 11 Apr 2012 00:39:42 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 11 Apr 2012 00:39:42 GMT Message-Id: <201204110039.q3B0dgxm062286@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 00:39:43 -0000 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 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-04-10 23:34:24 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2012-04-10 23:34:25 - cleaning the object tree TB --- 2012-04-10 23:34:25 - cvsupping the source tree TB --- 2012-04-10 23:34:25 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2012-04-10 23:34:58 - building world TB --- 2012-04-10 23:34:58 - CROSS_BUILD_TESTING=YES TB --- 2012-04-10 23:34:58 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-10 23:34:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-10 23:34:58 - SRCCONF=/dev/null TB --- 2012-04-10 23:34:58 - TARGET=sparc64 TB --- 2012-04-10 23:34:58 - TARGET_ARCH=sparc64 TB --- 2012-04-10 23:34:58 - TZ=UTC TB --- 2012-04-10 23:34:58 - __MAKE_CONF=/dev/null TB --- 2012-04-10 23:34:58 - cd /src TB --- 2012-04-10 23:34:58 - /usr/bin/make -B buildworld >>> World build started on Tue Apr 10 23:34:59 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Apr 11 00:35:18 UTC 2012 TB --- 2012-04-11 00:35:18 - generating LINT kernel config TB --- 2012-04-11 00:35:18 - cd /src/sys/sparc64/conf TB --- 2012-04-11 00:35:18 - /usr/bin/make -B LINT TB --- 2012-04-11 00:35:18 - cd /src/sys/sparc64/conf TB --- 2012-04-11 00:35:18 - /usr/sbin/config -m LINT TB --- 2012-04-11 00:35:18 - building LINT kernel TB --- 2012-04-11 00:35:18 - CROSS_BUILD_TESTING=YES TB --- 2012-04-11 00:35:18 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-11 00:35:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-11 00:35:18 - SRCCONF=/dev/null TB --- 2012-04-11 00:35:18 - TARGET=sparc64 TB --- 2012-04-11 00:35:18 - TARGET_ARCH=sparc64 TB --- 2012-04-11 00:35:18 - TZ=UTC TB --- 2012-04-11 00:35:18 - __MAKE_CONF=/dev/null TB --- 2012-04-11 00:35:18 - cd /src TB --- 2012-04-11 00:35:18 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Apr 11 00:35:18 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-serverworks.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-siliconimage.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-sis.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-via.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/ath/if_ath.c -I/src/sys/dev/ath cc1: warnings being treated as errors /src/sys/dev/ath/if_ath.c: In function 'ath_tx_processq': /src/sys/dev/ath/if_ath.c:4909: warning: unused variable 'ic' [-Wunused-variable] *** Error code 1 Stop in /obj/sparc64.sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-04-11 00:39:41 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-04-11 00:39:41 - ERROR: failed to build LINT kernel TB --- 2012-04-11 00:39:41 - 3096.15 user 556.28 system 3916.90 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Wed Apr 11 00:40:22 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2FEF2106566B; Wed, 11 Apr 2012 00:40:22 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id F34008FC16; Wed, 11 Apr 2012 00:40:21 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q3B0eLiW066508; Tue, 10 Apr 2012 20:40:21 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q3B0eLUN066507; Wed, 11 Apr 2012 00:40:21 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 11 Apr 2012 00:40:21 GMT Message-Id: <201204110040.q3B0eLUN066507@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 00:40:22 -0000 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 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-04-10 22:29:05 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2012-04-10 22:29:05 - cleaning the object tree TB --- 2012-04-10 22:29:05 - cvsupping the source tree TB --- 2012-04-10 22:29:05 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2012-04-10 22:30:16 - building world TB --- 2012-04-10 22:30:16 - CROSS_BUILD_TESTING=YES TB --- 2012-04-10 22:30:16 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-10 22:30:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-10 22:30:16 - SRCCONF=/dev/null TB --- 2012-04-10 22:30:16 - TARGET=powerpc TB --- 2012-04-10 22:30:16 - TARGET_ARCH=powerpc TB --- 2012-04-10 22:30:16 - TZ=UTC TB --- 2012-04-10 22:30:16 - __MAKE_CONF=/dev/null TB --- 2012-04-10 22:30:16 - cd /src TB --- 2012-04-10 22:30:16 - /usr/bin/make -B buildworld >>> World build started on Tue Apr 10 22:30:17 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Apr 11 00:36:31 UTC 2012 TB --- 2012-04-11 00:36:31 - generating LINT kernel config TB --- 2012-04-11 00:36:31 - cd /src/sys/powerpc/conf TB --- 2012-04-11 00:36:31 - /usr/bin/make -B LINT TB --- 2012-04-11 00:36:31 - cd /src/sys/powerpc/conf TB --- 2012-04-11 00:36:31 - /usr/sbin/config -m LINT TB --- 2012-04-11 00:36:31 - building LINT kernel TB --- 2012-04-11 00:36:31 - CROSS_BUILD_TESTING=YES TB --- 2012-04-11 00:36:31 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-11 00:36:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-11 00:36:31 - SRCCONF=/dev/null TB --- 2012-04-11 00:36:31 - TARGET=powerpc TB --- 2012-04-11 00:36:31 - TARGET_ARCH=powerpc TB --- 2012-04-11 00:36:31 - TZ=UTC TB --- 2012-04-11 00:36:31 - __MAKE_CONF=/dev/null TB --- 2012-04-11 00:36:31 - cd /src TB --- 2012-04-11 00:36:31 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Apr 11 00:36:32 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-serverworks.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-siliconimage.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-sis.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -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-via.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/ath/if_ath.c -I/src/sys/dev/ath cc1: warnings being treated as errors /src/sys/dev/ath/if_ath.c: In function 'ath_tx_processq': /src/sys/dev/ath/if_ath.c:4909: warning: unused variable 'ic' [-Wunused-variable] *** Error code 1 Stop in /obj/powerpc.powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-04-11 00:40:21 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-04-11 00:40:21 - ERROR: failed to build LINT kernel TB --- 2012-04-11 00:40:21 - 6426.59 user 853.27 system 7875.59 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Wed Apr 11 01:18:01 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3ED8B106564A; Wed, 11 Apr 2012 01:18:01 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 0DAA48FC0A; Wed, 11 Apr 2012 01:18:00 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q3B1I0YC063002; Tue, 10 Apr 2012 21:18:00 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q3B1I0GO063001; Wed, 11 Apr 2012 01:18:00 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 11 Apr 2012 01:18:00 GMT Message-Id: <201204110118.q3B1I0GO063001@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 01:18:01 -0000 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 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-04-10 22:40:57 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2012-04-10 22:40:57 - cleaning the object tree TB --- 2012-04-10 22:40:57 - cvsupping the source tree TB --- 2012-04-10 22:40:57 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2012-04-10 22:41:49 - building world TB --- 2012-04-10 22:41:49 - CROSS_BUILD_TESTING=YES TB --- 2012-04-10 22:41:49 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-10 22:41:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-10 22:41:49 - SRCCONF=/dev/null TB --- 2012-04-10 22:41:49 - TARGET=powerpc TB --- 2012-04-10 22:41:49 - TARGET_ARCH=powerpc64 TB --- 2012-04-10 22:41:49 - TZ=UTC TB --- 2012-04-10 22:41:49 - __MAKE_CONF=/dev/null TB --- 2012-04-10 22:41:49 - cd /src TB --- 2012-04-10 22:41:49 - /usr/bin/make -B buildworld >>> World build started on Tue Apr 10 22:41:50 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Wed Apr 11 01:14:42 UTC 2012 TB --- 2012-04-11 01:14:42 - generating LINT kernel config TB --- 2012-04-11 01:14:42 - cd /src/sys/powerpc/conf TB --- 2012-04-11 01:14:42 - /usr/bin/make -B LINT TB --- 2012-04-11 01:14:42 - cd /src/sys/powerpc/conf TB --- 2012-04-11 01:14:42 - /usr/sbin/config -m LINT TB --- 2012-04-11 01:14:42 - building LINT kernel TB --- 2012-04-11 01:14:42 - CROSS_BUILD_TESTING=YES TB --- 2012-04-11 01:14:42 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-11 01:14:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-11 01:14:42 - SRCCONF=/dev/null TB --- 2012-04-11 01:14:42 - TARGET=powerpc TB --- 2012-04-11 01:14:42 - TARGET_ARCH=powerpc64 TB --- 2012-04-11 01:14:42 - TZ=UTC TB --- 2012-04-11 01:14:42 - __MAKE_CONF=/dev/null TB --- 2012-04-11 01:14:42 - cd /src TB --- 2012-04-11 01:14:42 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Apr 11 01:14:42 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-serverworks.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-siliconimage.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-sis.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -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-via.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/ath/if_ath.c -I/src/sys/dev/ath cc1: warnings being treated as errors /src/sys/dev/ath/if_ath.c: In function 'ath_tx_processq': /src/sys/dev/ath/if_ath.c:4909: warning: unused variable 'ic' [-Wunused-variable] *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-04-11 01:18:00 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-04-11 01:18:00 - ERROR: failed to build LINT kernel TB --- 2012-04-11 01:18:00 - 7862.50 user 1071.04 system 9423.48 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Wed Apr 11 02:22:00 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04DE2106564A; Wed, 11 Apr 2012 02:22:00 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id C80C78FC08; Wed, 11 Apr 2012 02:21:59 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q3B2LxQL045021; Tue, 10 Apr 2012 22:21:59 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q3B2Lx7u045020; Wed, 11 Apr 2012 02:21:59 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 11 Apr 2012 02:21:59 GMT Message-Id: <201204110221.q3B2Lx7u045020@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 02:22:00 -0000 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 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-04-11 01:20:00 - starting HEAD tinderbox run for arm/arm TB --- 2012-04-11 01:20:00 - cleaning the object tree TB --- 2012-04-11 01:20:00 - cvsupping the source tree TB --- 2012-04-11 01:20:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2012-04-11 01:22:17 - building world TB --- 2012-04-11 01:22:17 - CROSS_BUILD_TESTING=YES TB --- 2012-04-11 01:22:17 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-11 01:22:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-11 01:22:17 - SRCCONF=/dev/null TB --- 2012-04-11 01:22:17 - TARGET=arm TB --- 2012-04-11 01:22:17 - TARGET_ARCH=arm TB --- 2012-04-11 01:22:17 - TZ=UTC TB --- 2012-04-11 01:22:17 - __MAKE_CONF=/dev/null TB --- 2012-04-11 01:22:17 - cd /src TB --- 2012-04-11 01:22:17 - /usr/bin/make -B buildworld >>> World build started on Wed Apr 11 01:22:18 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Apr 11 02:21:21 UTC 2012 TB --- 2012-04-11 02:21:21 - cd /src/sys/arm/conf TB --- 2012-04-11 02:21:21 - /usr/sbin/config -m AVILA TB --- 2012-04-11 02:21:22 - building AVILA kernel TB --- 2012-04-11 02:21:22 - CROSS_BUILD_TESTING=YES TB --- 2012-04-11 02:21:22 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-11 02:21:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-11 02:21:22 - SRCCONF=/dev/null TB --- 2012-04-11 02:21:22 - TARGET=arm TB --- 2012-04-11 02:21:22 - TARGET_ARCH=arm TB --- 2012-04-11 02:21:22 - TZ=UTC TB --- 2012-04-11 02:21:22 - __MAKE_CONF=/dev/null TB --- 2012-04-11 02:21:22 - cd /src TB --- 2012-04-11 02:21:22 - /usr/bin/make -B buildkernel KERNCONF=AVILA >>> Kernel build for AVILA started on Wed Apr 11 02:21:22 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -mbig-endian -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=xscale -ffreestanding -Werror /src/sys/dev/ata/chipsets/ata-siliconimage.c cc -mbig-endian -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=xscale -ffreestanding -Werror /src/sys/dev/ata/chipsets/ata-sis.c cc -mbig-endian -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=xscale -ffreestanding -Werror /src/sys/dev/ata/chipsets/ata-via.c cc -mbig-endian -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=xscale -ffreestanding -Werror /src/sys/dev/ath/if_ath_pci.c -I/src/sys/dev/ath cc -mbig-endian -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -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.c -I/src/sys/dev/ath cc1: warnings being treated as errors /src/sys/dev/ath/if_ath.c: In function 'ath_tx_processq': /src/sys/dev/ath/if_ath.c:4909: warning: unused variable 'ic' [-Wunused-variable] *** Error code 1 Stop in /obj/arm.arm/src/sys/AVILA. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-04-11 02:21:58 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-04-11 02:21:58 - ERROR: failed to build AVILA kernel TB --- 2012-04-11 02:21:58 - 2476.06 user 568.36 system 3718.35 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Wed Apr 11 03:51:33 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 233ED1065672; Wed, 11 Apr 2012 03:51:33 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id E19B88FC08; Wed, 11 Apr 2012 03:51:32 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q3B3pWBm060637; Tue, 10 Apr 2012 23:51:32 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q3B3pWFo060633; Wed, 11 Apr 2012 03:51:32 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 11 Apr 2012 03:51:32 GMT Message-Id: <201204110351.q3B3pWFo060633@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 03:51:33 -0000 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 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-04-11 01:20:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2012-04-11 01:20:00 - cleaning the object tree TB --- 2012-04-11 01:20:00 - cvsupping the source tree TB --- 2012-04-11 01:20:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2012-04-11 01:26:13 - building world TB --- 2012-04-11 01:26:13 - CROSS_BUILD_TESTING=YES TB --- 2012-04-11 01:26:13 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-11 01:26:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-11 01:26:13 - SRCCONF=/dev/null TB --- 2012-04-11 01:26:13 - TARGET=pc98 TB --- 2012-04-11 01:26:13 - TARGET_ARCH=i386 TB --- 2012-04-11 01:26:13 - TZ=UTC TB --- 2012-04-11 01:26:13 - __MAKE_CONF=/dev/null TB --- 2012-04-11 01:26:13 - cd /src TB --- 2012-04-11 01:26:13 - /usr/bin/make -B buildworld >>> World build started on Wed Apr 11 01:26:14 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Apr 11 03:43:54 UTC 2012 TB --- 2012-04-11 03:43:54 - generating LINT kernel config TB --- 2012-04-11 03:43:54 - cd /src/sys/pc98/conf TB --- 2012-04-11 03:43:54 - /usr/bin/make -B LINT TB --- 2012-04-11 03:43:54 - cd /src/sys/pc98/conf TB --- 2012-04-11 03:43:54 - /usr/sbin/config -m LINT TB --- 2012-04-11 03:43:54 - building LINT kernel TB --- 2012-04-11 03:43:54 - CROSS_BUILD_TESTING=YES TB --- 2012-04-11 03:43:54 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-11 03:43:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-11 03:43:54 - SRCCONF=/dev/null TB --- 2012-04-11 03:43:54 - TARGET=pc98 TB --- 2012-04-11 03:43:54 - TARGET_ARCH=i386 TB --- 2012-04-11 03:43:54 - TZ=UTC TB --- 2012-04-11 03:43:54 - __MAKE_CONF=/dev/null TB --- 2012-04-11 03:43:54 - cd /src TB --- 2012-04-11 03:43:54 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Apr 11 03:43:54 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/chipsets/ata-serverworks.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/chipsets/ata-siliconimage.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/chipsets/ata-sis.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -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-via.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/ath/if_ath.c -I/src/sys/dev/ath cc1: warnings being treated as errors /src/sys/dev/ath/if_ath.c: In function 'ath_tx_processq': /src/sys/dev/ath/if_ath.c:4909: warning: unused variable 'ic' [-Wunused-variable] *** Error code 1 Stop in /obj/pc98.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-04-11 03:51:31 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-04-11 03:51:31 - ERROR: failed to build LINT kernel TB --- 2012-04-11 03:51:31 - 6390.71 user 918.41 system 9091.41 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Wed Apr 11 03:51:54 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 23FF21065692; Wed, 11 Apr 2012 03:51:54 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id E792F8FC14; Wed, 11 Apr 2012 03:51:53 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q3B3pr9Y061435; Tue, 10 Apr 2012 23:51:53 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q3B3pr0s061434; Wed, 11 Apr 2012 03:51:53 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 11 Apr 2012 03:51:53 GMT Message-Id: <201204110351.q3B3pr0s061434@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 03:51:54 -0000 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 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-04-11 01:20:00 - starting HEAD tinderbox run for i386/i386 TB --- 2012-04-11 01:20:00 - cleaning the object tree TB --- 2012-04-11 01:20:00 - cvsupping the source tree TB --- 2012-04-11 01:20:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2012-04-11 01:22:05 - building world TB --- 2012-04-11 01:22:05 - CROSS_BUILD_TESTING=YES TB --- 2012-04-11 01:22:05 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-11 01:22:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-11 01:22:05 - SRCCONF=/dev/null TB --- 2012-04-11 01:22:05 - TARGET=i386 TB --- 2012-04-11 01:22:05 - TARGET_ARCH=i386 TB --- 2012-04-11 01:22:05 - TZ=UTC TB --- 2012-04-11 01:22:05 - __MAKE_CONF=/dev/null TB --- 2012-04-11 01:22:05 - cd /src TB --- 2012-04-11 01:22:05 - /usr/bin/make -B buildworld >>> World build started on Wed Apr 11 01:22:07 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Apr 11 03:42:49 UTC 2012 TB --- 2012-04-11 03:42:49 - generating LINT kernel config TB --- 2012-04-11 03:42:49 - cd /src/sys/i386/conf TB --- 2012-04-11 03:42:49 - /usr/bin/make -B LINT TB --- 2012-04-11 03:42:49 - cd /src/sys/i386/conf TB --- 2012-04-11 03:42:49 - /usr/sbin/config -m LINT TB --- 2012-04-11 03:42:49 - building LINT kernel TB --- 2012-04-11 03:42:49 - CROSS_BUILD_TESTING=YES TB --- 2012-04-11 03:42:49 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-11 03:42:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-11 03:42:49 - SRCCONF=/dev/null TB --- 2012-04-11 03:42:49 - TARGET=i386 TB --- 2012-04-11 03:42:49 - TARGET_ARCH=i386 TB --- 2012-04-11 03:42:49 - TZ=UTC TB --- 2012-04-11 03:42:49 - __MAKE_CONF=/dev/null TB --- 2012-04-11 03:42:49 - cd /src TB --- 2012-04-11 03:42:49 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Apr 11 03:42:50 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/chipsets/ata-serverworks.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/chipsets/ata-siliconimage.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/chipsets/ata-sis.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -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-via.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/ath/if_ath.c -I/src/sys/dev/ath cc1: warnings being treated as errors /src/sys/dev/ath/if_ath.c: In function 'ath_tx_processq': /src/sys/dev/ath/if_ath.c:4909: warning: unused variable 'ic' [-Wunused-variable] *** Error code 1 Stop in /obj/i386.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-04-11 03:51:53 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-04-11 03:51:53 - ERROR: failed to build LINT kernel TB --- 2012-04-11 03:51:53 - 6485.05 user 937.17 system 9112.70 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Wed Apr 11 04:08:29 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B23FD1065670; Wed, 11 Apr 2012 04:08:29 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 5F3F68FC0A; Wed, 11 Apr 2012 04:08:29 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q3B48SLk084013; Wed, 11 Apr 2012 00:08:28 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q3B48SIX083987; Wed, 11 Apr 2012 04:08:28 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 11 Apr 2012 04:08:28 GMT Message-Id: <201204110408.q3B48SIX083987@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 04:08:29 -0000 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 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-04-11 02:21:59 - starting HEAD tinderbox run for ia64/ia64 TB --- 2012-04-11 02:21:59 - cleaning the object tree TB --- 2012-04-11 02:21:59 - cvsupping the source tree TB --- 2012-04-11 02:21:59 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2012-04-11 02:22:28 - building world TB --- 2012-04-11 02:22:28 - CROSS_BUILD_TESTING=YES TB --- 2012-04-11 02:22:28 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-11 02:22:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-11 02:22:28 - SRCCONF=/dev/null TB --- 2012-04-11 02:22:28 - TARGET=ia64 TB --- 2012-04-11 02:22:28 - TARGET_ARCH=ia64 TB --- 2012-04-11 02:22:28 - TZ=UTC TB --- 2012-04-11 02:22:28 - __MAKE_CONF=/dev/null TB --- 2012-04-11 02:22:28 - cd /src TB --- 2012-04-11 02:22:28 - /usr/bin/make -B buildworld >>> World build started on Wed Apr 11 02:22:29 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Apr 11 04:02:03 UTC 2012 TB --- 2012-04-11 04:02:03 - generating LINT kernel config TB --- 2012-04-11 04:02:03 - cd /src/sys/ia64/conf TB --- 2012-04-11 04:02:03 - /usr/bin/make -B LINT TB --- 2012-04-11 04:02:03 - cd /src/sys/ia64/conf TB --- 2012-04-11 04:02:03 - /usr/sbin/config -m LINT TB --- 2012-04-11 04:02:03 - building LINT kernel TB --- 2012-04-11 04:02:03 - CROSS_BUILD_TESTING=YES TB --- 2012-04-11 04:02:03 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-11 04:02:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-11 04:02:03 - SRCCONF=/dev/null TB --- 2012-04-11 04:02:03 - TARGET=ia64 TB --- 2012-04-11 04:02:03 - TARGET_ARCH=ia64 TB --- 2012-04-11 04:02:03 - TZ=UTC TB --- 2012-04-11 04:02:03 - __MAKE_CONF=/dev/null TB --- 2012-04-11 04:02:03 - cd /src TB --- 2012-04-11 04:02:03 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Apr 11 04:02:03 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ata/chipsets/ata-serverworks.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ata/chipsets/ata-siliconimage.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ata/chipsets/ata-sis.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -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-via.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/ath/if_ath.c -I/src/sys/dev/ath cc1: warnings being treated as errors /src/sys/dev/ath/if_ath.c: In function 'ath_tx_processq': /src/sys/dev/ath/if_ath.c:4909: warning: unused variable 'ic' [-Wunused-variable] *** Error code 1 Stop in /obj/ia64.ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-04-11 04:08:28 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-04-11 04:08:28 - ERROR: failed to build LINT kernel TB --- 2012-04-11 04:08:28 - 4574.98 user 692.94 system 6389.45 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Wed Apr 11 04:09:53 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D4E7A106566C for ; Wed, 11 Apr 2012 04:09:53 +0000 (UTC) (envelope-from jhellenthal@dataix.net) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8977C8FC23 for ; Wed, 11 Apr 2012 04:09:53 +0000 (UTC) Received: by iahk25 with SMTP id k25so891088iah.13 for ; Tue, 10 Apr 2012 21:09:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=Zufs5q6xnWQp9SYx7MnO6ReeuRHBjoMxbFQgjJ3URGg=; b=R3+phvJKlWF8d5cDJD3ZyHuJitD942n/1KaY82ASoQLbyZpq13RXJT1uuyTy3MHWpM GpD8qrJzyFgAtCQcuXVGDdWM2WOXgyjar/iyNZzMfwlZxkR9GjUKQJkJ59UvQgeifHyJ 9SPkqUHbTNtPKhy6L8AHX+/RuLv817jTa9Ce8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-gm-message-state; bh=Zufs5q6xnWQp9SYx7MnO6ReeuRHBjoMxbFQgjJ3URGg=; b=M4YcjmFmAUjp9ce8Ku2e4yyD2kRKzZ1En4f/GjEY/Pw3zSgYQVbV1iwBxbw6xMu29V lukq5fTSYxasG43mMblpwZzZUuVOnkbzEEHQ+nFtXcTRYM2D931KdTPsSP67oAT/dsdw ev+KdlyHc49MhvCtqJcn9uEBqUK9b4B4q95+fTCsQR2ulXuGtOk3PmVTuRl2Ins+cqfv qep1x6C7yx3wAkDy4BsonS5jQ0QFQJ0mUuxOIaqdTZSC/QUw22bUnJRcvmu40WVrcItE yb1snc7R+jLeGxZfC2HR6880z7ceOPD091GVCZ0S5r3Hb0aMBIEV35vLbCi0NPB9OyWo NOiA== Received: by 10.50.154.169 with SMTP id vp9mr784115igb.53.1334117392759; Tue, 10 Apr 2012 21:09:52 -0700 (PDT) Received: from DataIX.net (adsl-99-181-142-73.dsl.klmzmi.sbcglobal.net. [99.181.142.73]) by mx.google.com with ESMTPS id i6sm4067643igq.3.2012.04.10.21.09.51 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 10 Apr 2012 21:09:52 -0700 (PDT) Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id q3B49oFa026333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Apr 2012 00:09:50 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Received: (from jhellenthal@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id q3B49mgM026332; Wed, 11 Apr 2012 00:09:48 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Date: Wed, 11 Apr 2012 00:09:48 -0400 From: Jason Hellenthal To: Luigi Rizzo Message-ID: <20120411040948.GA24775@DataIX.net> References: <20120410225257.GB53350@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120410225257.GB53350@onelab2.iet.unipi.it> X-Gm-Message-State: ALoCoQkfgQcwTBXTLm3upAbN8mK87yA2k2I0TWsMuiKCrsZvd6y/dk0/1C0kvlczE/HSXnhM6k/D Cc: current@freebsd.org, net@freebsd.org Subject: Re: strange ping response times... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 04:09:53 -0000 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 10000 -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-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" -- ;s =; From owner-freebsd-current@FreeBSD.ORG Wed Apr 11 04:24:39 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B86B7106566B; Wed, 11 Apr 2012 04:24:39 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 5B0678FC08; Wed, 11 Apr 2012 04:24:39 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q3B4OcQX027372; Wed, 11 Apr 2012 00:24:38 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q3B4Oc4J027368; Wed, 11 Apr 2012 04:24:38 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 11 Apr 2012 04:24:38 GMT Message-Id: <201204110424.q3B4Oc4J027368@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 04:24:39 -0000 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 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-04-11 01:20:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2012-04-11 01:20:00 - cleaning the object tree TB --- 2012-04-11 01:20:00 - cvsupping the source tree TB --- 2012-04-11 01:20:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2012-04-11 01:22:17 - building world TB --- 2012-04-11 01:22:17 - CROSS_BUILD_TESTING=YES TB --- 2012-04-11 01:22:17 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-11 01:22:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-11 01:22:17 - SRCCONF=/dev/null TB --- 2012-04-11 01:22:17 - TARGET=amd64 TB --- 2012-04-11 01:22:17 - TARGET_ARCH=amd64 TB --- 2012-04-11 01:22:17 - TZ=UTC TB --- 2012-04-11 01:22:17 - __MAKE_CONF=/dev/null TB --- 2012-04-11 01:22:17 - cd /src TB --- 2012-04-11 01:22:17 - /usr/bin/make -B buildworld >>> World build started on Wed Apr 11 01:22:18 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Wed Apr 11 04:17:46 UTC 2012 TB --- 2012-04-11 04:17:46 - generating LINT kernel config TB --- 2012-04-11 04:17:46 - cd /src/sys/amd64/conf TB --- 2012-04-11 04:17:46 - /usr/bin/make -B LINT TB --- 2012-04-11 04:17:46 - cd /src/sys/amd64/conf TB --- 2012-04-11 04:17:46 - /usr/sbin/config -m LINT TB --- 2012-04-11 04:17:46 - building LINT kernel TB --- 2012-04-11 04:17:46 - CROSS_BUILD_TESTING=YES TB --- 2012-04-11 04:17:46 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-11 04:17:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-11 04:17:46 - SRCCONF=/dev/null TB --- 2012-04-11 04:17:46 - TARGET=amd64 TB --- 2012-04-11 04:17:46 - TARGET_ARCH=amd64 TB --- 2012-04-11 04:17:46 - TZ=UTC TB --- 2012-04-11 04:17:46 - __MAKE_CONF=/dev/null TB --- 2012-04-11 04:17:46 - cd /src TB --- 2012-04-11 04:17:46 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Apr 11 04:17:46 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/chipsets/ata-serverworks.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/chipsets/ata-siliconimage.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/chipsets/ata-sis.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-via.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/ath/if_ath.c -I/src/sys/dev/ath cc1: warnings being treated as errors /src/sys/dev/ath/if_ath.c: In function 'ath_tx_processq': /src/sys/dev/ath/if_ath.c:4909: warning: unused variable 'ic' [-Wunused-variable] *** Error code 1 Stop in /obj/amd64.amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-04-11 04:24:38 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-04-11 04:24:38 - ERROR: failed to build LINT kernel TB --- 2012-04-11 04:24:38 - 7870.18 user 1238.03 system 11078.16 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Wed Apr 11 05:08:48 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7049A106568C for ; Wed, 11 Apr 2012 05:08:48 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id C598B8FC0C for ; Wed, 11 Apr 2012 05:08:47 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q3B58g3j072156; Wed, 11 Apr 2012 08:08:42 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q3B58gOw000472; Wed, 11 Apr 2012 08:08:42 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q3B58gKl000471; Wed, 11 Apr 2012 08:08:42 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 11 Apr 2012 08:08:42 +0300 From: Konstantin Belousov To: Ed Schouten Message-ID: <20120411050842.GE2358@deviant.kiev.zoral.com.ua> References: <4F83FF50.1010404@mail.zedat.fu-berlin.de> <20120410203645.GI62756@hoeg.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pCkiZZNKSjytm5Qt" Content-Disposition: inline In-Reply-To: <20120410203645.GI62756@hoeg.nl> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: "O. Hartmann" , Current FreeBSD Subject: Re: Changes to sbin/init/init.c (r233944) makes x11/xdm impossible to start from /etc/ttys X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 05:08:48 -0000 --pCkiZZNKSjytm5Qt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 10, 2012 at 10:36:45PM +0200, Ed Schouten wrote: > Hi Oliver, >=20 > * O. Hartmann , 20120410 11:37: > > Reverting init.c back to its previous state seems to make the error go = away. >=20 > 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. >=20 > It seems we can't do this reliably at all, so I guess I'd better just > revert the code like so: >=20 > http://80386.nl/pub/init.txt >=20 > 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 al= l. Esp. for xdm that is supposedly run on some vty and not on console. --pCkiZZNKSjytm5Qt Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk+FEdoACgkQC3+MBN1Mb4ggJwCcCU2GgpdxCIASiRHsGbp1ESOV O/YAoKn5rvN3e0Nx1gZyQ7aQCLs5tuCa =qv49 -----END PGP SIGNATURE----- --pCkiZZNKSjytm5Qt-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 11 06:32:01 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7AEBE106564A; Wed, 11 Apr 2012 06:32:01 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id D45088FC08; Wed, 11 Apr 2012 06:32:00 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q3B6VbgI092902; Wed, 11 Apr 2012 09:31:37 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q3B6VbiY000851; Wed, 11 Apr 2012 09:31:37 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q3B6VbxD000850; Wed, 11 Apr 2012 09:31:37 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 11 Apr 2012 09:31:37 +0300 From: Konstantin Belousov To: John Baldwin Message-ID: <20120411063136.GI2358@deviant.kiev.zoral.com.ua> References: <20120407125056.GS2358@deviant.kiev.zoral.com.ua> <201204100956.06750.jhb@freebsd.org> <20120410143835.GZ2358@deviant.kiev.zoral.com.ua> <201204101447.37988.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4NXZt1nqaY8isg8F" Content-Disposition: inline In-Reply-To: <201204101447.37988.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Ian Lepore , freebsd-drivers@freebsd.org, current@freebsd.org Subject: Re: device_attach(9) and driver initialization X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 06:32:01 -0000 --4NXZt1nqaY8isg8F Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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: > > > > > > > >=20 > > > > > > > > On Apr 7, 2012, at 8:46 AM, Ian Lepore wrote: > > > > > > > >=20 > > > > > > > > > On Sat, 2012-04-07 at 15:50 +0300, Konstantin Belousov wr= ote: > > > > > > > > >> Hello, > > > > > > > > >> there seems to be a problem with device attach sequence = offered by=20 > > > > > > > newbus. > > > > > > > > >> Basically, when device attach method is executing, devic= e is not fully > > > > > > > > >> initialized yet. Also the device state in the newbus par= t of the world > > > > > > > > >> is DS_ALIVE. There is definitely no shattering news in t= he statements, > > > > > > > > >> but drivers that e.g. create devfs node to communicate w= ith consumers > > > > > > > > >> are prone to a race. > > > > > > > > >>=20 > > > > > > > > >> If /dev node is created inside device attach method, the= n usermode > > > > > > > > >> can start calling cdevsw methods before device fully ini= tialized itself. > > > > > > > > >> Even more, if device tries to use newbus helpers in cdev= sw methods, > > > > > > > > >> like device_busy(9), then panic occurs "called for unatt= eched device". > > > > > > > > >> I get reports from users about this issues, to it is not= something > > > > > > > > >> that only could happen. > > > > > > > > >>=20 > > > > > > > > >> I propose to add DEVICE_AFTER_ATTACH() driver method, to= be called > > > > > > > > >> from newbus right after device attach finished and newbu= s considers > > > > > > > > >> the device fully initialized. Driver then could create d= evfs node > > > > > > > > >> in the after_attach method instead of attach. Please see= the patch below. > > > > > > > > >>=20 > > > > > > > > >> 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 { > > > > > > > > >> }; > > > > > > > > >>=20 > > > > > > > > >> /** > > > > > > > > >> + * @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 =3D DS_ATTACHED; > > > > > > > > >> dev->flags &=3D ~DF_DONENOMATCH; > > > > > > > > >> devadded(dev); > > > > > > > > >> + DEVICE_AFTER_ATTACH(dev); > > > > > > > > >> return (0); > > > > > > > > >> } > > > > > > > > >>=20 > > > > > > > > >=20 > > > > > > > > > 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 mu= tex initialized > > > > > > > > > and acquired early in the driver's attach routine, and al= so acquired in > > > > > > > > > the driver's cdev implementation routines before using an= y 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. > > > > > > > >=20 > > > > > > > > Also, more generally, don't create the dev nodes before you= are ready to=20 > > > > > > > deal with requests. Why do we need to uglify everything here= ? If you can't=20 > > > > > > > do that, you can check a bit in the softc and return EBUSY or= ENXIO on open if=20 > > > > > > > that bit says that your driver isn't ready to accept requests. > > > > > > >=20 > > > > > > > I agree, this dosen't actually fix anything as the decision f= or what to put > > > > > > > in your foo_attach() method rather than foo_after_attach() is= non-obvious and=20 > > > > > > > very arbitrary. > > > > > > >=20 > > > > > > > The actual bug appears to only be with using 'device_busy()'.= I think > > > > > > > this should be fixed by making device_busy() better, not by a= dding > > > > > > > this type of obfuscation to attach. It should be trivial to m= ake > > > > > > > device_busy() safe to use on a device that is currently being= attached > > > > > > > which will not require any changes to drivers. > > > > > >=20 > > > > > > Could you, please, elaborate your proposal ? How do you think d= evice_busy() > > > > > > can be enchanced ? > > > > > >=20 > > > > > > Obvious idea to sleep inside device_busy() until dev->state bec= omes !=3D > > > > > > DS_ATTACHED is no go, IMO. The issue is that this causes immedi= ate deadlocks > > > > > > if device_attach() method needs to call destroy_dev() to rollba= ck. > > > > >=20 > > > > > I think you could have a DS_ATTACHING state and allow device_busy= () to work > > > > > for DS_ATTACHING. The idea being that it is a bug for a driver t= o invoke > > > > > device_busy() if it is going to fail attach. You may then need t= o do a fixup > > > > > in device_attach() to promote the state from DS_ATTACHED to DS_BU= SY when it > > > > > returns if there is a non-zero busy count. > > > > This is quite good idea, but it still adds burden to device author, > > > > although I agree that this is manageable. A scenario I have in mind= now > > > > is the following: > > > > assume that driver needs to create two devfs nodes, lets name them > > > > dri/card0 and dri/forcewake0. Driver would perform two make_dev_p(9) > > > > calls, and while creation of dri/card0 succeed, consequent creation > > > > of dri/forcewake0 could fail for numerous reasons. > > > >=20 > > > > Now, the driver needs to ensure that cdesvw->d_open() on dri/card0 > > > > would return ENXIO until dri/forcewake0 is created. This can be imp= lemented > > > > with flag, indeed. But still somewhat muddy, and probably leads to > > > > user-visible errors (I mostly worry about graphical login managers). > > >=20 > > > You could also sleep on the flag in d_open() (you can imagine a two-s= tep > > > process where you set a "adding cdev's flag", then all d_open() calls= block > > > on it). Then when finished adding cdev's, you set a flag if an error > > > occurred and wake up all the waiters. If no error occured the waiter= s can > > > have the first open() work fine. But even with other proposals you s= till > > > have to deal with this problem if you want to fail out entirely if you > > > have problems creating cdevs. > > >=20 > > > > But for single-node drivers it is indeed a nice solution. > > >=20 > > > I think we are somewhat stuck with this for other reasons as well. N= ote > > > that device_busy() propagates up the tree to parent devices, so imagi= ne > > > kldloading a driver that creates a tree (e.g. a bus with a few consum= ers) > > > where the leaf devices are attached by a call to bus_generic_attach()= from > > > the device_attach() method for the parent device. Even if you add a > > > DEVICE_AFTER_ATTACH() hook, while it may allow device_busy() to be in= voked > > > on the leaf device, when it tries to propagate device_busy() up to the > > > parent device it would still be in the middle of attach and blow up a= nyway. > >=20 > > This looks like a bug in my implementation of after_attach, which > > apparently should be called for new tree after the top level attach > > finished. >=20 > Hmm, I think this is a bit less trivial as it involves an entire pass over > the tree (and you'd probably not want to invoke it more than once on a > device, so you'd have to track that, etc.). =20 Yes, I understand that the fix for the problem with after_attach() somewhat involved. I either could mark each device in the tree as being notified, and traverse the tree after top-level attach, or keep a deferred list of devices to notify. I also would need to distinguish top-level device_attach= () against nested attaches. >=20 > > Anyway, would you commit your change ? I definitely can work out the > > driver change after. But this seems to be a large amount of work for > > driver authors. >=20 > Oh, sure. Have you tried it out? I have not tested it yet, so I will ne= ed to > do that first unless you can do so easily. Yes, I did in a sense that drm uses device_busy(). I pushed 14.3 Intel patch to web, and specifically mailed a reporter about the possible fix for his problem. Lets see how it goes. I am still worry about ENXIO for login managers, but this would be next item. --4NXZt1nqaY8isg8F Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk+FJUgACgkQC3+MBN1Mb4g0kACfQA4/E0TlZ1ltssJIAG4J0r2K 1pkAmgMxMyPNGrUhZFCY+LXGJ17ZMRa3 =81ac -----END PGP SIGNATURE----- --4NXZt1nqaY8isg8F-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 11 10:02:41 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C041E1065672; Wed, 11 Apr 2012 10:02:41 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 622F38FC08; Wed, 11 Apr 2012 10:02:41 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 3A5C57300A; Wed, 11 Apr 2012 12:21:58 +0200 (CEST) Date: Wed, 11 Apr 2012 12:21:58 +0200 From: Luigi Rizzo To: Jason Hellenthal Message-ID: <20120411102158.GA59821@onelab2.iet.unipi.it> References: <20120410225257.GB53350@onelab2.iet.unipi.it> <20120411040948.GA24775@DataIX.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120411040948.GA24775@DataIX.net> User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org, net@freebsd.org Subject: Re: strange ping response times... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 10:02:41 -0000 On Wed, Apr 11, 2012 at 12:09:48AM -0400, Jason Hellenthal wrote: > ... > > 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. ? yes i have set net.inet.icmp.icmplim=0 the 127.0.0.1 are purely through the software path. The 10ge numbers are between two freebsd machines connected back-to-back with an SFP+ twinax cable. In this case i get a min RTT of 12-13us with a ping -f, and 22-25us with ping -i 0.001 For the 10ge experiments, there is a clear dependency on the ixgbe interrupt mitigation delay (setting to 10Kintr/s gives ~120us RTT) but once you get down to 30-35us the mitigation has no more effect and you need other tricks (such as disabling AIM, ipfw, ipv6) to shave the extra 3-4us. In both cases there are several microseconds wasted between the -f and normal case. cheers luigi > 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 10000 -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-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > -- > ;s =; From owner-freebsd-current@FreeBSD.ORG Wed Apr 11 10:34:37 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 51B06106566B for ; Wed, 11 Apr 2012 10:34:37 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id B43DF8FC12 for ; Wed, 11 Apr 2012 10:34:36 +0000 (UTC) Received: (qmail 48813 invoked from network); 11 Apr 2012 10:31:18 -0000 Received: from unknown (HELO [62.48.0.94]) ([62.48.0.94]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 11 Apr 2012 10:31:18 -0000 Message-ID: <4F855E5E.5000107@freebsd.org> Date: Wed, 11 Apr 2012 12:35:10 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Luigi Rizzo References: <20120410225257.GB53350@onelab2.iet.unipi.it> <4F84B6DB.5040904@freebsd.org> <20120410230500.GA22829@pit.databus.com> <20120410233211.GA53829@onelab2.iet.unipi.it> In-Reply-To: <20120410233211.GA53829@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Barney Wolff , current@freebsd.org, net@freebsd.org Subject: Re: strange ping response times... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 10:34:37 -0000 On 11.04.2012 01:32, Luigi Rizzo wrote: > 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...) Things going through loopback go through a NETISR and may end up queued to avoid LOR situations. In addition per-cpu queues with hash-distribution for affinity may cause your packet to be processed by a different core. Hence the additional delay. -- Andre From owner-freebsd-current@FreeBSD.ORG Wed Apr 11 10:41:18 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E4AD1065672; Wed, 11 Apr 2012 10:41:18 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id D05758FC18; Wed, 11 Apr 2012 10:41:17 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 6E2777300A; Wed, 11 Apr 2012 13:00:36 +0200 (CEST) Date: Wed, 11 Apr 2012 13:00:36 +0200 From: Luigi Rizzo To: Andre Oppermann Message-ID: <20120411110036.GA60031@onelab2.iet.unipi.it> References: <20120410225257.GB53350@onelab2.iet.unipi.it> <4F84B6DB.5040904@freebsd.org> <20120410230500.GA22829@pit.databus.com> <20120410233211.GA53829@onelab2.iet.unipi.it> <4F855E5E.5000107@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F855E5E.5000107@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: Barney Wolff , current@freebsd.org, net@freebsd.org Subject: Re: strange ping response times... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 10:41:18 -0000 On Wed, Apr 11, 2012 at 12:35:10PM +0200, Andre Oppermann wrote: > On 11.04.2012 01:32, Luigi Rizzo wrote: > >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...) > > Things going through loopback go through a NETISR and may > end up queued to avoid LOR situations. In addition per-cpu > queues with hash-distribution for affinity may cause your > packet to be processed by a different core. Hence the additional > delay. so you suggest that the (de)scheduling is costing several microseconds ? Do we have something like yield() to measure how expensive is the scheduler ? I ran some tests in a distant past and i remember numbers of a few microseconds, but that was almost two gigahertz ago... cheers luigi From owner-freebsd-current@FreeBSD.ORG Wed Apr 11 11:34:04 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AB87B106564A; Wed, 11 Apr 2012 11:34:04 +0000 (UTC) (envelope-from stefan@fafoe.narf.at) Received: from fep14.mx.upcmail.net (fep14.mx.upcmail.net [62.179.121.34]) by mx1.freebsd.org (Postfix) with ESMTP id 9B3B58FC19; Wed, 11 Apr 2012 11:34:03 +0000 (UTC) Received: from edge01.upcmail.net ([192.168.13.236]) by viefep14-int.chello.at (InterMail vM.8.01.05.04 201-2260-151-105-20111014) with ESMTP id <20120411113402.VRCU8105.viefep14-int.chello.at@edge01.upcmail.net>; Wed, 11 Apr 2012 13:34:02 +0200 Received: from mole.fafoe.narf.at ([80.109.55.137]) by edge01.upcmail.net with edge id wba11i0272xdvHc01ba13Q; Wed, 11 Apr 2012 13:34:02 +0200 X-SourceIP: 80.109.55.137 Received: by mole.fafoe.narf.at (Postfix, from userid 1001) id 685196D42E; Wed, 11 Apr 2012 13:34:01 +0200 (CEST) Date: Wed, 11 Apr 2012 13:34:01 +0200 From: Stefan Farfeleder To: AN , David Chisnall , Alexander Kabaev Message-ID: <20120411113400.GA1399@mole.fafoe.narf.at> References: <20120410063153.GA1458@mole.fafoe.narf.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120410063153.GA1458@mole.fafoe.narf.at> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: gnome@freebsd.org, freebsd-current@freebsd.org Subject: Re: recent update breaks some ports X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 11:34:04 -0000 On Tue, Apr 10, 2012 at 08:31:53AM +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). FWIW backing out r233749 fixes evince and xine for me. Stefan From owner-freebsd-current@FreeBSD.ORG Wed Apr 11 12:16:10 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7ED301065670 for ; Wed, 11 Apr 2012 12:16:10 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id DC0388FC0C for ; Wed, 11 Apr 2012 12:16:09 +0000 (UTC) Received: (qmail 49146 invoked from network); 11 Apr 2012 12:12:56 -0000 Received: from unknown (HELO [62.48.0.94]) ([62.48.0.94]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 11 Apr 2012 12:12:56 -0000 Message-ID: <4F857631.8040309@freebsd.org> Date: Wed, 11 Apr 2012 14:16:49 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Luigi Rizzo References: <20120410225257.GB53350@onelab2.iet.unipi.it> <4F84B6DB.5040904@freebsd.org> <20120410230500.GA22829@pit.databus.com> <20120410233211.GA53829@onelab2.iet.unipi.it> <4F855E5E.5000107@freebsd.org> <20120411110036.GA60031@onelab2.iet.unipi.it> In-Reply-To: <20120411110036.GA60031@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Barney Wolff , current@freebsd.org, net@freebsd.org Subject: Re: strange ping response times... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 12:16:10 -0000 On 11.04.2012 13:00, Luigi Rizzo wrote: > On Wed, Apr 11, 2012 at 12:35:10PM +0200, Andre Oppermann wrote: >> On 11.04.2012 01:32, Luigi Rizzo wrote: >>> 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...) >> >> Things going through loopback go through a NETISR and may >> end up queued to avoid LOR situations. In addition per-cpu >> queues with hash-distribution for affinity may cause your >> packet to be processed by a different core. Hence the additional >> delay. > > so you suggest that the (de)scheduling is costing several microseconds ? Not directly. I'm just trying to explain what's going on to get a better idea where it may go wrong. There may be a poor ISR/scheduler interaction that prevents that causes the packet to be processed only on the next tick or something like that. I don't have a better explanation for this. > Do we have something like yield() to measure how expensive is the > scheduler ? I ran some tests in a distant past and i remember numbers > of a few microseconds, but that was almost two gigahertz ago... -- Andre From owner-freebsd-current@FreeBSD.ORG Wed Apr 11 12:53:46 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 35303106566B; Wed, 11 Apr 2012 12:53:46 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 892448FC0A; Wed, 11 Apr 2012 12:53:45 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q3BCrdos009953; Wed, 11 Apr 2012 15:53:39 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q3BCrcjV003557; Wed, 11 Apr 2012 15:53:38 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q3BCrc1H003556; Wed, 11 Apr 2012 15:53:38 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 11 Apr 2012 15:53:38 +0300 From: Konstantin Belousov To: Stefan Farfeleder Message-ID: <20120411125338.GK2358@deviant.kiev.zoral.com.ua> References: <20120410063153.GA1458@mole.fafoe.narf.at> <20120411113400.GA1399@mole.fafoe.narf.at> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kfZ+rkSFeUxXWCQG" Content-Disposition: inline In-Reply-To: <20120411113400.GA1399@mole.fafoe.narf.at> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: gnome@freebsd.org, AN , David Chisnall , freebsd-current@freebsd.org Subject: Re: recent update breaks some ports X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 12:53:46 -0000 --kfZ+rkSFeUxXWCQG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 11, 2012 at 01:34:01PM +0200, Stefan Farfeleder wrote: > On Tue, Apr 10, 2012 at 08:31:53AM +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=20 > > > 17:36:38 EDT 2012 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL amd64 > > >=20 > > > After a recent update on Sunday to r234042 I am having a problem with= 2=20 > > > ports: > > >=20 > > > gedit > > > evince > > > (using Gnome2 - ports tree up to date) > > >=20 > > > My last update (before this past Sun build/install world) was 2 weeks= ago,=20 > > > so it was definitely a change made in the last 2 weeks. > > >=20 > > > Gedit will not start from the command line, or the applications menu.= =20 > > > There is no error message on the command line. Evince will start, ho= wever=20 > > > when you try to open a document the program freezes. > > >=20 > > > I have tried to: > > > make deinstall > > > make clean > > > make install clean > > >=20 > > > for both ports but they are still broken. I would appreciate any hel= p. > >=20 > > I'm experiencing that too (r234038), xine also no longer starts (hangs > > at splash screen). >=20 > FWIW backing out r233749 fixes evince and xine for me. Please recompile at least rtld/libc/libthr with debugging symbols and get a backtrace from the hung process. --kfZ+rkSFeUxXWCQG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk+FftIACgkQC3+MBN1Mb4hu6wCdFc64nK1tn4EWShun2r26idcF tO4AnjYf6z/v0QZ6sRacNPchMdOUMa4r =9YH+ -----END PGP SIGNATURE----- --kfZ+rkSFeUxXWCQG-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 11 13:00:03 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E8A311065670; Wed, 11 Apr 2012 13:00:02 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 981C98FC0C; Wed, 11 Apr 2012 13:00:02 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 5E1F17300A; Wed, 11 Apr 2012 15:19:20 +0200 (CEST) Date: Wed, 11 Apr 2012 15:19:20 +0200 From: Luigi Rizzo To: Andre Oppermann Message-ID: <20120411131920.GA61027@onelab2.iet.unipi.it> References: <20120410225257.GB53350@onelab2.iet.unipi.it> <4F84B6DB.5040904@freebsd.org> <20120410230500.GA22829@pit.databus.com> <20120410233211.GA53829@onelab2.iet.unipi.it> <4F855E5E.5000107@freebsd.org> <20120411110036.GA60031@onelab2.iet.unipi.it> <4F857631.8040309@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F857631.8040309@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: Barney Wolff , current@freebsd.org, net@freebsd.org Subject: Re: strange ping response times... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 13:00:03 -0000 On Wed, Apr 11, 2012 at 02:16:49PM +0200, Andre Oppermann wrote: > On 11.04.2012 13:00, Luigi Rizzo wrote: > >On Wed, Apr 11, 2012 at 12:35:10PM +0200, Andre Oppermann wrote: > >>On 11.04.2012 01:32, Luigi Rizzo wrote: > >>>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...) > >> > >>Things going through loopback go through a NETISR and may > >>end up queued to avoid LOR situations. In addition per-cpu > >>queues with hash-distribution for affinity may cause your > >>packet to be processed by a different core. Hence the additional > >>delay. > > > >so you suggest that the (de)scheduling is costing several microseconds ? > > Not directly. I'm just trying to explain what's going on to > get a better idea where it may go wrong. > > There may be a poor ISR/scheduler interaction that prevents that > causes the packet to be processed only on the next tick or something > like that. I don't have a better explanation for this. ok, some final remarks just for archival purposes (still related to the loopback ping) ping takes a timestamp in userspace before trying to transmit the packet, and then the timestamp for the received packet is recorded in the kernel (in the interrupt or netisr thread i believe -- anyways, not in userspace). A thing that seems to make the difference is the choice of idle states: machdep.idle = {acpi, hlt, mwait, spin} hw.acpi.cpu.cx_lowest={C1, C2, C3} results in 10-15% of samples with significantly different values (see table below, all values in microseconds) config normal top 10-15% ----------------------------------------- acpi+c3 13 85 acpi+c2 10 40 acpi+c1 7 10 spin 7 8 hlt,mwait 6..10 (no clear distinction) ping -f 5-6 This suggests that sometimes the responding thread may be started on a sleeping core and so takes longer to wake up. The high values are not periodic but the ratio is close to the 128/1000 which relates profhz and tick, so that might be something to look at. cheers luigi From owner-freebsd-current@FreeBSD.ORG Wed Apr 11 16:21:44 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B923B106564A for ; Wed, 11 Apr 2012 16:21:44 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id 40F368FC14 for ; Wed, 11 Apr 2012 16:21:44 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 3803825D385D; Wed, 11 Apr 2012 16:21:43 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 622E3BE49F0; Wed, 11 Apr 2012 16:21:42 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id mEEvzwDFdiSO; Wed, 11 Apr 2012 16:21:41 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 3B191BE49EF; Wed, 11 Apr 2012 16:21:41 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <4F73B99F.7000300@zedat.fu-berlin.de> Date: Wed, 11 Apr 2012 16:21:40 +0000 Content-Transfer-Encoding: 7bit Message-Id: <2C56D006-CE4E-43AE-B699-541C01B54D53@FreeBSD.org> References: <4F72C742.4020300@mail.zedat.fu-berlin.de> <4F73B99F.7000300@zedat.fu-berlin.de> To: O. Hartmann X-Mailer: Apple Mail (2.1084) Cc: Current FreeBSD Subject: Re: FreeBSD 10 completely on IPv6, without IPv4? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 16:21:44 -0000 On 29. Mar 2012, at 01:23 , O. Hartmann wrote: Hi, > Am 03/28/12 13:33, schrieb Andrey Fesenko: >> On Wed, Mar 28, 2012 at 12:09 PM, O. Hartmann >> wrote: >>> Hello. >>> >>> Is FreeBSD 10.0-CURRENT capable/ready to be run as a IPv6-only system? I >>> read some time ago that to be run still some portions of the IPv4-code >>> is needed to be compiled into the system/kernel. >>> >> >> >> http://wiki.freebsd.org/IPv6Only ;) > > Thank you ;-) Just catching up with emails and just for the archives, while the wiki is updated on new snapshots, the official page people might want to reference is http://www.freebsd.org/ipv6/ipv6only.html That all said, in case you have feedback please feel free to directly mail me as well! /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From owner-freebsd-current@FreeBSD.ORG Wed Apr 11 18:19:24 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F806106564A; Wed, 11 Apr 2012 18:19:24 +0000 (UTC) (envelope-from taku@tackymt.homeip.net) Received: from basalt.tackymt.homeip.net (unknown [IPv6:2001:3e0:577:0:20d:61ff:fecc:2253]) by mx1.freebsd.org (Postfix) with ESMTP id 87E528FC16; Wed, 11 Apr 2012 18:19:23 +0000 (UTC) Received: from basalt.tackymt.homeip.net (localhost [127.0.0.1]) by basalt.tackymt.homeip.net (Postfix) with ESMTP id 8695A83A0; Thu, 12 Apr 2012 03:19:21 +0900 (JST) X-Virus-Scanned: amavisd-new at tackymt.homeip.net Received: from localhost by basalt.tackymt.homeip.net (amavisd-new, unix socket) with ESMTP id jq31JY63g9wl; Thu, 12 Apr 2012 03:19:19 +0900 (JST) Received: from biotite.tackymt.homeip.net (biotite.tackymt.homeip.net [IPv6:2001:3e0:577:0:216:cfff:febc:1472]) by basalt.tackymt.homeip.net (Postfix) with ESMTPSA; Thu, 12 Apr 2012 03:19:19 +0900 (JST) Date: Thu, 12 Apr 2012 03:19:19 +0900 From: Taku YAMAMOTO To: Konstantin Belousov Message-Id: <20120412031919.be6c584e.taku@tackymt.homeip.net> In-Reply-To: <20120411125338.GK2358@deviant.kiev.zoral.com.ua> References: <20120410063153.GA1458@mole.fafoe.narf.at> <20120411113400.GA1399@mole.fafoe.narf.at> <20120411125338.GK2358@deviant.kiev.zoral.com.ua> X-Mailer: Sylpheed 3.1.0 (GTK+ 2.22.1; i386-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Thu__12_Apr_2012_03_19_19_+0900_RWOoxKRa_Zd/w1ay" Cc: Stefan Farfeleder , gnome@freebsd.org, AN , David Chisnall , freebsd-current@freebsd.org Subject: Re: recent update breaks some ports X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 18:19:24 -0000 This is a multi-part message in MIME format. --Multipart=_Thu__12_Apr_2012_03_19_19_+0900_RWOoxKRa_Zd/w1ay Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Wed, 11 Apr 2012 15:53:38 +0300 Konstantin Belousov wrote: > On Wed, Apr 11, 2012 at 01:34:01PM +0200, Stefan Farfeleder wrote: > > On Tue, Apr 10, 2012 at 08:31:53AM +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). > > > > FWIW backing out r233749 fixes evince and xine for me. > Please recompile at least rtld/libc/libthr with debugging symbols and get > a backtrace from the hung process. My wild guess tells me that the rtld_bind_lock gets held recursively when resolving filtered symbol. The attached band-aid patch supports the guess. I have the world/kernel as of r234038 and have difficulty to launch XFce's xfdesktop-settings (w/ im-scim.so which loads libstdc++), where every threads of xfdesktop-settings stuck into either "urdlck" or "uwrlck" states. I have to admit that the attached patch is something like 3-minute-hacking quality, but it at least avoids the stall. -- -|-__ YAMAMOTO, Taku | __ < - A chicken is an egg's way of producing more eggs. - --Multipart=_Thu__12_Apr_2012_03_19_19_+0900_RWOoxKRa_Zd/w1ay Content-Type: text/plain; name="thr_rtld_lock-recursive.patch" Content-Disposition: attachment; filename="thr_rtld_lock-recursive.patch" Content-Transfer-Encoding: 7bit --- lib/libthr/thread/thr_rtld.c.orig 2011-01-23 09:17:50.657791000 +0900 +++ lib/libthr/thread/thr_rtld.c 2012-04-12 02:48:05.091322596 +0900 @@ -52,6 +52,10 @@ static void _thr_rtld_wlock_acquire(void struct rtld_lock { struct urwlock lock; + struct pthread * volatile owner; + int nested; + int count_rw; /* total rlock-within-wlock incidents */ + int count_ww; /* total wlock-within-wlock incidents */ char _pad[CACHE_LINE_SIZE - sizeof(struct urwlock)]; }; @@ -106,6 +110,15 @@ _thr_rtld_lock_destroy(void *lock) errno = errsave; \ } +#define HANDLE_NESTED_ACQ(statfield) { \ + if ((l->lock.rw_state & URWLOCK_WRITE_OWNER) != 0 && \ + l->owner == curthread) { \ + l->nested++; \ + l->statfield++; \ + return; \ + } \ + } + static void _thr_rtld_rlock_acquire(void *lock) { @@ -117,6 +130,7 @@ _thr_rtld_rlock_acquire(void *lock) SAVE_ERRNO(); l = (struct rtld_lock *)lock; + HANDLE_NESTED_ACQ(count_rw); THR_CRITICAL_ENTER(curthread); while (_thr_rwlock_rdlock(&l->lock, 0, NULL) != 0) ; @@ -135,9 +149,11 @@ _thr_rtld_wlock_acquire(void *lock) SAVE_ERRNO(); l = (struct rtld_lock *)lock; + HANDLE_NESTED_ACQ(count_ww); THR_CRITICAL_ENTER(curthread); while (_thr_rwlock_wrlock(&l->lock, NULL) != 0) ; + l->owner = curthread; RESTORE_ERRNO(); } @@ -154,6 +170,14 @@ _thr_rtld_lock_release(void *lock) l = (struct rtld_lock *)lock; state = l->lock.rw_state; + if ((state & URWLOCK_WRITE_OWNER) != 0) { + if (l->nested == 0) + l->owner = NULL; + else { + l->nested--; + return; + } + } if (_thr_rwlock_unlock(&l->lock) == 0) { if ((state & URWLOCK_WRITE_OWNER) == 0) curthread->rdlock_count--; --Multipart=_Thu__12_Apr_2012_03_19_19_+0900_RWOoxKRa_Zd/w1ay-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 11 19:04:14 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6175B106564A for ; Wed, 11 Apr 2012 19:04:14 +0000 (UTC) (envelope-from taku@tackymt.homeip.net) Received: from basalt.tackymt.homeip.net (unknown [IPv6:2001:3e0:577:0:20d:61ff:fecc:2253]) by mx1.freebsd.org (Postfix) with ESMTP id 23AAD8FC08 for ; Wed, 11 Apr 2012 19:04:14 +0000 (UTC) Received: from basalt.tackymt.homeip.net (localhost [127.0.0.1]) by basalt.tackymt.homeip.net (Postfix) with ESMTP id 3CC8383A0; Thu, 12 Apr 2012 04:04:13 +0900 (JST) X-Virus-Scanned: amavisd-new at tackymt.homeip.net Received: from localhost by basalt.tackymt.homeip.net (amavisd-new, unix socket) with ESMTP id lbMC63fAPo1f; Thu, 12 Apr 2012 04:04:10 +0900 (JST) Received: from biotite.tackymt.homeip.net (biotite.tackymt.homeip.net [IPv6:2001:3e0:577:0:216:cfff:febc:1472]) by basalt.tackymt.homeip.net (Postfix) with ESMTPSA; Thu, 12 Apr 2012 04:04:10 +0900 (JST) Date: Thu, 12 Apr 2012 04:04:11 +0900 From: Taku YAMAMOTO To: Konstantin Belousov Message-Id: <20120412040411.03ee34dd.taku@tackymt.homeip.net> In-Reply-To: <20120412031919.be6c584e.taku@tackymt.homeip.net> References: <20120410063153.GA1458@mole.fafoe.narf.at> <20120411113400.GA1399@mole.fafoe.narf.at> <20120411125338.GK2358@deviant.kiev.zoral.com.ua> <20120412031919.be6c584e.taku@tackymt.homeip.net> X-Mailer: Sylpheed 3.1.0 (GTK+ 2.22.1; i386-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Follow-up: Re: recent update breaks some ports X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 19:04:14 -0000 The following is the first occurence of wlock-within-wlock incident when I run xfdesktop-settings under gdb. Hardware watchpoint 3: lock_place[0].count_ww Old value = 0 New value = 1 0x28f52522 in _thr_rtld_wlock_acquire (lock=0x28f63600) at /usr/src/lib/libthr/thread/thr_rtld.c:152 152 HANDLE_NESTED_ACQ(count_ww); (gdb) bt #0 0x28f52522 in _thr_rtld_wlock_acquire (lock=0x28f63600) at /usr/src/lib/libthr/thread/thr_rtld.c:152 #1 0x280719c1 in wlock_acquire () from /libexec/ld-elf.so.1 #2 0x2806eb15 in dlopen_object () from /libexec/ld-elf.so.1 #3 0x2806ef1b in load_filtee1 () from /libexec/ld-elf.so.1 #4 0x2806ef7d in load_filtees () from /libexec/ld-elf.so.1 #5 0x2806f318 in symlook_obj () from /libexec/ld-elf.so.1 #6 0x2806f421 in symlook_list () from /libexec/ld-elf.so.1 #7 0x2806fa0b in symlook_default () from /libexec/ld-elf.so.1 #8 0x2806fc1a in find_symdef () from /libexec/ld-elf.so.1 #9 0x2806a426 in reloc_non_plt () from /libexec/ld-elf.so.1 #10 0x2806d453 in relocate_objects () from /libexec/ld-elf.so.1 #11 0x2806ee6d in dlopen_object () from /libexec/ld-elf.so.1 #12 0x2806f862 in rtld_dlopen () from /libexec/ld-elf.so.1 #13 0x28d2a6b0 in g_module_open () from /usr/local/lib/libgmodule-2.0.so.0 #14 0x28406894 in gtk_im_context_simple_new () from /usr/local/lib/libgtk-x11-2.0.so.0 The following is the first occurence of rlock-within-wlock incident. Hardware watchpoint 2: lock_place[0].count_rw Old value = 0 New value = 1 0x28f526fd in _thr_rtld_rlock_acquire (lock=0x28f63600) at /usr/src/lib/libthr/thread/thr_rtld.c:133 133 HANDLE_NESTED_ACQ(count_rw); (gdb) bt #0 0x28f526fd in _thr_rtld_rlock_acquire (lock=0x28f63600) at /usr/src/lib/libthr/thread/thr_rtld.c:133 #1 0x28071291 in rlock_acquire () from /libexec/ld-elf.so.1 #2 0x2806fccb in _rtld_bind () from /libexec/ld-elf.so.1 #3 0x28069dc9 in _rtld_bind_start () from /libexec/ld-elf.so.1 #4 0x290c3000 in ?? () #5 0x00000148 in ?? () #6 0x29356318 in ?? () from /usr/lib/libsupc++.so.1 #7 0x28f503e0 in _thr_once_init () from /home/taku/work/build/biotite/usr/src/lib/libthr/libthr.so.3 #8 0xffffffff in ?? () #9 0x00200202 in ?? () #10 0x290c3000 in ?? () #11 0x00000148 in ?? () #12 0x2935eae0 in __gxx_personality_v0 () from /usr/lib/libsupc++.so.1 #13 0x2935f5c5 in __cxa_get_globals () from /usr/lib/libsupc++.so.1 #14 0x290c2710 in ?? () #15 0xbfbfdc48 in ?? () #16 0x29356325 in ?? () from /usr/lib/libsupc++.so.1 #17 0x280714c9 in lock_release () from /libexec/ld-elf.so.1 Previous frame inner to this frame (corrupt stack?) -- -|-__ YAMAMOTO, Taku | __ < - A chicken is an egg's way of producing more eggs. - From owner-freebsd-current@FreeBSD.ORG Wed Apr 11 19:42:47 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 29EA7106564A for ; Wed, 11 Apr 2012 19:42:47 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 864518FC0C for ; Wed, 11 Apr 2012 19:42:46 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q3BJgepM097696; Wed, 11 Apr 2012 22:42:40 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q3BJgem6005355; Wed, 11 Apr 2012 22:42:40 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q3BJgdjY005354; Wed, 11 Apr 2012 22:42:39 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 11 Apr 2012 22:42:39 +0300 From: Konstantin Belousov To: Taku YAMAMOTO Message-ID: <20120411194239.GN2358@deviant.kiev.zoral.com.ua> References: <20120410063153.GA1458@mole.fafoe.narf.at> <20120411113400.GA1399@mole.fafoe.narf.at> <20120411125338.GK2358@deviant.kiev.zoral.com.ua> <20120412031919.be6c584e.taku@tackymt.homeip.net> <20120412040411.03ee34dd.taku@tackymt.homeip.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jZYq8Bnk7KOiLUpC" Content-Disposition: inline In-Reply-To: <20120412040411.03ee34dd.taku@tackymt.homeip.net> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current@freebsd.org Subject: Re: Follow-up: Re: recent update breaks some ports X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 19:42:47 -0000 --jZYq8Bnk7KOiLUpC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 12, 2012 at 04:04:11AM +0900, Taku YAMAMOTO wrote: > The following is the first occurence of wlock-within-wlock incident > when I run xfdesktop-settings under gdb. >=20 > Hardware watchpoint 3: lock_place[0].count_ww >=20 > Old value =3D 0 > New value =3D 1 > 0x28f52522 in _thr_rtld_wlock_acquire (lock=3D0x28f63600) > at /usr/src/lib/libthr/thread/thr_rtld.c:152 > 152 HANDLE_NESTED_ACQ(count_ww); > (gdb) bt > #0 0x28f52522 in _thr_rtld_wlock_acquire (lock=3D0x28f63600) > at /usr/src/lib/libthr/thread/thr_rtld.c:152 > #1 0x280719c1 in wlock_acquire () from /libexec/ld-elf.so.1 > #2 0x2806eb15 in dlopen_object () from /libexec/ld-elf.so.1 > #3 0x2806ef1b in load_filtee1 () from /libexec/ld-elf.so.1 > #4 0x2806ef7d in load_filtees () from /libexec/ld-elf.so.1 > #5 0x2806f318 in symlook_obj () from /libexec/ld-elf.so.1 > #6 0x2806f421 in symlook_list () from /libexec/ld-elf.so.1 > #7 0x2806fa0b in symlook_default () from /libexec/ld-elf.so.1 > #8 0x2806fc1a in find_symdef () from /libexec/ld-elf.so.1 > #9 0x2806a426 in reloc_non_plt () from /libexec/ld-elf.so.1 > #10 0x2806d453 in relocate_objects () from /libexec/ld-elf.so.1 > #11 0x2806ee6d in dlopen_object () from /libexec/ld-elf.so.1 > #12 0x2806f862 in rtld_dlopen () from /libexec/ld-elf.so.1 > #13 0x28d2a6b0 in g_module_open () from /usr/local/lib/libgmodule-2.0.so.0 > #14 0x28406894 in gtk_im_context_simple_new () > from /usr/local/lib/libgtk-x11-2.0.so.0 Thank you for the report, I hope that the patch at the end of the message would take care of this problem. >=20 >=20 > The following is the first occurence of rlock-within-wlock incident. >=20 > Hardware watchpoint 2: lock_place[0].count_rw >=20 > Old value =3D 0 > New value =3D 1 > 0x28f526fd in _thr_rtld_rlock_acquire (lock=3D0x28f63600) > at /usr/src/lib/libthr/thread/thr_rtld.c:133 > 133 HANDLE_NESTED_ACQ(count_rw); > (gdb) bt > #0 0x28f526fd in _thr_rtld_rlock_acquire (lock=3D0x28f63600) > at /usr/src/lib/libthr/thread/thr_rtld.c:133 > #1 0x28071291 in rlock_acquire () from /libexec/ld-elf.so.1 > #2 0x2806fccb in _rtld_bind () from /libexec/ld-elf.so.1 > #3 0x28069dc9 in _rtld_bind_start () from /libexec/ld-elf.so.1 > #4 0x290c3000 in ?? () > #5 0x00000148 in ?? () > #6 0x29356318 in ?? () from /usr/lib/libsupc++.so.1 > #7 0x28f503e0 in _thr_once_init () > from /home/taku/work/build/biotite/usr/src/lib/libthr/libthr.so.3 > #8 0xffffffff in ?? () > #9 0x00200202 in ?? () > #10 0x290c3000 in ?? () > #11 0x00000148 in ?? () > #12 0x2935eae0 in __gxx_personality_v0 () from /usr/lib/libsupc++.so.1 > #13 0x2935f5c5 in __cxa_get_globals () from /usr/lib/libsupc++.so.1 > #14 0x290c2710 in ?? () > #15 0xbfbfdc48 in ?? () > #16 0x29356325 in ?? () from /usr/lib/libsupc++.so.1 > #17 0x280714c9 in lock_release () from /libexec/ld-elf.so.1 > Previous frame inner to this frame (corrupt stack?) Unortunately, this trace is not usefule, it seems that you need to recompile rtld/libc/libthr with debugging symbols to get the issue fixed. diff --git a/libexec/rtld-elf/rtld.c b/libexec/rtld-elf/rtld.c index f02d276..1def854 100644 --- a/libexec/rtld-elf/rtld.c +++ b/libexec/rtld-elf/rtld.c @@ -85,7 +85,7 @@ static void digest_dynamic(Obj_Entry *, int); static Obj_Entry *digest_phdr(const Elf_Phdr *, int, caddr_t, const char *= ); static Obj_Entry *dlcheck(void *); static Obj_Entry *dlopen_object(const char *name, int fd, Obj_Entry *refob= j, - int lo_flags, int mode); + int lo_flags, int mode, RtldLockState *lockstate); static Obj_Entry *do_load_object(int, const char *, char *, struct stat *,= int); static int do_search_info(const Obj_Entry *obj, int, struct dl_serinfo *); static bool donelist_check(DoneList *, const Obj_Entry *); @@ -1672,13 +1672,14 @@ unload_filtees(Obj_Entry *obj) } =20 static void -load_filtee1(Obj_Entry *obj, Needed_Entry *needed, int flags) +load_filtee1(Obj_Entry *obj, Needed_Entry *needed, int flags, + RtldLockState *lockstate) { =20 for (; needed !=3D NULL; needed =3D needed->next) { needed->obj =3D dlopen_object(obj->strtab + needed->name, -1, obj, flags, ((ld_loadfltr || obj->z_loadfltr) ? RTLD_NOW : RTLD_LAZY) | - RTLD_LOCAL); + RTLD_LOCAL, lockstate); } } =20 @@ -1688,8 +1689,8 @@ load_filtees(Obj_Entry *obj, int flags, RtldLockState= *lockstate) =20 lock_restart_for_upgrade(lockstate); if (!obj->filtees_loaded) { - load_filtee1(obj, obj->needed_filtees, flags); - load_filtee1(obj, obj->needed_aux_filtees, flags); + load_filtee1(obj, obj->needed_filtees, flags, lockstate); + load_filtee1(obj, obj->needed_aux_filtees, flags, lockstate); obj->filtees_loaded =3D true; } } @@ -2489,7 +2490,7 @@ rtld_dlopen(const char *name, int fd, int mode) lo_flags |=3D RTLD_LO_TRACE; =20 return (dlopen_object(name, fd, obj_main, lo_flags, - mode & (RTLD_MODEMASK | RTLD_GLOBAL))); + mode & (RTLD_MODEMASK | RTLD_GLOBAL), NULL)); } =20 static void @@ -2504,17 +2505,20 @@ dlopen_cleanup(Obj_Entry *obj) =20 static Obj_Entry * dlopen_object(const char *name, int fd, Obj_Entry *refobj, int lo_flags, - int mode) + int mode, RtldLockState *lockstate) { Obj_Entry **old_obj_tail; Obj_Entry *obj; Objlist initlist; - RtldLockState lockstate; + RtldLockState mlockstate; int result; =20 objlist_init(&initlist); =20 - wlock_acquire(rtld_bind_lock, &lockstate); + if (lockstate =3D=3D NULL && !(lo_flags & RTLD_LO_EARLY)) { + wlock_acquire(rtld_bind_lock, &mlockstate); + lockstate =3D &mlockstate; + } GDB_STATE(RT_ADD,NULL); =20 old_obj_tail =3D obj_tail; @@ -2543,7 +2547,7 @@ dlopen_object(const char *name, int fd, Obj_Entry *re= fobj, int lo_flags, if (result =3D=3D -1 || (relocate_objects(obj, (mode & RTLD_MODEMASK) =3D=3D RTLD_NOW, &obj_rtld, (lo_flags & RTLD_LO_EARLY) ? SYMLOOK_EARLY : 0, - &lockstate)) =3D=3D -1) { + lockstate)) =3D=3D -1) { dlopen_cleanup(obj); obj =3D NULL; } else if (lo_flags & RTLD_LO_EARLY) { @@ -2587,28 +2591,31 @@ dlopen_object(const char *name, int fd, Obj_Entry *= refobj, int lo_flags, GDB_STATE(RT_CONSISTENT,obj ? &obj->linkmap : NULL); =20 if (!(lo_flags & RTLD_LO_EARLY)) { - map_stacks_exec(&lockstate); + map_stacks_exec(lockstate); } =20 if (initlist_objects_ifunc(&initlist, (mode & RTLD_MODEMASK) =3D=3D RT= LD_NOW, (lo_flags & RTLD_LO_EARLY) ? SYMLOOK_EARLY : 0, - &lockstate) =3D=3D -1) { + lockstate) =3D=3D -1) { objlist_clear(&initlist); dlopen_cleanup(obj); - lock_release(rtld_bind_lock, &lockstate); + if (lockstate =3D=3D &mlockstate) + lock_release(rtld_bind_lock, lockstate); return (NULL); } =20 if (!(lo_flags & RTLD_LO_EARLY)) { /* Call the init functions. */ - objlist_call_init(&initlist, &lockstate); + objlist_call_init(&initlist, lockstate); } objlist_clear(&initlist); - lock_release(rtld_bind_lock, &lockstate); + if (lockstate =3D=3D &mlockstate) + lock_release(rtld_bind_lock, lockstate); return obj; trace: trace_loaded_objects(obj); - lock_release(rtld_bind_lock, &lockstate); + if (lockstate =3D=3D &mlockstate) + lock_release(rtld_bind_lock, lockstate); exit(0); } =20 --jZYq8Bnk7KOiLUpC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk+F3q8ACgkQC3+MBN1Mb4hlbwCg3itV3h1dFLBa61ydIN+pfsAT 9HQAoJRt6JwT2qGFMFCOa0/oJ+1Bia26 =Zr+l -----END PGP SIGNATURE----- --jZYq8Bnk7KOiLUpC-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 11 21:28:04 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 987A8106564A; Wed, 11 Apr 2012 21:28:04 +0000 (UTC) (envelope-from stefan@fafoe.narf.at) Received: from fep13.mx.upcmail.net (fep13.mx.upcmail.net [62.179.121.33]) by mx1.freebsd.org (Postfix) with ESMTP id B96388FC08; Wed, 11 Apr 2012 21:28:03 +0000 (UTC) Received: from edge04.upcmail.net ([192.168.13.239]) by viefep13-int.chello.at (InterMail vM.8.01.05.04 201-2260-151-105-20111014) with ESMTP id <20120411212756.ZRXD3333.viefep13-int.chello.at@edge04.upcmail.net>; Wed, 11 Apr 2012 23:27:56 +0200 Received: from mole.fafoe.narf.at ([80.109.55.137]) by edge04.upcmail.net with edge id wlTv1i0132xdvHc04lTvWJ; Wed, 11 Apr 2012 23:27:56 +0200 X-SourceIP: 80.109.55.137 Received: by mole.fafoe.narf.at (Postfix, from userid 1001) id 77A5E6D458; Wed, 11 Apr 2012 23:27:55 +0200 (CEST) Date: Wed, 11 Apr 2012 23:27:55 +0200 From: Stefan Farfeleder To: Konstantin Belousov Message-ID: <20120411212755.GA1355@mole.fafoe.narf.at> References: <20120410063153.GA1458@mole.fafoe.narf.at> <20120411113400.GA1399@mole.fafoe.narf.at> <20120411125338.GK2358@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120411125338.GK2358@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: gnome@freebsd.org, AN , David Chisnall , freebsd-current@freebsd.org Subject: Re: recent update breaks some ports X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 21:28:04 -0000 On Wed, Apr 11, 2012 at 03:53:38PM +0300, Konstantin Belousov wrote: > On Wed, Apr 11, 2012 at 01:34:01PM +0200, Stefan Farfeleder wrote: > > On Tue, Apr 10, 2012 at 08:31:53AM +0200, Stefan Farfeleder wrote: > > > > > > I'm experiencing that too (r234038), xine also no longer starts (hangs > > > at splash screen). > > > > FWIW backing out r233749 fixes evince and xine for me. > Please recompile at least rtld/libc/libthr with debugging symbols and get > a backtrace from the hung process. Attaching gdb to a hanging evince process yields this: (gdb) bt #0 0x0000000807f7c9ac in __error () from /lib/libthr.so.3 #1 0x0000000807f72431 in pthread_getschedparam () from /lib/libthr.so.3 #2 0x0000000807f78473 in pthread_kill () from /lib/libthr.so.3 #3 0x00000008006676a9 in _rtld_thread_init () from /libexec/ld-elf.so.1 #4 0x0000000800664a6e in dlclose () from /libexec/ld-elf.so.1 #5 0x0000000800664e2c in dlclose () from /libexec/ld-elf.so.1 #6 0x0000000800664e86 in dlclose () from /libexec/ld-elf.so.1 #7 0x00000008006651bb in dlclose () from /libexec/ld-elf.so.1 #8 0x0000000800665337 in dlclose () from /libexec/ld-elf.so.1 #9 0x0000000800665521 in dlclose () from /libexec/ld-elf.so.1 #10 0x00000008006658ef in dlopen () from /libexec/ld-elf.so.1 #11 0x0000000800665bed in dlopen () from /libexec/ld-elf.so.1 #12 0x000000080066065b in __tls_get_addr () from /libexec/ld-elf.so.1 #13 0x00000008006634e7 in _rtld_addr_phdr () from /libexec/ld-elf.so.1 #14 0x0000000800664c96 in dlclose () from /libexec/ld-elf.so.1 #15 0x00000008006657b4 in dlclose () from /libexec/ld-elf.so.1 #16 0x0000000806ba376b in g_module_open () from /usr/local/lib/libgmodule-2.0.so.0 #17 0x0000000800cb5097 in ev_module_get_path () from /usr/local/lib/libevdocument.so.3 #18 0x0000000806dd866c in g_type_module_use () from /usr/local/lib/libgobject-2.0.so.0 #19 0x0000000800cac949 in ev_backends_manager_get_document () from /usr/local/lib/libevdocument.so.3 #20 0x0000000800cb13f5 in ev_document_factory_add_filters () from /usr/local/lib/libevdocument.so.3 #21 0x0000000800cb15d4 in ev_document_factory_get_document () from /usr/local/lib/libevdocument.so.3 #22 0x0000000800ee77b9 in ev_job_load_new () from /usr/local/lib/libevview.so.3 #23 0x0000000800ee90f5 in ev_job_scheduler_push_job () from /usr/local/lib/libevview.so.3 #24 0x0000000807259274 in g_thread_create_full () from /usr/local/lib/libglib-2.0.so.0 #25 0x0000000807f70cdd in pthread_create () from /lib/libthr.so.3 #26 0x0000000000000000 in ?? () Error accessing memory address 0x7fffff5fb000: Bad address. For xine it's this: (gdb) bt #0 0x0000000802e3c9ac in __error () from /lib/libthr.so.3 #1 0x0000000802e3262f in pthread_getschedparam () from /lib/libthr.so.3 #2 0x0000000802e3b09d in pthread_cond_signal () from /lib/libthr.so.3 #3 0x0000000800bfbf23 in metronom_sync_loop (this_gen=Variable "this_gen" is not available. ) at metronom.c:871 #4 0x0000000802e30cdd in pthread_create () from /lib/libthr.so.3 #5 0x0000000000000000 in ?? () Error accessing memory address 0x7fffff7fc000: Bad address. I hope this helps. Stefan From owner-freebsd-current@FreeBSD.ORG Wed Apr 11 21:33:18 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 25860106564A for ; Wed, 11 Apr 2012 21:33:18 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id A86E38FC14 for ; Wed, 11 Apr 2012 21:33:17 +0000 (UTC) Received: by wern13 with SMTP id n13so1148837wer.13 for ; Wed, 11 Apr 2012 14:33:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=It1Ic+nQCp09rLk0Ql/GnHKcxJ1fcvt3YQ2+9DYt3So=; b=hUIzf+fLR32ksiqJY8RxpR40v9oIrYln7wIlNTQiPhWFrQz2lykX+cmj76dKKJb5MD szpDHEcl+wpDShmVOljCJljepE8Hfdv0vulzad+QpK4E8xLpQ5M+rFIqECUWDRkr75m3 NJDrr00LeBTn79Ed40EhHoztRP5GSV0rPJgoJkvFxpI16NvjtX1LxrzBK4k4FRDAUVE1 HikSgQGG3KW2Ww7GDXTDWIZgR86qTjr8wWzDHvYo3xYlB2XThAITV8RRbHjtcbFxsgpk jEN6zk0m11A1O8ifpfuPKJAyWE/icEPRTqjtGLUqMpHOajSpbFKZaBN/8zjQirC4DMc2 VMGQ== MIME-Version: 1.0 Received: by 10.180.79.135 with SMTP id j7mr9867643wix.19.1334179991253; Wed, 11 Apr 2012 14:33:11 -0700 (PDT) Received: by 10.216.49.81 with HTTP; Wed, 11 Apr 2012 14:33:11 -0700 (PDT) Date: Wed, 11 Apr 2012 17:33:11 -0400 Message-ID: From: Arnaud Lacombe To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 Subject: FreeBSD on recent Xeon E5 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 21:33:18 -0000 Hi, I just booted FreeBSD 9.0-RELEASE on a Xeon E5-1650 based platform. It would seems that the CPU handles by itself a lots of PCI functions which do not seem to be supported by FreeBSD. Here is the output of `pciconf -l' restricted to unhandled devices: none0@pci0:0:4:0: class=0x088000 card=0x062b15d9 chip=0x3c208086 none1@pci0:0:4:1: class=0x088000 card=0x062b15d9 chip=0x3c218086 none2@pci0:0:4:2: class=0x088000 card=0x062b15d9 chip=0x3c228086 none3@pci0:0:4:3: class=0x088000 card=0x062b15d9 chip=0x3c238086 none4@pci0:0:4:4: class=0x088000 card=0x062b15d9 chip=0x3c248086 none5@pci0:0:4:5: class=0x088000 card=0x062b15d9 chip=0x3c258086 none6@pci0:0:4:6: class=0x088000 card=0x062b15d9 chip=0x3c268086 none7@pci0:0:4:7: class=0x088000 card=0x062b15d9 chip=0x3c278086 none8@pci0:0:5:0: class=0x088000 card=0x062b15d9 chip=0x3c288086 none9@pci0:0:5:2: class=0x088000 card=0x062b15d9 chip=0x3c2a8086 none10@pci0:0:22:0: class=0x078000 card=0x062b15d9 chip=0x1d3a8086 none11@pci0:0:22:1: class=0x078000 card=0x062b15d9 chip=0x1d3b8086 none12@pci0:0:22:3: class=0x070002 card=0x062b15d9 chip=0x1d3d8086 none13@pci0:0:31:3: class=0x0c0500 card=0x062b15d9 chip=0x1d228086 none14@pci0:0:31:6: class=0x118000 card=0x062b15d9 chip=0x1d248086 none15@pci0:8:0:0: class=0x010700 card=0x062b15d9 chip=0x1d6b8086 none16@pci0:255:8:0: class=0x088000 card=0x062b15d9 chip=0x3c808086 none17@pci0:255:8:3: class=0x088000 card=0x062b15d9 chip=0x3c838086 none18@pci0:255:8:4: class=0x088000 card=0x062b15d9 chip=0x3c848086 none19@pci0:255:9:0: class=0x088000 card=0x062b15d9 chip=0x3c908086 none20@pci0:255:9:3: class=0x088000 card=0x062b15d9 chip=0x3c938086 none21@pci0:255:9:4: class=0x088000 card=0x062b15d9 chip=0x3c948086 none22@pci0:255:10:0: class=0x088000 card=0x062b15d9 chip=0x3cc08086 none23@pci0:255:10:1: class=0x088000 card=0x062b15d9 chip=0x3cc18086 none24@pci0:255:10:2: class=0x088000 card=0x062b15d9 chip=0x3cc28086 none25@pci0:255:10:3: class=0x088000 card=0x062b15d9 chip=0x3cd08086 none26@pci0:255:11:0: class=0x088000 card=0x062b15d9 chip=0x3ce08086 none27@pci0:255:11:3: class=0x088000 card=0x062b15d9 chip=0x3ce38086 none28@pci0:255:12:0: class=0x088000 card=0x000015d9 chip=0x3ce88086 none29@pci0:255:12:1: class=0x088000 card=0x000015d9 chip=0x3ce88086 none30@pci0:255:12:2: class=0x088000 card=0x000015d9 chip=0x3ce88086 none31@pci0:255:12:6: class=0x088000 card=0x000015d9 chip=0x3cf48086 none32@pci0:255:12:7: class=0x088000 card=0x000015d9 chip=0x3cf68086 none33@pci0:255:13:0: class=0x088000 card=0x000015d9 chip=0x3ce88086 none34@pci0:255:13:1: class=0x088000 card=0x000015d9 chip=0x3ce88086 none35@pci0:255:13:2: class=0x088000 card=0x000015d9 chip=0x3ce88086 none36@pci0:255:13:6: class=0x088000 card=0x000015d9 chip=0x3cf58086 none37@pci0:255:14:0: class=0x088000 card=0x062b15d9 chip=0x3ca08086 none38@pci0:255:14:1: class=0x110100 card=0x062b15d9 chip=0x3c468086 none39@pci0:255:15:0: class=0x088000 card=0x062b15d9 chip=0x3ca88086 none40@pci0:255:15:1: class=0x088000 card=0x062b15d9 chip=0x3c718086 none41@pci0:255:15:2: class=0x088000 card=0x062b15d9 chip=0x3caa8086 none42@pci0:255:15:3: class=0x088000 card=0x062b15d9 chip=0x3cab8086 none43@pci0:255:15:4: class=0x088000 card=0x062b15d9 chip=0x3cac8086 none44@pci0:255:15:5: class=0x088000 card=0x062b15d9 chip=0x3cad8086 none45@pci0:255:15:6: class=0x088000 card=0x062b15d9 chip=0x3cae8086 none46@pci0:255:16:0: class=0x088000 card=0x062b15d9 chip=0x3cb08086 none47@pci0:255:16:1: class=0x088000 card=0x062b15d9 chip=0x3cb18086 none48@pci0:255:16:2: class=0x088000 card=0x062b15d9 chip=0x3cb28086 none49@pci0:255:16:3: class=0x088000 card=0x062b15d9 chip=0x3cb38086 none50@pci0:255:16:4: class=0x088000 card=0x062b15d9 chip=0x3cb48086 none51@pci0:255:16:5: class=0x088000 card=0x062b15d9 chip=0x3cb58086 none52@pci0:255:16:6: class=0x088000 card=0x062b15d9 chip=0x3cb68086 none53@pci0:255:16:7: class=0x088000 card=0x062b15d9 chip=0x3cb78086 none54@pci0:255:17:0: class=0x088000 card=0x062b15d9 chip=0x3cb88086 none55@pci0:255:19:0: class=0x088000 card=0x062b15d9 chip=0x3ce48086 none56@pci0:255:19:1: class=0x110100 card=0x062b15d9 chip=0x3c438086 none57@pci0:255:19:4: class=0x110100 card=0x062b15d9 chip=0x3ce68086 none58@pci0:255:19:5: class=0x110100 card=0x062b15d9 chip=0x3c448086 none59@pci0:255:19:6: class=0x088000 card=0x062b15d9 chip=0x3c458086 These would seem to correspond to Uncore feature, namely, as per [0]: 0x3C20 - 0x3C3F: IO Features (QDDMA, APIC, Intel VT, RAS, Intel TXT) 0x3C40 - 0x3C5F: Performance Monitors 0x3C60 - 0x3C7F: DFX 0x3C80 - 0x3C9F: Intel QuickPath Interconnect 0x3CA0 - 0x3CBF: Home Agent/Memory Controller 0x3CC0 - 0x3CDF: Power Management 0x3CE0 - 0x3CFF: Cbo/Ring Even if it would not seem to be critical features, what will be the consequence of having those features currently unhandled ? Thanks, - Arnaud [0]: http://www.intel.vn/content/dam/www/public/us/en/documents/datasheets/xeon-e5-1600-2600-vol-2-datasheet.pdf From owner-freebsd-current@FreeBSD.ORG Wed Apr 11 23:26:41 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 407BC106564A; Wed, 11 Apr 2012 23:26:41 +0000 (UTC) (envelope-from venture37@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 944F98FC0A; Wed, 11 Apr 2012 23:26:40 +0000 (UTC) Received: by wgbds12 with SMTP id ds12so1420446wgb.31 for ; Wed, 11 Apr 2012 16:26:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ViXK48+SsS0kPYRRJnFsg6oIRQ9S3klkq4a9+GHwTeM=; b=Qv5QJk1c7NDtNUL5hKgKw4drj639FuUUyu1nkRsT78gpupjXBKvr2BJEK+Tm5q5InU ztuylw0+6Ha1WqzYRBinpaT86GZutgofmAuF46ZJVUlRsSkL/6yocObNMkHXVkeMzvqb YWRmEH3HN4Fh2C9xgPh8lRXaK457KT+0HuiRAud7pGwbTzytnKEpDPb+rmfpd/cgy5Ho zCqhIDvbZ0CT8ZC2nPTF+JGoJtJoCC/bTeEQUhtvqNtl2bIuZwvZqDFDhAYX8bixzmXv Hda8XfI5nkmt/Ks6FSeMFWWPmA7UAcdZNl/XkL12EiPv3cIPBCHj3cgK2X5npw2x5gi7 CJhQ== Received: by 10.180.82.136 with SMTP id i8mr602497wiy.19.1334186793732; Wed, 11 Apr 2012 16:26:33 -0700 (PDT) Received: from Sevans-MacBook-Pro.local (cpc2-brig17-2-0-cust527.3-3.cable.virginmedia.com. [81.101.198.16]) by mx.google.com with ESMTPS id n20sm14796180wiw.5.2012.04.11.16.26.31 (version=SSLv3 cipher=OTHER); Wed, 11 Apr 2012 16:26:32 -0700 (PDT) Message-ID: <4F861326.8010506@gmail.com> Date: Thu, 12 Apr 2012 00:26:30 +0100 From: Sevan / Venture37 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Daichi GOTO References: <566771C2-84CA-4824-AE99-38EB5DE1F786@gmail.com> <20120410104521.ba15b1c3.daichi@freebsd.org> <4F84B0AF.7010401@gmail.com> <20120411092145.3eccb9e4.daichi@freebsd.org> In-Reply-To: <20120411092145.3eccb9e4.daichi@freebsd.org> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: "freebsd-current@freebsd.org" Subject: Re: DTrace on FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 23:26:41 -0000 On 11/04/2012 01:21, Daichi GOTO wrote: > I do not know well. And I think Tod McQuillin could help you. > (http://2012.asiabsdcon.org/timetable.html#T1B) I have emailed Tod on an address I found in the archive here from 2009. I've been digging around the archive of this list to see if I could shed any more light on the matter & found this reply from John Birrell himself 3 months after DTrace had been imported, again rather than mention a licensing issue he questions the demand. http://marc.info/?l=freebsd-current&m=122177370027975&w=2 Sevan From owner-freebsd-current@FreeBSD.ORG Thu Apr 12 00:03:39 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55DF3106566B; Thu, 12 Apr 2012 00:03:39 +0000 (UTC) (envelope-from venture37@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id AED818FC16; Thu, 12 Apr 2012 00:03:38 +0000 (UTC) Received: by wgbds12 with SMTP id ds12so1438810wgb.31 for ; Wed, 11 Apr 2012 17:03:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=5QJZiQ1micTUh9m/powlcDfVidb57VEd1ICYFjdZr6Q=; b=np37fkx3rwICJ/SYWe4U4ZVLCAtCdihAPLW91z1ZZP4RLxzQZ7if/HKj1VM9NnYTxx 4Hw6WQ6SIIZVLj3/1NoZOoVYR8ONoVXltwnj6HjOCcoKmVGOMrE30hGC8ZXwuPwi6+a2 VdyrwjdetZyPkz1bhuLUWBOcw/zJuZtB9w3Dol4v3lSs6D3j9wAAhLD5ezp6/mBF25W0 SVXwBPTNzhy5S7DvulWcnXclnJKWfY8fEfZwTdseakjV9/ZRdzHRGIyfb+P0qlJSMz6p WC3Z6EPdvBWqu2fJPEhyGjk2MH2CRWK6LCyPQxuFs03C2As1Mx2eOyp2CYDfXtRKwuPD CFLg== Received: by 10.180.91.165 with SMTP id cf5mr889623wib.2.1334189014865; Wed, 11 Apr 2012 17:03:34 -0700 (PDT) Received: from Sevans-MacBook-Pro.local (cpc2-brig17-2-0-cust527.3-3.cable.virginmedia.com. [81.101.198.16]) by mx.google.com with ESMTPS id j3sm15101709wiw.1.2012.04.11.17.03.33 (version=SSLv3 cipher=OTHER); Wed, 11 Apr 2012 17:03:34 -0700 (PDT) Message-ID: <4F861BD4.3020001@gmail.com> Date: Thu, 12 Apr 2012 01:03:32 +0100 From: Sevan / Venture37 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Daichi GOTO References: <566771C2-84CA-4824-AE99-38EB5DE1F786@gmail.com> <20120410104521.ba15b1c3.daichi@freebsd.org> <4F84B0AF.7010401@gmail.com> <20120411092145.3eccb9e4.daichi@freebsd.org> <4F861326.8010506@gmail.com> In-Reply-To: <4F861326.8010506@gmail.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: "freebsd-current@freebsd.org" Subject: Re: DTrace on FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 00:03:39 -0000 On 12/04/2012 00:26, Sevan / Venture37 wrote: > I have emailed Tod on an address I found in the archive here from 2009. > I've been digging around the archive of this list to see if I could shed > any more light on the matter& found this reply from John Birrell > himself 3 months after DTrace had been imported, again rather than > mention a licensing issue he questions the demand. > http://marc.info/?l=freebsd-current&m=122177370027975&w=2 18/11/2007 http://web.archive.org/web/20080914164317/http://dtrace.what-creek.com/ 12/1/2008 http://marc.info/?l=freebsd-chat&m=120017390123976&w=2 28/8/2008 http://marc.info/?l=freebsd-stable&m=121982215016172&w=2 Sevan From owner-freebsd-current@FreeBSD.ORG Thu Apr 12 03:19:18 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F7CD106566B; Thu, 12 Apr 2012 03:19:18 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail01.syd.optusnet.com.au (mail01.syd.optusnet.com.au [211.29.132.182]) by mx1.freebsd.org (Postfix) with ESMTP id E7B868FC0C; Thu, 12 Apr 2012 03:19:17 +0000 (UTC) Received: from c211-30-171-136.carlnfd1.nsw.optusnet.com.au (c211-30-171-136.carlnfd1.nsw.optusnet.com.au [211.30.171.136]) by mail01.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q3C3Ixxn028956 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2012 13:19:01 +1000 Date: Thu, 12 Apr 2012 13:18:59 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Luigi Rizzo In-Reply-To: <20120411131920.GA61027@onelab2.iet.unipi.it> Message-ID: <20120412112401.Q981@besplex.bde.org> References: <20120410225257.GB53350@onelab2.iet.unipi.it> <4F84B6DB.5040904@freebsd.org> <20120410230500.GA22829@pit.databus.com> <20120410233211.GA53829@onelab2.iet.unipi.it> <4F855E5E.5000107@freebsd.org> <20120411110036.GA60031@onelab2.iet.unipi.it> <4F857631.8040309@freebsd.org> <20120411131920.GA61027@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Thu, 12 Apr 2012 03:24:55 +0000 Cc: Barney Wolff , Andre Oppermann , current@freebsd.org, net@freebsd.org Subject: Re: strange ping response times... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 03:19:18 -0000 On Wed, 11 Apr 2012, Luigi Rizzo wrote: > On Wed, Apr 11, 2012 at 02:16:49PM +0200, Andre Oppermann wrote: >> On 11.04.2012 13:00, Luigi Rizzo wrote: >>> On Wed, Apr 11, 2012 at 12:35:10PM +0200, Andre Oppermann wrote: >>>> On 11.04.2012 01:32, Luigi Rizzo wrote: >>>> >>>> Things going through loopback go through a NETISR and may >>>> end up queued to avoid LOR situations. In addition per-cpu >>>> queues with hash-distribution for affinity may cause your >>>> packet to be processed by a different core. Hence the additional >>>> delay. >>> >>> so you suggest that the (de)scheduling is costing several microseconds ? >> >> Not directly. I'm just trying to explain what's going on to >> get a better idea where it may go wrong. >> >> There may be a poor ISR/scheduler interaction that prevents that >> causes the packet to be processed only on the next tick or something >> like that. I don't have a better explanation for this. It's certainly abysmally slow. Just the extra context switching made in FreeBSD-5 made the RTT for pinging localhost 3-4 times slower than in FreeBSD-3 in old tests (I compared with FreeBSD-3 instead of FreeBSD-4 since general bloat had already made FreeBSD-4 significantly slower, although not 3-4 times). Direct dispatch of netisrs never did anything good in old tests, and the situation doesn't seem to have improved -- you now need an i7 2600 (SMP?) to get the same speed as my Athlon64 2000 (UP) in the best cases for both (2-3 usec RTT). SMP and multiple cores give more chances for scheduler pessimizations. > ok, some final remarks just for archival purposes > (still related to the loopback ping) > > ping takes a timestamp in userspace before trying to transmit > the packet, and then the timestamp for the received packet > is recorded in the kernel (in the interrupt or netisr thread > i believe -- anyways, not in userspace). No, all timestamps recorded used by ping are recorded in userland. IIRC, there is no kernel timestamping at all for ping packets, unless ping is invoked with "-M time" to make it use ICMP_TSTAMP, and ICMP_TSTAMP gives at best milliseconds resolution so it is useless for measuring RTTs in the 2-999 usec range. (ICMP_TSTAMP uses iptime(), and the protocol only supports milliseconds resolution, which was good enough for 1 Mbps ethernet. iptime() is more broken than that (except in my version), since it uses getmicrotime() instead of microtime(). getmicrotime() gives at best 1/HZ resolution, so it is not even good enough for 1 Mbps ethernet when HZ is small, and now it may give extra inaccuracies from stopping the 1/HZ clock while in sleep states.) This reminds me that slow timecounters make measuring small differences in times difficult. It can take longer to read the timecounter than the entire RTT. I tested this by pessimizing kern.timecounter.hardware from TSC to i8254. On my test system, clock_gettime() with CLOCK_MONOTONIC takes an average of 273 nsec with the TSC timecounter and 4695 nsec with the i8254 timecounter. ping uses gettimeofday() which is slightly slower and more broken (since it uses CLOCK_REALTIME). My normal ping -fq localhost RTT is 2-3 usec (closer to 3; another bug in this area is that the timestamps only have microseconds resolution so you can't see if 3 is actually more like 2.5. I was thinking of changing the resolution to nanoseconds 8-10 years ago, before the FreeBSD-5 pessimizations and CPU speeds hitting a wall made this not really necessary), but the kernel I'm testing with uses ipfw which bloats the RTT to 8-9 usec. Then kern.timecounter.hardware=i8254 bloates the RTT to 24-25! That's 16 usec extra, enough for the extra overhead of 4 gettimeofday() calls. Timecounter statistics confirm that there are many more than 2 timecounter calls per packet: - 7 binuptime calls per packet. That's the hardware part that is very slow with an i8254 timecounter. It apparently takes more like 3000 nsec than 4695 nsec (to fit 7 in 24-25 usec). - 3 bintime calls per packet. bintime calls binuptime, so this accounts for 3 of the above 7. The other 4 are apparently for context switching. There are 2 context switches per packet :-(. I can't explain why there are apparently 2 timestamps per context switch. (Note that -current uses the inferior cputicker mechanism instead of timecounters for timestamping context switches. It does this because some timecounters are very slow. But when the timecounter is the TSC, it binuptime() only takes a few cycles more than cpu_ticks(). (The above time of 273 nsec for reading the TSC timecounter is from userland. The kernel part takes only about 30 nsec, while cpu_ticks() might take 15 nsec.) So -current wouldn't be pessimized for this part by changing the timecounter to i8254, but without the pessimization it would be only a few nsec faster than old kernels provided the timecounter for old kernels is the TSC.) - 2 microtime calls per packet. These are for the 2 gettimeofday()s. microtime calls bintime, so this accounts for 2 of the above 3. The other 1 is unaccounted for. - 1 getmicrouptime call per packet. This doesn't involve the hardware. This is for the select() timeout. If we fixed the resolution bugs in select(), then we would have to be careful not to pessimize it too much by replacing this by microuptime. - 0 calls to iptime() per packet. Benchmarks like this show what a bad idea the get*time() timecounter APIs are. When you actually need to read the time a lot, you need high resolution and thus the full functions, and optimizing for when only low resolution is needed only optimizes the part that doesn't take very long anyway (except for broken programs). > A thing that seems to make > the difference is the choice of idle states: > machdep.idle = {acpi, hlt, mwait, spin} > hw.acpi.cpu.cx_lowest={C1, C2, C3} > results in 10-15% of samples with significantly different values > (see table below, all values in microseconds) > > config normal top 10-15% > ----------------------------------------- > acpi+c3 13 85 > acpi+c2 10 40 > acpi+c1 7 10 > > spin 7 8 > hlt,mwait 6..10 (no clear distinction) > ping -f 5-6 > > This suggests that sometimes the responding thread > may be started on a sleeping core and so takes > longer to wake up. > > The high values are not periodic but the ratio is close to > the 128/1000 which relates profhz and tick, so that might be > something to look at. I guess this is to be expected on a multi-core system. The scheduler should probably try to use a different core for netisrs, but this would cause both cores to block waiting for each other, so both might sleep. Any batching of netisrs would give bursts with longer sleeps in between. I didn't see any large differences between ping -f and ping -i 0.01 on a UP system. My HZ is 100, so -i 0.01 is not really possible and gives more like 0.015 (average) or perhaps 0.02 or even 0.03 after synchronization, as we discussed previously. -i 0.1 is closer to possible and gave a small increase in RTT (-i 1.0 gives the default and a much larger increase). The increases are absolute and not so large relatively starting with the slowness given by ipfw. Note that ping -f doesn't actually flood, since it waits for 1/100 seconds for something to come back, and 1/100 was only a short time with 1 Mbps ethernet. This can be worked around to some extent using ping -i to give a wait time of less than 1/100 seconds. It is still impossible to flood, since wait times of less than 1/HZ are impossible, and the resolution of ping -i is gratuitously limited to 1 msec. You could try setting the -i arg to 1/HZ to see the effects of this, or hack the hard-coded -f timeout to 1 usec. With hardware, there are many more ways for the RTT to vary. One way is that although ping -f doesn't flood, injecting an extra packet on some 1/100 second boundaries can cause queue lengths to build up. This might be only with my version of ping (it keeps track of the boundaries an might send an extra packet when it shouldn't). When the queue lengths increase for any reason (due to injecting packets or when there is a delay for other system activity), packets are sent and received in bursts; throughput goes up almost proporitionally to the queue lengths, and RTT goes up. Bruce From owner-freebsd-current@FreeBSD.ORG Thu Apr 12 04:18:59 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1EA5E106564A; Thu, 12 Apr 2012 04:18:59 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id B13FB8FC14; Thu, 12 Apr 2012 04:18:58 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q3C4IqUG002225; Thu, 12 Apr 2012 00:18:52 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q3C4IqPN002200; Thu, 12 Apr 2012 04:18:52 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 12 Apr 2012 04:18:52 GMT Message-Id: <201204120418.q3C4IqPN002200@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 04:18:59 -0000 TB --- 2012-04-12 03:00:05 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-04-12 03:00:05 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-04-12 03:00:05 - starting HEAD tinderbox run for ia64/ia64 TB --- 2012-04-12 03:00:05 - cleaning the object tree TB --- 2012-04-12 03:00:05 - cvsupping the source tree TB --- 2012-04-12 03:00:05 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2012-04-12 03:01:35 - building world TB --- 2012-04-12 03:01:35 - CROSS_BUILD_TESTING=YES TB --- 2012-04-12 03:01:35 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-12 03:01:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-12 03:01:35 - SRCCONF=/dev/null TB --- 2012-04-12 03:01:35 - TARGET=ia64 TB --- 2012-04-12 03:01:35 - TARGET_ARCH=ia64 TB --- 2012-04-12 03:01:35 - TZ=UTC TB --- 2012-04-12 03:01:35 - __MAKE_CONF=/dev/null TB --- 2012-04-12 03:01:35 - cd /src TB --- 2012-04-12 03:01:35 - /usr/bin/make -B buildworld >>> World build started on Thu Apr 12 03:01:36 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 [...] colldef -I /src/share/colldef -o tr_TR.ISO8859-9.out /src/share/colldef/tr_TR.ISO8859-9.src colldef -I /src/share/colldef -o uk_UA.CP1251.out /src/share/colldef/uk_UA.CP1251.src colldef -I /src/share/colldef -o uk_UA.ISO8859-5.out /src/share/colldef/uk_UA.ISO8859-5.src colldef -I /src/share/colldef -o uk_UA.KOI8-U.out /src/share/colldef/uk_UA.KOI8-U.src ===> share/dict (all) ===> share/doc (all) ===> share/doc/bind9 (all) make: don't know how to make RELEASE-NOTES-BIND-9.8.1.pdf. Stop *** Error code 2 Stop in /src/share/doc. *** Error code 1 Stop in /src/share. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-04-12 04:18:52 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-04-12 04:18:52 - ERROR: failed to build world TB --- 2012-04-12 04:18:52 - 3549.45 user 570.63 system 4726.89 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Thu Apr 12 06:42:35 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0C2B106566C for ; Thu, 12 Apr 2012 06:42:35 +0000 (UTC) (envelope-from taku@tackymt.homeip.net) Received: from basalt.tackymt.homeip.net (unknown [IPv6:2001:3e0:577:0:20d:61ff:fecc:2253]) by mx1.freebsd.org (Postfix) with ESMTP id 27BE18FC08 for ; Thu, 12 Apr 2012 06:42:35 +0000 (UTC) Received: from basalt.tackymt.homeip.net (localhost [127.0.0.1]) by basalt.tackymt.homeip.net (Postfix) with ESMTP id BC4EC83A0; Thu, 12 Apr 2012 15:42:33 +0900 (JST) X-Virus-Scanned: amavisd-new at tackymt.homeip.net Received: from localhost by basalt.tackymt.homeip.net (amavisd-new, unix socket) with ESMTP id pCx6X7Jz6BST; Thu, 12 Apr 2012 15:42:31 +0900 (JST) Received: from biotite.tackymt.homeip.net (biotite.tackymt.homeip.net [IPv6:2001:3e0:577:0:216:cfff:febc:1472]) by basalt.tackymt.homeip.net (Postfix) with ESMTPSA; Thu, 12 Apr 2012 15:42:31 +0900 (JST) Date: Thu, 12 Apr 2012 15:42:32 +0900 From: Taku YAMAMOTO To: Konstantin Belousov Message-Id: <20120412154232.354fed8c.taku@tackymt.homeip.net> In-Reply-To: <20120411194239.GN2358@deviant.kiev.zoral.com.ua> References: <20120410063153.GA1458@mole.fafoe.narf.at> <20120411113400.GA1399@mole.fafoe.narf.at> <20120411125338.GK2358@deviant.kiev.zoral.com.ua> <20120412031919.be6c584e.taku@tackymt.homeip.net> <20120412040411.03ee34dd.taku@tackymt.homeip.net> <20120411194239.GN2358@deviant.kiev.zoral.com.ua> X-Mailer: Sylpheed 3.1.0 (GTK+ 2.22.1; i386-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Follow-up: Re: recent update breaks some ports X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 06:42:36 -0000 I'm glad to report that your patch fixes not only wlock-within-wlock cases but also rlock-within-wlock cases properly! On Wed, 11 Apr 2012 22:42:39 +0300 Konstantin Belousov wrote: > On Thu, Apr 12, 2012 at 04:04:11AM +0900, Taku YAMAMOTO wrote: (snip) > > The following is the first occurence of rlock-within-wlock incident. > > > > Hardware watchpoint 2: lock_place[0].count_rw > > > > Old value = 0 > > New value = 1 > > 0x28f526fd in _thr_rtld_rlock_acquire (lock=0x28f63600) > > at /usr/src/lib/libthr/thread/thr_rtld.c:133 > > 133 HANDLE_NESTED_ACQ(count_rw); > > (gdb) bt > > #0 0x28f526fd in _thr_rtld_rlock_acquire (lock=0x28f63600) > > at /usr/src/lib/libthr/thread/thr_rtld.c:133 > > #1 0x28071291 in rlock_acquire () from /libexec/ld-elf.so.1 > > #2 0x2806fccb in _rtld_bind () from /libexec/ld-elf.so.1 > > #3 0x28069dc9 in _rtld_bind_start () from /libexec/ld-elf.so.1 > > #4 0x290c3000 in ?? () > > #5 0x00000148 in ?? () > > #6 0x29356318 in ?? () from /usr/lib/libsupc++.so.1 > > #7 0x28f503e0 in _thr_once_init () > > from /home/taku/work/build/biotite/usr/src/lib/libthr/libthr.so.3 > > #8 0xffffffff in ?? () > > #9 0x00200202 in ?? () > > #10 0x290c3000 in ?? () > > #11 0x00000148 in ?? () > > #12 0x2935eae0 in __gxx_personality_v0 () from /usr/lib/libsupc++.so.1 > > #13 0x2935f5c5 in __cxa_get_globals () from /usr/lib/libsupc++.so.1 > > #14 0x290c2710 in ?? () > > #15 0xbfbfdc48 in ?? () > > #16 0x29356325 in ?? () from /usr/lib/libsupc++.so.1 > > #17 0x280714c9 in lock_release () from /libexec/ld-elf.so.1 > > Previous frame inner to this frame (corrupt stack?) > Unortunately, this trace is not usefule, it seems that you need > to recompile rtld/libc/libthr with debugging symbols to get the issue > fixed. I retook the latter execution path with debugging symbols, without your patch for the record. Hardware watchpoint 3: lock_place[0].count_rw Old value = 0 New value = 1 0x28f5275d in _thr_rtld_rlock_acquire (lock=0x28f63680) at /usr/src/lib/libthr/thread/thr_rtld.c:133 133 HANDLE_NESTED_ACQ(count_rw); (gdb) bt #0 0x28f5275d in _thr_rtld_rlock_acquire (lock=0x28f63680) at /usr/src/lib/libthr/thread/thr_rtld.c:133 #1 0x28071291 in rlock_acquire (lock=0x2807efbc, lockstate=0xbfbfdb70) at /usr/src/libexec/rtld-elf/rtld_lock.c:197 #2 0x2806fccb in _rtld_bind (obj=0x290c3000, reloff=328) at /usr/src/libexec/rtld-elf/rtld.c:642 #3 0x28069dc9 in _rtld_bind_start () at /usr/src/libexec/rtld-elf/i386/rtld_start.S:81 #4 0x290c3000 in ?? () #5 0x00000148 in ?? () #6 0x29356318 in .rel.plt () from /home/taku/lib/debug/libsupc++.so.1 #7 0xffffffff in ?? () #8 0x00200206 in ?? () #9 0x290c3000 in ?? () #10 0x00000148 in ?? () #11 0x2935eae0 in __static_initialization_and_destruction_0 (__initialize_p=Variable "__initialize_p" is not available. ) at gthr-default.h:188 #12 0x2935f5c5 in __cxa_get_globals () from /home/taku/lib/debug/libsupc++.so.1 #13 0x290c2710 in ?? () #14 0xbfbfdc48 in ?? () #15 0x29356325 in _init () from /home/taku/lib/debug/libsupc++.so.1 #16 0x280714c9 in lock_release (lock=0x280714c9, lockstate=0x2807d2a4) at /usr/src/libexec/rtld-elf/rtld_lock.c:219 Previous frame inner to this frame (corrupt stack?) (gdb) c Continuing. Hardware watchpoint 3: lock_place[0].count_rw Old value = 1 New value = 2 0x28f5275d in _thr_rtld_rlock_acquire (lock=0x28f63680) at /usr/src/lib/libthr/thread/thr_rtld.c:133 133 HANDLE_NESTED_ACQ(count_rw); (gdb) bt #0 0x28f5275d in _thr_rtld_rlock_acquire (lock=0x28f63680) at /usr/src/lib/libthr/thread/thr_rtld.c:133 #1 0x28071291 in rlock_acquire (lock=0x2807efbc, lockstate=0xbfbfdb70) at /usr/src/libexec/rtld-elf/rtld_lock.c:197 #2 0x2806fccb in _rtld_bind (obj=0x290c3000, reloff=64) at /usr/src/libexec/rtld-elf/rtld.c:642 #3 0x28069dc9 in _rtld_bind_start () at /usr/src/libexec/rtld-elf/i386/rtld_start.S:81 #4 0x290c3000 in ?? () #5 0x00000040 in ?? () #6 0x00018747 in ?? () #7 0x00018747 in ?? () #8 0x29362f8c in __new_handler () from /home/taku/lib/debug/libsupc++.so.1 #9 0x00200246 in ?? () #10 0x290c3000 in ?? () #11 0x00000040 in ?? () #12 0x2935eaf8 in __static_initialization_and_destruction_0 (__initialize_p=Variable "__initialize_p" is not available. ) at gthr-default.h:189 #13 0x2935f5c5 in __cxa_get_globals () from /home/taku/lib/debug/libsupc++.so.1 #14 0x290c2710 in ?? () #15 0xbfbfdc48 in ?? () #16 0x29356325 in _init () from /home/taku/lib/debug/libsupc++.so.1 #17 0x280714c9 in lock_release (lock=0x280714c9, lockstate=0x2807d2a4) ---Type to continue, or q to quit--- at /usr/src/libexec/rtld-elf/rtld_lock.c:219 Previous frame inner to this frame (corrupt stack?) (gdb) c Continuing. Hardware watchpoint 3: lock_place[0].count_rw Old value = 2 New value = 3 0x28f5275d in _thr_rtld_rlock_acquire (lock=0x28f63680) at /usr/src/lib/libthr/thread/thr_rtld.c:133 133 HANDLE_NESTED_ACQ(count_rw); (gdb) bt #0 0x28f5275d in _thr_rtld_rlock_acquire (lock=0x28f63680) at /usr/src/lib/libthr/thread/thr_rtld.c:133 #1 0x28071291 in rlock_acquire (lock=0x2807efbc, lockstate=0xbfbfdb70) at /usr/src/libexec/rtld-elf/rtld_lock.c:197 #2 0x2806fccb in _rtld_bind (obj=0x290c3000, reloff=80) at /usr/src/libexec/rtld-elf/rtld.c:642 #3 0x28069dc9 in _rtld_bind_start () at /usr/src/libexec/rtld-elf/i386/rtld_start.S:81 #4 0x290c3000 in ?? () #5 0x00000050 in ?? () #6 0x29362e44 in .got () from /home/taku/lib/debug/libsupc++.so.1 #7 0x00000001 in ?? () #8 0x00000000 in ?? () #9 0x00200246 in ?? () #10 0x290c3000 in ?? () #11 0x00000050 in ?? () #12 0x2935eb00 in __static_initialization_and_destruction_0 (__initialize_p=Variable "__initialize_p" is not available. ) at gthr-default.h:190 #13 0x2935f5c5 in __cxa_get_globals () from /home/taku/lib/debug/libsupc++.so.1 #14 0x290c2710 in ?? () #15 0xbfbfdc48 in ?? () #16 0x29356325 in _init () from /home/taku/lib/debug/libsupc++.so.1 #17 0x280714c9 in lock_release (lock=0x280714c9, lockstate=0x2807d2a4) ---Type to continue, or q to quit--- at /usr/src/libexec/rtld-elf/rtld_lock.c:219 Previous frame inner to this frame (corrupt stack?) (gdb) c Continuing. -- -|-__ YAMAMOTO, Taku | __ < - A chicken is an egg's way of producing more eggs. - From owner-freebsd-current@FreeBSD.ORG Thu Apr 12 07:12:54 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 19385106564A; Thu, 12 Apr 2012 07:12:54 +0000 (UTC) (envelope-from stefan@fafoe.narf.at) Received: from fep13.mx.upcmail.net (fep13.mx.upcmail.net [62.179.121.33]) by mx1.freebsd.org (Postfix) with ESMTP id 358248FC08; Thu, 12 Apr 2012 07:12:53 +0000 (UTC) Received: from edge02.upcmail.net ([192.168.13.237]) by viefep13-int.chello.at (InterMail vM.8.01.05.04 201-2260-151-105-20111014) with ESMTP id <20120412071251.MVIY3333.viefep13-int.chello.at@edge02.upcmail.net>; Thu, 12 Apr 2012 09:12:51 +0200 Received: from mole.fafoe.narf.at ([80.109.55.137]) by edge02.upcmail.net with edge id wvCq1i00n2xdvHc02vCqKG; Thu, 12 Apr 2012 09:12:51 +0200 X-SourceIP: 80.109.55.137 Received: by mole.fafoe.narf.at (Postfix, from userid 1001) id 38ACF6D42E; Thu, 12 Apr 2012 09:12:50 +0200 (CEST) Date: Thu, 12 Apr 2012 09:12:50 +0200 From: Stefan Farfeleder To: Konstantin Belousov Message-ID: <20120412071249.GA1434@mole.fafoe.narf.at> References: <20120410063153.GA1458@mole.fafoe.narf.at> <20120411113400.GA1399@mole.fafoe.narf.at> <20120411125338.GK2358@deviant.kiev.zoral.com.ua> <20120411212755.GA1355@mole.fafoe.narf.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120411212755.GA1355@mole.fafoe.narf.at> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: gnome@freebsd.org, AN , David Chisnall , freebsd-current@freebsd.org Subject: Re: recent update breaks some ports X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 07:12:54 -0000 On Wed, Apr 11, 2012 at 11:27:55PM +0200, Stefan Farfeleder wrote: > On Wed, Apr 11, 2012 at 03:53:38PM +0300, Konstantin Belousov wrote: > > On Wed, Apr 11, 2012 at 01:34:01PM +0200, Stefan Farfeleder wrote: > > > On Tue, Apr 10, 2012 at 08:31:53AM +0200, Stefan Farfeleder wrote: > > > > > > > > I'm experiencing that too (r234038), xine also no longer starts (hangs > > > > at splash screen). > > > > > > FWIW backing out r233749 fixes evince and xine for me. > > Please recompile at least rtld/libc/libthr with debugging symbols and get > > a backtrace from the hung process. > > Attaching gdb to a hanging evince process yields this: Sorry, I forgot that make install strips debug info. Here are the traces with actual debug info: 0x0000000807f7c9ac in _umtx_op_err () at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 37 RSYSCALL_ERR(_umtx_op) (gdb) bt #0 0x0000000807f7c9ac in _umtx_op_err () at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 #1 0x0000000807f72431 in __thr_rwlock_wrlock (rwlock=Variable "rwlock" is not available. ) at /usr/src/lib/libthr/thread/thr_umtx.c:296 #2 0x0000000807f78473 in _thr_rtld_wlock_acquire (lock=0x808189b00) at thr_umtx.h:194 #3 0x00000008006676a9 in wlock_acquire (lock=0x800877760, lockstate=0x7fffff5fa570) at /usr/src/libexec/rtld-elf/rtld_lock.c:213 #4 0x0000000800664a6e in dlopen_object (name=0x80ac87632 "libsupc++.so.1", fd=-1, refobj=0x8007e2400, lo_flags=0, mode=1) at /usr/src/libexec/rtld-elf/rtld.c:2517 #5 0x0000000800664e2c in load_filtee1 (obj=0x8007e2400, needed=0x8007e1b80, flags=0) at /usr/src/libexec/rtld-elf/rtld.c:1679 #6 0x0000000800664e86 in load_filtees (obj=0x8007e2400, flags=0, lockstate=Variable "lockstate" is not available. ) at /usr/src/libexec/rtld-elf/rtld.c:1692 #7 0x00000008006651bb in symlook_obj (req=0x7fffff5fa720, obj=0x8007e2400) at /usr/src/libexec/rtld-elf/rtld.c:3421 #8 0x0000000800665337 in symlook_list (req=0x7fffff5fa7a0, objlist=Variable "objlist" is not available. ) at /usr/src/libexec/rtld-elf/rtld.c:3335 #9 0x0000000800665521 in symlook_global (req=0x7fffff5faaf0, donelist=0x7fffff5faa90) at /usr/src/libexec/rtld-elf/rtld.c:3247 #10 0x00000008006658ef in symlook_default (req=0x7fffff5faaf0, refobj=0x8007e0c00) at /usr/src/libexec/rtld-elf/rtld.c:3286 #11 0x0000000800665bed in find_symdef (symnum=266, refobj=0x8007e0c00, defobj_out=0x7fffff5fab90, flags=0, cache=0x80079a000, lockstate=0x7fffff5fac30) at /usr/src/libexec/rtld-elf/rtld.c:1416 #12 0x000000080066065b in reloc_non_plt (obj=0x8007e0c00, obj_rtld=Variable "obj_rtld" is not available. ) at /usr/src/libexec/rtld-elf/amd64/reloc.c:155 #13 0x00000008006634e7 in relocate_objects (first=Variable "first" is not available. ) at /usr/src/libexec/rtld-elf/rtld.c:2185 #14 0x0000000800664c96 in dlopen_object (name=0x80a497100 "/usr/local/lib/evince/3/backends/libpdfdocument.so", fd=Variable "fd" is not available. ) at /usr/src/libexec/rtld-elf/rtld.c:2543 #15 0x00000008006657b4 in rtld_dlopen (name=0x80a497100 "/usr/local/lib/evince/3/backends/libpdfdocument.so", fd=-1, mode=258) at /usr/src/libexec/rtld-elf/rtld.c:2491 #16 0x0000000806ba376b in g_module_open () from /usr/local/lib/libgmodule-2.0.so.0 #17 0x0000000800cb5097 in ev_module_get_path () from /usr/local/lib/libevdocument.so.3 #18 0x0000000806dd866c in g_type_module_use () from /usr/local/lib/libgobject-2.0.so.0 #19 0x0000000800cac949 in ev_backends_manager_get_document () from /usr/local/lib/libevdocument.so.3 #20 0x0000000800cb13f5 in ev_document_factory_add_filters () from /usr/local/lib/libevdocument.so.3 #21 0x0000000800cb15d4 in ev_document_factory_get_document () from /usr/local/lib/libevdocument.so.3 #22 0x0000000800ee77b9 in ev_job_load_new () from /usr/local/lib/libevview.so.3 #23 0x0000000800ee90f5 in ev_job_scheduler_push_job () from /usr/local/lib/libevview.so.3 #24 0x0000000807259274 in g_thread_create_full () from /usr/local/lib/libglib-2.0.so.0 #25 0x0000000807f70cdd in thread_start (curthread=0x808f1e400) at /usr/src/lib/libthr/thread/thr_create.c:284 #26 0x0000000000000000 in ?? () Error accessing memory address 0x7fffff5fb000: Bad address. and: 0x0000000802e3c9ac in _umtx_op_err () at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 37 RSYSCALL_ERR(_umtx_op) (gdb) bt #0 0x0000000802e3c9ac in _umtx_op_err () at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 #1 0x0000000802e3262f in _thr_umtx_timedwait_uint (mtx=Variable "mtx" is not available. ) at /usr/src/lib/libthr/thread/thr_umtx.c:212 #2 0x0000000802e3b09d in cond_wait_common (cond=Variable "cond" is not available. ) at /usr/src/lib/libthr/thread/thr_cond.c:243 #3 0x0000000800bfbf23 in metronom_sync_loop (this_gen=Variable "this_gen" is not available. ) at metronom.c:871 #4 0x0000000802e30cdd in thread_start (curthread=0x804c0b400) at /usr/src/lib/libthr/thread/thr_create.c:284 #5 0x0000000000000000 in ?? () Error accessing memory address 0x7fffff7fc000: Bad address. Stefan From owner-freebsd-current@FreeBSD.ORG Thu Apr 12 07:35:17 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15F88106564A; Thu, 12 Apr 2012 07:35:17 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id C5A068FC15; Thu, 12 Apr 2012 07:35:16 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 531F57300A; Thu, 12 Apr 2012 09:54:30 +0200 (CEST) Date: Thu, 12 Apr 2012 09:54:30 +0200 From: Luigi Rizzo To: Bruce Evans Message-ID: <20120412075430.GA71623@onelab2.iet.unipi.it> References: <20120410225257.GB53350@onelab2.iet.unipi.it> <4F84B6DB.5040904@freebsd.org> <20120410230500.GA22829@pit.databus.com> <20120410233211.GA53829@onelab2.iet.unipi.it> <4F855E5E.5000107@freebsd.org> <20120411110036.GA60031@onelab2.iet.unipi.it> <4F857631.8040309@freebsd.org> <20120411131920.GA61027@onelab2.iet.unipi.it> <20120412112401.Q981@besplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120412112401.Q981@besplex.bde.org> User-Agent: Mutt/1.4.2.3i Cc: Barney Wolff , Andre Oppermann , current@freebsd.org, net@freebsd.org Subject: Re: strange ping response times... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 07:35:17 -0000 On Thu, Apr 12, 2012 at 01:18:59PM +1000, Bruce Evans wrote: > On Wed, 11 Apr 2012, Luigi Rizzo wrote: > > >On Wed, Apr 11, 2012 at 02:16:49PM +0200, Andre Oppermann wrote: ... > >ping takes a timestamp in userspace before trying to transmit > >the packet, and then the timestamp for the received packet > >is recorded in the kernel (in the interrupt or netisr thread > >i believe -- anyways, not in userspace). > > No, all timestamps recorded used by ping are recorded in userland. Bruce, look at the code in ping.c -- SO_TIMESTAMP is defined, so the program does (successfully) a setsockopt(s, SOL_SOCKET, SO_TIMESTAMP, &on, sizeof(on)); and then (verified that at runtime the code follows this path) struct cmsghdr *cmsg = (struct cmsghdr *)&ctrl; msg.msg_controllen = sizeof(ctrl); msg.msg_namelen = sizeof(from); if ((cc = recvmsg(s, &msg, 0)) < 0) { if (errno == EINTR) continue; warn("recvmsg"); continue; } if (cmsg->cmsg_level == SOL_SOCKET && cmsg->cmsg_type == SCM_TIMESTAMP && cmsg->cmsg_len == CMSG_LEN(sizeof *tv)) { /* Copy to avoid alignment problems: */ memcpy(&now, CMSG_DATA(cmsg), sizeof(now)); tv = &now; } ... > My normal ping -fq localhost RTT is 2-3 usec > (closer to 3; another bug in this area is that the timestamps only > have microseconds resolution so you can't see if 3 is actually > more like 2.5. I was thinking of changing the resolution to > nanoseconds 8-10 years ago, before the FreeBSD-5 pessimizations > and CPU speeds hitting a wall made this not really necessary), > but the kernel I'm testing with uses ipfw which bloats the RTT to 8-9 ipfw overhead obviously depends on your firewall configuration, i have tested without ipfw to remove that noise. cheers luigi From owner-freebsd-current@FreeBSD.ORG Thu Apr 12 10:39:40 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0EA0C106566B; Thu, 12 Apr 2012 10:39:40 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 50AD18FC08; Thu, 12 Apr 2012 10:39:38 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q3CAdTe3078067; Thu, 12 Apr 2012 13:39:29 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q3CAdTkS010577; Thu, 12 Apr 2012 13:39:29 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q3CAdST8010576; Thu, 12 Apr 2012 13:39:28 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 12 Apr 2012 13:39:28 +0300 From: Konstantin Belousov To: Stefan Farfeleder Message-ID: <20120412103928.GS2358@deviant.kiev.zoral.com.ua> References: <20120410063153.GA1458@mole.fafoe.narf.at> <20120411113400.GA1399@mole.fafoe.narf.at> <20120411125338.GK2358@deviant.kiev.zoral.com.ua> <20120411212755.GA1355@mole.fafoe.narf.at> <20120412071249.GA1434@mole.fafoe.narf.at> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="c9doUuMJYXyM0w+K" Content-Disposition: inline In-Reply-To: <20120412071249.GA1434@mole.fafoe.narf.at> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: gnome@freebsd.org, AN , David Chisnall , freebsd-current@freebsd.org Subject: Re: recent update breaks some ports X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 10:39:40 -0000 --c9doUuMJYXyM0w+K Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 12, 2012 at 09:12:50AM +0200, Stefan Farfeleder wrote: > On Wed, Apr 11, 2012 at 11:27:55PM +0200, Stefan Farfeleder wrote: > > On Wed, Apr 11, 2012 at 03:53:38PM +0300, Konstantin Belousov wrote: > > > On Wed, Apr 11, 2012 at 01:34:01PM +0200, Stefan Farfeleder wrote: > > > > On Tue, Apr 10, 2012 at 08:31:53AM +0200, Stefan Farfeleder wrote: > > > > >=20 > > > > > I'm experiencing that too (r234038), xine also no longer starts (= hangs > > > > > at splash screen). > > > >=20 > > > > FWIW backing out r233749 fixes evince and xine for me. > > > Please recompile at least rtld/libc/libthr with debugging symbols and= get > > > a backtrace from the hung process. > >=20 > > Attaching gdb to a hanging evince process yields this: >=20 > Sorry, I forgot that make install strips debug info. Here are the traces > with actual debug info: >=20 > 0x0000000807f7c9ac in _umtx_op_err () at /usr/src/lib/libthr/arch/amd64/a= md64/_umtx_op_err.S:37 > 37 RSYSCALL_ERR(_umtx_op) > (gdb) bt > #0 0x0000000807f7c9ac in _umtx_op_err () at /usr/src/lib/libthr/arch/amd= 64/amd64/_umtx_op_err.S:37 > #1 0x0000000807f72431 in __thr_rwlock_wrlock (rwlock=3DVariable "rwlock"= is not available. > ) at /usr/src/lib/libthr/thread/thr_umtx.c:296 > #2 0x0000000807f78473 in _thr_rtld_wlock_acquire (lock=3D0x808189b00) at= thr_umtx.h:194 > #3 0x00000008006676a9 in wlock_acquire (lock=3D0x800877760, lockstate=3D= 0x7fffff5fa570) > at /usr/src/libexec/rtld-elf/rtld_lock.c:213 > #4 0x0000000800664a6e in dlopen_object (name=3D0x80ac87632 "libsupc++.so= .1", fd=3D-1, refobj=3D0x8007e2400, lo_flags=3D0,=20 > mode=3D1) at /usr/src/libexec/rtld-elf/rtld.c:2517 > #5 0x0000000800664e2c in load_filtee1 (obj=3D0x8007e2400, needed=3D0x800= 7e1b80, flags=3D0) > at /usr/src/libexec/rtld-elf/rtld.c:1679 > #6 0x0000000800664e86 in load_filtees (obj=3D0x8007e2400, flags=3D0, loc= kstate=3DVariable "lockstate" is not available. > ) > at /usr/src/libexec/rtld-elf/rtld.c:1692 > #7 0x00000008006651bb in symlook_obj (req=3D0x7fffff5fa720, obj=3D0x8007= e2400) at /usr/src/libexec/rtld-elf/rtld.c:3421 > #8 0x0000000800665337 in symlook_list (req=3D0x7fffff5fa7a0, objlist=3DV= ariable "objlist" is not available. > ) at /usr/src/libexec/rtld-elf/rtld.c:3335 > #9 0x0000000800665521 in symlook_global (req=3D0x7fffff5faaf0, donelist= =3D0x7fffff5faa90) > at /usr/src/libexec/rtld-elf/rtld.c:3247 > #10 0x00000008006658ef in symlook_default (req=3D0x7fffff5faaf0, refobj= =3D0x8007e0c00) > at /usr/src/libexec/rtld-elf/rtld.c:3286 > #11 0x0000000800665bed in find_symdef (symnum=3D266, refobj=3D0x8007e0c00= , defobj_out=3D0x7fffff5fab90, flags=3D0,=20 > cache=3D0x80079a000, lockstate=3D0x7fffff5fac30) at /usr/src/libexec/= rtld-elf/rtld.c:1416 > #12 0x000000080066065b in reloc_non_plt (obj=3D0x8007e0c00, obj_rtld=3DVa= riable "obj_rtld" is not available. > ) at /usr/src/libexec/rtld-elf/amd64/reloc.c:155 > #13 0x00000008006634e7 in relocate_objects (first=3DVariable "first" is n= ot available. > ) at /usr/src/libexec/rtld-elf/rtld.c:2185 > #14 0x0000000800664c96 in dlopen_object (name=3D0x80a497100 "/usr/local/l= ib/evince/3/backends/libpdfdocument.so", fd=3DVariable "fd" is not availabl= e. > ) > at /usr/src/libexec/rtld-elf/rtld.c:2543 > #15 0x00000008006657b4 in rtld_dlopen (name=3D0x80a497100 "/usr/local/lib= /evince/3/backends/libpdfdocument.so", fd=3D-1,=20 > mode=3D258) at /usr/src/libexec/rtld-elf/rtld.c:2491 > #16 0x0000000806ba376b in g_module_open () from /usr/local/lib/libgmodule= -2.0.so.0 > #17 0x0000000800cb5097 in ev_module_get_path () from /usr/local/lib/libev= document.so.3 > #18 0x0000000806dd866c in g_type_module_use () from /usr/local/lib/libgob= ject-2.0.so.0 > #19 0x0000000800cac949 in ev_backends_manager_get_document () from /usr/l= ocal/lib/libevdocument.so.3 > #20 0x0000000800cb13f5 in ev_document_factory_add_filters () from /usr/lo= cal/lib/libevdocument.so.3 > #21 0x0000000800cb15d4 in ev_document_factory_get_document () from /usr/l= ocal/lib/libevdocument.so.3 > #22 0x0000000800ee77b9 in ev_job_load_new () from /usr/local/lib/libevvie= w.so.3 > #23 0x0000000800ee90f5 in ev_job_scheduler_push_job () from /usr/local/li= b/libevview.so.3 > #24 0x0000000807259274 in g_thread_create_full () from /usr/local/lib/lib= glib-2.0.so.0 > #25 0x0000000807f70cdd in thread_start (curthread=3D0x808f1e400) at /usr/= src/lib/libthr/thread/thr_create.c:284 > #26 0x0000000000000000 in ?? () > Error accessing memory address 0x7fffff5fb000: Bad address. >=20 > and: >=20 > 0x0000000802e3c9ac in _umtx_op_err () at /usr/src/lib/libthr/arch/amd64/a= md64/_umtx_op_err.S:37 > 37 RSYSCALL_ERR(_umtx_op) > (gdb) bt > #0 0x0000000802e3c9ac in _umtx_op_err () at /usr/src/lib/libthr/arch/amd= 64/amd64/_umtx_op_err.S:37 > #1 0x0000000802e3262f in _thr_umtx_timedwait_uint (mtx=3DVariable "mtx" = is not available. > ) at /usr/src/lib/libthr/thread/thr_umtx.c:212 > #2 0x0000000802e3b09d in cond_wait_common (cond=3DVariable "cond" is not= available. > ) at /usr/src/lib/libthr/thread/thr_cond.c:243 > #3 0x0000000800bfbf23 in metronom_sync_loop (this_gen=3DVariable "this_g= en" is not available. > ) at metronom.c:871 > #4 0x0000000802e30cdd in thread_start (curthread=3D0x804c0b400) at /usr/= src/lib/libthr/thread/thr_create.c:284 > #5 0x0000000000000000 in ?? () > Error accessing memory address 0x7fffff7fc000: Bad address. >=20 This is supposedly fixed by r234170. --c9doUuMJYXyM0w+K Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk+GsOAACgkQC3+MBN1Mb4hUCwCg53tL7omJ/rJ9ohIKT7XBMLUR 1f8AoIR1Wrgu/diKeOtpMctfobHMfjV5 =KTCj -----END PGP SIGNATURE----- --c9doUuMJYXyM0w+K-- From owner-freebsd-current@FreeBSD.ORG Thu Apr 12 10:49:29 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8F93A1065676; Thu, 12 Apr 2012 10:49:29 +0000 (UTC) (envelope-from stefan@fafoe.narf.at) Received: from fep15.mx.upcmail.net (fep15.mx.upcmail.net [62.179.121.35]) by mx1.freebsd.org (Postfix) with ESMTP id 91AD08FC12; Thu, 12 Apr 2012 10:49:28 +0000 (UTC) Received: from edge03.upcmail.net ([192.168.13.238]) by viefep15-int.chello.at (InterMail vM.8.01.05.05 201-2260-151-110-20120111) with ESMTP id <20120412104927.EGHO18555.viefep15-int.chello.at@edge03.upcmail.net>; Thu, 12 Apr 2012 12:49:27 +0200 Received: from mole.fafoe.narf.at ([80.109.55.137]) by edge03.upcmail.net with edge id wypS1i0212xdvHc03ypSEK; Thu, 12 Apr 2012 12:49:26 +0200 X-SourceIP: 80.109.55.137 Received: by mole.fafoe.narf.at (Postfix, from userid 1001) id 556E56D42E; Thu, 12 Apr 2012 12:49:26 +0200 (CEST) Date: Thu, 12 Apr 2012 12:49:26 +0200 From: Stefan Farfeleder To: Konstantin Belousov Message-ID: <20120412104926.GD1434@mole.fafoe.narf.at> References: <20120410063153.GA1458@mole.fafoe.narf.at> <20120411113400.GA1399@mole.fafoe.narf.at> <20120411125338.GK2358@deviant.kiev.zoral.com.ua> <20120411212755.GA1355@mole.fafoe.narf.at> <20120412071249.GA1434@mole.fafoe.narf.at> <20120412103928.GS2358@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120412103928.GS2358@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: gnome@freebsd.org, AN , David Chisnall , freebsd-current@freebsd.org Subject: Re: recent update breaks some ports X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 10:49:29 -0000 On Thu, Apr 12, 2012 at 01:39:28PM +0300, Konstantin Belousov wrote: > On Thu, Apr 12, 2012 at 09:12:50AM +0200, Stefan Farfeleder wrote: > > On Wed, Apr 11, 2012 at 11:27:55PM +0200, Stefan Farfeleder wrote: > > > On Wed, Apr 11, 2012 at 03:53:38PM +0300, Konstantin Belousov wrote: > > > > On Wed, Apr 11, 2012 at 01:34:01PM +0200, Stefan Farfeleder wrote: > > > > > On Tue, Apr 10, 2012 at 08:31:53AM +0200, Stefan Farfeleder wrote: > > > > > > > > > > > > I'm experiencing that too (r234038), xine also no longer starts (hangs > > > > > > at splash screen). > > > > > > > > > > FWIW backing out r233749 fixes evince and xine for me. > > > > Please recompile at least rtld/libc/libthr with debugging symbols and get > > > > a backtrace from the hung process. > > > > > > Attaching gdb to a hanging evince process yields this: > > [snip] > This is supposedly fixed by r234170. Thanks, works for me! From owner-freebsd-current@FreeBSD.ORG Thu Apr 12 11:22:17 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 967C81065670; Thu, 12 Apr 2012 11:22:17 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail01.syd.optusnet.com.au (mail01.syd.optusnet.com.au [211.29.132.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1524F8FC16; Thu, 12 Apr 2012 11:22:16 +0000 (UTC) Received: from c211-30-171-136.carlnfd1.nsw.optusnet.com.au (c211-30-171-136.carlnfd1.nsw.optusnet.com.au [211.30.171.136]) by mail01.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q3CBM2Rl020290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2012 21:22:04 +1000 Date: Thu, 12 Apr 2012 21:22:02 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Luigi Rizzo In-Reply-To: <20120412075430.GA71623@onelab2.iet.unipi.it> Message-ID: <20120412193745.O2350@besplex.bde.org> References: <20120410225257.GB53350@onelab2.iet.unipi.it> <4F84B6DB.5040904@freebsd.org> <20120410230500.GA22829@pit.databus.com> <20120410233211.GA53829@onelab2.iet.unipi.it> <4F855E5E.5000107@freebsd.org> <20120411110036.GA60031@onelab2.iet.unipi.it> <4F857631.8040309@freebsd.org> <20120411131920.GA61027@onelab2.iet.unipi.it> <20120412112401.Q981@besplex.bde.org> <20120412075430.GA71623@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Thu, 12 Apr 2012 11:27:59 +0000 Cc: Barney Wolff , Andre Oppermann , current@freebsd.org, Bruce Evans , net@freebsd.org Subject: Re: strange ping response times... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 11:22:17 -0000 On Thu, 12 Apr 2012, Luigi Rizzo wrote: > On Thu, Apr 12, 2012 at 01:18:59PM +1000, Bruce Evans wrote: >> On Wed, 11 Apr 2012, Luigi Rizzo wrote: >> >>> On Wed, Apr 11, 2012 at 02:16:49PM +0200, Andre Oppermann wrote: > ... >>> ping takes a timestamp in userspace before trying to transmit >>> the packet, and then the timestamp for the received packet >>> is recorded in the kernel (in the interrupt or netisr thread >>> i believe -- anyways, not in userspace). >> >> No, all timestamps recorded used by ping are recorded in userland. > > Bruce, look at the code in ping.c -- SO_TIMESTAMP is defined, > so the program does (successfully) a > > setsockopt(s, SOL_SOCKET, SO_TIMESTAMP, &on, sizeof(on)); > > and then (verified that at runtime the code follows this path) > ... Indeed it does. This accounts for the previously unaccounted for binuptime call in the kernel. This is part of fenner's change (perhaps the most important part) to put the timestamping closer to the actual i/o, so that the RTT doesn't count setup overheads. Timestamping still works when SO_TIMESTAMP is undefed (after fixing the ifdefs on it). Not using it costs only 1 more gettimeofday() call in ping, but it increases my apparent RTT from 7-8 usec to 10-11 usec. 3 extra usec seems a lot for the overhead. I found that ping -f saves 1 gettimeofday() call per packet, and my version saves another 1. -current ping -q localhost: 4 my ping -q localhost: 3 -current ping -fq localhost: 3 my ping -fq localhost: 2 1 gettimeofday() call is needed for putting a timestamp in the output packet. Apparently, this is not well integrated with the bookkeeping for select(), and up to 3 more gettimeofday() calls are used. select() timeouts only have 1/HZ granulatrity, so the gettimeofday() calls to set them up could use clock_gettime() with CLOCK_REALTIME_FAST_N_BROKEN, but this would be a bogus optimization since most of the overhead is in the syscall provided the timecounter hardware is not slow (it takes 9-80 cycles to read TSC timecounter hardware and 600-800 cycles for clock_gettime() with a TSC timecounter). I just noticed Note that CLOCK_MONOTONIC cannot be used for the timestamp in the output packet if SO_TIMESTAMP is used for the timestamp in the input packet, since SO_TIMESTAMP uses CLOCK_REALTIME for historical reasons. There are 2 select()s per packet. Perhaps the number of gettimeofday()s can be reduced to 1 per packet in most cases (get one for the output packet and use it for both select()s). With my version the truss trace for ping localhost is: % 64 bytes from 127.0.0.1: icmp_seq=6 ttl=64 time=0.473 ms % write(1,0x80d4000,57) = 57 (0x39) % gettimeofday({1334226305 409249},0x0) = 0 (0x0) Need this for the next select(). There is a ~1 second pause here. % select(4,{3},0x0,0x0,{0 989607}) = 0 (0x0) Truss doesn't show this until select() returns ~1 second later. The gettimeofday() call was needed because we don't simply use a 1 second pause, but adjust for overheads. My version uses a fancier adjustment. % gettimeofday({1334226306 408632},0x0) = 0 (0x0) We need this accurately to put in the packet. But all the other timestamps can be derived from this for the non-flood case. We can just try to send every `interval' and adjust the timeouts a bit when we see that we get here a bit early or late, and when we get here more than a bit early or late we can either recalibrate or adjust by more. Note that this gettimeofday() returned 1.0 - 0.000617 seconds after the previous one, although we asked for a timeout of ~1/HZ = 0.0010000 seconds. Select timeouts have a large granularity and we expect errors of O(1/HZ) and mostly compensate for them. The drift without compensation would be 1% with HZ = 100 and -i 1.0, and much larger with -i . My version compensates more accurately than -current. % sendto(0x3,0x80b8d34,0,0x0,{ AF_INET 127.0.0.1:0 },0x10) = 64 (0x40) % gettimeofday({1334226306 408831},0x0) = 0 (0x0) % select(4,{3},0x0,0x0,{0 990025}) = 1 (0x1) % recvmsg(0x3,0xbfbfe8c0,0x0) = 84 (0x54) % gettimeofday({1334226306 409104},0x0) = 0 (0x0) I don't know what this is for. We got a timestamp in the returned packet, and use it. Since this timestamp has microsecond resolution and select() only has 1/Hz resolution. this timestamp should be more than good enough for sleeping for the interval. % 64 bytes from 127.0.0.1: icmp_seq=7 ttl=64 time=0.472 ms % write(1,0x80d4000,57) = 57 (0x39) Next packet: % gettimeofday({1334226306 409279},0x0) = 0 (0x0) % ... But select() timeouts are not needed at all. Versions before fenner's changes used a select() timeout for flood pings. alarm() was used to generate other timeouts. The alarm() code was not very good. It did a lot of work in the signal handler to set up the next alarm (1 call to signal() and 1 call to alarm()), and it did unsafe work in the signal handler. It was not careful about drift. These overheads and the drift can can be avoided using a periodic itimer. Ideally, expiry of each period would just cause select() to return, but AFAIK there is no way to make select() return without catching the signal, and even a null signal catcher has a lot of overhead. It is unclear if the overhead for a null signal catcher is larger than that for select timeouts. The current overhead for select timeouts is 2 or 3 gettimeofday() calls in ping and 1 or 2 getmicrouptime() calls in each select(). These take at least 1 usec on my Athlon64 2GHz UP, and signal handling also takes about 1 usec in old versions of FreeBSD, but now takes more like 1.5 usec. SO_TIMESTAMP seems to have been invented in 1996 by fenner to make ping work better. (The log messages seem to only mention fixing it but I can't find it in earlier code.) There seems to be no way to timestamp outgoing packets properly in the kernel. ICMP_TIMESTAMP might give milliseconds resolution for ping, but FreeBSD ping has given microseconds resulotion since 1993. Bruce From owner-freebsd-current@FreeBSD.ORG Thu Apr 12 13:18:36 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DAB521065672 for ; Thu, 12 Apr 2012 13:18:36 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 83EDA8FC14 for ; Thu, 12 Apr 2012 13:18:36 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D8D4FB915; Thu, 12 Apr 2012 09:18:35 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 12 Apr 2012 08:23:21 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201204120823.21943.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 12 Apr 2012 09:18:36 -0400 (EDT) Cc: Arnaud Lacombe Subject: Re: FreeBSD on recent Xeon E5 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 13:18:36 -0000 On Wednesday, April 11, 2012 5:33:11 pm Arnaud Lacombe wrote: > Hi, > > I just booted FreeBSD 9.0-RELEASE on a Xeon E5-1650 based platform. It > would seems that the CPU handles by itself a lots of PCI functions > which do not seem to be supported by FreeBSD. Here is the output of > `pciconf -l' restricted to unhandled devices: > > none0@pci0:0:4:0: class=0x088000 card=0x062b15d9 chip=0x3c208086 > none1@pci0:0:4:1: class=0x088000 card=0x062b15d9 chip=0x3c218086 > none2@pci0:0:4:2: class=0x088000 card=0x062b15d9 chip=0x3c228086 > none3@pci0:0:4:3: class=0x088000 card=0x062b15d9 chip=0x3c238086 > none4@pci0:0:4:4: class=0x088000 card=0x062b15d9 chip=0x3c248086 > none5@pci0:0:4:5: class=0x088000 card=0x062b15d9 chip=0x3c258086 > none6@pci0:0:4:6: class=0x088000 card=0x062b15d9 chip=0x3c268086 > none7@pci0:0:4:7: class=0x088000 card=0x062b15d9 chip=0x3c278086 > none8@pci0:0:5:0: class=0x088000 card=0x062b15d9 chip=0x3c288086 > none9@pci0:0:5:2: class=0x088000 card=0x062b15d9 chip=0x3c2a8086 > none10@pci0:0:22:0: class=0x078000 card=0x062b15d9 chip=0x1d3a8086 > none11@pci0:0:22:1: class=0x078000 card=0x062b15d9 chip=0x1d3b8086 > none12@pci0:0:22:3: class=0x070002 card=0x062b15d9 chip=0x1d3d8086 > none13@pci0:0:31:3: class=0x0c0500 card=0x062b15d9 chip=0x1d228086 > none14@pci0:0:31:6: class=0x118000 card=0x062b15d9 chip=0x1d248086 > none15@pci0:8:0:0: class=0x010700 card=0x062b15d9 chip=0x1d6b8086 > none16@pci0:255:8:0: class=0x088000 card=0x062b15d9 chip=0x3c808086 > none17@pci0:255:8:3: class=0x088000 card=0x062b15d9 chip=0x3c838086 > none18@pci0:255:8:4: class=0x088000 card=0x062b15d9 chip=0x3c848086 > none19@pci0:255:9:0: class=0x088000 card=0x062b15d9 chip=0x3c908086 > none20@pci0:255:9:3: class=0x088000 card=0x062b15d9 chip=0x3c938086 > none21@pci0:255:9:4: class=0x088000 card=0x062b15d9 chip=0x3c948086 > none22@pci0:255:10:0: class=0x088000 card=0x062b15d9 chip=0x3cc08086 > none23@pci0:255:10:1: class=0x088000 card=0x062b15d9 chip=0x3cc18086 > none24@pci0:255:10:2: class=0x088000 card=0x062b15d9 chip=0x3cc28086 > none25@pci0:255:10:3: class=0x088000 card=0x062b15d9 chip=0x3cd08086 > none26@pci0:255:11:0: class=0x088000 card=0x062b15d9 chip=0x3ce08086 > none27@pci0:255:11:3: class=0x088000 card=0x062b15d9 chip=0x3ce38086 > none28@pci0:255:12:0: class=0x088000 card=0x000015d9 chip=0x3ce88086 > none29@pci0:255:12:1: class=0x088000 card=0x000015d9 chip=0x3ce88086 > none30@pci0:255:12:2: class=0x088000 card=0x000015d9 chip=0x3ce88086 > none31@pci0:255:12:6: class=0x088000 card=0x000015d9 chip=0x3cf48086 > none32@pci0:255:12:7: class=0x088000 card=0x000015d9 chip=0x3cf68086 > none33@pci0:255:13:0: class=0x088000 card=0x000015d9 chip=0x3ce88086 > none34@pci0:255:13:1: class=0x088000 card=0x000015d9 chip=0x3ce88086 > none35@pci0:255:13:2: class=0x088000 card=0x000015d9 chip=0x3ce88086 > none36@pci0:255:13:6: class=0x088000 card=0x000015d9 chip=0x3cf58086 > none37@pci0:255:14:0: class=0x088000 card=0x062b15d9 chip=0x3ca08086 > none38@pci0:255:14:1: class=0x110100 card=0x062b15d9 chip=0x3c468086 > none39@pci0:255:15:0: class=0x088000 card=0x062b15d9 chip=0x3ca88086 > none40@pci0:255:15:1: class=0x088000 card=0x062b15d9 chip=0x3c718086 > none41@pci0:255:15:2: class=0x088000 card=0x062b15d9 chip=0x3caa8086 > none42@pci0:255:15:3: class=0x088000 card=0x062b15d9 chip=0x3cab8086 > none43@pci0:255:15:4: class=0x088000 card=0x062b15d9 chip=0x3cac8086 > none44@pci0:255:15:5: class=0x088000 card=0x062b15d9 chip=0x3cad8086 > none45@pci0:255:15:6: class=0x088000 card=0x062b15d9 chip=0x3cae8086 > none46@pci0:255:16:0: class=0x088000 card=0x062b15d9 chip=0x3cb08086 > none47@pci0:255:16:1: class=0x088000 card=0x062b15d9 chip=0x3cb18086 > none48@pci0:255:16:2: class=0x088000 card=0x062b15d9 chip=0x3cb28086 > none49@pci0:255:16:3: class=0x088000 card=0x062b15d9 chip=0x3cb38086 > none50@pci0:255:16:4: class=0x088000 card=0x062b15d9 chip=0x3cb48086 > none51@pci0:255:16:5: class=0x088000 card=0x062b15d9 chip=0x3cb58086 > none52@pci0:255:16:6: class=0x088000 card=0x062b15d9 chip=0x3cb68086 > none53@pci0:255:16:7: class=0x088000 card=0x062b15d9 chip=0x3cb78086 > none54@pci0:255:17:0: class=0x088000 card=0x062b15d9 chip=0x3cb88086 > none55@pci0:255:19:0: class=0x088000 card=0x062b15d9 chip=0x3ce48086 > none56@pci0:255:19:1: class=0x110100 card=0x062b15d9 chip=0x3c438086 > none57@pci0:255:19:4: class=0x110100 card=0x062b15d9 chip=0x3ce68086 > none58@pci0:255:19:5: class=0x110100 card=0x062b15d9 chip=0x3c448086 > none59@pci0:255:19:6: class=0x088000 card=0x062b15d9 chip=0x3c458086 > > These would seem to correspond to Uncore feature, namely, as per [0]: > > 0x3C20 - 0x3C3F: IO Features (QDDMA, APIC, Intel VT, RAS, Intel TXT) > 0x3C40 - 0x3C5F: Performance Monitors > 0x3C60 - 0x3C7F: DFX > 0x3C80 - 0x3C9F: Intel QuickPath Interconnect > 0x3CA0 - 0x3CBF: Home Agent/Memory Controller > 0x3CC0 - 0x3CDF: Power Management > 0x3CE0 - 0x3CFF: Cbo/Ring > > Even if it would not seem to be critical features, what will be the > consequence of having those features currently unhandled ? None. These do not generally need active management. However, they can allow you to do interesting things in some cases such as ECC error injection. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Apr 12 18:48:07 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF342106566B; Thu, 12 Apr 2012 18:48:07 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id BCA458FC1B; Thu, 12 Apr 2012 18:48:07 +0000 (UTC) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.5/8.14.5) with ESMTP id q3CIfEfN053556; Thu, 12 Apr 2012 11:41:14 -0700 (PDT) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.5/8.14.5/Submit) id q3CIfEPK053555; Thu, 12 Apr 2012 11:41:14 -0700 (PDT) (envelope-from obrien) Date: Thu, 12 Apr 2012 11:41:14 -0700 From: "David O'Brien" To: jasone@freebsd.org Message-ID: <20120412184114.GB71001@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, jasone@freebsd.org, freebsd-current@freebsd.org References: <431CB493-836B-4DF4-AC42-A7C6ABF7DE3E@canonware.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <431CB493-836B-4DF4-AC42-A7C6ABF7DE3E@canonware.com> X-Operating-System: FreeBSD 10.0-CURRENT X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org Subject: Re: contrib/jemalloc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 18:48:08 -0000 On Wed, Apr 04, 2012 at 09:56:45PM -0700, Jason Evans wrote: > I have the current version of jemalloc integrated into libc as contrib/jemalloc: > http://people.freebsd.org/~jasone/patches/jemalloc_20120404b.patch Looking at the latest patch http://people.freebsd.org/~jasone/patches/jemalloc_20120405a.patch I cannot tell for sure if you did an 'svn move' of the files from lib/libc/stdlib/ to contrib/jemalloc/. It looks to me like they have not. If not, can you regen the diff after using 'svn move' so we maintain log history? > * Is it acceptable to check this in directly to trunk without using a > vendor branch? For the import workflow I have planned, a vendor branch > would just be extra work with no benefit that I can see. I do not think it is acceptable. Our workflow is to do vendor imports. They are invaluable in tracking down history and changes years after the fact. They are also very valuable to commercial third-parties that consume FreeBSD into their products (I speak for Juniper Networks in this). Why do you feel they are [measurably] extra work with no benefit? -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Thu Apr 12 20:20:03 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A1AC5106564A; Thu, 12 Apr 2012 20:20:03 +0000 (UTC) (envelope-from jasone@canonware.com) Received: from canonware.com (10140.x.rootbsd.net [204.109.63.53]) by mx1.freebsd.org (Postfix) with ESMTP id 795F68FC0A; Thu, 12 Apr 2012 20:20:03 +0000 (UTC) Received: from [172.25.16.174] (unknown [173.252.71.3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by canonware.com (Postfix) with ESMTPSA id E6ACD2843B; Thu, 12 Apr 2012 13:19:56 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Jason Evans In-Reply-To: <20120412184114.GB71001@dragon.NUXI.org> Date: Thu, 12 Apr 2012 13:19:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <431CB493-836B-4DF4-AC42-A7C6ABF7DE3E@canonware.com> <20120412184114.GB71001@dragon.NUXI.org> To: obrien@freebsd.org X-Mailer: Apple Mail (2.1257) Cc: freebsd-current@freebsd.org Subject: Re: contrib/jemalloc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jasone@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 20:20:03 -0000 On Apr 12, 2012, at 11:41 AM, David O'Brien wrote: > On Wed, Apr 04, 2012 at 09:56:45PM -0700, Jason Evans wrote: >> I have the current version of jemalloc integrated into libc as = contrib/jemalloc: >> = http://people.freebsd.org/~jasone/patches/jemalloc_20120404b.patch >=20 > Looking at the latest patch > http://people.freebsd.org/~jasone/patches/jemalloc_20120405a.patch >=20 > I cannot tell for sure if you did an 'svn move' of the files from > lib/libc/stdlib/ to contrib/jemalloc/. It looks to me like they have > not. If not, can you regen the diff after using 'svn move' so we > maintain log history? Done now for malloc.3 --> reallocf.3 in my tree. = http://people.freebsd.org/~jasone/patches/jemalloc_20120412a.patch For the rest of the code, its structure/origin is different enough that = 'svn move' doesn't really apply. >> * Is it acceptable to check this in directly to trunk without using a >> vendor branch? For the import workflow I have planned, a vendor = branch >> would just be extra work with no benefit that I can see. >=20 > I do not think it is acceptable. Our workflow is to do vendor = imports. > They are invaluable in tracking down history and changes years after = the > fact. They are also very valuable to commercial third-parties that > consume FreeBSD into their products (I speak for Juniper Networks in > this). >=20 > Why do you feel they are [measurably] extra work with no benefit? The workflow I'm using is documented in the patch = (contrib/jemalloc/FREEBSD-upgrade). Can you tell me how to achieve a = similarly streamlined import flow with a vendor branch in the mix? = Also, what history would a vendor branch preserve that this workflow = does not? The only upside to vendor branch merges I can think of is = that if any jemalloc sources were manually modified between imports, = merging would fail rather than silently overwriting the changes. = However, this presumes that changes aren't making it upstream. Jason= From owner-freebsd-current@FreeBSD.ORG Thu Apr 12 21:19:55 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 747561065687; Thu, 12 Apr 2012 21:19:55 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 3C4868FC0A; Thu, 12 Apr 2012 21:19:55 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q3CLJsgD084679; Thu, 12 Apr 2012 17:19:54 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q3CLJsM5084659; Thu, 12 Apr 2012 21:19:54 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 12 Apr 2012 21:19:54 GMT Message-Id: <201204122119.q3CLJsM5084659@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 21:19:55 -0000 TB --- 2012-04-12 19:40:11 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-04-12 19:40:11 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-04-12 19:40:11 - starting HEAD tinderbox run for ia64/ia64 TB --- 2012-04-12 19:40:11 - cleaning the object tree TB --- 2012-04-12 19:40:11 - cvsupping the source tree TB --- 2012-04-12 19:40:11 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2012-04-12 19:41:27 - building world TB --- 2012-04-12 19:41:27 - CROSS_BUILD_TESTING=YES TB --- 2012-04-12 19:41:27 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-12 19:41:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-12 19:41:27 - SRCCONF=/dev/null TB --- 2012-04-12 19:41:27 - TARGET=ia64 TB --- 2012-04-12 19:41:27 - TARGET_ARCH=ia64 TB --- 2012-04-12 19:41:27 - TZ=UTC TB --- 2012-04-12 19:41:27 - __MAKE_CONF=/dev/null TB --- 2012-04-12 19:41:27 - cd /src TB --- 2012-04-12 19:41:27 - /usr/bin/make -B buildworld >>> World build started on Thu Apr 12 19:41:28 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 Thu Apr 12 21:14:34 UTC 2012 TB --- 2012-04-12 21:14:34 - generating LINT kernel config TB --- 2012-04-12 21:14:34 - cd /src/sys/ia64/conf TB --- 2012-04-12 21:14:34 - /usr/bin/make -B LINT TB --- 2012-04-12 21:14:34 - cd /src/sys/ia64/conf TB --- 2012-04-12 21:14:34 - /usr/sbin/config -m LINT TB --- 2012-04-12 21:14:34 - building LINT kernel TB --- 2012-04-12 21:14:34 - CROSS_BUILD_TESTING=YES TB --- 2012-04-12 21:14:34 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-12 21:14:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-12 21:14:34 - SRCCONF=/dev/null TB --- 2012-04-12 21:14:34 - TARGET=ia64 TB --- 2012-04-12 21:14:34 - TARGET_ARCH=ia64 TB --- 2012-04-12 21:14:34 - TZ=UTC TB --- 2012-04-12 21:14:34 - __MAKE_CONF=/dev/null TB --- 2012-04-12 21:14:34 - cd /src TB --- 2012-04-12 21:14:34 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Apr 12 21:14:34 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/ddb/db_expr.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/ddb/db_input.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/ddb/db_lex.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/ddb/db_main.c /src/sys/ddb/db_main.c:55:57: error: macro "KDB_BACKEND" requires 5 arguments, but only 4 given cc1: warnings being treated as errors /src/sys/ddb/db_main.c:55: warning: data definition has no type or storage class /src/sys/ddb/db_main.c:55: warning: type defaults to 'int' in declaration of 'KDB_BACKEND' *** Error code 1 Stop in /obj/ia64.ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-04-12 21:19:54 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-04-12 21:19:54 - ERROR: failed to build LINT kernel TB --- 2012-04-12 21:19:54 - 4469.45 user 691.21 system 5983.02 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Thu Apr 12 21:39:17 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 23106106564A; Thu, 12 Apr 2012 21:39:17 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id E2D4A8FC1C; Thu, 12 Apr 2012 21:39:16 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q3CLdGPO024025; Thu, 12 Apr 2012 17:39:16 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q3CLdGaR024009; Thu, 12 Apr 2012 21:39:16 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 12 Apr 2012 21:39:16 GMT Message-Id: <201204122139.q3CLdGaR024009@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 21:39:17 -0000 TB --- 2012-04-12 20:34:01 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-04-12 20:34:01 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-04-12 20:34:01 - starting HEAD tinderbox run for mips/mips TB --- 2012-04-12 20:34:01 - cleaning the object tree TB --- 2012-04-12 20:34:01 - cvsupping the source tree TB --- 2012-04-12 20:34:01 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2012-04-12 20:34:55 - building world TB --- 2012-04-12 20:34:55 - CROSS_BUILD_TESTING=YES TB --- 2012-04-12 20:34:55 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-12 20:34:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-12 20:34:55 - SRCCONF=/dev/null TB --- 2012-04-12 20:34:55 - TARGET=mips TB --- 2012-04-12 20:34:55 - TARGET_ARCH=mips TB --- 2012-04-12 20:34:55 - TZ=UTC TB --- 2012-04-12 20:34:55 - __MAKE_CONF=/dev/null TB --- 2012-04-12 20:34:55 - cd /src TB --- 2012-04-12 20:34:55 - /usr/bin/make -B buildworld >>> World build started on Thu Apr 12 20:34:56 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 Thu Apr 12 21:38:06 UTC 2012 TB --- 2012-04-12 21:38:06 - cd /src/sys/mips/conf TB --- 2012-04-12 21:38:06 - /usr/sbin/config -m ADM5120 TB --- 2012-04-12 21:38:06 - skipping ADM5120 kernel TB --- 2012-04-12 21:38:06 - cd /src/sys/mips/conf TB --- 2012-04-12 21:38:06 - /usr/sbin/config -m ALCHEMY TB --- 2012-04-12 21:38:06 - skipping ALCHEMY kernel TB --- 2012-04-12 21:38:06 - cd /src/sys/mips/conf TB --- 2012-04-12 21:38:06 - /usr/sbin/config -m AR71XX_BASE TB --- 2012-04-12 21:38:06 - building AR71XX_BASE kernel TB --- 2012-04-12 21:38:06 - CROSS_BUILD_TESTING=YES TB --- 2012-04-12 21:38:06 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-12 21:38:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-12 21:38:06 - SRCCONF=/dev/null TB --- 2012-04-12 21:38:06 - TARGET=mips TB --- 2012-04-12 21:38:06 - TARGET_ARCH=mips TB --- 2012-04-12 21:38:06 - TZ=UTC TB --- 2012-04-12 21:38:06 - __MAKE_CONF=/dev/null TB --- 2012-04-12 21:38:06 - cd /src TB --- 2012-04-12 21:38:06 - /usr/bin/make -B buildkernel KERNCONF=AR71XX_BASE >>> Kernel build for AR71XX_BASE started on Thu Apr 12 21:38:06 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 -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=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x80050000 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/ddb/db_expr.c cc -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=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x80050000 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/ddb/db_input.c cc -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=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x80050000 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/ddb/db_lex.c cc -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=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x80050000 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/ddb/db_main.c /src/sys/ddb/db_main.c:55:57: error: macro "KDB_BACKEND" requires 5 arguments, but only 4 given cc1: warnings being treated as errors /src/sys/ddb/db_main.c:55: warning: data definition has no type or storage class /src/sys/ddb/db_main.c:55: warning: type defaults to 'int' in declaration of 'KDB_BACKEND' *** Error code 1 Stop in /obj/mips.mips/src/sys/AR71XX_BASE. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-04-12 21:39:16 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-04-12 21:39:16 - ERROR: failed to build AR71XX_BASE kernel TB --- 2012-04-12 21:39:16 - 2609.15 user 548.57 system 3914.67 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Thu Apr 12 22:22:07 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CBE7F1065674 for ; Thu, 12 Apr 2012 22:22:07 +0000 (UTC) (envelope-from andy@neu.net) Received: from mail.neu.net (unknown [IPv6:2607:fc50:0:d300:216:3eff:fe54:f1c6]) by mx1.freebsd.org (Postfix) with ESMTP id 6AE778FC18 for ; Thu, 12 Apr 2012 22:22:06 +0000 (UTC) Received: from neu.net (neu.net [199.48.129.194]) by mail.neu.net (8.14.5/8.14.5) with ESMTP id q3CMLwA5002043 for ; Thu, 12 Apr 2012 18:22:05 -0400 (EDT) (envelope-from andy@neu.net) Date: Thu, 12 Apr 2012 18:21:58 -0400 (EDT) From: AN To: freebsd-current@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Spam-Status: No, score=-0.0 required=5.0 tests=T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mail.neu.net Subject: kernel build failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 22:22:08 -0000 At Thu Apr 12 17:52:05 EDT 2012: [root@FBSD10 /usr/src]# svn up Updating '.': At revision 234196. Trying to build the kernel I get the following failure: time make -j8 buildkernel KERNCONF=MYKERNEL ===> zlib (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/MYKERNEL/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -fno-omit-frame-pointer -I/usr/obj/usr/src/sys/MYKERNEL -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -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 -c /usr/src/sys/modules/zlib/../../net/zlib.c ld -d -warn-common -r -d -o zlib.ko.debug zlib.o :> export_syms awk -f /usr/src/sys/conf/kmod_syms.awk zlib.ko.debug export_syms | xargs -J% objcopy % zlib.ko.debug objcopy --only-keep-debug zlib.ko.debug zlib.ko.symbols objcopy --strip-debug --add-gnu-debuglink=zlib.ko.symbols zlib.ko.debug zlib.ko 1 error *** [buildkernel] Error code 2 1 error *** [buildkernel] Error code 2 1 error real 8m20.095s user 12m37.161s sys 6m59.844s I tried this 4 times, twice with MYKERNEL and twice with GENERIC. It failed in the same spot every time. Is anyone else seeing this? Also, I tried without -j8, and it fails with the following: cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -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/usr/src/sys -I/usr/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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror /usr/src/sys/kern/subr_turnstile.c cc1: warnings being treated as errors /usr/src/sys/kern/subr_turnstile.c: In function 'propagate_priority': /usr/src/sys/kern/subr_turnstile.c:220: warning: implicit declaration of function 'kdb_backtrace_thread' /usr/src/sys/kern/subr_turnstile.c:220: warning: nested extern declaration of 'kdb_backtrace_thread' [-Wnested-externs] *** [subr_turnstile.o] Error code 1 Stop in /usr/obj/usr/src/sys/MYKERNEL. *** [buildkernel] Error code 1 Stop in /usr/src. *** [buildkernel] Error code 1 Stop in /usr/src. real 5m19.701s user 4m33.051s sys 0m51.466s Here is /etc/make.conf # cat /etc/make.conf OVERRIDE_LINUX_BASE_PORT=f10 QT4_OPTIONS= QGTKSTYLE WITH_OPENSSL_PORT=yes # added by use.perl 2012-04-04 01:11:13 PERL_VERSION=5.14.2 The kernel previously built without problems with this same configuration. From owner-freebsd-current@FreeBSD.ORG Thu Apr 12 23:35:20 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D0F9B106566B; Thu, 12 Apr 2012 23:35:20 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id A09B78FC18; Thu, 12 Apr 2012 23:35:20 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q3CNZJwd013660; Thu, 12 Apr 2012 19:35:19 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q3CNZJZv013659; Thu, 12 Apr 2012 23:35:19 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 12 Apr 2012 23:35:19 GMT Message-Id: <201204122335.q3CNZJZv013659@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 23:35:20 -0000 TB --- 2012-04-12 21:19:54 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-04-12 21:19:54 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-04-12 21:19:54 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2012-04-12 21:19:54 - cleaning the object tree TB --- 2012-04-12 21:19:54 - cvsupping the source tree TB --- 2012-04-12 21:19:54 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2012-04-12 21:20:40 - building world TB --- 2012-04-12 21:20:40 - CROSS_BUILD_TESTING=YES TB --- 2012-04-12 21:20:40 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-12 21:20:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-12 21:20:40 - SRCCONF=/dev/null TB --- 2012-04-12 21:20:40 - TARGET=powerpc TB --- 2012-04-12 21:20:40 - TARGET_ARCH=powerpc TB --- 2012-04-12 21:20:40 - TZ=UTC TB --- 2012-04-12 21:20:40 - __MAKE_CONF=/dev/null TB --- 2012-04-12 21:20:40 - cd /src TB --- 2012-04-12 21:20:40 - /usr/bin/make -B buildworld >>> World build started on Thu Apr 12 21:20:41 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 Thu Apr 12 23:32:13 UTC 2012 TB --- 2012-04-12 23:32:13 - generating LINT kernel config TB --- 2012-04-12 23:32:13 - cd /src/sys/powerpc/conf TB --- 2012-04-12 23:32:13 - /usr/bin/make -B LINT TB --- 2012-04-12 23:32:13 - cd /src/sys/powerpc/conf TB --- 2012-04-12 23:32:13 - /usr/sbin/config -m LINT TB --- 2012-04-12 23:32:13 - building LINT kernel TB --- 2012-04-12 23:32:13 - CROSS_BUILD_TESTING=YES TB --- 2012-04-12 23:32:13 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-12 23:32:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-12 23:32:13 - SRCCONF=/dev/null TB --- 2012-04-12 23:32:13 - TARGET=powerpc TB --- 2012-04-12 23:32:13 - TARGET_ARCH=powerpc TB --- 2012-04-12 23:32:13 - TZ=UTC TB --- 2012-04-12 23:32:13 - __MAKE_CONF=/dev/null TB --- 2012-04-12 23:32:13 - cd /src TB --- 2012-04-12 23:32:13 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Apr 12 23:32:13 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/ddb/db_expr.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/ddb/db_input.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/ddb/db_lex.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/ddb/db_main.c /src/sys/ddb/db_main.c:55:57: error: macro "KDB_BACKEND" requires 5 arguments, but only 4 given cc1: warnings being treated as errors /src/sys/ddb/db_main.c:55: warning: data definition has no type or storage class /src/sys/ddb/db_main.c:55: warning: type defaults to 'int' in declaration of 'KDB_BACKEND' *** Error code 1 Stop in /obj/powerpc.powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-04-12 23:35:19 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-04-12 23:35:19 - ERROR: failed to build LINT kernel TB --- 2012-04-12 23:35:19 - 6433.92 user 848.28 system 8124.43 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Fri Apr 13 00:18:07 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 593E8106564A; Fri, 13 Apr 2012 00:18:07 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 26F308FC08; Fri, 13 Apr 2012 00:18:07 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q3D0I6wB032552; Thu, 12 Apr 2012 20:18:06 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q3D0I6V2032551; Fri, 13 Apr 2012 00:18:06 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 13 Apr 2012 00:18:06 GMT Message-Id: <201204130018.q3D0I6V2032551@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 00:18:07 -0000 TB --- 2012-04-12 21:39:16 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-04-12 21:39:16 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-04-12 21:39:16 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2012-04-12 21:39:16 - cleaning the object tree TB --- 2012-04-12 21:39:16 - cvsupping the source tree TB --- 2012-04-12 21:39:16 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2012-04-12 21:40:30 - building world TB --- 2012-04-12 21:40:30 - CROSS_BUILD_TESTING=YES TB --- 2012-04-12 21:40:30 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-12 21:40:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-12 21:40:30 - SRCCONF=/dev/null TB --- 2012-04-12 21:40:30 - TARGET=powerpc TB --- 2012-04-12 21:40:30 - TARGET_ARCH=powerpc64 TB --- 2012-04-12 21:40:30 - TZ=UTC TB --- 2012-04-12 21:40:30 - __MAKE_CONF=/dev/null TB --- 2012-04-12 21:40:30 - cd /src TB --- 2012-04-12 21:40:30 - /usr/bin/make -B buildworld >>> World build started on Thu Apr 12 21:40:31 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 Fri Apr 13 00:15:04 UTC 2012 TB --- 2012-04-13 00:15:04 - generating LINT kernel config TB --- 2012-04-13 00:15:04 - cd /src/sys/powerpc/conf TB --- 2012-04-13 00:15:04 - /usr/bin/make -B LINT TB --- 2012-04-13 00:15:04 - cd /src/sys/powerpc/conf TB --- 2012-04-13 00:15:04 - /usr/sbin/config -m LINT TB --- 2012-04-13 00:15:04 - building LINT kernel TB --- 2012-04-13 00:15:04 - CROSS_BUILD_TESTING=YES TB --- 2012-04-13 00:15:04 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-13 00:15:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-13 00:15:04 - SRCCONF=/dev/null TB --- 2012-04-13 00:15:04 - TARGET=powerpc TB --- 2012-04-13 00:15:04 - TARGET_ARCH=powerpc64 TB --- 2012-04-13 00:15:04 - TZ=UTC TB --- 2012-04-13 00:15:04 - __MAKE_CONF=/dev/null TB --- 2012-04-13 00:15:04 - cd /src TB --- 2012-04-13 00:15:04 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Apr 13 00:15:04 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/ddb/db_expr.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/ddb/db_input.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/ddb/db_lex.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/ddb/db_main.c /src/sys/ddb/db_main.c:55:57: error: macro "KDB_BACKEND" requires 5 arguments, but only 4 given cc1: warnings being treated as errors /src/sys/ddb/db_main.c:55: warning: data definition has no type or storage class /src/sys/ddb/db_main.c:55: warning: type defaults to 'int' in declaration of 'KDB_BACKEND' *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-04-13 00:18:06 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-04-13 00:18:06 - ERROR: failed to build LINT kernel TB --- 2012-04-13 00:18:06 - 7810.46 user 1090.85 system 9529.88 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Fri Apr 13 04:01:46 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B239F1065692; Fri, 13 Apr 2012 04:01:46 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 81E2E8FC0C; Fri, 13 Apr 2012 04:01:46 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q3D41j07063933; Fri, 13 Apr 2012 00:01:45 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q3D41jvT063896; Fri, 13 Apr 2012 04:01:45 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 13 Apr 2012 04:01:45 GMT Message-Id: <201204130401.q3D41jvT063896@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 04:01:46 -0000 TB --- 2012-04-13 01:10:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-04-13 01:10:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-04-13 01:10:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2012-04-13 01:10:00 - cleaning the object tree TB --- 2012-04-13 01:10:00 - cvsupping the source tree TB --- 2012-04-13 01:10:01 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2012-04-13 01:11:01 - building world TB --- 2012-04-13 01:11:01 - CROSS_BUILD_TESTING=YES TB --- 2012-04-13 01:11:01 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-13 01:11:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-13 01:11:01 - SRCCONF=/dev/null TB --- 2012-04-13 01:11:01 - TARGET=pc98 TB --- 2012-04-13 01:11:01 - TARGET_ARCH=i386 TB --- 2012-04-13 01:11:01 - TZ=UTC TB --- 2012-04-13 01:11:01 - __MAKE_CONF=/dev/null TB --- 2012-04-13 01:11:01 - cd /src TB --- 2012-04-13 01:11:01 - /usr/bin/make -B buildworld >>> World build started on Fri Apr 13 01:11:01 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 Fri Apr 13 03:26:40 UTC 2012 TB --- 2012-04-13 03:26:40 - generating LINT kernel config TB --- 2012-04-13 03:26:40 - cd /src/sys/pc98/conf TB --- 2012-04-13 03:26:40 - /usr/bin/make -B LINT TB --- 2012-04-13 03:26:40 - cd /src/sys/pc98/conf TB --- 2012-04-13 03:26:40 - /usr/sbin/config -m LINT TB --- 2012-04-13 03:26:40 - building LINT kernel TB --- 2012-04-13 03:26:40 - CROSS_BUILD_TESTING=YES TB --- 2012-04-13 03:26:40 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-13 03:26:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-13 03:26:40 - SRCCONF=/dev/null TB --- 2012-04-13 03:26:40 - TARGET=pc98 TB --- 2012-04-13 03:26:40 - TARGET_ARCH=i386 TB --- 2012-04-13 03:26:40 - TZ=UTC TB --- 2012-04-13 03:26:40 - __MAKE_CONF=/dev/null TB --- 2012-04-13 03:26:40 - cd /src TB --- 2012-04-13 03:26:40 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Apr 13 03:26:40 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 Fri Apr 13 03:57:00 UTC 2012 TB --- 2012-04-13 03:57:00 - cd /src/sys/pc98/conf TB --- 2012-04-13 03:57:00 - /usr/sbin/config -m GENERIC TB --- 2012-04-13 03:57:00 - building GENERIC kernel TB --- 2012-04-13 03:57:00 - CROSS_BUILD_TESTING=YES TB --- 2012-04-13 03:57:00 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-13 03:57:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-13 03:57:00 - SRCCONF=/dev/null TB --- 2012-04-13 03:57:00 - TARGET=pc98 TB --- 2012-04-13 03:57:00 - TARGET_ARCH=i386 TB --- 2012-04-13 03:57:00 - TZ=UTC TB --- 2012-04-13 03:57:00 - __MAKE_CONF=/dev/null TB --- 2012-04-13 03:57:00 - cd /src TB --- 2012-04-13 03:57:00 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Apr 13 03:57:00 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 -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 -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 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/kern/subr_stack.c cc -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 -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 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/kern/subr_taskqueue.c cc -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 -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 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/kern/subr_trap.c cc -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 -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 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/kern/subr_turnstile.c cc1: warnings being treated as errors /src/sys/kern/subr_turnstile.c: In function 'propagate_priority': /src/sys/kern/subr_turnstile.c:220: warning: implicit declaration of function 'kdb_backtrace_thread' /src/sys/kern/subr_turnstile.c:220: warning: nested extern declaration of 'kdb_backtrace_thread' [-Wnested-externs] *** Error code 1 Stop in /obj/pc98.i386/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-04-13 04:01:45 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-04-13 04:01:45 - ERROR: failed to build GENERIC kernel TB --- 2012-04-13 04:01:45 - 7735.05 user 1113.35 system 10304.60 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Fri Apr 13 06:04:03 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04394106564A for ; Fri, 13 Apr 2012 06:04:03 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7B1BC8FC12 for ; Fri, 13 Apr 2012 06:04:02 +0000 (UTC) Received: by lbbgj3 with SMTP id gj3so2769355lbb.13 for ; Thu, 12 Apr 2012 23:04:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=7mUrONPF8GACXJ3fMMhuo0IVBYakW/PGOIyyQz/8MtE=; b=vZt5g+yKuV3nLnMho/T3hA+ZAIJfbz99wul/mSj5VDo/DZBf9ZMTxIBdQFycfj4+TV fr2x137P8dJ2rYJINtoVMzdmCSsT0AuJ9ls6J3aGDkig77xMNRR09FNTrT/5l5o7KEyY kPiuOCGwx+bxZwroOeKEsCHVsrEBVfWg/QKBSyaU+zvxb449HLT64sWrrq36m2GJhSsJ PxMqPF07uzUvKwBu9Lq+qJUvNzjLfx7wNZVGJL6xWJePcUd6j69kUGRtwv2rygz84IM0 ZzM7MUrdrMScxrbj7cQGo1OwEfiN0NUb7xI8S9c8BG4/gL8oykF9yqUdRhqC1DWIOwKM W3DA== MIME-Version: 1.0 Received: by 10.152.104.109 with SMTP id gd13mr401931lab.9.1334297041289; Thu, 12 Apr 2012 23:04:01 -0700 (PDT) Received: by 10.152.25.69 with HTTP; Thu, 12 Apr 2012 23:04:01 -0700 (PDT) In-Reply-To: References: Date: Fri, 13 Apr 2012 10:04:01 +0400 Message-ID: From: Sergey Kandaurov To: AN Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: kernel build failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 06:04:03 -0000 On 13 April 2012 02:21, AN wrote: > At Thu Apr 12 17:52:05 EDT 2012: > > [root@FBSD10 /usr/src]# svn up > Updating '.': > At revision 234196. [...] > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing =A0-std=3Dc99 -g = -Wall > -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototyp= es > -Wpointer-arith -Winline -Wcast-qual =A0-Wundef -Wno-pointer-sign > -fformat-extensions =A0-Wmissing-include-dirs -fdiagnostics-show-option > -nostdinc =A0-I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL > -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common > -finline-limit=3D8000 --param inline-unit-growth=3D100 --param > large-function-growth=3D1000 -fno-omit-frame-pointer -mcmodel=3Dkernel > -mno-red-zone -mno-mmx -mno-sse -msoft-float > =A0-fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werr= or > =A0/usr/src/sys/kern/subr_turnstile.c > cc1: warnings being treated as errors > /usr/src/sys/kern/subr_turnstile.c: In function 'propagate_priority': > /usr/src/sys/kern/subr_turnstile.c:220: warning: implicit declaration of > function 'kdb_backtrace_thread' > /usr/src/sys/kern/subr_turnstile.c:220: warning: nested extern declaratio= n > of 'kdb_backtrace_thread' [-Wnested-externs] > *** [subr_turnstile.o] Error code 1 > > Stop in /usr/obj/usr/src/sys/MYKERNEL. > *** [buildkernel] Error code 1 > > Stop in /usr/src. > *** [buildkernel] Error code 1 > > Stop in /usr/src. This is a transient failure, it will be fixed soon. --=20 wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Fri Apr 13 12:15:00 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4B39D1065670; Fri, 13 Apr 2012 12:15:00 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 0FB048FC0A; Fri, 13 Apr 2012 12:14:59 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q3DCEr05090874; Fri, 13 Apr 2012 08:14:53 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q3DCEr5t090857; Fri, 13 Apr 2012 12:14:53 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 13 Apr 2012 12:14:53 GMT Message-Id: <201204131214.q3DCEr5t090857@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 12:15:00 -0000 TB --- 2012-04-13 09:20:01 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-04-13 09:20:01 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-04-13 09:20:01 - starting HEAD tinderbox run for i386/pc98 TB --- 2012-04-13 09:20:01 - cleaning the object tree TB --- 2012-04-13 09:24:10 - cvsupping the source tree TB --- 2012-04-13 09:24:10 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2012-04-13 09:24:50 - building world TB --- 2012-04-13 09:24:50 - CROSS_BUILD_TESTING=YES TB --- 2012-04-13 09:24:50 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-13 09:24:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-13 09:24:50 - SRCCONF=/dev/null TB --- 2012-04-13 09:24:50 - TARGET=pc98 TB --- 2012-04-13 09:24:50 - TARGET_ARCH=i386 TB --- 2012-04-13 09:24:50 - TZ=UTC TB --- 2012-04-13 09:24:50 - __MAKE_CONF=/dev/null TB --- 2012-04-13 09:24:50 - cd /src TB --- 2012-04-13 09:24:50 - /usr/bin/make -B buildworld >>> World build started on Fri Apr 13 09:24:51 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 Fri Apr 13 11:39:51 UTC 2012 TB --- 2012-04-13 11:39:51 - generating LINT kernel config TB --- 2012-04-13 11:39:51 - cd /src/sys/pc98/conf TB --- 2012-04-13 11:39:51 - /usr/bin/make -B LINT TB --- 2012-04-13 11:39:51 - cd /src/sys/pc98/conf TB --- 2012-04-13 11:39:51 - /usr/sbin/config -m LINT TB --- 2012-04-13 11:39:51 - building LINT kernel TB --- 2012-04-13 11:39:51 - CROSS_BUILD_TESTING=YES TB --- 2012-04-13 11:39:51 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-13 11:39:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-13 11:39:51 - SRCCONF=/dev/null TB --- 2012-04-13 11:39:51 - TARGET=pc98 TB --- 2012-04-13 11:39:51 - TARGET_ARCH=i386 TB --- 2012-04-13 11:39:51 - TZ=UTC TB --- 2012-04-13 11:39:51 - __MAKE_CONF=/dev/null TB --- 2012-04-13 11:39:51 - cd /src TB --- 2012-04-13 11:39:51 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Apr 13 11:39:51 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 Fri Apr 13 12:09:48 UTC 2012 TB --- 2012-04-13 12:09:48 - cd /src/sys/pc98/conf TB --- 2012-04-13 12:09:48 - /usr/sbin/config -m GENERIC TB --- 2012-04-13 12:09:49 - building GENERIC kernel TB --- 2012-04-13 12:09:49 - CROSS_BUILD_TESTING=YES TB --- 2012-04-13 12:09:49 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-13 12:09:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-13 12:09:49 - SRCCONF=/dev/null TB --- 2012-04-13 12:09:49 - TARGET=pc98 TB --- 2012-04-13 12:09:49 - TARGET_ARCH=i386 TB --- 2012-04-13 12:09:49 - TZ=UTC TB --- 2012-04-13 12:09:49 - __MAKE_CONF=/dev/null TB --- 2012-04-13 12:09:49 - cd /src TB --- 2012-04-13 12:09:49 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Apr 13 12:09:49 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 -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 -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 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/kern/subr_stack.c cc -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 -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 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/kern/subr_taskqueue.c cc -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 -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 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/kern/subr_trap.c cc -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 -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 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/kern/subr_turnstile.c cc1: warnings being treated as errors /src/sys/kern/subr_turnstile.c: In function 'propagate_priority': /src/sys/kern/subr_turnstile.c:220: warning: implicit declaration of function 'kdb_backtrace_thread' /src/sys/kern/subr_turnstile.c:220: warning: nested extern declaration of 'kdb_backtrace_thread' [-Wnested-externs] *** Error code 1 Stop in /obj/pc98.i386/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-04-13 12:14:53 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-04-13 12:14:53 - ERROR: failed to build GENERIC kernel TB --- 2012-04-13 12:14:53 - 7784.58 user 1116.72 system 10491.95 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Fri Apr 13 13:27:04 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F3F60106564A for ; Fri, 13 Apr 2012 13:27:03 +0000 (UTC) (envelope-from darrenr@freebsd.org) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id BB8128FC0C for ; Fri, 13 Apr 2012 13:27:03 +0000 (UTC) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 9607620A06 for ; Fri, 13 Apr 2012 09:27:02 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute4.internal (MEProxy); Fri, 13 Apr 2012 09:27:02 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:reply-to :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=gQIQqwzKZIxPsysG1IVW0C uiBZs=; b=ltGkG+WlW+wOG5T5fhKTZedkyuj+fA3h2vIrCDhSKeo8hAr1FJxvkd R8uXSXWyGE61Fn/aSQRW4LmUTNGpxdlBsMJMjeVzI2MYBdf4VM2l+UMACQX6Dp9/ VmlS9pCJQXXMGX3IFRO9LcENn6U/Oz6+DEhTJjUb2iefGAs/hxDqk= X-Sasl-enc: mucnzXP++/kaefDIjj9AXA+7LqZdPWrNqLmWRTBFkIsX 1334323622 Received: from [192.168.1.124] (dsl-202-45-110-141-static.VIC.netspace.net.au [202.45.110.141]) by mail.messagingengine.com (Postfix) with ESMTPSA id D92924824E2 for ; Fri, 13 Apr 2012 09:27:01 -0400 (EDT) Message-ID: <4F8829A7.4010307@freebsd.org> Date: Fri, 13 Apr 2012 23:27:03 +1000 From: Darren Reed Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-AU; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: New FreeBSD SVN seed snapshot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: darrenr@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 13:27:04 -0000 On 24/08/2010 4:56 AM, Simon L. B. Nielsen wrote: > Hey, > > I have made a new snapshot of the svn repo which can be used to start new FreeBSD svn mirrors. > > Hopefully I made it the right way, but... let me know if there are any issues. > > Since the original snapshot was made by peter the repo was 'packed' which means it uses a lot fewer files. > > The snapshot can be found at: > > ftp://ftp.freebsd.org/pub/FreeBSD/development/subversion/ > > You need ports/archivers/xz installed if you aren't running FreeBSD 8.1+. > > Thanks to rpaulo and bz for prodding my into finding out how this worked and making the new snapshot :-). > > I can't think of what else to say, so that was probably it :-). The committers guide at: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/article.html should be updated with the above location to use instead of ~peter/something as the file at freefall/~peter is quite old now. Also, what's the chance of the mirror being updated and exported to the above URL as part of the release process, so that a new mirror is available when 8.2 is available, followed by 9.0, etc, and naming them as such? Darren From owner-freebsd-current@FreeBSD.ORG Fri Apr 13 13:45:45 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E9FF0106564A for ; Fri, 13 Apr 2012 13:45:45 +0000 (UTC) (envelope-from ray@dlink.ua) Received: from smtp.dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id A88F48FC15 for ; Fri, 13 Apr 2012 13:45:45 +0000 (UTC) Received: from terran.dlink.ua (unknown [192.168.10.90]) (Authenticated sender: ray) by smtp.dlink.ua (Postfix) with ESMTPSA id C0004C4936 for ; Fri, 13 Apr 2012 16:36:27 +0300 (EEST) Date: Fri, 13 Apr 2012 16:37:29 +0300 From: Aleksandr Rybalko To: current@freebsd.org Message-Id: <20120413163729.3ecd1136.ray@dlink.ua> Organization: D-Link X-Mailer: Sylpheed 2.7.1 (GTK+ 2.20.1; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Subject: build with KTR and KTR_CPUMASK X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 13:45:46 -0000 Hi, When kernel build with option KTR_CPUMASK, build failed with following error: 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/usr/1/MIPS_FreeBSD/HEAD/head/sys -I/usr/1/MIPS_FreeBSD/HEAD/head/sys/contrib/altq -I/usr/1/MIPS_FreeBSD/HEAD/head/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x80001000 -march=mips32 -msoft-float -ffreestanding -Werror /usr/1/MIPS_FreeBSD/HEAD/head/sys/kern/kern_ktr.c cc1: warnings being treated as errors /usr/1/MIPS_FreeBSD/HEAD/head/sys/kern/kern_ktr.c: In function 'ktr_cpumask_initializer': /usr/1/MIPS_FreeBSD/HEAD/head/sys/kern/kern_ktr.c:112: warning: passing argument 2 of 'cpusetobj_strscan' makes pointer from integer without a cast *** Error code 1 SVN revision 234222. WBW -- Alexandr Rybalko aka Alex RAY From owner-freebsd-current@FreeBSD.ORG Fri Apr 13 13:53:43 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 24102106566C for ; Fri, 13 Apr 2012 13:53:43 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 960D98FC08 for ; Fri, 13 Apr 2012 13:53:42 +0000 (UTC) Received: by lagv3 with SMTP id v3so3119949lag.13 for ; Fri, 13 Apr 2012 06:53:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Vzen1s1WunniAwiHE9YoneiVVmjYSpQQZ1c448laiBk=; b=XYyymP/dnS5nS6pjPOGMlCIEQ7kZVmZIcWEF1RlgO/R2S0eGkNZ2G6Odn14h703Zny dHZqZXTi2+0G57aDJJAOYjTCgn/oBq4LphoeWTvDs06IIW+e3LoLhfOFcWf+nX5YJtlA lQV0PI7MnT+4JRQfJE4fTu1IKfc4Dh4gs0/e7tHQQ2M6Eok7IRtefFt4qdH0edDKMeSZ iQ8ZM14zJDXaxcG8D/4D2ISsYJw1AZUOiPYpT5w787tvf86jxoTBlmxzrvOTtu9wfXSW EVmVd/oqcxFJrp6JoU+hzkrt0UjsgzQzsJZ+j4Owc/1kQtDNp9Sxvd40zXAbWM9bHks6 SMLg== MIME-Version: 1.0 Received: by 10.152.147.202 with SMTP id tm10mr1617586lab.49.1334325221525; Fri, 13 Apr 2012 06:53:41 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.112.93.138 with HTTP; Fri, 13 Apr 2012 06:53:41 -0700 (PDT) In-Reply-To: <20120413163729.3ecd1136.ray@dlink.ua> References: <20120413163729.3ecd1136.ray@dlink.ua> Date: Fri, 13 Apr 2012 14:53:41 +0100 X-Google-Sender-Auth: Ux6Gr1dWFVI9d7SmExKOdtuq0eI Message-ID: From: Attilio Rao To: Aleksandr Rybalko Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org Subject: Re: build with KTR and KTR_CPUMASK X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 13:53:43 -0000 Please read NOTES. Attilio Il 13 aprile 2012 14:37, Aleksandr Rybalko ha scritto: > Hi, > > When kernel build with option KTR_CPUMASK, build failed with following > error: > > cc -c -O2 -pipe -fno-strict-aliasing =C2=A0-std=3Dc99 =C2=A0-Wall -Wredun= dant-decls > -Wnested-externs -Wstrict-prototypes =C2=A0-Wmissing-prototypes > -Wpointer-arith -Winline -Wcast-qual =C2=A0-Wundef -Wno-pointer-sign > -fformat-extensions =C2=A0-Wmissing-include-dirs -fdiagnostics-show-optio= n > -nostdinc =C2=A0-I. -I/usr/1/MIPS_FreeBSD/HEAD/head/sys > -I/usr/1/MIPS_FreeBSD/HEAD/head/sys/contrib/altq > -I/usr/1/MIPS_FreeBSD/HEAD/head/sys/contrib/libfdt -D_KERNEL > -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common > -finline-limit=3D8000 --param inline-unit-growth=3D10000 --param > large-function-growth=3D100000 --param max-inline-insns-single=3D10000 > -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=3D0x80001000 -march=3Dmips32 > -msoft-float -ffreestanding > -Werror =C2=A0/usr/1/MIPS_FreeBSD/HEAD/head/sys/kern/kern_ktr.c cc1: > warnings being treated as > errors /usr/1/MIPS_FreeBSD/HEAD/head/sys/kern/kern_ktr.c: In function > 'ktr_cpumask_initializer': /usr/1/MIPS_FreeBSD/HEAD/head/sys/kern/kern_kt= r.c:112: > warning: passing argument 2 of 'cpusetobj_strscan' makes pointer from > integer without a cast *** Error code 1 > > SVN revision 234222. > > WBW > -- > Alexandr Rybalko > aka Alex RAY > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Fri Apr 13 14:14:32 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 63BFC106564A; Fri, 13 Apr 2012 14:14:32 +0000 (UTC) (envelope-from ray@ddteam.net) Received: from smtp.dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id 1D82B8FC08; Fri, 13 Apr 2012 14:14:32 +0000 (UTC) Received: from terran.dlink.ua (unknown [192.168.10.90]) (Authenticated sender: ray) by smtp.dlink.ua (Postfix) with ESMTPSA id CCF93C493C; Fri, 13 Apr 2012 17:14:30 +0300 (EEST) Date: Fri, 13 Apr 2012 17:15:33 +0300 From: Aleksandr Rybalko To: Attilio Rao Message-Id: <20120413171533.7d2279f5.ray@ddteam.net> In-Reply-To: References: <20120413163729.3ecd1136.ray@dlink.ua> Organization: DDTeam.net X-Mailer: Sylpheed 2.7.1 (GTK+ 2.20.1; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: build with KTR and KTR_CPUMASK X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 14:14:32 -0000 On Fri, 13 Apr 2012 14:53:41 +0100 Attilio Rao wrote: >> Please read NOTES. It is really my fault, but with different source :) Sorry for noise. P.S. It was wrong kernel config generated by zrouter. WBW -- Aleksandr Rybalko From owner-freebsd-current@FreeBSD.ORG Fri Apr 13 17:09:54 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C4165106566B for ; Fri, 13 Apr 2012 17:09:54 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 74F788FC0A for ; Fri, 13 Apr 2012 17:09:54 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1SIk0O-0001OA-Bo>; Fri, 13 Apr 2012 19:09:52 +0200 Received: from e178041147.adsl.alicedsl.de ([85.178.41.147] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1SIk0O-0007pt-6L>; Fri, 13 Apr 2012 19:09:52 +0200 Message-ID: <4F885DDA.9070608@zedat.fu-berlin.de> Date: Fri, 13 Apr 2012 19:09:46 +0200 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120314 Thunderbird/10.0.3 MIME-Version: 1.0 To: Konstantin Belousov References: <4F83FF50.1010404@mail.zedat.fu-berlin.de> <20120410203645.GI62756@hoeg.nl> <20120411050842.GE2358@deviant.kiev.zoral.com.ua> In-Reply-To: <20120411050842.GE2358@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 1.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3D7F29FA7FF7A1000AEAD223" X-Originating-IP: 85.178.41.147 Cc: Ed Schouten , "O. Hartmann" , Current FreeBSD Subject: Re: Changes to sbin/init/init.c (r233944) makes x11/xdm impossible to start from /etc/ttys X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 17:09:54 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3D7F29FA7FF7A1000AEAD223 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 04/11/12 07:08, schrieb Konstantin Belousov: > 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 g= o 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 misbeha= ve >> 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@. Than= ks >> for reporting! >=20 > Ok, lets discuss. I do not understand why this patch makes any change a= t all. > Esp. for xdm that is supposedly run on some vty and not on console. Hope the discussion is going on and will make the problem go away. It is still present and bothering ... Regards, Oliver --------------enig3D7F29FA7FF7A1000AEAD223 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJPiF3fAAoJEOgBcD7A/5N8x+YH/3aMsLEgOb5zXGAhrNfLjjhU LGzp/MzBfLJDkvV0hdbF95h8IV7yr+heHjIoxQ9zvsJe8r4Q5aWjCewdYRuSt54w CGwzo5OJg6XGdty+1ewKLrDfixTDZsahmE9GxmaN9xhVJWyCYItGFrnQsCiLVfdX U7U627Dz3Cq2UBYOHtdpaqTK3zeHBMJKKap+BmyMoroJwW2/Cm0DUHJxWwDe0FcB RxhmEPpLeVA6tGKewG97YJ6dZDxyEoPao3MdKh9JjkcoOQYF3IZUf+LUFRdkqUbk DNlAW0qbjDICtEjrtuxdhsgJEyVgmVBUSrCwJbI/DcDGK+uUt58JBMn1c8P+bn8= =W+wF -----END PGP SIGNATURE----- --------------enig3D7F29FA7FF7A1000AEAD223-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 13 20:04:29 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4845D1065670; Fri, 13 Apr 2012 20:04:29 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 154878FC16; Fri, 13 Apr 2012 20:04:28 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q3DK4RYF057882; Fri, 13 Apr 2012 16:04:27 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q3DK4RUq057826; Fri, 13 Apr 2012 20:04:27 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 13 Apr 2012 20:04:27 GMT Message-Id: <201204132004.q3DK4RUq057826@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 20:04:29 -0000 TB --- 2012-04-13 17:40:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-04-13 17:40:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-04-13 17:40:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2012-04-13 17:40:00 - cleaning the object tree TB --- 2012-04-13 17:44:06 - cvsupping the source tree TB --- 2012-04-13 17:44:06 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2012-04-13 17:44:51 - building world TB --- 2012-04-13 17:44:51 - CROSS_BUILD_TESTING=YES TB --- 2012-04-13 17:44:51 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-13 17:44:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-13 17:44:51 - SRCCONF=/dev/null TB --- 2012-04-13 17:44:51 - TARGET=pc98 TB --- 2012-04-13 17:44:51 - TARGET_ARCH=i386 TB --- 2012-04-13 17:44:51 - TZ=UTC TB --- 2012-04-13 17:44:51 - __MAKE_CONF=/dev/null TB --- 2012-04-13 17:44:51 - cd /src TB --- 2012-04-13 17:44:51 - /usr/bin/make -B buildworld >>> World build started on Fri Apr 13 17:44:52 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 Fri Apr 13 19:55:07 UTC 2012 TB --- 2012-04-13 19:55:07 - generating LINT kernel config TB --- 2012-04-13 19:55:07 - cd /src/sys/pc98/conf TB --- 2012-04-13 19:55:07 - /usr/bin/make -B LINT TB --- 2012-04-13 19:55:08 - cd /src/sys/pc98/conf TB --- 2012-04-13 19:55:08 - /usr/sbin/config -m LINT TB --- 2012-04-13 19:55:08 - building LINT kernel TB --- 2012-04-13 19:55:08 - CROSS_BUILD_TESTING=YES TB --- 2012-04-13 19:55:08 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-13 19:55:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-13 19:55:08 - SRCCONF=/dev/null TB --- 2012-04-13 19:55:08 - TARGET=pc98 TB --- 2012-04-13 19:55:08 - TARGET_ARCH=i386 TB --- 2012-04-13 19:55:08 - TZ=UTC TB --- 2012-04-13 19:55:08 - __MAKE_CONF=/dev/null TB --- 2012-04-13 19:55:08 - cd /src TB --- 2012-04-13 19:55:08 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Apr 13 19:55:08 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/mxge/mxge_rss_ethp_z8e.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/my/if_my.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/ncv/ncr53c500.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/ncv/ncr53c500_pccard.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/netmap/netmap.c cc1: warnings being treated as errors In file included from /src/sys/dev/netmap/netmap.c:121: /src/sys/dev/netmap/netmap_mem2.c:178: warning: no previous prototype for 'netmap_obj_offset' [-Wmissing-prototypes] *** Error code 1 Stop in /obj/pc98.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-04-13 20:04:27 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-04-13 20:04:27 - ERROR: failed to build LINT kernel TB --- 2012-04-13 20:04:27 - 6340.60 user 932.64 system 8666.66 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Fri Apr 13 20:05:41 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 176371065670; Fri, 13 Apr 2012 20:05:41 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id D9FAF8FC17; Fri, 13 Apr 2012 20:05:40 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q3DK5efh064174; Fri, 13 Apr 2012 16:05:40 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q3DK5eCt064169; Fri, 13 Apr 2012 20:05:40 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 13 Apr 2012 20:05:40 GMT Message-Id: <201204132005.q3DK5eCt064169@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 20:05:41 -0000 TB --- 2012-04-13 17:40:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-04-13 17:40:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-04-13 17:40:00 - starting HEAD tinderbox run for i386/i386 TB --- 2012-04-13 17:40:00 - cleaning the object tree TB --- 2012-04-13 17:40:00 - cvsupping the source tree TB --- 2012-04-13 17:40:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2012-04-13 17:42:13 - building world TB --- 2012-04-13 17:42:13 - CROSS_BUILD_TESTING=YES TB --- 2012-04-13 17:42:13 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-13 17:42:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-13 17:42:13 - SRCCONF=/dev/null TB --- 2012-04-13 17:42:13 - TARGET=i386 TB --- 2012-04-13 17:42:13 - TARGET_ARCH=i386 TB --- 2012-04-13 17:42:13 - TZ=UTC TB --- 2012-04-13 17:42:13 - __MAKE_CONF=/dev/null TB --- 2012-04-13 17:42:13 - cd /src TB --- 2012-04-13 17:42:13 - /usr/bin/make -B buildworld >>> World build started on Fri Apr 13 17:42:15 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 Fri Apr 13 19:54:23 UTC 2012 TB --- 2012-04-13 19:54:23 - generating LINT kernel config TB --- 2012-04-13 19:54:23 - cd /src/sys/i386/conf TB --- 2012-04-13 19:54:23 - /usr/bin/make -B LINT TB --- 2012-04-13 19:54:23 - cd /src/sys/i386/conf TB --- 2012-04-13 19:54:23 - /usr/sbin/config -m LINT TB --- 2012-04-13 19:54:23 - building LINT kernel TB --- 2012-04-13 19:54:23 - CROSS_BUILD_TESTING=YES TB --- 2012-04-13 19:54:23 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-13 19:54:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-13 19:54:23 - SRCCONF=/dev/null TB --- 2012-04-13 19:54:23 - TARGET=i386 TB --- 2012-04-13 19:54:23 - TARGET_ARCH=i386 TB --- 2012-04-13 19:54:23 - TZ=UTC TB --- 2012-04-13 19:54:23 - __MAKE_CONF=/dev/null TB --- 2012-04-13 19:54:23 - cd /src TB --- 2012-04-13 19:54:23 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Apr 13 19:54: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 [...] 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/mxge/mxge_rss_ethp_z8e.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/my/if_my.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/ncv/ncr53c500.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/ncv/ncr53c500_pccard.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/netmap/netmap.c cc1: warnings being treated as errors In file included from /src/sys/dev/netmap/netmap.c:121: /src/sys/dev/netmap/netmap_mem2.c:178: warning: no previous prototype for 'netmap_obj_offset' [-Wmissing-prototypes] *** Error code 1 Stop in /obj/i386.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-04-13 20:05:40 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-04-13 20:05:40 - ERROR: failed to build LINT kernel TB --- 2012-04-13 20:05:40 - 6464.48 user 953.38 system 8739.59 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Fri Apr 13 20:35:23 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mandree.no-ip.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 98763106564A for ; Fri, 13 Apr 2012 20:35:23 +0000 (UTC) (envelope-from mandree@FreeBSD.org) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by apollo.emma.line.org (Postfix) with ESMTP id AC2A923CF8A for ; Fri, 13 Apr 2012 22:35:22 +0200 (CEST) Message-ID: <4F888E0A.4050807@FreeBSD.org> Date: Fri, 13 Apr 2012 22:35:22 +0200 From: Matthias Andree User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Mnenhy/0.8.3 Thunderbird/3.1.20 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4F83FF50.1010404@mail.zedat.fu-berlin.de> In-Reply-To: <4F83FF50.1010404@mail.zedat.fu-berlin.de> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: Changes to sbin/init/init.c (r233944) makes x11/xdm impossible to start from /etc/ttys X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 20:35:23 -0000 > 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 BTW, there is an unrelated xdm error that I'd suggest you report to the xdm maintainer - the exit code cannot be 2560; this means that xdm doesn't process the wait/waitpid/wait3/wait4 status with WIFEXITED/WIFSIGNALED/WEXITSTATUS/WTERMSIG. The exit code was 10 in this situation. (See /usr/include/sys/wait.h) From owner-freebsd-current@FreeBSD.ORG Fri Apr 13 20:37:09 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00FA51065674; Fri, 13 Apr 2012 20:37:09 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id C24178FC1E; Fri, 13 Apr 2012 20:37:08 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q3DKb8Mg023396; Fri, 13 Apr 2012 16:37:08 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q3DKb8VE023385; Fri, 13 Apr 2012 20:37:08 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 13 Apr 2012 20:37:08 GMT Message-Id: <201204132037.q3DKb8VE023385@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 20:37:09 -0000 TB --- 2012-04-13 17:40:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-04-13 17:40:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-04-13 17:40:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2012-04-13 17:40:00 - cleaning the object tree TB --- 2012-04-13 17:40:00 - cvsupping the source tree TB --- 2012-04-13 17:40:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2012-04-13 17:42:39 - building world TB --- 2012-04-13 17:42:39 - CROSS_BUILD_TESTING=YES TB --- 2012-04-13 17:42:39 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-13 17:42:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-13 17:42:39 - SRCCONF=/dev/null TB --- 2012-04-13 17:42:39 - TARGET=amd64 TB --- 2012-04-13 17:42:39 - TARGET_ARCH=amd64 TB --- 2012-04-13 17:42:39 - TZ=UTC TB --- 2012-04-13 17:42:39 - __MAKE_CONF=/dev/null TB --- 2012-04-13 17:42:39 - cd /src TB --- 2012-04-13 17:42:39 - /usr/bin/make -B buildworld >>> World build started on Fri Apr 13 17:42:40 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 Fri Apr 13 20:27:41 UTC 2012 TB --- 2012-04-13 20:27:41 - generating LINT kernel config TB --- 2012-04-13 20:27:41 - cd /src/sys/amd64/conf TB --- 2012-04-13 20:27:41 - /usr/bin/make -B LINT TB --- 2012-04-13 20:27:41 - cd /src/sys/amd64/conf TB --- 2012-04-13 20:27:41 - /usr/sbin/config -m LINT TB --- 2012-04-13 20:27:42 - building LINT kernel TB --- 2012-04-13 20:27:42 - CROSS_BUILD_TESTING=YES TB --- 2012-04-13 20:27:42 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-13 20:27:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-13 20:27:42 - SRCCONF=/dev/null TB --- 2012-04-13 20:27:42 - TARGET=amd64 TB --- 2012-04-13 20:27:42 - TARGET_ARCH=amd64 TB --- 2012-04-13 20:27:42 - TZ=UTC TB --- 2012-04-13 20:27:42 - __MAKE_CONF=/dev/null TB --- 2012-04-13 20:27:42 - cd /src TB --- 2012-04-13 20:27:42 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Apr 13 20:27: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 -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/ncv/ncr53c500_pccard.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/netmap/netmap.c cc1: warnings being treated as errors In file included from /src/sys/dev/netmap/netmap.c:121: /src/sys/dev/netmap/netmap_mem2.c: In function 'netmap_ofstophys': /src/sys/dev/netmap/netmap_mem2.c:164: warning: format '%x' expects type 'unsigned int', but argument 6 has type 'vm_offset_t' [-Wformat] /src/sys/dev/netmap/netmap_mem2.c: At top level: /src/sys/dev/netmap/netmap_mem2.c:178: warning: no previous prototype for 'netmap_obj_offset' [-Wmissing-prototypes] *** Error code 1 Stop in /obj/amd64.amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-04-13 20:37:08 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-04-13 20:37:08 - ERROR: failed to build LINT kernel TB --- 2012-04-13 20:37:08 - 7839.63 user 1257.59 system 10627.50 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Fri Apr 13 20:58:50 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1C9D5106566C for ; Fri, 13 Apr 2012 20:58:50 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id B14E88FC1A for ; Fri, 13 Apr 2012 20:58:49 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1SInZw-0001nr-A4>; Fri, 13 Apr 2012 22:58:48 +0200 Received: from e178041147.adsl.alicedsl.de ([85.178.41.147] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1SInZw-0001IJ-3N>; Fri, 13 Apr 2012 22:58:48 +0200 Message-ID: <4F889381.6090808@zedat.fu-berlin.de> Date: Fri, 13 Apr 2012 22:58:41 +0200 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120314 Thunderbird/10.0.3 MIME-Version: 1.0 To: AN References: In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig797D15B0B817E67021842F7B" X-Originating-IP: 85.178.41.147 Cc: freebsd-current@freebsd.org Subject: Re: kernel build failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 20:58:50 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig797D15B0B817E67021842F7B Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 04/13/12 00:21, schrieb AN: > At Thu Apr 12 17:52:05 EDT 2012: >=20 > [root@FBSD10 /usr/src]# svn up > Updating '.': > At revision 234196. >=20 > Trying to build the kernel I get the following failure: >=20 > time make -j8 buildkernel KERNCONF=3DMYKERNEL >=20 > >=20 > =3D=3D=3D> zlib (all) > cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE > -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include > /usr/obj/usr/src/sys/MYKERNEL/opt_global.h -I. -I@ -I@/contrib/altq > -finline-limit=3D8000 --param inline-unit-growth=3D100 --param > large-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer > -I/usr/obj/usr/src/sys/MYKERNEL -mcmodel=3Dkernel -mno-red-zone -mno-m= mx > -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding > -fstack-protector -std=3Diso9899:1999 -fstack-protector -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 -c /usr/src/sys/modules/zlib/../../net/zlib= =2Ec > ld -d -warn-common -r -d -o zlib.ko.debug zlib.o > :> export_syms > awk -f /usr/src/sys/conf/kmod_syms.awk zlib.ko.debug export_syms | > xargs -J% objcopy % zlib.ko.debug > objcopy --only-keep-debug zlib.ko.debug zlib.ko.symbols > objcopy --strip-debug --add-gnu-debuglink=3Dzlib.ko.symbols zlib.ko.deb= ug > zlib.ko > 1 error > *** [buildkernel] Error code 2 > 1 error > *** [buildkernel] Error code 2 > 1 error >=20 > real 8m20.095s > user 12m37.161s > sys 6m59.844s >=20 > I tried this 4 times, twice with MYKERNEL and twice with GENERIC. It > failed in the same spot every time. Is anyone else seeing this? >=20 > Also, I tried without -j8, and it fails with the following: >=20 > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=3Dc99 -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/usr/src/sys > -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS > -include opt_global.h -fno-common -finline-limit=3D8000 --param > inline-unit-growth=3D100 --param large-function-growth=3D1000 > -fno-omit-frame-pointer -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-s= se > -msoft-float -fno-asynchronous-unwind-tables -ffreestanding > -fstack-protector -Werror /usr/src/sys/kern/subr_turnstile.c > cc1: warnings being treated as errors > /usr/src/sys/kern/subr_turnstile.c: In function 'propagate_priority': > /usr/src/sys/kern/subr_turnstile.c:220: warning: implicit declaration o= f > function 'kdb_backtrace_thread' > /usr/src/sys/kern/subr_turnstile.c:220: warning: nested extern > declaration of 'kdb_backtrace_thread' [-Wnested-externs] > *** [subr_turnstile.o] Error code 1 >=20 > Stop in /usr/obj/usr/src/sys/MYKERNEL. > *** [buildkernel] Error code 1 >=20 > Stop in /usr/src. > *** [buildkernel] Error code 1 >=20 > Stop in /usr/src. >=20 > real 5m19.701s > user 4m33.051s > sys 0m51.466s >=20 >=20 >=20 > Here is /etc/make.conf >=20 > # cat /etc/make.conf > OVERRIDE_LINUX_BASE_PORT=3Df10 > QT4_OPTIONS=3D QGTKSTYLE > WITH_OPENSSL_PORT=3Dyes > # added by use.perl 2012-04-04 01:11:13 > PERL_VERSION=3D5.14.2 >=20 > The kernel previously built without problems with this same configurati= on. > _______________________________________________ clang -c -O2 -pipe -pipe -O3 -fno-strict-aliasing -march=3Dnative -std=3D= 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 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-aes -mno-avx -mcmodel=3Dkernel -mno-red-zone= -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror /usr/src/sys/kern/subr_turnstil= e.c /usr/src/sys/kern/subr_turnstile.c:220:4: error: implicit declaration of function 'kdb_backtrace_thread' is invalid in C99 [-Werror,-Wimplicit-function-declaration] kdb_backtrace_thread(td); ^ 1 error generated. *** [subr_turnstile.o] Error code 1 1 error *** [buildkernel] Error code 2 1 error *** [buildkernel] Error code 2 1 error I still get this error on one of my boxes. Another, with almost the same setup and config, build fine! All systems build with CLANG. They share the same /etc/src.conf and have the same /etc/make.conf. Before building kernel/world, I cleanup/delete /usr/obj. But the error still persists. Regards, Oliver --------------enig797D15B0B817E67021842F7B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJPiJOHAAoJEOgBcD7A/5N8Ep4H/ipXElLO2696Zyxn7ocnigjA 1KabmXKgpOyYU51Mgt6cSZnxM+WnGf3G/Qw34Vn48svo6lIWozLTw2Ekn/hKH3Yg 6ipZ/8iMSdDBYsi07DgvS0nmecgwnX9Q9J+y7WeZS0HffB0dwmdtUV57H5zH41UP pne/PB8BES0zSar+jQcB21TgcVxq1fZNKzouAAPTs/RVLETL+duuLFErQ33vgj88 oYgWGrlBP49y2AQ8M2MhkxD3ovy6qSC2xhB7Vzqjw1AyAtBvFyvJjyJ6E3ocX40s 8uDm4aKNoAFQTLaxI8DukiZa9Umg+VQQNTIGKY8j2Dt8Uw+K2/9fhPwYgqL/6IE= =HJbw -----END PGP SIGNATURE----- --------------enig797D15B0B817E67021842F7B-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 13 21:01:47 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B11B21065676; Fri, 13 Apr 2012 21:01:47 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 632A48FC16; Fri, 13 Apr 2012 21:01:47 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1SInco-000271-Jw>; Fri, 13 Apr 2012 23:01:46 +0200 Received: from e178041147.adsl.alicedsl.de ([85.178.41.147] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1SInco-0001Pc-ET>; Fri, 13 Apr 2012 23:01:46 +0200 Message-ID: <4F88943A.1040302@zedat.fu-berlin.de> Date: Fri, 13 Apr 2012 23:01:46 +0200 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120314 Thunderbird/10.0.3 MIME-Version: 1.0 To: Matthias Andree References: <4F83FF50.1010404@mail.zedat.fu-berlin.de> <4F888E0A.4050807@FreeBSD.org> In-Reply-To: <4F888E0A.4050807@FreeBSD.org> X-Enigmail-Version: 1.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig657340B9FCD2A1387526999B" X-Originating-IP: 85.178.41.147 Cc: freebsd-current@freebsd.org Subject: Re: Changes to sbin/init/init.c (r233944) makes x11/xdm impossible to start from /etc/ttys X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 21:01:47 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig657340B9FCD2A1387526999B Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Am 04/13/12 22:35, schrieb Matthias Andree: >> The error xdm is loggin is: >> >> =3D=3D=3D >> 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, (=3D=3D) default setting,= >> (++) from command line, (!!) notice, (II) informational, >> (WW) warning, (EE) error, (NI) not implemented, (??) unknown. >> (=3D=3D) Log file: "/var/log/Xorg.0.log", Time: Sat Apr 7 18:38:24 20= 12 >> (=3D=3D) 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= >=20 > BTW, there is an unrelated xdm error that I'd suggest you report to the= > xdm maintainer - the exit code cannot be 2560; this means that xdm > doesn't process the wait/waitpid/wait3/wait4 status with > WIFEXITED/WIFSIGNALED/WEXITSTATUS/WTERMSIG. The exit code was 10 in > this situation. (See /usr/include/sys/wait.h) Thank you very much. I already filed an PR (ports/166813), but until now no response. Regards, Oliver --------------enig657340B9FCD2A1387526999B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJPiJQ6AAoJEOgBcD7A/5N8kG4H/0f7tFrIyiT4d5bY5B4dWPGs xWVHTA8EL1tTdTwdy70LKDSX4cg2RYY96bUVux1/qJvv+UXXbdrojRfns6JDbMvW A12Q81Qzchu3q9nmP4T00h+5HSLUa8TCFQKpCK0nmP03haibSmcucoWAIwsNLyrf OFc4RRXxl6mH1wVMFaweHiSZXoGtmfsvDDzM/fXDfXCV4ENMLVU/B4Ja6CgCkfDt i56hWrnfgCJVnTkO/cCoDfZHqBdGJDN0Rays5mjfjTpKxP8eZJEoXv16SFfcESyU hsJ7pCAwbmJRIfJS97akNEZ1KuvN33Yn36m9vcH4M3v5snUU6brJsABAVmm4rE8= =tGID -----END PGP SIGNATURE----- --------------enig657340B9FCD2A1387526999B-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 13 21:35:20 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D9C771065673; Fri, 13 Apr 2012 21:35:20 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 9FB458FC14; Fri, 13 Apr 2012 21:35:20 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q3DLZJ0e013339; Fri, 13 Apr 2012 17:35:19 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q3DLZJdP013338; Fri, 13 Apr 2012 21:35:19 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 13 Apr 2012 21:35:19 GMT Message-Id: <201204132135.q3DLZJdP013338@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 21:35:21 -0000 TB --- 2012-04-13 19:50:56 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-04-13 19:50:56 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-04-13 19:50:56 - starting HEAD tinderbox run for ia64/ia64 TB --- 2012-04-13 19:50:56 - cleaning the object tree TB --- 2012-04-13 19:50:56 - cvsupping the source tree TB --- 2012-04-13 19:50:56 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2012-04-13 19:52:03 - building world TB --- 2012-04-13 19:52:03 - CROSS_BUILD_TESTING=YES TB --- 2012-04-13 19:52:03 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-13 19:52:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-13 19:52:03 - SRCCONF=/dev/null TB --- 2012-04-13 19:52:03 - TARGET=ia64 TB --- 2012-04-13 19:52:03 - TARGET_ARCH=ia64 TB --- 2012-04-13 19:52:03 - TZ=UTC TB --- 2012-04-13 19:52:03 - __MAKE_CONF=/dev/null TB --- 2012-04-13 19:52:03 - cd /src TB --- 2012-04-13 19:52:03 - /usr/bin/make -B buildworld >>> World build started on Fri Apr 13 19:52:04 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 Fri Apr 13 21:25:40 UTC 2012 TB --- 2012-04-13 21:25:40 - generating LINT kernel config TB --- 2012-04-13 21:25:40 - cd /src/sys/ia64/conf TB --- 2012-04-13 21:25:40 - /usr/bin/make -B LINT TB --- 2012-04-13 21:25:40 - cd /src/sys/ia64/conf TB --- 2012-04-13 21:25:40 - /usr/sbin/config -m LINT TB --- 2012-04-13 21:25:40 - building LINT kernel TB --- 2012-04-13 21:25:40 - CROSS_BUILD_TESTING=YES TB --- 2012-04-13 21:25:40 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-13 21:25:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-13 21:25:40 - SRCCONF=/dev/null TB --- 2012-04-13 21:25:40 - TARGET=ia64 TB --- 2012-04-13 21:25:40 - TARGET_ARCH=ia64 TB --- 2012-04-13 21:25:40 - TZ=UTC TB --- 2012-04-13 21:25:40 - __MAKE_CONF=/dev/null TB --- 2012-04-13 21:25:40 - cd /src TB --- 2012-04-13 21:25:40 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Apr 13 21:25:40 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/my/if_my.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/netmap/netmap.c cc1: warnings being treated as errors In file included from /src/sys/dev/netmap/netmap.c:121: /src/sys/dev/netmap/netmap_mem2.c: In function 'netmap_ofstophys': /src/sys/dev/netmap/netmap_mem2.c:164: warning: format '%x' expects type 'unsigned int', but argument 6 has type 'vm_offset_t' [-Wformat] /src/sys/dev/netmap/netmap_mem2.c: At top level: /src/sys/dev/netmap/netmap_mem2.c:178: warning: no previous prototype for 'netmap_obj_offset' [-Wmissing-prototypes] *** Error code 1 Stop in /obj/ia64.ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-04-13 21:35:19 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-04-13 21:35:19 - ERROR: failed to build LINT kernel TB --- 2012-04-13 21:35:19 - 4676.49 user 717.43 system 6263.23 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Fri Apr 13 21:36:44 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 26EE51065676; Fri, 13 Apr 2012 21:36:44 +0000 (UTC) Date: Fri, 13 Apr 2012 21:36:44 +0000 From: Alexander Best To: freebsd-current@freebsd.org Message-ID: <20120413213644.GA92873@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: howto debug a complete hard reset X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 21:36:44 -0000 hi there, i'm running HEAD on amd64 and experienced some really annoying resets during the last couple of months. when i do 'sysctl -a' or 'sysctl -a|grep bla', my whole system does a hard reset. no core dump gets produced. isn't there a way to find out which sysctl variable is causing the reset? cheers. alex From owner-freebsd-current@FreeBSD.ORG Fri Apr 13 22:23:32 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 544851065670; Fri, 13 Apr 2012 22:23:32 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 217E58FC15; Fri, 13 Apr 2012 22:23:32 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q3DMNVS2096741; Fri, 13 Apr 2012 18:23:31 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q3DMNVOM096740; Fri, 13 Apr 2012 22:23:31 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 13 Apr 2012 22:23:31 GMT Message-Id: <201204132223.q3DMNVOM096740@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 22:23:32 -0000 TB --- 2012-04-13 20:05:40 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-04-13 20:05:40 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-04-13 20:05:40 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2012-04-13 20:05:40 - cleaning the object tree TB --- 2012-04-13 20:05:40 - cvsupping the source tree TB --- 2012-04-13 20:05:40 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2012-04-13 20:06:45 - building world TB --- 2012-04-13 20:06:45 - CROSS_BUILD_TESTING=YES TB --- 2012-04-13 20:06:45 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-13 20:06:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-13 20:06:45 - SRCCONF=/dev/null TB --- 2012-04-13 20:06:45 - TARGET=powerpc TB --- 2012-04-13 20:06:45 - TARGET_ARCH=powerpc TB --- 2012-04-13 20:06:45 - TZ=UTC TB --- 2012-04-13 20:06:45 - __MAKE_CONF=/dev/null TB --- 2012-04-13 20:06:45 - cd /src TB --- 2012-04-13 20:06:45 - /usr/bin/make -B buildworld >>> World build started on Fri Apr 13 20:06:46 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 Fri Apr 13 22:18:23 UTC 2012 TB --- 2012-04-13 22:18:23 - generating LINT kernel config TB --- 2012-04-13 22:18:23 - cd /src/sys/powerpc/conf TB --- 2012-04-13 22:18:23 - /usr/bin/make -B LINT TB --- 2012-04-13 22:18:23 - cd /src/sys/powerpc/conf TB --- 2012-04-13 22:18:23 - /usr/sbin/config -m LINT TB --- 2012-04-13 22:18:23 - building LINT kernel TB --- 2012-04-13 22:18:23 - CROSS_BUILD_TESTING=YES TB --- 2012-04-13 22:18:23 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-13 22:18:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-13 22:18:23 - SRCCONF=/dev/null TB --- 2012-04-13 22:18:23 - TARGET=powerpc TB --- 2012-04-13 22:18:23 - TARGET_ARCH=powerpc TB --- 2012-04-13 22:18:23 - TZ=UTC TB --- 2012-04-13 22:18:23 - __MAKE_CONF=/dev/null TB --- 2012-04-13 22:18:23 - cd /src TB --- 2012-04-13 22:18:23 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Apr 13 22:18:24 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/mxge/mxge_ethp_z8e.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/mxge/mxge_rss_eth_z8e.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/mxge/mxge_rss_ethp_z8e.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/my/if_my.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/netmap/netmap.c cc1: warnings being treated as errors In file included from /src/sys/dev/netmap/netmap.c:121: /src/sys/dev/netmap/netmap_mem2.c:178: warning: no previous prototype for 'netmap_obj_offset' [-Wmissing-prototypes] *** Error code 1 Stop in /obj/powerpc.powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-04-13 22:23:31 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-04-13 22:23:31 - ERROR: failed to build LINT kernel TB --- 2012-04-13 22:23:31 - 6519.34 user 887.32 system 8270.89 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Fri Apr 13 22:40:37 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8348F1065676 for ; Fri, 13 Apr 2012 22:40:37 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 3767A8FC15 for ; Fri, 13 Apr 2012 22:40:37 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1SIpAS-0002yD-Au>; Sat, 14 Apr 2012 00:40:36 +0200 Received: from e178041147.adsl.alicedsl.de ([85.178.41.147] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1SIpAS-0005Zc-5n>; Sat, 14 Apr 2012 00:40:36 +0200 Message-ID: <4F88AB5D.1030504@zedat.fu-berlin.de> Date: Sat, 14 Apr 2012 00:40:29 +0200 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120314 Thunderbird/10.0.3 MIME-Version: 1.0 CC: freebsd-current@freebsd.org References: <20120413213644.GA92873@freebsd.org> In-Reply-To: <20120413213644.GA92873@freebsd.org> X-Enigmail-Version: 1.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig01DBF1B359E37398A6CFAC88" X-Originating-IP: 85.178.41.147 Subject: Re: howto debug a complete hard reset X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 22:40:37 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig01DBF1B359E37398A6CFAC88 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 04/13/12 23:36, schrieb Alexander Best: > hi there, >=20 > i'm running HEAD on amd64 and experienced some really annoying resets d= uring > the last couple of months. >=20 > when i do 'sysctl -a' or 'sysctl -a|grep bla', my whole system does a h= ard > reset. no core dump gets produced. >=20 > isn't there a way to find out which sysctl variable is causing the rese= t? >=20 > cheers. > alex I experienced the same behaviour just two days ago. --------------enig01DBF1B359E37398A6CFAC88 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJPiKtjAAoJEOgBcD7A/5N8BnsH/1w0PTcL9paAG+oolsbE+8ft YIO7j4DUEpnCb9KWfvWoA0BLbajP8fwSvSQoPIfQqML7oFLDHE7BGYjGFmO2lPWb ww3KymIt9/0NWmj54gJxeqXrz2mRFjRUMk+9UTUzX+oiJ6Y7ue8obi69MWAKrJqC sfpI/LpMoW2Dmql63hHse88fWXtEEDKCB60M1mKNfUb6/TfQ9J/ntBWlfhyuJ3bb f3pZuG5xr2UT0Wrhqll0KisSKp9ioC5pYHFBY+DUwvDQmVrjyZiZLC3f7m/5JQM9 uDosBeIbaG6NtYeARMqoZ4Jvhu2UZBoIsyzvgHw3GeTI3URvg5Y9UGIrGi6AdVQ= =0kiw -----END PGP SIGNATURE----- --------------enig01DBF1B359E37398A6CFAC88-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 13 22:43:10 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 477DA1065673; Fri, 13 Apr 2012 22:43:10 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id 2675E8FC0C; Fri, 13 Apr 2012 22:43:10 +0000 (UTC) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.5/8.14.5) with ESMTP id q3DMh3KV090272; Fri, 13 Apr 2012 15:43:03 -0700 (PDT) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.5/8.14.5/Submit) id q3DMh3nV090271; Fri, 13 Apr 2012 15:43:03 -0700 (PDT) (envelope-from obrien) Date: Fri, 13 Apr 2012 15:43:03 -0700 From: "David O'Brien" To: jasone@freebsd.org Message-ID: <20120413224303.GA89952@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, jasone@freebsd.org, freebsd-current@freebsd.org References: <431CB493-836B-4DF4-AC42-A7C6ABF7DE3E@canonware.com> <20120412184114.GB71001@dragon.NUXI.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 10.0-CURRENT X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org Subject: Re: contrib/jemalloc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 22:43:10 -0000 On Thu, Apr 12, 2012 at 01:19:56PM -0700, Jason Evans wrote: > On Apr 12, 2012, at 11:41 AM, David O'Brien wrote: > > On Wed, Apr 04, 2012 at 09:56:45PM -0700, Jason Evans wrote: > >> I have the current version of jemalloc integrated into libc as contrib/jemalloc: > >> http://people.freebsd.org/~jasone/patches/jemalloc_20120404b.patch ... > >> * Is it acceptable to check this in directly to trunk without using a > >> vendor branch? For the import workflow I have planned, a vendor branch > >> would just be extra work with no benefit that I can see. > > > > I do not think it is acceptable. Our workflow is to do vendor imports. > > They are invaluable in tracking down history and changes years after the > > fact. They are also very valuable to commercial third-parties that > > consume FreeBSD into their products (I speak for Juniper Networks in > > this). > > > > Why do you feel they are [measurably] extra work with no benefit? > > The workflow I'm using is documented in the patch > (contrib/jemalloc/FREEBSD-upgrade). Can you tell me how to achieve a > similarly streamlined import flow with a vendor branch in the mix? Hi Jason, It looks like you could run './FREEBSD-upgrade extract' from a check out of ssh://svn.freebsd.org/base/vendor/jemalloc. I'm unclear what the './FREEBSD-upgrade rediff' step is for. I'm having trouble following what "then regenerate diffs to update line offsets" is for. How do you handle the difference between FreeBSD having include/malloc_np.h and your GIT repo having jemalloc/include/jemalloc/jemalloc.h[.in]? Does './FREEBSD-upgrade extract' or './FREEBSD-upgrade rediff' patch 'include/malloc_np.h' and 'include/stdlib.h'? Especially with the '#define JEMALLOC_P(s) s' wrapping. Is that part of the './FREEBSD-upgrade rediff' step? Can you nudge me in the right direction to understanding this workflow? Typically the tracking of diffs between what's in your vendor GIT repo and FreeBSD comes from the FreeBSD SCM system. A combination of 'svn diff ^/vendor/jemalloc/dist ^/head/contrib/jemalloc' and 'cd contrib/jemalloc && svn merge ^/vendor/jemalloc/dist'. > Also, what history would a vendor branch preserve that this workflow > does not? contrib/jemalloc/FREEBSD-upgrade doesn't describe the "commit into FreeBSD subversion repo" step, that I can see. So I am not sure what gets committed vs. what's in git://canonware.com/jemalloc.git. > The only upside to vendor branch merges I can think of is > that if any jemalloc sources were manually modified between imports, > merging would fail rather than silently overwriting the changes. I feel that is an important check-and-balance. Not following our established procedure also means that the average developer(committer) and commercial consumer will have their expectations fails. One expects to be able to find the stock vendor sources in ssh://svn.freebsd.org/base/vendor/ and to be able to find FreeBSD local changes to the sources thru 'svn diff' against ssh://obrien@svn.freebsd.org/base. > However, this presumes that changes aren't making it upstream. That is not an unreasonable presumption. Unless contrib/jemalloc/ is locked so that you are aware of every commit FreeBSD and git://canonware.com/jemalloc.git can diverge at times. -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Fri Apr 13 22:46:47 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EDDDC106566C; Fri, 13 Apr 2012 22:46:47 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id B5D268FC14; Fri, 13 Apr 2012 22:46:47 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q3DMkkaU080761; Fri, 13 Apr 2012 18:46:46 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q3DMkk4G080760; Fri, 13 Apr 2012 22:46:46 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 13 Apr 2012 22:46:46 GMT Message-Id: <201204132246.q3DMkk4G080760@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 22:46:48 -0000 TB --- 2012-04-13 21:35:20 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-04-13 21:35:20 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-04-13 21:35:20 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2012-04-13 21:35:20 - cleaning the object tree TB --- 2012-04-13 21:35:20 - cvsupping the source tree TB --- 2012-04-13 21:35:20 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2012-04-13 21:35:50 - building world TB --- 2012-04-13 21:35:50 - CROSS_BUILD_TESTING=YES TB --- 2012-04-13 21:35:50 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-13 21:35:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-13 21:35:50 - SRCCONF=/dev/null TB --- 2012-04-13 21:35:50 - TARGET=sparc64 TB --- 2012-04-13 21:35:50 - TARGET_ARCH=sparc64 TB --- 2012-04-13 21:35:50 - TZ=UTC TB --- 2012-04-13 21:35:50 - __MAKE_CONF=/dev/null TB --- 2012-04-13 21:35:50 - cd /src TB --- 2012-04-13 21:35:50 - /usr/bin/make -B buildworld >>> World build started on Fri Apr 13 21:35:51 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 Fri Apr 13 22:40:37 UTC 2012 TB --- 2012-04-13 22:40:37 - generating LINT kernel config TB --- 2012-04-13 22:40:37 - cd /src/sys/sparc64/conf TB --- 2012-04-13 22:40:37 - /usr/bin/make -B LINT TB --- 2012-04-13 22:40:37 - cd /src/sys/sparc64/conf TB --- 2012-04-13 22:40:37 - /usr/sbin/config -m LINT TB --- 2012-04-13 22:40:37 - building LINT kernel TB --- 2012-04-13 22:40:37 - CROSS_BUILD_TESTING=YES TB --- 2012-04-13 22:40:37 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-13 22:40:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-13 22:40:37 - SRCCONF=/dev/null TB --- 2012-04-13 22:40:37 - TARGET=sparc64 TB --- 2012-04-13 22:40:37 - TARGET_ARCH=sparc64 TB --- 2012-04-13 22:40:37 - TZ=UTC TB --- 2012-04-13 22:40:37 - __MAKE_CONF=/dev/null TB --- 2012-04-13 22:40:37 - cd /src TB --- 2012-04-13 22:40:37 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Apr 13 22:40:37 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/my/if_my.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/netmap/netmap.c cc1: warnings being treated as errors In file included from /src/sys/dev/netmap/netmap.c:121: /src/sys/dev/netmap/netmap_mem2.c: In function 'netmap_ofstophys': /src/sys/dev/netmap/netmap_mem2.c:164: warning: format '%x' expects type 'unsigned int', but argument 6 has type 'vm_offset_t' [-Wformat] /src/sys/dev/netmap/netmap_mem2.c: At top level: /src/sys/dev/netmap/netmap_mem2.c:178: warning: no previous prototype for 'netmap_obj_offset' [-Wmissing-prototypes] *** Error code 1 Stop in /obj/sparc64.sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-04-13 22:46:46 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-04-13 22:46:46 - ERROR: failed to build LINT kernel TB --- 2012-04-13 22:46:46 - 3254.24 user 559.10 system 4286.62 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Fri Apr 13 23:18:23 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 223F81065670; Fri, 13 Apr 2012 23:18:23 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id DD2DC8FC12; Fri, 13 Apr 2012 23:18:22 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q3DNIMct068915; Fri, 13 Apr 2012 19:18:22 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q3DNIMdG068914; Fri, 13 Apr 2012 23:18:22 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 13 Apr 2012 23:18:22 GMT Message-Id: <201204132318.q3DNIMdG068914@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 23:18:23 -0000 TB --- 2012-04-13 20:37:08 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-04-13 20:37:08 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-04-13 20:37:08 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2012-04-13 20:37:08 - cleaning the object tree TB --- 2012-04-13 20:37:08 - cvsupping the source tree TB --- 2012-04-13 20:37:08 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2012-04-13 20:39:02 - building world TB --- 2012-04-13 20:39:02 - CROSS_BUILD_TESTING=YES TB --- 2012-04-13 20:39:02 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-13 20:39:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-13 20:39:02 - SRCCONF=/dev/null TB --- 2012-04-13 20:39:02 - TARGET=powerpc TB --- 2012-04-13 20:39:02 - TARGET_ARCH=powerpc64 TB --- 2012-04-13 20:39:02 - TZ=UTC TB --- 2012-04-13 20:39:02 - __MAKE_CONF=/dev/null TB --- 2012-04-13 20:39:02 - cd /src TB --- 2012-04-13 20:39:02 - /usr/bin/make -B buildworld >>> World build started on Fri Apr 13 20:39:04 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 Fri Apr 13 23:13:29 UTC 2012 TB --- 2012-04-13 23:13:29 - generating LINT kernel config TB --- 2012-04-13 23:13:29 - cd /src/sys/powerpc/conf TB --- 2012-04-13 23:13:29 - /usr/bin/make -B LINT TB --- 2012-04-13 23:13:29 - cd /src/sys/powerpc/conf TB --- 2012-04-13 23:13:29 - /usr/sbin/config -m LINT TB --- 2012-04-13 23:13:29 - building LINT kernel TB --- 2012-04-13 23:13:29 - CROSS_BUILD_TESTING=YES TB --- 2012-04-13 23:13:29 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-13 23:13:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-13 23:13:29 - SRCCONF=/dev/null TB --- 2012-04-13 23:13:29 - TARGET=powerpc TB --- 2012-04-13 23:13:29 - TARGET_ARCH=powerpc64 TB --- 2012-04-13 23:13:29 - TZ=UTC TB --- 2012-04-13 23:13:29 - __MAKE_CONF=/dev/null TB --- 2012-04-13 23:13:29 - cd /src TB --- 2012-04-13 23:13:29 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Apr 13 23:13:29 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/my/if_my.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/netmap/netmap.c cc1: warnings being treated as errors In file included from /src/sys/dev/netmap/netmap.c:121: /src/sys/dev/netmap/netmap_mem2.c: In function 'netmap_ofstophys': /src/sys/dev/netmap/netmap_mem2.c:164: warning: format '%x' expects type 'unsigned int', but argument 6 has type 'vm_offset_t' [-Wformat] /src/sys/dev/netmap/netmap_mem2.c: At top level: /src/sys/dev/netmap/netmap_mem2.c:178: warning: no previous prototype for 'netmap_obj_offset' [-Wmissing-prototypes] *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-04-13 23:18:22 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-04-13 23:18:22 - ERROR: failed to build LINT kernel TB --- 2012-04-13 23:18:22 - 7923.76 user 1066.45 system 9673.74 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sat Apr 14 02:07:27 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F9361065791; Sat, 14 Apr 2012 02:07:26 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id F10F78FC08; Sat, 14 Apr 2012 02:07:25 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q3E27Pjq041879; Fri, 13 Apr 2012 22:07:25 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q3E27PQJ041878; Sat, 14 Apr 2012 02:07:25 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 14 Apr 2012 02:07:25 GMT Message-Id: <201204140207.q3E27PQJ041878@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 02:07:27 -0000 TB --- 2012-04-13 23:20:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-04-13 23:20:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-04-13 23:20:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2012-04-13 23:20:00 - cleaning the object tree TB --- 2012-04-13 23:27:48 - cvsupping the source tree TB --- 2012-04-13 23:27:48 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2012-04-13 23:30:18 - building world TB --- 2012-04-13 23:30:18 - CROSS_BUILD_TESTING=YES TB --- 2012-04-13 23:30:18 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-13 23:30:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-13 23:30:18 - SRCCONF=/dev/null TB --- 2012-04-13 23:30:18 - TARGET=pc98 TB --- 2012-04-13 23:30:18 - TARGET_ARCH=i386 TB --- 2012-04-13 23:30:18 - TZ=UTC TB --- 2012-04-13 23:30:18 - __MAKE_CONF=/dev/null TB --- 2012-04-13 23:30:18 - cd /src TB --- 2012-04-13 23:30:18 - /usr/bin/make -B buildworld >>> World build started on Fri Apr 13 23:30:19 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 Sat Apr 14 01:45:05 UTC 2012 TB --- 2012-04-14 01:45:05 - generating LINT kernel config TB --- 2012-04-14 01:45:05 - cd /src/sys/pc98/conf TB --- 2012-04-14 01:45:05 - /usr/bin/make -B LINT TB --- 2012-04-14 01:45:05 - cd /src/sys/pc98/conf TB --- 2012-04-14 01:45:05 - /usr/sbin/config -m LINT TB --- 2012-04-14 01:45:05 - building LINT kernel TB --- 2012-04-14 01:45:05 - CROSS_BUILD_TESTING=YES TB --- 2012-04-14 01:45:05 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-14 01:45:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-14 01:45:05 - SRCCONF=/dev/null TB --- 2012-04-14 01:45:05 - TARGET=pc98 TB --- 2012-04-14 01:45:05 - TARGET_ARCH=i386 TB --- 2012-04-14 01:45:05 - TZ=UTC TB --- 2012-04-14 01:45:05 - __MAKE_CONF=/dev/null TB --- 2012-04-14 01:45:05 - cd /src TB --- 2012-04-14 01:45:05 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Apr 14 01:45:05 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 [...] ld -Bshareable -d -warn-common -o ip_mroute.ko ip_mroute.kld objcopy --strip-debug ip_mroute.ko ===> iscsi (all) ===> iscsi/initiator (all) cc -O2 -pipe -DISCSI_INITIATOR_DEBUG=2 -DINVARIANTS -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/iscsi/initiator/../../.. -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98.i386/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/pc98.i386/src/sys/LINT -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -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 -c /src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/iscsi.c In file included from /src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/iscsi.c:34: ./opt_iscsi_initiator.h:1:1: error: "ISCSI_INITIATOR_DEBUG" redefined : error: this is the location of the previous definition *** Error code 1 Stop in /src/sys/modules/iscsi/initiator. *** Error code 1 Stop in /src/sys/modules/iscsi. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/pc98.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-04-14 02:07:24 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-04-14 02:07:24 - ERROR: failed to build LINT kernel TB --- 2012-04-14 02:07:24 - 7057.16 user 1020.60 system 10044.19 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sat Apr 14 00:44:32 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 07B6F106564A for ; Sat, 14 Apr 2012 00:44:32 +0000 (UTC) (envelope-from kwhite@site.uottawa.ca) Received: from courriel.site.uottawa.ca (eecsmail.engineering.uottawa.ca [137.122.24.224]) by mx1.freebsd.org (Postfix) with ESMTP id B52F58FC0C for ; Sat, 14 Apr 2012 00:44:31 +0000 (UTC) Received: from courriel.site.uottawa.ca (localhost [127.0.0.1]) by courriel.site.uottawa.ca (8.14.4/8.14.4) with ESMTP id q3E0iPSJ086294 for ; Fri, 13 Apr 2012 20:44:25 -0400 (EDT) (envelope-from kwhite@site.uottawa.ca) Received: from 74.51.53.177 (SquirrelMail authenticated user kwhite) by courriel.site.uottawa.ca with HTTP; Fri, 13 Apr 2012 20:44:25 -0400 (EDT) Message-ID: <31940.74.51.53.177.1334364265.squirrel@courriel.site.uottawa.ca> Date: Fri, 13 Apr 2012 20:44:25 -0400 (EDT) From: kwhite@site.uottawa.ca To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.5 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mailman-Approved-At: Sat, 14 Apr 2012 02:10:10 +0000 Subject: r234118 uart kernel module failure: "uart_cpu_eqres undefined" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 00:44:32 -0000 The change from sys/dev/uart/uart_cpu_{i386,amd64}.c to uart_cpu_x86.c probably also needs a corresponding change in the module Makefile. # kldload uart link_elf: symbol uart_cpu_eqres undefined Here's one suggestion that works for me: Index: /sys/modules/uart/Makefile =================================================================== --- /sys/modules/uart/Makefile (revision 234249) +++ /sys/modules/uart/Makefile (working copy) @@ -16,6 +16,8 @@ uart_if.c uart_if.h uart_subr.c uart_tty.c .if exists(${.CURDIR}/../../dev/uart/uart_cpu_${MACHINE}.c) SRCS+= uart_cpu_${MACHINE}.c +.elif ${MACHINE} == "i386" || ${MACHINE} == "amd64" +SRCS+= uart_cpu_x86.c .endif SRCS+= bus_if.h card_if.h device_if.h isa_if.h ${ofw_bus_if} pci_if.h \ power_if.h pccarddevs.h serdev_if.h ------------------------------------------------------------------------ ...keith From owner-freebsd-current@FreeBSD.ORG Sat Apr 14 02:12:21 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7BCA106564A; Sat, 14 Apr 2012 02:12:21 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 96CB78FC1C; Sat, 14 Apr 2012 02:12:21 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q3E2CLLo075161; Fri, 13 Apr 2012 22:12:21 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q3E2CLpd075154; Sat, 14 Apr 2012 02:12:21 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 14 Apr 2012 02:12:21 GMT Message-Id: <201204140212.q3E2CLpd075154@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 02:12:21 -0000 TB --- 2012-04-13 23:20:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-04-13 23:20:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-04-13 23:20:00 - starting HEAD tinderbox run for i386/i386 TB --- 2012-04-13 23:20:00 - cleaning the object tree TB --- 2012-04-13 23:28:21 - cvsupping the source tree TB --- 2012-04-13 23:28:21 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2012-04-13 23:30:37 - building world TB --- 2012-04-13 23:30:37 - CROSS_BUILD_TESTING=YES TB --- 2012-04-13 23:30:37 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-13 23:30:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-13 23:30:37 - SRCCONF=/dev/null TB --- 2012-04-13 23:30:37 - TARGET=i386 TB --- 2012-04-13 23:30:37 - TARGET_ARCH=i386 TB --- 2012-04-13 23:30:37 - TZ=UTC TB --- 2012-04-13 23:30:37 - __MAKE_CONF=/dev/null TB --- 2012-04-13 23:30:37 - cd /src TB --- 2012-04-13 23:30:37 - /usr/bin/make -B buildworld >>> World build started on Fri Apr 13 23:30:38 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 Sat Apr 14 01:45:26 UTC 2012 TB --- 2012-04-14 01:45:26 - generating LINT kernel config TB --- 2012-04-14 01:45:26 - cd /src/sys/i386/conf TB --- 2012-04-14 01:45:26 - /usr/bin/make -B LINT TB --- 2012-04-14 01:45:27 - cd /src/sys/i386/conf TB --- 2012-04-14 01:45:27 - /usr/sbin/config -m LINT TB --- 2012-04-14 01:45:27 - building LINT kernel TB --- 2012-04-14 01:45:27 - CROSS_BUILD_TESTING=YES TB --- 2012-04-14 01:45:27 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-14 01:45:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-14 01:45:27 - SRCCONF=/dev/null TB --- 2012-04-14 01:45:27 - TARGET=i386 TB --- 2012-04-14 01:45:27 - TARGET_ARCH=i386 TB --- 2012-04-14 01:45:27 - TZ=UTC TB --- 2012-04-14 01:45:27 - __MAKE_CONF=/dev/null TB --- 2012-04-14 01:45:27 - cd /src TB --- 2012-04-14 01:45:27 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Apr 14 01:45:27 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 [...] ld -Bshareable -d -warn-common -o isci.ko isci.kld objcopy --strip-debug isci.ko ===> iscsi (all) ===> iscsi/initiator (all) cc -O2 -pipe -DISCSI_INITIATOR_DEBUG=2 -DINVARIANTS -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/iscsi/initiator/../../.. -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386.i386/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/i386.i386/src/sys/LINT -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -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 -c /src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/iscsi.c In file included from /src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/iscsi.c:34: ./opt_iscsi_initiator.h:1:1: error: "ISCSI_INITIATOR_DEBUG" redefined : error: this is the location of the previous definition *** Error code 1 Stop in /src/sys/modules/iscsi/initiator. *** Error code 1 Stop in /src/sys/modules/iscsi. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/i386.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-04-14 02:12:21 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-04-14 02:12:21 - ERROR: failed to build LINT kernel TB --- 2012-04-14 02:12:21 - 7329.12 user 1048.51 system 10340.32 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sat Apr 14 02:31:29 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94812106566B; Sat, 14 Apr 2012 02:31:29 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 5B91A8FC14; Sat, 14 Apr 2012 02:31:29 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q3E2VSHr034525; Fri, 13 Apr 2012 22:31:28 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q3E2VSV8034522; Sat, 14 Apr 2012 02:31:28 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 14 Apr 2012 02:31:28 GMT Message-Id: <201204140231.q3E2VSV8034522@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 02:31:29 -0000 TB --- 2012-04-13 23:20:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-04-13 23:20:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-04-13 23:20:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2012-04-13 23:20:00 - cleaning the object tree TB --- 2012-04-13 23:30:58 - cvsupping the source tree TB --- 2012-04-13 23:30:58 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2012-04-13 23:31:29 - building world TB --- 2012-04-13 23:31:29 - CROSS_BUILD_TESTING=YES TB --- 2012-04-13 23:31:29 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-13 23:31:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-13 23:31:29 - SRCCONF=/dev/null TB --- 2012-04-13 23:31:29 - TARGET=amd64 TB --- 2012-04-13 23:31:29 - TARGET_ARCH=amd64 TB --- 2012-04-13 23:31:29 - TZ=UTC TB --- 2012-04-13 23:31:29 - __MAKE_CONF=/dev/null TB --- 2012-04-13 23:31:29 - cd /src TB --- 2012-04-13 23:31:29 - /usr/bin/make -B buildworld >>> World build started on Fri Apr 13 23:31:30 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 Sat Apr 14 02:20:28 UTC 2012 TB --- 2012-04-14 02:20:28 - generating LINT kernel config TB --- 2012-04-14 02:20:28 - cd /src/sys/amd64/conf TB --- 2012-04-14 02:20:28 - /usr/bin/make -B LINT TB --- 2012-04-14 02:20:28 - cd /src/sys/amd64/conf TB --- 2012-04-14 02:20:28 - /usr/sbin/config -m LINT TB --- 2012-04-14 02:20:28 - building LINT kernel TB --- 2012-04-14 02:20:28 - CROSS_BUILD_TESTING=YES TB --- 2012-04-14 02:20:28 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-14 02:20:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-14 02:20:28 - SRCCONF=/dev/null TB --- 2012-04-14 02:20:28 - TARGET=amd64 TB --- 2012-04-14 02:20:28 - TARGET_ARCH=amd64 TB --- 2012-04-14 02:20:28 - TZ=UTC TB --- 2012-04-14 02:20:28 - __MAKE_CONF=/dev/null TB --- 2012-04-14 02:20:28 - cd /src TB --- 2012-04-14 02:20:28 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Apr 14 02:20:28 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/my/if_my.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/ncv/ncr53c500.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/ncv/ncr53c500_pccard.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/netmap/netmap.c cc1: warnings being treated as errors In file included from /src/sys/dev/netmap/netmap.c:121: /src/sys/dev/netmap/netmap_mem2.c: In function 'netmap_ofstophys': /src/sys/dev/netmap/netmap_mem2.c:164: warning: format '%x' expects type 'unsigned int', but argument 6 has type 'vm_offset_t' [-Wformat] *** Error code 1 Stop in /obj/amd64.amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-04-14 02:31:28 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-04-14 02:31:28 - ERROR: failed to build LINT kernel TB --- 2012-04-14 02:31:28 - 7937.37 user 1271.56 system 11487.92 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Sat Apr 14 02:34:38 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F11A1106566B; Sat, 14 Apr 2012 02:34:38 +0000 (UTC) (envelope-from jasone@canonware.com) Received: from canonware.com (10140.x.rootbsd.net [204.109.63.53]) by mx1.freebsd.org (Postfix) with ESMTP id CC5D18FC17; Sat, 14 Apr 2012 02:34:38 +0000 (UTC) Received: from [192.168.168.4] (70-91-206-178-BusName-SFBA.hfc.comcastbusiness.net [70.91.206.178]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by canonware.com (Postfix) with ESMTPSA id 461CF28419; Fri, 13 Apr 2012 19:34:32 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Jason Evans In-Reply-To: <20120413224303.GA89952@dragon.NUXI.org> Date: Fri, 13 Apr 2012 19:34:30 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <56C2E1FF-DEC4-47DA-A23B-BF81F5EE26FE@canonware.com> References: <431CB493-836B-4DF4-AC42-A7C6ABF7DE3E@canonware.com> <20120412184114.GB71001@dragon.NUXI.org> <20120413224303.GA89952@dragon.NUXI.org> To: obrien@freebsd.org X-Mailer: Apple Mail (2.1257) Cc: freebsd-current@freebsd.org Subject: Re: contrib/jemalloc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jasone@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 02:34:39 -0000 On Apr 13, 2012, at 3:43 PM, David O'Brien wrote: > On Thu, Apr 12, 2012 at 01:19:56PM -0700, Jason Evans wrote: >> On Apr 12, 2012, at 11:41 AM, David O'Brien wrote: > It looks like you could run './FREEBSD-upgrade extract' from a check = out > of ssh://svn.freebsd.org/base/vendor/jemalloc. >=20 > I'm unclear what the './FREEBSD-upgrade rediff' step is for. I'm = having > trouble following what "then regenerate diffs to update line offsets" = is > for. The 'rediff' step regenerates the diff so that it precisely matches the = differences as they apply to the code about to be imported. If this = step were omitted, patch fuzz would accumulate in FREEBSD-diffs. > How do you handle the difference between FreeBSD having > include/malloc_np.h and your GIT repo having > jemalloc/include/jemalloc/jemalloc.h[.in]? >=20 > Does './FREEBSD-upgrade extract' or './FREEBSD-upgrade rediff' patch > 'include/malloc_np.h' and 'include/stdlib.h'? > Especially with the '#define JEMALLOC_P(s) s' wrapping. > Is that part of the './FREEBSD-upgrade rediff' step? stdlib.h+malloc_np.h and jemalloc.h are different enough that they = require separate maintenance. Alas, not all programming can be = automated; if interfaces change, manual intervention is required. > contrib/jemalloc/FREEBSD-upgrade doesn't describe the "commit into > FreeBSD subversion repo" step, that I can see. So I am not sure what > gets committed vs. what's in git://canonware.com/jemalloc.git. Every difference that remains in the tree afterwards is to be committed. = That might require some 'svn add' and/or 'svn rm' commands prior to = 'svn commit'. >> The only upside to vendor branch merges I can think of is >> that if any jemalloc sources were manually modified between imports, >> merging would fail rather than silently overwriting the changes. >=20 > I feel that is an important check-and-balance. >=20 > Not following our established procedure also means that the average > developer(committer) and commercial consumer will have their = expectations > fails. One expects to be able to find the stock vendor sources in > ssh://svn.freebsd.org/base/vendor/ and to be able to find FreeBSD = local > changes to the sources thru 'svn diff' against > ssh://obrien@svn.freebsd.org/base. Regarding established procedure, I read through several of the = contrib/*/FREEBSD-upgrade files when trying to understand established = procedure, and the conclusion I came to is that many of the vendor = imports would be painful for a new person to take over. In contrast, = contrib/jemalloc/FREEBSD-upgrade provides nearly complete automation, = and documentation on how to deal with the manual parts of the process, = should the need arise. >> However, this presumes that changes aren't making it upstream. >=20 > That is not an unreasonable presumption. Unless contrib/jemalloc/ > is locked so that you are aware of every commit FreeBSD and > git://canonware.com/jemalloc.git can diverge at times. Today I updated the FREEBSD-upgrade script to take care of this = possibility. = http://people.freebsd.org/~jasone/patches/jemalloc_20120413a.patch One problem that doesn't fit neatly into the standard vendor import = procedure is that jemalloc.3 is a generated file. It isn't feasible to = keep FreeBSD-specific changes out of the vendor branch unless jemalloc's = build system is imported, or manual changes are made directly to the = generated file (yuck). In contrast, the FREEBSD-upgrade script leaves = all non-essential files out of the imports, resulting in a cleaner = import. Imagine we're looking at the svn history three years from now, and I've = croaked, leaving the FreeBSD copy of jemalloc to drift where it will. = svn might contain something like the following sequence of relevant = commits: - (jasone) Import jemalloc 7ca0fdfb85b2a9fc7a112e158892c098e004385b. - (jasone) Import jemalloc [some other git rev]. - (jasone) Import jemalloc [some other git rev]. - (jasone) Import jemalloc 3.0.0. - (jasone) Import jemalloc 3.0.1. - (obrien) Fix aligned_alloc() to stop snatching helpless children. - (jasone) Import jemalloc 3.2.0. - (obrien) Stop protecting children; they're not as helpless as they = appear. - (obrien) Import jemalloc 3.2.1. May jasone RIP. - (obrien) This allocator sucks. Gut it. What gets lost? As near as I can tell, the svn history tells the whole = story, and 'svn blame' even reflects FreeBSD-specific changes that = weren't made as part of an import commit (and FREEBSD-diffs provides a = full audit trail for those). It's worth mentioning that the less work imports are, the more often I = will be able to do them. I've put several days of effort into = streamlining this process so that FreeBSD's jemalloc won't languish. = I've been working more or less full time on jemalloc for the past six = weeks (thanks Facebook!), but I really have to wrap this up and get back = to other projects. Jason= From owner-freebsd-current@FreeBSD.ORG Sat Apr 14 03:22:48 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86AD7106566C; Sat, 14 Apr 2012 03:22:48 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 4E5288FC08; Sat, 14 Apr 2012 03:22:48 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q3E3MlCL025042; Fri, 13 Apr 2012 23:22:47 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q3E3MlP4025037; Sat, 14 Apr 2012 03:22:47 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 14 Apr 2012 03:22:47 GMT Message-Id: <201204140322.q3E3MlP4025037@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 03:22:48 -0000 TB --- 2012-04-14 01:36:50 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-04-14 01:36:50 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-04-14 01:36:50 - starting HEAD tinderbox run for ia64/ia64 TB --- 2012-04-14 01:36:50 - cleaning the object tree TB --- 2012-04-14 01:38:06 - cvsupping the source tree TB --- 2012-04-14 01:38:06 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2012-04-14 01:38:53 - building world TB --- 2012-04-14 01:38:53 - CROSS_BUILD_TESTING=YES TB --- 2012-04-14 01:38:53 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-14 01:38:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-14 01:38:53 - SRCCONF=/dev/null TB --- 2012-04-14 01:38:53 - TARGET=ia64 TB --- 2012-04-14 01:38:53 - TARGET_ARCH=ia64 TB --- 2012-04-14 01:38:53 - TZ=UTC TB --- 2012-04-14 01:38:53 - __MAKE_CONF=/dev/null TB --- 2012-04-14 01:38:53 - cd /src TB --- 2012-04-14 01:38:53 - /usr/bin/make -B buildworld >>> World build started on Sat Apr 14 01:38:54 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 Sat Apr 14 03:13:06 UTC 2012 TB --- 2012-04-14 03:13:06 - generating LINT kernel config TB --- 2012-04-14 03:13:06 - cd /src/sys/ia64/conf TB --- 2012-04-14 03:13:06 - /usr/bin/make -B LINT TB --- 2012-04-14 03:13:06 - cd /src/sys/ia64/conf TB --- 2012-04-14 03:13:06 - /usr/sbin/config -m LINT TB --- 2012-04-14 03:13:06 - building LINT kernel TB --- 2012-04-14 03:13:06 - CROSS_BUILD_TESTING=YES TB --- 2012-04-14 03:13:06 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-14 03:13:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-14 03:13:06 - SRCCONF=/dev/null TB --- 2012-04-14 03:13:06 - TARGET=ia64 TB --- 2012-04-14 03:13:06 - TARGET_ARCH=ia64 TB --- 2012-04-14 03:13:06 - TZ=UTC TB --- 2012-04-14 03:13:06 - __MAKE_CONF=/dev/null TB --- 2012-04-14 03:13:06 - cd /src TB --- 2012-04-14 03:13:06 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Apr 14 03:13:07 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/mxge/mxge_rss_eth_z8e.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/mxge/mxge_rss_ethp_z8e.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/my/if_my.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/netmap/netmap.c cc1: warnings being treated as errors In file included from /src/sys/dev/netmap/netmap.c:121: /src/sys/dev/netmap/netmap_mem2.c: In function 'netmap_ofstophys': /src/sys/dev/netmap/netmap_mem2.c:164: warning: format '%x' expects type 'unsigned int', but argument 6 has type 'vm_offset_t' [-Wformat] *** Error code 1 Stop in /obj/ia64.ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-04-14 03:22:47 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-04-14 03:22:47 - ERROR: failed to build LINT kernel TB --- 2012-04-14 03:22:47 - 4680.16 user 715.30 system 6356.91 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sat Apr 14 04:36:37 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35ED0106564A; Sat, 14 Apr 2012 04:36:37 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 05E578FC12; Sat, 14 Apr 2012 04:36:36 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q3E4aa6M018498; Sat, 14 Apr 2012 00:36:36 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q3E4aaW2018497; Sat, 14 Apr 2012 04:36:36 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 14 Apr 2012 04:36:36 GMT Message-Id: <201204140436.q3E4aaW2018497@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 04:36:37 -0000 TB --- 2012-04-14 03:22:47 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-04-14 03:22:47 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-04-14 03:22:47 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2012-04-14 03:22:47 - cleaning the object tree TB --- 2012-04-14 03:24:10 - cvsupping the source tree TB --- 2012-04-14 03:24:10 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2012-04-14 03:24:39 - building world TB --- 2012-04-14 03:24:39 - CROSS_BUILD_TESTING=YES TB --- 2012-04-14 03:24:39 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-14 03:24:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-14 03:24:39 - SRCCONF=/dev/null TB --- 2012-04-14 03:24:39 - TARGET=sparc64 TB --- 2012-04-14 03:24:39 - TARGET_ARCH=sparc64 TB --- 2012-04-14 03:24:39 - TZ=UTC TB --- 2012-04-14 03:24:39 - __MAKE_CONF=/dev/null TB --- 2012-04-14 03:24:39 - cd /src TB --- 2012-04-14 03:24:39 - /usr/bin/make -B buildworld >>> World build started on Sat Apr 14 03:24:40 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 Sat Apr 14 04:29:58 UTC 2012 TB --- 2012-04-14 04:29:58 - generating LINT kernel config TB --- 2012-04-14 04:29:58 - cd /src/sys/sparc64/conf TB --- 2012-04-14 04:29:58 - /usr/bin/make -B LINT TB --- 2012-04-14 04:29:58 - cd /src/sys/sparc64/conf TB --- 2012-04-14 04:29:58 - /usr/sbin/config -m LINT TB --- 2012-04-14 04:29:59 - building LINT kernel TB --- 2012-04-14 04:29:59 - CROSS_BUILD_TESTING=YES TB --- 2012-04-14 04:29:59 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-14 04:29:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-14 04:29:59 - SRCCONF=/dev/null TB --- 2012-04-14 04:29:59 - TARGET=sparc64 TB --- 2012-04-14 04:29:59 - TARGET_ARCH=sparc64 TB --- 2012-04-14 04:29:59 - TZ=UTC TB --- 2012-04-14 04:29:59 - __MAKE_CONF=/dev/null TB --- 2012-04-14 04:29:59 - cd /src TB --- 2012-04-14 04:29:59 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Apr 14 04:29:59 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/mxge/mxge_rss_eth_z8e.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/mxge/mxge_rss_ethp_z8e.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/my/if_my.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/netmap/netmap.c cc1: warnings being treated as errors In file included from /src/sys/dev/netmap/netmap.c:121: /src/sys/dev/netmap/netmap_mem2.c: In function 'netmap_ofstophys': /src/sys/dev/netmap/netmap_mem2.c:164: warning: format '%x' expects type 'unsigned int', but argument 6 has type 'vm_offset_t' [-Wformat] *** Error code 1 Stop in /obj/sparc64.sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-04-14 04:36:36 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-04-14 04:36:36 - ERROR: failed to build LINT kernel TB --- 2012-04-14 04:36:36 - 3257.75 user 591.61 system 4428.55 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sat Apr 14 04:38:07 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9B2CB106566B; Sat, 14 Apr 2012 04:38:07 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 54CBA8FC08; Sat, 14 Apr 2012 04:38:07 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q3E4c6q6022908; Sat, 14 Apr 2012 00:38:06 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q3E4c6wl022907; Sat, 14 Apr 2012 04:38:06 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 14 Apr 2012 04:38:06 GMT Message-Id: <201204140438.q3E4c6wl022907@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 04:38:07 -0000 TB --- 2012-04-14 02:12:21 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-04-14 02:12:21 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-04-14 02:12:21 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2012-04-14 02:12:21 - cleaning the object tree TB --- 2012-04-14 02:14:03 - cvsupping the source tree TB --- 2012-04-14 02:14:03 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2012-04-14 02:14:38 - building world TB --- 2012-04-14 02:14:38 - CROSS_BUILD_TESTING=YES TB --- 2012-04-14 02:14:38 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-14 02:14:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-14 02:14:38 - SRCCONF=/dev/null TB --- 2012-04-14 02:14:38 - TARGET=powerpc TB --- 2012-04-14 02:14:38 - TARGET_ARCH=powerpc TB --- 2012-04-14 02:14:38 - TZ=UTC TB --- 2012-04-14 02:14:38 - __MAKE_CONF=/dev/null TB --- 2012-04-14 02:14:38 - cd /src TB --- 2012-04-14 02:14:38 - /usr/bin/make -B buildworld >>> World build started on Sat Apr 14 02:14:39 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 Sat Apr 14 04:24:19 UTC 2012 TB --- 2012-04-14 04:24:19 - generating LINT kernel config TB --- 2012-04-14 04:24:19 - cd /src/sys/powerpc/conf TB --- 2012-04-14 04:24:19 - /usr/bin/make -B LINT TB --- 2012-04-14 04:24:19 - cd /src/sys/powerpc/conf TB --- 2012-04-14 04:24:19 - /usr/sbin/config -m LINT TB --- 2012-04-14 04:24:19 - building LINT kernel TB --- 2012-04-14 04:24:19 - CROSS_BUILD_TESTING=YES TB --- 2012-04-14 04:24:19 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-14 04:24:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-14 04:24:19 - SRCCONF=/dev/null TB --- 2012-04-14 04:24:19 - TARGET=powerpc TB --- 2012-04-14 04:24:19 - TARGET_ARCH=powerpc TB --- 2012-04-14 04:24:19 - TZ=UTC TB --- 2012-04-14 04:24:19 - __MAKE_CONF=/dev/null TB --- 2012-04-14 04:24:19 - cd /src TB --- 2012-04-14 04:24:19 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Apr 14 04:24:19 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 [...] ld -Bshareable -d -warn-common -o ip_mroute.ko ip_mroute.kld objcopy --strip-debug ip_mroute.ko ===> iscsi (all) ===> iscsi/initiator (all) cc -O2 -pipe -DISCSI_INITIATOR_DEBUG=2 -DINVARIANTS -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/iscsi/initiator/../../.. -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc/src/sys/LINT -fno-builtin -msoft-float -mno-altivec -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -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 -c /src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/iscsi.c In file included from /src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/iscsi.c:34: ./opt_iscsi_initiator.h:1:1: error: "ISCSI_INITIATOR_DEBUG" redefined : error: this is the location of the previous definition *** Error code 1 Stop in /src/sys/modules/iscsi/initiator. *** Error code 1 Stop in /src/sys/modules/iscsi. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/powerpc.powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-04-14 04:38:06 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-04-14 04:38:06 - ERROR: failed to build LINT kernel TB --- 2012-04-14 04:38:06 - 6895.56 user 927.40 system 8745.41 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sat Apr 14 05:13:52 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3620F106566C; Sat, 14 Apr 2012 05:13:52 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 042898FC17; Sat, 14 Apr 2012 05:13:51 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q3E5Dpcg018028; Sat, 14 Apr 2012 01:13:51 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q3E5DpVi018027; Sat, 14 Apr 2012 05:13:51 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 14 Apr 2012 05:13:51 GMT Message-Id: <201204140513.q3E5DpVi018027@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 05:13:52 -0000 TB --- 2012-04-14 02:31:28 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-04-14 02:31:28 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-04-14 02:31:28 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2012-04-14 02:31:28 - cleaning the object tree TB --- 2012-04-14 02:32:57 - cvsupping the source tree TB --- 2012-04-14 02:32:57 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2012-04-14 02:33:27 - building world TB --- 2012-04-14 02:33:27 - CROSS_BUILD_TESTING=YES TB --- 2012-04-14 02:33:27 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-14 02:33:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-14 02:33:27 - SRCCONF=/dev/null TB --- 2012-04-14 02:33:27 - TARGET=powerpc TB --- 2012-04-14 02:33:27 - TARGET_ARCH=powerpc64 TB --- 2012-04-14 02:33:27 - TZ=UTC TB --- 2012-04-14 02:33:27 - __MAKE_CONF=/dev/null TB --- 2012-04-14 02:33:27 - cd /src TB --- 2012-04-14 02:33:27 - /usr/bin/make -B buildworld >>> World build started on Sat Apr 14 02:33:28 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 Sat Apr 14 05:08:56 UTC 2012 TB --- 2012-04-14 05:08:56 - generating LINT kernel config TB --- 2012-04-14 05:08:56 - cd /src/sys/powerpc/conf TB --- 2012-04-14 05:08:56 - /usr/bin/make -B LINT TB --- 2012-04-14 05:08:56 - cd /src/sys/powerpc/conf TB --- 2012-04-14 05:08:56 - /usr/sbin/config -m LINT TB --- 2012-04-14 05:08:56 - building LINT kernel TB --- 2012-04-14 05:08:56 - CROSS_BUILD_TESTING=YES TB --- 2012-04-14 05:08:56 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-14 05:08:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-14 05:08:56 - SRCCONF=/dev/null TB --- 2012-04-14 05:08:56 - TARGET=powerpc TB --- 2012-04-14 05:08:56 - TARGET_ARCH=powerpc64 TB --- 2012-04-14 05:08:56 - TZ=UTC TB --- 2012-04-14 05:08:56 - __MAKE_CONF=/dev/null TB --- 2012-04-14 05:08:56 - cd /src TB --- 2012-04-14 05:08:56 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Apr 14 05:08:56 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/mxge/mxge_rss_eth_z8e.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/mxge/mxge_rss_ethp_z8e.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/my/if_my.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/netmap/netmap.c cc1: warnings being treated as errors In file included from /src/sys/dev/netmap/netmap.c:121: /src/sys/dev/netmap/netmap_mem2.c: In function 'netmap_ofstophys': /src/sys/dev/netmap/netmap_mem2.c:164: warning: format '%x' expects type 'unsigned int', but argument 6 has type 'vm_offset_t' [-Wformat] *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-04-14 05:13:51 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-04-14 05:13:51 - ERROR: failed to build LINT kernel TB --- 2012-04-14 05:13:51 - 7875.27 user 1094.75 system 9742.46 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sat Apr 14 08:24:38 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 704B81065676; Sat, 14 Apr 2012 08:24:38 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 2D6B58FC12; Sat, 14 Apr 2012 08:24:38 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q3E8ObkK095223; Sat, 14 Apr 2012 04:24:37 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q3E8ObTB095222; Sat, 14 Apr 2012 08:24:37 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 14 Apr 2012 08:24:37 GMT Message-Id: <201204140824.q3E8ObTB095222@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 08:24:38 -0000 TB --- 2012-04-14 05:20:01 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-04-14 05:20:01 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-04-14 05:20:01 - starting HEAD tinderbox run for i386/pc98 TB --- 2012-04-14 05:20:01 - cleaning the object tree TB --- 2012-04-14 05:26:46 - cvsupping the source tree TB --- 2012-04-14 05:26:46 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2012-04-14 05:28:56 - building world TB --- 2012-04-14 05:28:56 - CROSS_BUILD_TESTING=YES TB --- 2012-04-14 05:28:56 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-14 05:28:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-14 05:28:56 - SRCCONF=/dev/null TB --- 2012-04-14 05:28:56 - TARGET=pc98 TB --- 2012-04-14 05:28:56 - TARGET_ARCH=i386 TB --- 2012-04-14 05:28:56 - TZ=UTC TB --- 2012-04-14 05:28:56 - __MAKE_CONF=/dev/null TB --- 2012-04-14 05:28:56 - cd /src TB --- 2012-04-14 05:28:56 - /usr/bin/make -B buildworld >>> World build started on Sat Apr 14 05:28:57 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 Sat Apr 14 07:58:32 UTC 2012 TB --- 2012-04-14 07:58:32 - generating LINT kernel config TB --- 2012-04-14 07:58:32 - cd /src/sys/pc98/conf TB --- 2012-04-14 07:58:32 - /usr/bin/make -B LINT TB --- 2012-04-14 07:58:32 - cd /src/sys/pc98/conf TB --- 2012-04-14 07:58:32 - /usr/sbin/config -m LINT TB --- 2012-04-14 07:58:32 - building LINT kernel TB --- 2012-04-14 07:58:32 - CROSS_BUILD_TESTING=YES TB --- 2012-04-14 07:58:32 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-14 07:58:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-14 07:58:32 - SRCCONF=/dev/null TB --- 2012-04-14 07:58:32 - TARGET=pc98 TB --- 2012-04-14 07:58:32 - TARGET_ARCH=i386 TB --- 2012-04-14 07:58:32 - TZ=UTC TB --- 2012-04-14 07:58:32 - __MAKE_CONF=/dev/null TB --- 2012-04-14 07:58:32 - cd /src TB --- 2012-04-14 07:58:32 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Apr 14 07:58:33 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 [...] ld -Bshareable -d -warn-common -o ip_mroute.ko ip_mroute.kld objcopy --strip-debug ip_mroute.ko ===> iscsi (all) ===> iscsi/initiator (all) cc -O2 -pipe -DISCSI_INITIATOR_DEBUG=2 -DINVARIANTS -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/iscsi/initiator/../../.. -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98.i386/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/pc98.i386/src/sys/LINT -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -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 -c /src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/iscsi.c In file included from /src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/iscsi.c:34: ./opt_iscsi_initiator.h:1:1: error: "ISCSI_INITIATOR_DEBUG" redefined : error: this is the location of the previous definition *** Error code 1 Stop in /src/sys/modules/iscsi/initiator. *** Error code 1 Stop in /src/sys/modules/iscsi. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/pc98.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-04-14 08:24:37 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-04-14 08:24:37 - ERROR: failed to build LINT kernel TB --- 2012-04-14 08:24:37 - 7029.05 user 1010.02 system 11076.02 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sat Apr 14 08:29:21 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5FDEC106566C; Sat, 14 Apr 2012 08:29:21 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 1B9AD8FC0C; Sat, 14 Apr 2012 08:29:21 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q3E8TK9r027473; Sat, 14 Apr 2012 04:29:20 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q3E8TKDw027470; Sat, 14 Apr 2012 08:29:20 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 14 Apr 2012 08:29:20 GMT Message-Id: <201204140829.q3E8TKDw027470@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 08:29:21 -0000 TB --- 2012-04-14 05:20:01 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-04-14 05:20:01 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-04-14 05:20:01 - starting HEAD tinderbox run for i386/i386 TB --- 2012-04-14 05:20:01 - cleaning the object tree TB --- 2012-04-14 05:27:27 - cvsupping the source tree TB --- 2012-04-14 05:27:27 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2012-04-14 05:29:14 - building world TB --- 2012-04-14 05:29:14 - CROSS_BUILD_TESTING=YES TB --- 2012-04-14 05:29:14 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-14 05:29:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-14 05:29:14 - SRCCONF=/dev/null TB --- 2012-04-14 05:29:14 - TARGET=i386 TB --- 2012-04-14 05:29:14 - TARGET_ARCH=i386 TB --- 2012-04-14 05:29:14 - TZ=UTC TB --- 2012-04-14 05:29:14 - __MAKE_CONF=/dev/null TB --- 2012-04-14 05:29:14 - cd /src TB --- 2012-04-14 05:29:14 - /usr/bin/make -B buildworld >>> World build started on Sat Apr 14 05:29:15 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 Sat Apr 14 07:58:02 UTC 2012 TB --- 2012-04-14 07:58:02 - generating LINT kernel config TB --- 2012-04-14 07:58:02 - cd /src/sys/i386/conf TB --- 2012-04-14 07:58:02 - /usr/bin/make -B LINT TB --- 2012-04-14 07:58:03 - cd /src/sys/i386/conf TB --- 2012-04-14 07:58:03 - /usr/sbin/config -m LINT TB --- 2012-04-14 07:58:03 - building LINT kernel TB --- 2012-04-14 07:58:03 - CROSS_BUILD_TESTING=YES TB --- 2012-04-14 07:58:03 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-14 07:58:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-14 07:58:03 - SRCCONF=/dev/null TB --- 2012-04-14 07:58:03 - TARGET=i386 TB --- 2012-04-14 07:58:03 - TARGET_ARCH=i386 TB --- 2012-04-14 07:58:03 - TZ=UTC TB --- 2012-04-14 07:58:03 - __MAKE_CONF=/dev/null TB --- 2012-04-14 07:58:03 - cd /src TB --- 2012-04-14 07:58:03 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Apr 14 07:58: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 [...] ld -Bshareable -d -warn-common -o isci.ko isci.kld objcopy --strip-debug isci.ko ===> iscsi (all) ===> iscsi/initiator (all) cc -O2 -pipe -DISCSI_INITIATOR_DEBUG=2 -DINVARIANTS -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/iscsi/initiator/../../.. -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386.i386/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/i386.i386/src/sys/LINT -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -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 -c /src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/iscsi.c In file included from /src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/iscsi.c:34: ./opt_iscsi_initiator.h:1:1: error: "ISCSI_INITIATOR_DEBUG" redefined : error: this is the location of the previous definition *** Error code 1 Stop in /src/sys/modules/iscsi/initiator. *** Error code 1 Stop in /src/sys/modules/iscsi. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/i386.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-04-14 08:29:20 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-04-14 08:29:20 - ERROR: failed to build LINT kernel TB --- 2012-04-14 08:29:20 - 7280.62 user 1040.55 system 11359.45 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sat Apr 14 08:48:17 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3F7A106566C; Sat, 14 Apr 2012 08:48:17 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id ABA498FC16; Sat, 14 Apr 2012 08:48:17 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q3E8mHF6084864; Sat, 14 Apr 2012 04:48:17 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q3E8mHEQ084855; Sat, 14 Apr 2012 08:48:17 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 14 Apr 2012 08:48:17 GMT Message-Id: <201204140848.q3E8mHEQ084855@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 08:48:18 -0000 TB --- 2012-04-14 05:20:01 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-04-14 05:20:01 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-04-14 05:20:01 - starting HEAD tinderbox run for amd64/amd64 TB --- 2012-04-14 05:20:01 - cleaning the object tree TB --- 2012-04-14 05:29:31 - cvsupping the source tree TB --- 2012-04-14 05:29:31 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2012-04-14 05:29:57 - building world TB --- 2012-04-14 05:29:57 - CROSS_BUILD_TESTING=YES TB --- 2012-04-14 05:29:57 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-14 05:29:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-14 05:29:57 - SRCCONF=/dev/null TB --- 2012-04-14 05:29:57 - TARGET=amd64 TB --- 2012-04-14 05:29:57 - TARGET_ARCH=amd64 TB --- 2012-04-14 05:29:57 - TZ=UTC TB --- 2012-04-14 05:29:57 - __MAKE_CONF=/dev/null TB --- 2012-04-14 05:29:57 - cd /src TB --- 2012-04-14 05:29:57 - /usr/bin/make -B buildworld >>> World build started on Sat Apr 14 05:29:58 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 Sat Apr 14 08:37:33 UTC 2012 TB --- 2012-04-14 08:37:33 - generating LINT kernel config TB --- 2012-04-14 08:37:33 - cd /src/sys/amd64/conf TB --- 2012-04-14 08:37:33 - /usr/bin/make -B LINT TB --- 2012-04-14 08:37:33 - cd /src/sys/amd64/conf TB --- 2012-04-14 08:37:33 - /usr/sbin/config -m LINT TB --- 2012-04-14 08:37:33 - building LINT kernel TB --- 2012-04-14 08:37:33 - CROSS_BUILD_TESTING=YES TB --- 2012-04-14 08:37:33 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-14 08:37:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-14 08:37:33 - SRCCONF=/dev/null TB --- 2012-04-14 08:37:33 - TARGET=amd64 TB --- 2012-04-14 08:37:33 - TARGET_ARCH=amd64 TB --- 2012-04-14 08:37:33 - TZ=UTC TB --- 2012-04-14 08:37:33 - __MAKE_CONF=/dev/null TB --- 2012-04-14 08:37:33 - cd /src TB --- 2012-04-14 08:37:33 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Apr 14 08:37:34 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/my/if_my.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/ncv/ncr53c500.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/ncv/ncr53c500_pccard.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/netmap/netmap.c cc1: warnings being treated as errors In file included from /src/sys/dev/netmap/netmap.c:121: /src/sys/dev/netmap/netmap_mem2.c: In function 'netmap_ofstophys': /src/sys/dev/netmap/netmap_mem2.c:164: warning: format '%x' expects type 'unsigned int', but argument 6 has type 'vm_offset_t' [-Wformat] *** Error code 1 Stop in /obj/amd64.amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-04-14 08:48:16 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-04-14 08:48:16 - ERROR: failed to build LINT kernel TB --- 2012-04-14 08:48:16 - 7883.26 user 1256.86 system 12495.96 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Sat Apr 14 09:07:39 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47F0E106564A; Sat, 14 Apr 2012 09:07:39 +0000 (UTC) (envelope-from jeremie@le-hen.org) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [IPv6:2a01:e0c:1:1599::14]) by mx1.freebsd.org (Postfix) with ESMTP id 056E38FC0C; Sat, 14 Apr 2012 09:07:36 +0000 (UTC) Received: from endor.tataz.chchile.org (unknown [82.233.239.98]) by smtp5-g21.free.fr (Postfix) with ESMTP id 06180D4804B; Sat, 14 Apr 2012 11:07:29 +0200 (CEST) Received: from felucia.tataz.chchile.org (felucia.tataz.chchile.org [192.168.1.9]) by endor.tataz.chchile.org (Postfix) with ESMTP id 9EC2B923; Sat, 14 Apr 2012 11:07:28 +0200 (CEST) Received: by felucia.tataz.chchile.org (Postfix, from userid 1000) id 7858261F7; Sat, 14 Apr 2012 09:07:28 +0000 (UTC) Date: Sat, 14 Apr 2012 11:07:28 +0200 From: Jeremie Le Hen To: Alexander Best Message-ID: <20120414090728.GA8798@felucia.tataz.chchile.org> Mail-Followup-To: Alexander Best , freebsd-current@freebsd.org References: <20120413213644.GA92873@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120413213644.GA92873@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org Subject: Re: howto debug a complete hard reset X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 09:07:39 -0000 Hi Alexander, On Fri, Apr 13, 2012 at 09:36:44PM +0000, Alexander Best wrote: > > i'm running HEAD on amd64 and experienced some really annoying resets during > the last couple of months. > > when i do 'sysctl -a' or 'sysctl -a|grep bla', my whole system does a hard > reset. no core dump gets produced. > > isn't there a way to find out which sysctl variable is causing the reset? This is probably a sysctl handler that is causing the reboot. You can run this one-liner to spot the culprit (use sh): for i in $(sysctl -Na); do sysctl $i >> ~/sysctl.out; sync; done Each sysctl will be called in turn and the output is appended to a file, but the file will forcibly written to the disk before the next occurence. When your computer will be reset, the culprit will obviously not be written to this file, but the previous one will. You can then look at the output of sysctl -Na to see which one is causing the reboot. Regards, -- Jeremie Le Hen Men are born free and equal. Later on, they're on their own. Jean Yanne From owner-freebsd-current@FreeBSD.ORG Sat Apr 14 09:37:48 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6A26110656D6; Sat, 14 Apr 2012 09:37:48 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 30F928FC14; Sat, 14 Apr 2012 09:37:48 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q3E9bl0q070027; Sat, 14 Apr 2012 05:37:47 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q3E9blur070023; Sat, 14 Apr 2012 09:37:47 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 14 Apr 2012 09:37:47 GMT Message-Id: <201204140937.q3E9blur070023@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 09:37:48 -0000 TB --- 2012-04-14 07:48:11 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-04-14 07:48:11 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-04-14 07:48:11 - starting HEAD tinderbox run for ia64/ia64 TB --- 2012-04-14 07:48:11 - cleaning the object tree TB --- 2012-04-14 07:49:39 - cvsupping the source tree TB --- 2012-04-14 07:49:39 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2012-04-14 07:50:27 - building world TB --- 2012-04-14 07:50:27 - CROSS_BUILD_TESTING=YES TB --- 2012-04-14 07:50:27 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-14 07:50:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-14 07:50:27 - SRCCONF=/dev/null TB --- 2012-04-14 07:50:27 - TARGET=ia64 TB --- 2012-04-14 07:50:27 - TARGET_ARCH=ia64 TB --- 2012-04-14 07:50:27 - TZ=UTC TB --- 2012-04-14 07:50:27 - __MAKE_CONF=/dev/null TB --- 2012-04-14 07:50:27 - cd /src TB --- 2012-04-14 07:50:27 - /usr/bin/make -B buildworld >>> World build started on Sat Apr 14 07:50:28 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 Sat Apr 14 09:27:47 UTC 2012 TB --- 2012-04-14 09:27:47 - generating LINT kernel config TB --- 2012-04-14 09:27:47 - cd /src/sys/ia64/conf TB --- 2012-04-14 09:27:47 - /usr/bin/make -B LINT TB --- 2012-04-14 09:27:47 - cd /src/sys/ia64/conf TB --- 2012-04-14 09:27:47 - /usr/sbin/config -m LINT TB --- 2012-04-14 09:27:48 - building LINT kernel TB --- 2012-04-14 09:27:48 - CROSS_BUILD_TESTING=YES TB --- 2012-04-14 09:27:48 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-14 09:27:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-14 09:27:48 - SRCCONF=/dev/null TB --- 2012-04-14 09:27:48 - TARGET=ia64 TB --- 2012-04-14 09:27:48 - TARGET_ARCH=ia64 TB --- 2012-04-14 09:27:48 - TZ=UTC TB --- 2012-04-14 09:27:48 - __MAKE_CONF=/dev/null TB --- 2012-04-14 09:27:48 - cd /src TB --- 2012-04-14 09:27:48 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Apr 14 09:27:48 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/mxge/mxge_rss_eth_z8e.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/mxge/mxge_rss_ethp_z8e.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/my/if_my.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/netmap/netmap.c cc1: warnings being treated as errors In file included from /src/sys/dev/netmap/netmap.c:121: /src/sys/dev/netmap/netmap_mem2.c: In function 'netmap_ofstophys': /src/sys/dev/netmap/netmap_mem2.c:164: warning: format '%x' expects type 'unsigned int', but argument 6 has type 'vm_offset_t' [-Wformat] *** Error code 1 Stop in /obj/ia64.ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-04-14 09:37:47 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-04-14 09:37:47 - ERROR: failed to build LINT kernel TB --- 2012-04-14 09:37:47 - 4683.64 user 710.89 system 6576.11 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sat Apr 14 10:23:37 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id BDBDD1065672; Sat, 14 Apr 2012 10:23:37 +0000 (UTC) Date: Sat, 14 Apr 2012 10:23:37 +0000 From: Alexander Best To: freebsd-current@freebsd.org Message-ID: <20120414102337.GA14000@freebsd.org> References: <20120413213644.GA92873@freebsd.org> <20120414090728.GA8798@felucia.tataz.chchile.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Nq2Wo0NMKNjxTN9z" Content-Disposition: inline In-Reply-To: <20120414090728.GA8798@felucia.tataz.chchile.org> Subject: Re: howto debug a complete hard reset X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 10:23:37 -0000 --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat Apr 14 12, Jeremie Le Hen wrote: > Hi Alexander, > > On Fri, Apr 13, 2012 at 09:36:44PM +0000, Alexander Best wrote: > > > > i'm running HEAD on amd64 and experienced some really annoying resets during > > the last couple of months. > > > > when i do 'sysctl -a' or 'sysctl -a|grep bla', my whole system does a hard > > reset. no core dump gets produced. > > > > isn't there a way to find out which sysctl variable is causing the reset? > > This is probably a sysctl handler that is causing the reboot. You can > run this one-liner to spot the culprit (use sh): > > for i in $(sysctl -Na); do sysctl $i >> ~/sysctl.out; sync; done thanks a lot. i ran that command and it finished without a hard reset. next i rebooted my system and ran 'sysctl -a' on the console. the time my system was resetting i ran it under X. running 'sysctl -a' under the console didn't reset my system, but triggered a panic. i've attached the textdump, but also have a complete dump handy, if more or specific information is needed. cheers. alex > > Each sysctl will be called in turn and the output is appended to a file, > but the file will forcibly written to the disk before the next > occurence. > > When your computer will be reset, the culprit will obviously not be > written to this file, but the previous one will. You can then look at > the output of sysctl -Na to see which one is causing the reboot. > > Regards, > -- > Jeremie Le Hen > > Men are born free and equal. Later on, they're on their own. > Jean Yanne --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="info.2" Dump header from device /dev/label/swapfs Architecture: amd64 Architecture Version: 2 Dump Length: 182468608B (174 MB) Blocksize: 512 Dumptime: Sat Apr 14 12:10:53 2012 Hostname: otaku Magic: FreeBSD Kernel Dump Version String: FreeBSD 10.0-CURRENT #2 r234233=5c0394f-dirty: Fri Apr 13 22:00:03 CEST 2012 arundel@otaku:/usr/obj/usr/github-freebsd-head/sys/ARUNDEL Panic String: from debugger Dump Parity: 822965859 Bounds: 2 Dump Status: good --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="core.txt.2" otaku dumped core - see /var/crash/vmcore.2 Sat Apr 14 12:12:59 CEST 2012 FreeBSD otaku 10.0-CURRENT FreeBSD 10.0-CURRENT #2 r234233=5c0394f-dirty: Fri Apr 13 22:00:03 CEST 2012 arundel@otaku:/usr/obj/usr/github-freebsd-head/sys/ARUNDEL amd64 panic: from debugger GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x100000f fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff804406ff stack pointer = 0x28:0xffffff8091e99760 frame pointer = 0x28:0xffffff8091e997d0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 902 (sysctl) Uptime: 40s Dumping 174 out of 2020 MB: No symbol "dumptid" in current context. Reading symbols from /boot/modules/nvidia.ko...done. Loaded symbols for /boot/modules/nvidia.ko Reading symbols from /usr/local/libexec/linux_adobe/linux_adobe.ko...done. Loaded symbols for /usr/local/libexec/linux_adobe/linux_adobe.ko #0 sched_switch (td=dwarf2_read_address: Corrupted DWARF expression. ) at /usr/github-freebsd-head/sys/kern/sched_4bsd.c:1028 1028 if (td->td_flags & TDF_IDLETD) (kgdb) #0 sched_switch (td=dwarf2_read_address: Corrupted DWARF expression. ) at /usr/github-freebsd-head/sys/kern/sched_4bsd.c:1028 #1 0xffffffff8043d672 in mi_switch (flags=dwarf2_read_address: Corrupted DWARF expression. ) at /usr/github-freebsd-head/sys/kern/kern_synch.c:468 #2 0xffffffff8046ef8a in sleepq_timedwait (wchan=dwarf2_read_address: Corrupted DWARF expression. ) at /usr/github-freebsd-head/sys/kern/subr_sleepqueue.c:652 #3 0xffffffff8043d1bc in _sleep (ident=Variable "ident" is not available. ) at /usr/github-freebsd-head/sys/kern/kern_synch.c:230 #4 0xffffffff80595079 in scheduler (dummy=dwarf2_read_address: Corrupted DWARF expression. ) at /usr/github-freebsd-head/sys/vm/vm_glue.c:788 #5 0xffffffff803ecf43 in mi_startup () at /usr/github-freebsd-head/sys/kern/init_main.c:258 #6 0xffffffff8026840c in btext () #7 0xffffffff809555e8 in sleepq_chains () #8 0xfffffe00026798a0 in ?? () #9 0x0000000000000000 in ?? () #10 0x0000000000000000 in ?? () #11 0xffffffff81b7cba0 in ?? () #12 0xffffffff81b7cb68 in ?? () #13 0xffffffff809990c0 in bootverbose () #14 0xffffffff80458eb1 in sched_switch (td=dwarf2_read_address: Corrupted DWARF expression. ) at /usr/github-freebsd-head/sys/kern/sched_4bsd.c:1002 Current language: auto; currently minimal (kgdb) ------------------------------------------------------------------------ ps -axl UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND 0 0 0 0 -52 0 0 0 - DLs - 0:00.56 [kernel] 0 1 0 0 8 0 6276 0 wait DLs - 0:00.01 [init] 0 2 0 0 -8 0 0 0 ccb_scan DL - 0:00.00 [xpt_thrd] 0 3 0 0 -16 0 0 0 psleep DL - 0:00.00 [pagedaemon] 0 4 0 0 16 0 0 0 psleep DL - 0:00.00 [vmdaemon] 0 5 0 0 155 0 0 0 pgzero DL - 0:00.00 [pagezero] 0 6 0 0 -16 0 0 0 psleep DL - 0:00.00 [bufdaemon] 0 7 0 0 16 0 0 0 syncer DL - 0:00.00 [syncer] 0 8 0 0 -4 0 0 0 vlruwt DL - 0:00.00 [vnlru] 0 9 0 0 -16 0 0 0 sdflush DL - 0:00.00 [softdepflush] 0 10 0 0 155 0 0 0 - RL - 1:14.19 [idle] 0 11 0 0 -88 0 0 0 - WL - 0:00.07 [intr] 0 12 0 0 -8 0 0 0 - DL - 0:00.07 [geom] 0 13 0 0 -16 0 0 0 - DL - 0:00.01 [yarrow] 0 14 0 0 -68 0 0 0 - DL - 0:00.03 [usb] 0 15 0 0 -16 0 0 0 - DL - 0:00.00 [schedcpu] 0 332 1 0 45 0 18140 0 select Ds - 0:00.11 [wpa_supplicant] 0 436 1 0 45 0 10376 0 select Ds - 0:00.00 [devd] 0 623 1 0 44 0 11904 0 select Ds - 0:00.01 [syslogd] 0 687 1 0 42 0 11904 0 select Ds - 0:00.01 [powerd] 0 715 1 0 8 0 25652 0 nanslp D - 0:00.00 [smartd] 556 720 1 0 56 0 14172 0 select Ds - 0:00.01 [dbus-daemon] 1001 732 1 0 58 0 150168 0 uwait Ds - 0:00.02 [musicpd] 65534 737 1 0 49 0 33244 0 select Ds - 0:00.01 [mpdscribble] 0 778 1 0 50 0 20080 0 select Ds - 0:00.00 [sendmail] 25 781 1 0 16 0 20080 0 pause Ds - 0:00.00 [sendmail] 0 785 1 0 8 0 13992 0 nanslp Ds - 0:00.00 [cron] 65534 795 1 0 65 0 9776 0 select Ds - 0:00.00 [identd] 0 823 1 0 8 0 36796 0 wait Ds - 0:00.01 [login] 0 824 1 0 65 0 11908 0 ttyin Ds+ - 0:00.00 [getty] 0 825 1 0 65 0 11908 0 ttyin Ds+ - 0:00.00 [getty] 0 826 1 0 65 0 11908 0 ttyin Ds+ - 0:00.00 [getty] 0 827 1 0 65 0 11908 0 ttyin Ds+ - 0:00.00 [getty] 0 828 1 0 65 0 11908 0 ttyin Ds+ - 0:00.00 [getty] 0 829 1 0 65 0 11908 0 ttyin Ds+ - 0:00.00 [getty] 0 830 1 0 65 0 11908 0 ttyin Ds+ - 0:00.00 [getty] 560 835 1 0 -8 0 56744 0 piperd Ds - 0:00.32 [hald] 0 837 1 0 50 0 60720 0 n D - 0:00.03 [console-kit-dae 0 839 1 0 53 0 53456 0 select D - 0:00.03 [polkitd] 0 841 1 0 50 0 22500 0 select D - 0:00.01 [gam_server] 0 842 835 0 64 0 38868 0 select D - 0:00.05 [hald-runner] 1001 873 823 0 16 0 25200 0 pause D - 0:00.02 [zsh] 0 874 842 0 56 0 29124 0 s D - 0:00.01 [hald-addon-mous 0 894 842 0 60 0 20720 0 e D - 0:00.01 [hald-addon-stor 1001 902 873 0 49 0 9776 0 - R+ - 0:00.00 [sysctl] ------------------------------------------------------------------------ vmstat -s 63033 cpu context switches 21855 device interrupts 7114 software interrupts 91730 traps 816579 system calls 15 kernel threads created 661 fork() calls 226 vfork() calls 0 rfork() calls 0 swap pager pageins 0 swap pager pages paged in 0 swap pager pageouts 0 swap pager pages paged out 509 vnode pager pageins 3709 vnode pager pages paged in 0 vnode pager pageouts 0 vnode pager pages paged out 0 page daemon wakeups 0 pages examined by the page daemon 594 pages reactivated 27851 copy-on-write faults 105 copy-on-write optimized faults 39417 zero fill pages zeroed 0 zero fill pages prezeroed 31 intransit blocking page faults 100187 total VM faults taken 0 pages affected by kernel thread creation 337740 pages affected by fork() 115796 pages affected by vfork() 0 pages affected by rfork() 0 pages cached 83392 pages freed 0 pages freed by daemon 0 pages freed by exiting processes 6263 pages active 3581 pages inactive 80 pages in VM cache 22215 pages wired down 469596 pages free 4096 bytes per page 31276 total name lookups cache hits (88% pos + 4% neg) system 0% per-directory deletions 0%, falsehits 0%, toolong 0% ------------------------------------------------------------------------ vmstat -m Type InUse MemUse HighUse Requests Size(s) devbuf 20399 38289K - 20686 16,32,64,128,256,512,1024,2048,4096 temp 71 17K - 7417 16,32,64,128,256,512,1024,2048,4096 scsi_cd 0 0K - 5 16 module 151 19K - 151 128 mtx_pool 2 16K - 2 CAM SIM 9 3K - 9 256 osd 2 1K - 2 16,64 pmchooks 1 1K - 1 128 USB 101 147K - 113 16,32,64,128,256,512,2048 USBdev 107 40K - 510 64,128,512,1024 pgrp 25 4K - 27 128 session 23 3K - 24 128 proc 2 16K - 2 subproc 106 211K - 964 512,4096 cred 50 8K - 6580 64,256 plimit 13 4K - 149 256 uidinfo 7 3K - 7 128,2048 CAM XPT 100 70K - 325 16,32,64,128,256,1024,2048 scsi_da 0 0K - 43 16,32 ddb_capture 1 48K - 1 entropy 1024 64K - 1024 64 sysctl 0 0K - 642 16,32,64 sysctloid 4886 243K - 5006 16,32,64,128 sysctltmp 0 0K - 694 16,32,64,128,256 tidhash 1 16K - 1 callout 1 512K - 1 umtx 324 41K - 324 128 p1003.1b 1 1K - 1 16 SWAP 2 1097K - 2 64 bus 608 58K - 2738 16,32,64,128,256,512,1024 bus-sc 80 399K - 610 16,32,64,128,256,512,1024,2048 devstat 18 37K - 18 32,4096 eventhandler 62 5K - 62 64,128 DEVFS2 147 3K - 147 16 DEVFS3 350 88K - 359 256 kobj 83 332K - 210 4096 DEVFS1 151 76K - 159 512 Per-cpu 1 1K - 1 32 DEVFS_RULE 66 31K - 66 64,512 DEVFS 44 1K - 45 16,32,128 DEVFSP 1 1K - 404 64 rman 205 24K - 610 16,32,128 sbuf 0 0K - 2451 16,32,64,128,256,512,1024,2048,4096 sglist 3 1K - 3 32 stack 0 0K - 2 256 taskqueue 19 2K - 19 16,32,128 Unitno 16 1K - 252 32,64 ioctlops 0 0K - 2305 16,32,64,128,256,512,1024,2048,4096 select 36 5K - 36 128 iov 0 0K - 4726 16,32,64,128,256,512 msg 4 30K - 4 2048,4096 sem 4 106K - 4 2048,4096 shm 1 20K - 1 tty 17 17K - 21 1024,2048 mbuf_tag 0 0K - 5 32,64 ksem 1 8K - 1 shmfd 1 8K - 1 soname 19 2K - 442 16,32,64,128 pcb 13 13K - 15 16,32,1024,2048,4096 biobuf 0 0K - 1 2048 vfscache 1 1024K - 1 vfs_hash 1 512K - 1 vnodes 2 1K - 2 256 pfs_nodes 156 39K - 156 256 pfs_vncache 2 1K - 2 64 mount 113 6K - 185 16,32,64,128,256 vnodemarker 0 0K - 14 512 BPF 15 1026K - 16 16,128,512 tmpfs mount 1 1K - 1 128 ifnet 12 23K - 12 128,2048 ifaddr 286 19K - 594 32,512,4096 ether_multi 9 1K - 10 16,64 arpcom 1 1K - 1 16 lltable 13 6K - 13 256,512 tmpfs name 6 1K - 7 16 GEOM 233 42K - 1436 16,32,64,128,256,512,1024,2048 hdaa 5 47K - 5 1024,2048,4096 hdac 1 1K - 1 1024 hdacc 1 1K - 1 32 routetbl 11 3K - 58 32,64,128,256,512 80211vap 1 4K - 1 4096 80211crypto 2 1K - 2 128,512 80211com 1 8K - 1 80211node 2 37K - 4 1024 80211nodeie 4 2K - 7 32,128,256,512 80211scan 4 7K - 6 512,2048,4096 igmp 11 3K - 11 256 in_multi 2 1K - 2 256 acpiintr 1 1K - 1 64 acpica 2227 230K - 44567 16,32,64,128,256,512,1024,2048 CAM periph 13 4K - 35 16,32,64,128,256 hostcache 1 28K - 1 syncache 1 96K - 1 pagedep 8 130K - 9 256 inodedep 59 541K - 64 512 bmsafemap 6 10K - 7 256 newblk 19 133K - 28 256 freefrag 0 0K - 1 128 freeblks 18 3K - 19 128 freefile 1 1K - 3 64 diradd 24 3K - 30 128 mkdir 0 0K - 2 128 dirrem 25 4K - 30 128 newdirblk 0 0K - 1 64 freework 19 3K - 20 16,128 jnewblk 0 0K - 1 128 jseg 1 1K - 1 128 jsegdep 1 1K - 1 64 sbdep 0 0K - 1 64 jblocks 2 1K - 2 128,256 ufs_mount 9 148K - 9 512,2048,4096 vm_pgdata 2 129K - 2 128 pci_link 16 2K - 16 64,128 acpi_perf 1 1K - 1 64 CAM queue 37 2K - 171 16,32,256 feeder 23 3K - 29 32,128 isadev 9 2K - 9 128 acpitask 1 2K - 1 2048 memdesc 1 4K - 1 4096 acpisem 16 2K - 16 128 CAM dev queue 9 2K - 9 128 athdev 3 132K - 3 4096 cpuctl 1 1K - 1 16 cdev 7 2K - 7 256 ath_hal 3 22K - 4 2048 mixer 3 12K - 3 4096 filedesc 53 31K - 954 512,1024 sigio 1 1K - 1 64 kenv 87 11K - 92 16,32,64,128 kqueue 11 10K - 13 256,512,2048 linux 16 1K - 16 64 apmdev 1 1K - 1 128 madt_table 0 0K - 1 4096 proc-args 30 2K - 501 32,64,128,256 LED 24 2K - 24 16,128 hhook 2 1K - 2 128 ithread 72 12K - 72 32,128,256 io_apic 1 2K - 1 2048 KTRACE 100 13K - 100 128 MCA 6 1K - 6 128 acpidev 34 3K - 34 64 msi 2 1K - 2 128 nexusdev 3 1K - 3 16 linker 73 10K - 85 16,32,64,128,256,512,1024 lockf 20 3K - 32 64,128 loginclass 2 1K - 3 64 nvidia 176 1112K - 181 16,32,64,128,256,512,2048 ------------------------------------------------------------------------ vmstat -z ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP UMA Kegs: 208, 0, 78, 7, 78, 0, 0 UMA Zones: 640, 0, 78, 0, 78, 0, 0 UMA Slabs: 568, 0, 681, 5, 954, 0, 0 UMA RCntSlabs: 568, 0, 210, 0, 210, 0, 0 UMA Hash: 256, 0, 3, 12, 3, 0, 0 16 Bucket: 152, 0, 65, 10, 65, 0, 0 32 Bucket: 280, 0, 53, 3, 53, 0, 0 64 Bucket: 536, 0, 30, 5, 30, 57, 0 128 Bucket: 1048, 0, 39, 0, 39, 378, 0 VM OBJECT: 232, 0, 1581, 115, 12538, 0, 0 MAP: 232, 0, 7, 25, 7, 0, 0 KMAP ENTRY: 120, 87389, 39, 240, 9183, 0, 0 MAP ENTRY: 120, 0, 1071, 293, 28779, 0, 0 fakepg: 120, 0, 0, 62, 17, 0, 0 mt_zone: 4112, 0, 211, 4, 211, 0, 0 16: 16, 0, 2537, 151, 26575, 0, 0 32: 32, 0, 2506, 524, 9989, 0, 0 64: 64, 0, 10858, 118, 37009, 0, 0 128: 128, 0, 6554, 116, 9326, 0, 0 256: 256, 0, 1731, 114, 6096, 0, 0 512: 512, 0, 616, 49, 2270, 0, 0 1024: 1024, 0, 102, 126, 2881, 0, 0 2048: 2048, 0, 102, 32, 854, 0, 0 4096: 4096, 0, 184, 20, 6585, 0, 0 Files: 80, 0, 249, 66, 5876, 0, 0 TURNSTILE: 136, 0, 163, 37, 163, 0, 0 umtx pi: 96, 0, 0, 0, 0, 0, 0 PROC: 1184, 0, 44, 16, 902, 0, 0 THREAD: 1104, 0, 140, 22, 140, 0, 0 SLEEPQUEUE: 80, 0, 163, 40, 163, 0, 0 VMSPACE: 392, 0, 30, 40, 889, 0, 0 cpuset: 72, 0, 74, 76, 74, 0, 0 mbuf_packet: 256, 0, 40, 356, 973, 0, 0 mbuf: 256, 0, 1, 395, 1351, 0, 0 mbuf_cluster: 2048, 25600, 384, 18, 384, 0, 0 mbuf_jumbo_page: 4096, 12800, 0, 9, 8, 0, 0 mbuf_jumbo_9k: 9216, 19200, 0, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 12800, 0, 0, 0, 0, 0 mbuf_ext_refcnt: 4, 0, 0, 0, 0, 0, 0 g_bio: 232, 0, 0, 80, 18284, 0, 0 ttyinq: 160, 0, 120, 24, 255, 0, 0 ttyoutq: 256, 0, 64, 26, 136, 0, 0 nv_stack_t: 12288, 0, 2, 7, 18, 0, 0 VNODE: 472, 0, 935, 9, 942, 0, 0 VNODEPOLL: 112, 0, 56, 76, 56, 0, 0 S VFS Cache: 108, 0, 836, 88, 1872, 0, 0 STS VFS Cache: 148, 0, 0, 0, 0, 0, 0 L VFS Cache: 328, 0, 0, 0, 0, 0, 0 LTS VFS Cache: 368, 0, 0, 0, 0, 0, 0 NAMEI: 1024, 0, 0, 36, 12192, 0, 0 mqnode: 408, 0, 3, 15, 3, 0, 0 mqueue: 248, 0, 0, 0, 0, 0, 0 mvdata: 64, 0, 0, 0, 0, 0, 0 mqnotifier: 216, 0, 0, 0, 0, 0, 0 Mountpoints: 760, 0, 8, 7, 8, 0, 0 pipe: 728, 0, 66, 24, 487, 0, 0 ksiginfo: 112, 0, 54, 1002, 55, 0, 0 itimer: 344, 0, 0, 0, 0, 0, 0 KNOTE: 128, 0, 65, 51, 71, 0, 0 socket: 680, 25602, 46, 26, 308, 0, 0 unpcb: 240, 25600, 38, 42, 178, 0, 0 ipq: 56, 819, 0, 0, 0, 0, 0 udp_inpcb: 392, 25600, 2, 28, 122, 0, 0 udpcb: 16, 25704, 2, 334, 122, 0, 0 tcp_inpcb: 392, 25600, 6, 24, 6, 0, 0 tcpcb: 976, 25600, 5, 7, 6, 0, 0 tcptw: 72, 5150, 1, 99, 1, 0, 0 syncache: 152, 15375, 0, 50, 1, 0, 0 hostcache: 136, 15372, 0, 0, 0, 0, 0 tcpreass: 40, 1680, 0, 0, 0, 0, 0 sackhole: 32, 0, 0, 0, 0, 0, 0 ripcb: 392, 25600, 0, 0, 0, 0, 0 rtentry: 200, 0, 4, 53, 6, 0, 0 selfd: 56, 0, 90, 225, 20277, 0, 0 SWAPMETA: 288, 116519, 0, 0, 0, 0, 0 FFS inode: 168, 0, 814, 22, 818, 0, 0 FFS1 dinode: 128, 0, 0, 0, 0, 0, 0 FFS2 dinode: 256, 0, 814, 41, 818, 0, 0 TMPFS dirent: 40, 0, 6, 162, 7, 0, 0 TMPFS node: 224, 0, 7, 44, 8, 0, 0 ------------------------------------------------------------------------ vmstat -i interrupt total rate irq16: vgapci0+ 63 1 irq18: uhci2 ehci0+ 480 15 irq19: ath0 uhci4 331 10 irq20: hpet0 16114 503 irq21: uhci1 20 0 irq23: uhci3 ehci1 756 23 irq256: hdac0 74 2 irq257: ahci0 4017 125 Total 21855 682 ------------------------------------------------------------------------ pstat -T 249/12328 files 0M/8191M swap space ------------------------------------------------------------------------ pstat -s Device 512-blocks Used Avail Capacity /dev/label/swapfs8 16776952 0 16776952 0% ------------------------------------------------------------------------ iostat iostat: kvm_read(_tk_nin): invalid address (0x0) iostat: disabling TTY statistics ada0 ada1 da0 cpu KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id 13.55 27 0.36 22.94 94 2.11 2.99 3 0.01 2 0 3 0 95 ------------------------------------------------------------------------ ipcs -a Message Queues: T ID KEY MODE OWNER GROUP CREATOR CGROUP CBYTES QNUM QBYTES LSPID LRPID STIME RTIME CTIME Shared Memory: T ID KEY MODE OWNER GROUP CREATOR CGROUP NATTCH SEGSZ CPID LPID ATIME DTIME CTIME Semaphores: T ID KEY MODE OWNER GROUP CREATOR CGROUP NSEMS OTIME CTIME ------------------------------------------------------------------------ ipcs -T msginfo: msgmax: 16384 (max characters in a message) msgmni: 40 (# of message queues) msgmnb: 2048 (max characters in a message queue) msgtql: 40 (max # of messages in system) msgssz: 8 (size of a message segment) msgseg: 2048 (# of message segments in system) shminfo: shmmax: 536870912 (max shared memory segment size) shmmin: 1 (min shared memory segment size) shmmni: 192 (max number of shared memory identifiers) shmseg: 128 (max shared memory segments per process) shmall: 131072 (max amount of shared memory in pages) seminfo: semmni: 50 (# of semaphore identifiers) semmns: 340 (# of semaphores in system) semmnu: 150 (# of undo structures in system) semmsl: 340 (max # of semaphores per id) semopm: 100 (max # of operations per semop call) semume: 50 (max # of undo entries per process) semusz: 632 (size in bytes of undo structure) semvmx: 32767 (semaphore maximum value) semaem: 16384 (adjust on exit max value) ------------------------------------------------------------------------ nfsstat nfsstat: new client/server not loaded ------------------------------------------------------------------------ netstat -s tcp: 15 packets sent 7 data packets (879 bytes) 0 data packets (0 bytes) retransmitted 0 data packets unnecessarily retransmitted 0 resends initiated by MTU discovery 5 ack-only packets (1 delayed) 0 URG only packets 0 window probe packets 0 window update packets 3 control packets 16 packets received 11 acks (for 881 bytes) 2 duplicate acks 0 acks for unsent data 8 packets (1038 bytes) received in-sequence 0 completely duplicate packets (0 bytes) 0 old duplicate packets 0 packets with some dup. data (0 bytes duped) 0 out-of-order packets (0 bytes) 0 packets (0 bytes) of data after window 0 window probes 0 window update packets 0 packets received after close 0 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short 0 discarded due to memory problems 2 connection requests 1 connection accept 0 bad connection attempts 0 listen queue overflows 0 ignored RSTs in the windows 3 connections established (including accepts) 0 connections closed (including 0 drops) 0 connections updated cached RTT on close 0 connections updated cached RTT variance on close 0 connections updated cached ssthresh on close 0 embryonic connections dropped 11 segments updated rtt (of 10 attempts) 0 retransmit timeouts 0 connections dropped by rexmit timeout 0 persist timeouts 0 connections dropped by persist timeout 0 Connections (fin_wait_2) dropped because of timeout 0 keepalive timeouts 0 keepalive probes sent 0 connections dropped by keepalive 1 correct ACK header prediction 1 correct data packet header prediction 1 syncache entry added 0 retransmitted 0 dupsyn 0 dropped 1 completed 0 bucket overflow 0 cache overflow 0 reset 0 stale 0 aborted 0 badack 0 unreach 0 zone failures 1 cookie sent 0 cookies received 0 hostcache entries added 0 bucket overflow 0 SACK recovery episodes 0 segment rexmits in SACK recovery episodes 0 byte rexmits in SACK recovery episodes 0 SACK options (SACK blocks) received 0 SACK options (SACK blocks) sent 0 SACK scoreboard overflow 0 packets with ECN CE bit set 0 packets with ECN ECT(0) bit set 0 packets with ECN ECT(1) bit set 0 successful ECN handshakes 0 times ECN reduced the congestion window udp: 1 datagram received 0 with incomplete header 0 with bad data length field 0 with bad checksum 0 with no checksum 0 dropped due to no socket 0 broadcast/multicast datagrams undelivered 0 dropped due to full socket buffers 0 not for hashed pcb 1 delivered 2 datagrams output 0 times multicast source filter matched ip: 17 total packets received 0 bad header checksums 0 with size smaller than minimum 0 with data size < data length 0 with ip length > max ip packet size 0 with header length < data size 0 with data length < header length 0 with bad options 0 with incorrect version number 0 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 0 packets reassembled ok 17 packets for this host 0 packets for unknown/unsupported protocol 0 packets forwarded (0 packets fast forwarded) 0 packets not forwardable 0 packets received for unknown multicast group 0 redirects sent 17 packets sent from this host 0 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 0 output packets discarded due to no route 0 output datagrams fragmented 0 fragments created 0 datagrams that can't be fragmented 0 tunneling packets that can't find gif 0 datagrams with bad address in header icmp: 0 calls to icmp_error 0 errors not generated in response to an icmp message 0 messages with bad code fields 0 messages less than the minimum length 0 messages with bad checksum 0 messages with bad length 0 multicast echo requests ignored 0 multicast timestamp requests ignored 0 message responses generated 0 invalid return addresses 0 no return routes igmp: 0 messages received 0 messages received with too few bytes 0 messages received with wrong TTL 0 messages received with bad checksum 0 V1/V2 membership queries received 0 V3 membership queries received 0 membership queries received with invalid field(s) 0 general queries received 0 group queries received 0 group-source queries received 0 group-source queries dropped 0 membership reports received 0 membership reports received with invalid field(s) 0 membership reports received for groups to which we belong 0 V3 reports received without Router Alert 0 membership reports sent arp: 3 ARP requests sent 0 ARP replies sent 0 ARP requests received 1 ARP reply received 1 ARP packet received 1 total packet dropped due to no ARP entry 0 ARP entrys timed out 0 Duplicate IPs seen ------------------------------------------------------------------------ netstat -m 41/751/792 mbufs in use (current/cache/total) 28/374/402/25600 mbuf clusters in use (current/cache/total/max) 40/356 mbuf+clusters out of packet secondary zone in use (current/cache) 0/9/9/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/19200 9k jumbo clusters in use (current/cache/total/max) 0/0/0/12800 16k jumbo clusters in use (current/cache/total/max) 66K/971K/1038K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines ------------------------------------------------------------------------ netstat -id Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll Drop usbus 0 0 0 0 0 0 0 0 usbus 0 0 0 0 0 0 0 0 usbus 0 0 0 0 0 0 0 0 usbus 0 0 0 0 0 0 0 0 usbus 0 0 0 0 0 0 0 0 usbus 0 0 0 0 0 0 0 0 usbus 0 0 0 0 0 0 0 0 usbus 0 0 0 0 0 0 0 0 ath0 2290 00:0f:b5:82:07:c8 156 9 0 41 0 0 0 lo0 16384 10 0 0 10 0 0 0 lo0 16384 your-net localhost.otaku 10 - - 10 - - - wlan0 1500 00:0f:b5:82:07:c8 10 0 0 10 0 0 0 wlan0 1500 192.168.1.0 localhost.otaku 7 - - 7 - - - ------------------------------------------------------------------------ netstat -anr Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 192.168.1.1 UGS 0 5 wlan0 127.0.0.1 link#10 UH 0 10 lo0 192.168.1.0/24 link#11 U 0 2 wlan0 192.168.1.10 link#11 UHS 0 0 lo0 ------------------------------------------------------------------------ netstat -anA Active Internet connections (including servers) Tcpcb Proto Recv-Q Send-Q Local Address Foreign Address (state) fffffe00065d3000 tcp4 0 0 192.168.1.10.45335 195.24.233.57.80 TIME_WAIT fffffe00065fd7a0 tcp4 0 0 *.113 *.* LISTEN fffffe00065fdb70 tcp4 0 0 127.0.0.1.25 *.* LISTEN fffffe000643e3d0 tcp4 0 0 127.0.0.1.6600 127.0.0.1.34032 ESTABLISHED fffffe000643e7a0 tcp4 0 0 127.0.0.1.34032 127.0.0.1.6600 ESTABLISHED fffffe00065fe000 tcp4 0 0 *.6600 *.* LISTEN fffffe00061f6ab8 udp4 0 0 *.514 *.* fffffe00061f5498 udp4 0 0 *.* *.* Active UNIX domain sockets Address Type Recv-Q Send-Q Inode Conn Refs Nextref Addr fffffe0006459e10 stream 0 0 0 fffffe00064b7960 0 0 /var/run/dbus/system_bus_socket fffffe00064b7960 stream 0 0 0 fffffe0006459e10 0 0 fffffe000645ad20 stream 0 0 0 fffffe0006459690 0 0 /var/run/hald/dbus-zVYHHE10Qt fffffe0006459690 stream 0 0 0 fffffe000645ad20 0 0 fffffe00068c55a0 stream 0 0 0 fffffe00068c52d0 0 0 /var/run/hald/dbus-zVYHHE10Qt fffffe00068c52d0 stream 0 0 0 fffffe00068c55a0 0 0 fffffe00064b7d20 stream 0 0 0 fffffe00064b7e10 0 0 /var/run/devd.pipe fffffe00064b7e10 stream 0 0 0 fffffe00064b7d20 0 0 fffffe0006459960 stream 0 0 0 fffffe0006459870 0 0 /var/run/hald/dbus-TOYaXgEs2a fffffe0006459870 stream 0 0 0 fffffe0006459960 0 0 fffffe0006459780 stream 0 0 fffffe0006859b10 0 0 0 /var/run/hald/dbus-TOYaXgEs2a fffffe000683f000 stream 0 0 0 fffffe000683f0f0 0 0 /tmp/fam-root/fam- fffffe000683f0f0 stream 0 0 0 fffffe000683f000 0 0 fffffe000683f1e0 stream 0 0 fffffe0006849000 0 0 0 /tmp/fam-root/fam- fffffe000683f3c0 stream 0 0 0 fffffe000683f4b0 0 0 /var/run/dbus/system_bus_socket fffffe000683f4b0 stream 0 0 0 fffffe000683f3c0 0 0 fffffe000645a1e0 stream 0 0 0 fffffe000645a2d0 0 0 /var/run/dbus/system_bus_socket fffffe000645a2d0 stream 0 0 0 fffffe000645a1e0 0 0 fffffe00064b70f0 stream 0 0 0 fffffe000645ae10 0 0 /var/run/dbus/system_bus_socket fffffe000645ae10 stream 0 0 0 fffffe00064b70f0 0 0 fffffe00064592d0 stream 0 0 0 fffffe00064593c0 0 0 /var/run/dbus/system_bus_socket fffffe00064593c0 stream 0 0 0 fffffe00064592d0 0 0 fffffe00064594b0 stream 0 0 fffffe00066b3588 0 0 0 /var/run/hald/dbus-zVYHHE10Qt fffffe000645a780 stream 0 0 0 fffffe000645a690 0 0 /var/run/dbus/system_bus_socket fffffe000645a690 stream 0 0 0 fffffe000645a780 0 0 fffffe000645a5a0 stream 0 0 0 fffffe000645a4b0 0 0 fffffe000645a4b0 stream 0 0 0 fffffe000645a5a0 0 0 fffffe000645a3c0 stream 0 0 fffffe00064df1d8 0 0 0 /var/run/dbus/system_bus_socket fffffe00064b7000 stream 0 0 fffffe000619d000 0 0 0 /var/run/devd.pipe fffffe00068c50f0 dgram 0 0 0 fffffe0006459a50 0 fffffe000645aa50 fffffe000645ab40 dgram 0 0 0 fffffe0006459b40 0 fffffe000645a960 fffffe000645aa50 dgram 0 0 0 fffffe0006459a50 0 fffffe000645a870 fffffe000645a960 dgram 0 0 0 fffffe0006459b40 0 0 fffffe000645a870 dgram 0 0 0 fffffe0006459a50 0 fffffe000645a0f0 fffffe000645a0f0 dgram 0 0 0 fffffe0006459a50 0 0 fffffe0006459a50 dgram 0 0 fffffe00061d3000 0 fffffe00068c50f0 0 /var/run/logpriv fffffe0006459b40 dgram 0 0 fffffe00061d31d8 0 fffffe000645ab40 0 /var/run/log fffffe00064b71e0 dgram 0 0 fffffe00061bc000 0 0 0 /var/run/wpa_supplicant/wlan0 ------------------------------------------------------------------------ netstat -aL Current listen queue sizes (qlen/incqlen/maxqlen) Proto Listen Local Address tcp4 0/0/5 *.auth tcp4 0/0/10 localhost.otaku.smtp tcp4 0/0/5 *.6600 unix 0/0/30 /var/run/hald/dbus-TOYaXgEs2a unix 0/0/30 /tmp/fam-root/fam- unix 0/0/30 /var/run/hald/dbus-zVYHHE10Qt unix 0/0/30 /var/run/dbus/system_bus_socket unix 0/0/4 /var/run/devd.pipe ------------------------------------------------------------------------ fstat USER CMD PID FD MOUNT INUM MODE SZ|DV R/W arundel sysctl 902 root / 2 drwxr-xr-x 1024 r arundel sysctl 902 wd /usr 21456023 drwxr-xr-x 6144 r arundel sysctl 902 text / 22845503 -r-xr-xr-x 15224 r arundel sysctl 902 ctty /dev 49 crw------- ttyv0 rw arundel sysctl 902 0 /dev 49 crw------- ttyv0 rw arundel sysctl 902 1 /dev 49 crw------- ttyv0 rw arundel sysctl 902 2 /dev 49 crw------- ttyv0 rw root hald-addon-storage 894 root / 2 drwxr-xr-x 1024 r root hald-addon-storage 894 wd /usr 20608124 drwxr-xr-x 2560 r root hald-addon-storage 894 text /usr 20609229 -r-xr-xr-x 20416 r root hald-addon-storage 894 0 /dev 9 crw-rw-rw- null r root hald-addon-storage 894 1 /dev 9 crw-rw-rw- null rw root hald-addon-storage 894 2 /dev 9 crw-rw-rw- null rw root hald-addon-storage 894 3* local stream fffffe0006459690 <-> fffffe000645ad20 root hald-addon-storage 894 4* local stream fffffe00064b7960 <-> fffffe0006459e10 root hald-addon-mouse-s 874 root / 2 drwxr-xr-x 1024 r root hald-addon-mouse-s 874 wd /usr 20608124 drwxr-xr-x 2560 r root hald-addon-mouse-s 874 text /usr 20609239 -r-xr-xr-x 13488 r root hald-addon-mouse-s 874 0 /dev 9 crw-rw-rw- null r root hald-addon-mouse-s 874 1 /dev 9 crw-rw-rw- null rw root hald-addon-mouse-s 874 2 /dev 9 crw-rw-rw- null rw root hald-addon-mouse-s 874 3* local stream fffffe00068c52d0 <-> fffffe00068c55a0 arundel zsh 873 root / 2 drwxr-xr-x 1024 r arundel zsh 873 wd /usr 21456023 drwxr-xr-x 6144 r arundel zsh 873 text /usr 20325937 -r-xr-xr-x 604688 r arundel zsh 873 ctty /dev 49 crw------- ttyv0 rw arundel zsh 873 0 /dev 49 crw------- ttyv0 rw arundel zsh 873 1 /dev 49 crw------- ttyv0 rw arundel zsh 873 2 /dev 49 crw------- ttyv0 rw arundel zsh 873 10 /dev 49 crw------- ttyv0 rw root hald-runner 842 root / 2 drwxr-xr-x 1024 r root hald-runner 842 wd / 2 drwxr-xr-x 1024 r root hald-runner 842 text /usr 20609080 -r-xr-xr-x 17008 r root hald-runner 842 0 /dev 9 crw-rw-rw- null r root hald-runner 842 1 /dev 9 crw-rw-rw- null rw root hald-runner 842 2 /dev 9 crw-rw-rw- null rw root hald-runner 842 3* local stream fffffe0006459870 <-> fffffe0006459960 root hald-runner 842 7* pipe fffffe000618a430 <-> fffffe000618a2d8 0 rw root hald-runner 842 8* pipe fffffe0006843708 <-> fffffe00068435b0 0 rw root hald-runner 842 9* pipe fffffe0006843158 <-> fffffe0006843000 0 rw root hald-runner 842 10* pipe fffffe000618a708 <-> fffffe000618a5b0 0 rw root hald-runner 842 11* pipe fffffe0006844708 <-> fffffe00068445b0 0 rw root hald-runner 842 12* pipe fffffe00060fe430 <-> fffffe00060fe2d8 0 rw root hald-runner 842 13* pipe fffffe00066f9cb8 <-> fffffe00066f9b60 0 rw root hald-runner 842 14* pipe fffffe000618a9e0 <-> fffffe000618a888 0 rw root hald-runner 842 15* pipe fffffe00066f9708 <-> fffffe00066f95b0 0 rw root hald-runner 842 16* pipe fffffe0006189708 <-> fffffe00061895b0 0 rw root hald-runner 842 17* pipe fffffe00066f9430 <-> fffffe00066f92d8 0 rw root hald-runner 842 18* pipe fffffe00060fe9e0 <-> fffffe00060fe888 0 rw root hald-runner 842 19* pipe fffffe00060fe708 <-> fffffe00060fe5b0 0 rw root hald-runner 842 20* pipe fffffe00068b9708 <-> fffffe00068b95b0 0 rw root hald-runner 842 21* pipe fffffe00068b9158 <-> fffffe00068b9000 0 rw root hald-runner 842 22* pipe fffffe00068c49e0 <-> fffffe00068c4888 0 rw root hald-runner 842 23* pipe fffffe00068c4430 <-> fffffe00068c42d8 0 rw root hald-runner 842 24* pipe fffffe00061069e0 <-> fffffe0006106888 0 rw root hald-runner 842 25* pipe fffffe0006106430 <-> fffffe00061062d8 0 rw root hald-runner 842 26* pipe fffffe0006845cb8 <-> fffffe0006845b60 0 rw root hald-runner 842 27* pipe fffffe0006189158 <-> fffffe0006189000 0 rw root hald-runner 842 28* pipe fffffe000618acb8 <-> fffffe000618ab60 0 rw root hald-runner 842 29* pipe fffffe00068439e0 <-> fffffe0006843888 0 rw root hald-runner 842 30* pipe fffffe0006844430 <-> fffffe00068442d8 0 rw root hald-runner 842 31* pipe fffffe0006845708 <-> fffffe00068455b0 0 rw root hald-runner 842 32* pipe fffffe00060fe158 <-> fffffe00060fe000 0 rw root hald-runner 842 33* pipe fffffe00068459e0 <-> fffffe0006845888 0 rw root hald-runner 842 34* pipe fffffe00068c4158 <-> fffffe00068c4000 0 rw root hald-runner 842 35* pipe fffffe00068c4708 <-> fffffe00068c45b0 0 rw root hald-runner 842 36* pipe fffffe00068b9430 <-> fffffe00068b92d8 0 rw root hald-runner 842 37* pipe fffffe00068449e0 <-> fffffe0006844888 0 rw root hald-runner 842 38* pipe fffffe000698b158 <-> fffffe000698b000 0 rw root hald-runner 842 39* pipe fffffe000698a9e0 <-> fffffe000698a888 0 rw root hald-runner 842 40* pipe fffffe0006504708 <-> fffffe00065045b0 0 rw root hald-runner 842 41* pipe fffffe000698a430 <-> fffffe000698a2d8 0 rw root hald-runner 842 42* pipe fffffe000697bcb8 <-> fffffe000697bb60 0 rw root hald-runner 842 43* pipe fffffe000618a158 <-> fffffe000618a000 0 rw root hald-runner 842 44* pipe fffffe000697b708 <-> fffffe000697b5b0 0 rw root hald-runner 842 45* pipe fffffe000697b158 <-> fffffe000697b000 0 rw root hald-runner 842 46* pipe fffffe00068b99e0 <-> fffffe00068b9888 0 rw root hald-runner 842 47* pipe fffffe00060fd430 <-> fffffe00060fd2d8 0 rw root hald-runner 842 48* pipe fffffe00068b9cb8 <-> fffffe00068b9b60 0 rw root hald-runner 842 49* pipe fffffe000697b9e0 <-> fffffe000697b888 0 rw root hald-runner 842 50* pipe fffffe00065049e0 <-> fffffe0006504888 0 rw root hald-runner 842 51* pipe fffffe0006845158 <-> fffffe0006845000 0 rw root hald-runner 842 52* pipe fffffe000698a708 <-> fffffe000698a5b0 0 rw root hald-runner 842 53* pipe fffffe000698a158 <-> fffffe000698a000 0 rw root hald-runner 842 54* pipe fffffe000697b430 <-> fffffe000697b2d8 0 rw root hald-runner 842 55* pipe fffffe0006504cb8 <-> fffffe0006504b60 0 rw root hald-runner 842 56* pipe fffffe000698acb8 <-> fffffe000698ab60 0 rw root hald-runner 842 57* pipe fffffe00069b2cb8 <-> fffffe00069b2b60 0 rw root hald-runner 842 58* pipe fffffe00069b2708 <-> fffffe00069b25b0 0 rw root hald-runner 842 59* pipe fffffe00069b2158 <-> fffffe00069b2000 0 rw root gam_server 841 root / 2 drwxr-xr-x 1024 r root gam_server 841 wd / 2 drwxr-xr-x 1024 r root gam_server 841 text /usr 20608596 -r-xr-xr-x 74536 r root gam_server 841 0 /dev 9 crw-rw-rw- null r root gam_server 841 1 /dev 9 crw-rw-rw- null w root gam_server 841 2 /dev 9 crw-rw-rw- null w root gam_server 841 4* local stream fffffe000683f1e0 root gam_server 841 5* pipe fffffe0006844b60 <-> fffffe0006844cb8 0 rw root gam_server 841 6* pipe fffffe0006844cb8 <-> fffffe0006844b60 0 rw root gam_server 841 7* local stream fffffe000683f000 <-> fffffe000683f0f0 root gam_server 841 8 /usr 21832714 drwxr-xr-x 512 r root gam_server 841 9 /usr 21832776 -r--r--r-- 26899 r root gam_server 841 10 /usr 21832715 -r--r--r-- 1352 r root gam_server 841 11 /usr 21832731 -r--r--r-- 1652 r root gam_server 841 12 /var 188482 -rw-r--r-- 68 r root gam_server 841 13 /usr 20849213 drwxr-xr-x 512 r root gam_server 841 14 /usr 20849214 -r--r--r-- 267 r root gam_server 841 15 /var 23565 drwxr-xr-x 512 r root gam_server 841 16 /usr 20749460 drwxr-xr-x 512 r root gam_server 841 17 /var 23566 drwxr-xr-x 512 r root gam_server 841 18 /usr 20749461 drwxr-xr-x 512 r root gam_server 841 19 /var 23567 drwxr-xr-x 512 r root gam_server 841 20 /usr 20749462 drwxr-xr-x 512 r root gam_server 841 21 /var 23568 drwxr-xr-x 512 r root gam_server 841 22 /usr 20849211 drwxr-xr-x 512 r root gam_server 841 23 /var 23569 drwxr-xr-x 512 r root gam_server 841 24 /usr 20849212 drwxr-xr-x 512 r root gam_server 841 25 /var 23564 drwxr-xr-x 512 r root gam_server 841 26 /var 23565 drwxr-xr-x 512 r root gam_server 841 27 /var 23566 drwxr-xr-x 512 r root gam_server 841 28 /var 23567 drwxr-xr-x 512 r root gam_server 841 29 /var 23568 drwxr-xr-x 512 r root gam_server 841 30 /var 23569 drwxr-xr-x 512 r root gam_server 841 31 /usr 20749459 drwx------ 512 r root gam_server 841 32 /usr 20749460 drwxr-xr-x 512 r root gam_server 841 33 /usr 20749461 drwxr-xr-x 512 r root gam_server 841 34 /usr 20749462 drwxr-xr-x 512 r root gam_server 841 35 /usr 20849211 drwxr-xr-x 512 r root gam_server 841 36 /usr 20849212 drwxr-xr-x 512 r root polkitd 839 root / 2 drwxr-xr-x 1024 r root polkitd 839 wd / 2 drwxr-xr-x 1024 r root polkitd 839 text /usr 20608810 -r-xr-xr-x 11240 r root polkitd 839 0 /dev 9 crw-rw-rw- null rw root polkitd 839 1 /dev 9 crw-rw-rw- null rw root polkitd 839 2 /dev 9 crw-rw-rw- null rw root polkitd 839 3* pipe fffffe00060fd5b0 <-> fffffe00060fd708 0 rw root polkitd 839 4 /dev 9 crw-rw-rw- null rw root polkitd 839 5* pipe fffffe00060fd708 <-> fffffe00060fd5b0 0 rw root polkitd 839 6 /usr 20608034 drwxr-xr-x 512 r root polkitd 839 7 /usr 20420668 drwxr-xr-x 512 r root polkitd 839 8 /usr 20796426 drwxr-xr-x 512 r root polkitd 839 10* local stream fffffe000683f4b0 <-> fffffe000683f3c0 root polkitd 839 11* pipe fffffe00066f9000 <-> fffffe00066f9158 0 rw root polkitd 839 12* pipe fffffe00066f9158 <-> fffffe00066f9000 0 rw root polkitd 839 13* pipe fffffe00066f8000 <-> fffffe00066f8158 0 rw root polkitd 839 14* pipe fffffe00066f8158 <-> fffffe00066f8000 0 rw root polkitd 839 15* local stream fffffe000683f0f0 <-> fffffe000683f000 root console-kit-daemon 837 root / 2 drwxr-xr-x 1024 r root console-kit-daemon 837 wd / 2 drwxr-xr-x 1024 r root console-kit-daemon 837 text /usr 20608823 -r-xr-xr-x 133040 r root console-kit-daemon 837 0 /dev 9 crw-rw-rw- null rw root console-kit-daemon 837 1 /dev 9 crw-rw-rw- null rw root console-kit-daemon 837 2 /dev 9 crw-rw-rw- null rw root console-kit-daemon 837 3* pipe fffffe00066f8b60 <-> fffffe00066f8cb8 0 rw root console-kit-daemon 837 4 /dev 9 crw-rw-rw- null rw root console-kit-daemon 837 5* pipe fffffe00066f8cb8 <-> fffffe00066f8b60 0 rw root console-kit-daemon 837 6 /usr 20608034 drwxr-xr-x 512 r root console-kit-daemon 837 7 /usr 20420668 drwxr-xr-x 512 r root console-kit-daemon 837 8 /usr 20796426 drwxr-xr-x 512 r root console-kit-daemon 837 9* pipe fffffe00066f9888 <-> fffffe00066f99e0 0 rw root console-kit-daemon 837 10* pipe fffffe00066f99e0 <-> fffffe00066f9888 0 rw root console-kit-daemon 837 11* local stream fffffe000645ae10 <-> fffffe00064b70f0 root console-kit-daemon 837 12 /var 212311 -rw-r--r-- 9577 w root console-kit-daemon 837 13* local stream fffffe000645a2d0 <-> fffffe000645a1e0 root console-kit-daemon 837 14 /dev 4 crw------- console r root console-kit-daemon 837 15* pipe fffffe00066f8888 <-> fffffe00066f89e0 0 rw root console-kit-daemon 837 16* pipe fffffe00066f89e0 <-> fffffe00066f8888 0 rw root console-kit-daemon 837 19* pipe fffffe0006504000 <-> fffffe0006504158 0 rw root console-kit-daemon 837 20* pipe fffffe0006504158 <-> fffffe0006504000 0 rw haldaemo hald 835 root / 2 drwxr-xr-x 1024 r haldaemo hald 835 wd / 2 drwxr-xr-x 1024 r haldaemo hald 835 text /usr 20609040 -r-xr-xr-x 289552 r haldaemo hald 835 0 /dev 9 crw-rw-rw- null rw haldaemo hald 835 1 /dev 9 crw-rw-rw- null rw haldaemo hald 835 2 /dev 9 crw-rw-rw- null rw haldaemo hald 835 3* pipe fffffe00066f85b0 <-> fffffe00066f8708 0 rw haldaemo hald 835 4* pipe fffffe00066f8708 <-> fffffe00066f85b0 0 rw haldaemo hald 835 7* pipe fffffe0006189b60 <-> fffffe0006189cb8 0 rw haldaemo hald 835 8* pipe fffffe0006189cb8 <-> fffffe0006189b60 0 rw haldaemo hald 835 9* local stream fffffe00064594b0 haldaemo hald 835 10* local stream fffffe00064593c0 <-> fffffe00064592d0 haldaemo hald 835 11* local stream fffffe0006459780 haldaemo hald 835 12* pipe fffffe0006843b60 <-> fffffe0006843cb8 0 rw haldaemo hald 835 13* pipe fffffe0006843cb8 <-> fffffe0006843b60 0 rw haldaemo hald 835 14* local stream fffffe0006459960 <-> fffffe0006459870 haldaemo hald 835 16 /dev 11 crw-r--r-- pci rw haldaemo hald 835 17 /dev 68 crw------- xpt0 rw haldaemo hald 835 19 /usr 20609170 -r--r--r-- 669 r haldaemo hald 835 20 /usr 20796431 drwxr-xr-x 512 r haldaemo hald 835 21 /var 23586 -rw-rw-r-- 0 r haldaemo hald 835 22 /usr 20796440 drwxr-xr-x 512 r haldaemo hald 835 23 /usr 20796442 drwxr-xr-x 512 r haldaemo hald 835 24 /usr 20796657 -rw-r--r-- 269 r haldaemo hald 835 25 /usr 20844208 drwxr-xr-x 512 r haldaemo hald 835 26 /usr 20844209 drwxr-xr-x 512 r haldaemo hald 835 27 /usr 20844189 drwxr-xr-x 512 r haldaemo hald 835 28 /usr 20844192 drwxr-xr-x 512 r haldaemo hald 835 29 /usr 20844190 drwxr-xr-x 512 r haldaemo hald 835 30 /usr 20844191 -r--r--r-- 1648 r haldaemo hald 835 31 /usr 20844193 drwxr-xr-x 512 r haldaemo hald 835 32 /usr 20844194 drwxr-xr-x 512 r haldaemo hald 835 33 /usr 20844207 drwxr-xr-x 512 r haldaemo hald 835 34 /usr 20844195 drwxr-xr-x 512 r haldaemo hald 835 35 /usr 20844206 -r--r--r-- 1603 r haldaemo hald 835 36 /usr 20844205 -r--r--r-- 20371 r haldaemo hald 835 37 /usr 20844204 -r--r--r-- 1214 r haldaemo hald 835 38 /usr 20844203 -r--r--r-- 1028 r haldaemo hald 835 39 /usr 20844202 -r--r--r-- 1236 r haldaemo hald 835 40 /usr 20844201 -r--r--r-- 1767 r haldaemo hald 835 41 /usr 20844200 -r--r--r-- 4032 r haldaemo hald 835 42 /usr 20844212 -r--r--r-- 257 r haldaemo hald 835 43 /usr 20844199 -r--r--r-- 390 r haldaemo hald 835 44 /usr 20844198 -r--r--r-- 1661 r haldaemo hald 835 45 /usr 20844196 -r--r--r-- 795 r haldaemo hald 835 46 /usr 20844197 -r--r--r-- 720 r haldaemo hald 835 47 /usr 20608046 drwxrwxr-x 512 r haldaemo hald 835 48 /usr 20608640 -rw-rw-r-- 269 r haldaemo hald 835 49 /usr 20609272 -rw-rw-r-- 518 r haldaemo hald 835 50 /usr 20609273 -rw-rw-r-- 2498 r haldaemo hald 835 51* local stream fffffe00064b7e10 <-> fffffe00064b7d20 haldaemo hald 835 52* local stream fffffe00068c55a0 <-> fffffe00068c52d0 haldaemo hald 835 53* local stream fffffe000645ad20 <-> fffffe0006459690 root getty 830 root / 2 drwxr-xr-x 1024 r root getty 830 wd / 2 drwxr-xr-x 1024 r root getty 830 text /usr 20304053 -r-xr-xr-x 26616 r root getty 830 ctty /dev 56 crw------- ttyv7 rw root getty 830 0 /dev 56 crw------- ttyv7 rw root getty 830 1 /dev 56 crw------- ttyv7 rw root getty 830 2 /dev 56 crw------- ttyv7 rw root getty 829 root / 2 drwxr-xr-x 1024 r root getty 829 wd / 2 drwxr-xr-x 1024 r root getty 829 text /usr 20304053 -r-xr-xr-x 26616 r root getty 829 ctty /dev 55 crw------- ttyv6 rw root getty 829 0 /dev 55 crw------- ttyv6 rw root getty 829 1 /dev 55 crw------- ttyv6 rw root getty 829 2 /dev 55 crw------- ttyv6 rw root getty 828 root / 2 drwxr-xr-x 1024 r root getty 828 wd / 2 drwxr-xr-x 1024 r root getty 828 text /usr 20304053 -r-xr-xr-x 26616 r root getty 828 ctty /dev 54 crw------- ttyv5 rw root getty 828 0 /dev 54 crw------- ttyv5 rw root getty 828 1 /dev 54 crw------- ttyv5 rw root getty 828 2 /dev 54 crw------- ttyv5 rw root getty 827 root / 2 drwxr-xr-x 1024 r root getty 827 wd / 2 drwxr-xr-x 1024 r root getty 827 text /usr 20304053 -r-xr-xr-x 26616 r root getty 827 ctty /dev 53 crw------- ttyv4 rw root getty 827 0 /dev 53 crw------- ttyv4 rw root getty 827 1 /dev 53 crw------- ttyv4 rw root getty 827 2 /dev 53 crw------- ttyv4 rw root getty 826 root / 2 drwxr-xr-x 1024 r root getty 826 wd / 2 drwxr-xr-x 1024 r root getty 826 text /usr 20304053 -r-xr-xr-x 26616 r root getty 826 ctty /dev 52 crw------- ttyv3 rw root getty 826 0 /dev 52 crw------- ttyv3 rw root getty 826 1 /dev 52 crw------- ttyv3 rw root getty 826 2 /dev 52 crw------- ttyv3 rw root getty 825 root / 2 drwxr-xr-x 1024 r root getty 825 wd / 2 drwxr-xr-x 1024 r root getty 825 text /usr 20304053 -r-xr-xr-x 26616 r root getty 825 ctty /dev 51 crw------- ttyv2 rw root getty 825 0 /dev 51 crw------- ttyv2 rw root getty 825 1 /dev 51 crw------- ttyv2 rw root getty 825 2 /dev 51 crw------- ttyv2 rw root getty 824 root / 2 drwxr-xr-x 1024 r root getty 824 wd / 2 drwxr-xr-x 1024 r root getty 824 text /usr 20304053 -r-xr-xr-x 26616 r root getty 824 ctty /dev 50 crw------- ttyv1 rw root getty 824 0 /dev 50 crw------- ttyv1 rw root getty 824 1 /dev 50 crw------- ttyv1 rw root getty 824 2 /dev 50 crw------- ttyv1 rw root login 823 root / 2 drwxr-xr-x 1024 r root login 823 wd /usr 21456023 drwxr-xr-x 6144 r root login 823 text /usr 20302406 -r-sr-xr-x 20760 r root login 823 ctty /dev 49 crw------- ttyv0 rw root login 823 0 /dev 49 crw------- ttyv0 rw root login 823 1 /dev 49 crw------- ttyv0 rw root login 823 2 /dev 49 crw------- ttyv0 rw root login 823 3* local dgram fffffe00068c50f0 <-> fffffe0006459a50 nobody identd 795 root / 2 drwxr-xr-x 1024 r nobody identd 795 wd / 2 drwxr-xr-x 1024 r nobody identd 795 text /usr 20608105 -r-xr-xr-x 14955 r nobody identd 795 0* internet stream tcp fffffe00065fd7a0 root cron 785 root / 2 drwxr-xr-x 1024 r root cron 785 wd /var 211968 drwxr-x--- 512 r root cron 785 text /usr 21856484 -r-xr-xr-x 37800 r root cron 785 0 /dev 9 crw-rw-rw- null rw root cron 785 1 /dev 9 crw-rw-rw- null rw root cron 785 2 /dev 9 crw-rw-rw- null rw root cron 785 3 /var 188477 -rw------- 3 w root cron 785 5* local dgram fffffe000645aa50 <-> fffffe0006459a50 smmsp sendmail 781 root / 2 drwxr-xr-x 1024 r smmsp sendmail 781 wd /var 164889 drwxrwx--- 512 r smmsp sendmail 781 text /usr 20303046 -r-xr-sr-x 655192 r smmsp sendmail 781 0 /dev 9 crw-rw-rw- null r smmsp sendmail 781 1 /dev 9 crw-rw-rw- null w smmsp sendmail 781 2 /dev 9 crw-rw-rw- null w smmsp sendmail 781 3* local dgram fffffe000645a960 <-> fffffe0006459b40 smmsp sendmail 781 4 /var 164865 -rw------- 49 w root sendmail 778 root / 2 drwxr-xr-x 1024 r root sendmail 778 wd /var 164886 drwxr-xr-x 512 r root sendmail 778 text /usr 20303046 -r-xr-sr-x 655192 r root sendmail 778 0 /dev 9 crw-rw-rw- null r root sendmail 778 1 /dev 9 crw-rw-rw- null w root sendmail 778 2 /dev 9 crw-rw-rw- null w root sendmail 778 3* local dgram fffffe000645a870 <-> fffffe0006459a50 root sendmail 778 4* internet stream tcp fffffe00065fdb70 root sendmail 778 5 /var 188476 -rw------- 78 w nobody mpdscribble 737 root / 2 drwxr-xr-x 1024 r nobody mpdscribble 737 wd / 2 drwxr-xr-x 1024 r nobody mpdscribble 737 text /usr 20326157 -r-xr-xr-x 45464 r nobody mpdscribble 737 0 /dev 9 crw-rw-rw- null r nobody mpdscribble 737 1 /dev 9 crw-rw-rw- null w nobody mpdscribble 737 2 /dev 9 crw-rw-rw- null w nobody mpdscribble 737 3* internet stream tcp fffffe000643e7a0 arundel musicpd 732 root / 2 drwxr-xr-x 1024 r arundel musicpd 732 wd / 2 drwxr-xr-x 1024 r arundel musicpd 732 text /usr 20325587 -r-xr-xr-x 371936 r arundel musicpd 732 0 /dev 9 crw-rw-rw- null r arundel musicpd 732 1 /usr 21668183 -rw-r--r-- 11293423 w arundel musicpd 732 2 /usr 21668183 -rw-r--r-- 11293423 w arundel musicpd 732 3* local stream fffffe000645a690 <-> fffffe000645a780 arundel musicpd 732 4* internet stream tcp fffffe00065fe000 arundel musicpd 732 5* pipe fffffe00060fd888 <-> fffffe00060fd9e0 0 rw arundel musicpd 732 6* pipe fffffe00060fd9e0 <-> fffffe00060fd888 0 rw arundel musicpd 732 7* pipe fffffe00060feb60 <-> fffffe00060fecb8 0 rw arundel musicpd 732 8* pipe fffffe00060fecb8 <-> fffffe00060feb60 0 rw arundel musicpd 732 9* internet stream tcp fffffe000643e3d0 arundel musicpd 732 10 /dev 69 crw-rw-rw- mixer0 r messageb dbus-daemon 720 root / 2 drwxr-xr-x 1024 r messageb dbus-daemon 720 wd / 2 drwxr-xr-x 1024 r messageb dbus-daemon 720 text /usr 20326997 -r-xr-xr-x 377736 r messageb dbus-daemon 720 0 /dev 9 crw-rw-rw- null rw messageb dbus-daemon 720 1 /dev 9 crw-rw-rw- null rw messageb dbus-daemon 720 2 /dev 9 crw-rw-rw- null rw messageb dbus-daemon 720 3* local stream fffffe000645a3c0 messageb dbus-daemon 720 4 /dev 9 crw-rw-rw- null rw messageb dbus-daemon 720 6 /usr 20608034 drwxr-xr-x 512 r messageb dbus-daemon 720 7 /usr 20420668 drwxr-xr-x 512 r messageb dbus-daemon 720 8 /usr 20796426 drwxr-xr-x 512 r messageb dbus-daemon 720 9* local stream fffffe000645a4b0 <-> fffffe000645a5a0 messageb dbus-daemon 720 10* local stream fffffe000645a5a0 <-> fffffe000645a4b0 messageb dbus-daemon 720 11* local stream fffffe000645a780 <-> fffffe000645a690 messageb dbus-daemon 720 12* local stream fffffe00064592d0 <-> fffffe00064593c0 messageb dbus-daemon 720 13* local dgram fffffe000645ab40 <-> fffffe0006459b40 messageb dbus-daemon 720 14* local stream fffffe0006459e10 <-> fffffe00064b7960 messageb dbus-daemon 720 15* local stream fffffe00064b70f0 <-> fffffe000645ae10 messageb dbus-daemon 720 17* local stream fffffe000645a1e0 <-> fffffe000645a2d0 messageb dbus-daemon 720 19* local stream fffffe000683f3c0 <-> fffffe000683f4b0 root smartd 715 root / 2 drwxr-xr-x 1024 r root smartd 715 wd / 2 drwxr-xr-x 1024 r root smartd 715 text /usr 20608710 -r-xr-xr-x 384608 r root smartd 715 0 /dev 9 crw-rw-rw- null rw root smartd 715 1 /dev 9 crw-rw-rw- null rw root smartd 715 2 /dev 9 crw-rw-rw- null rw root powerd 687 root / 2 drwxr-xr-x 1024 r root powerd 687 wd / 2 drwxr-xr-x 1024 r root powerd 687 text /usr 21856570 -r-xr-xr-x 14888 r root powerd 687 0 /dev 9 crw-rw-rw- null rw root powerd 687 1 /dev 9 crw-rw-rw- null rw root powerd 687 2 /dev 9 crw-rw-rw- null rw root powerd 687 3 /var 188462 -rw------- 3 w root syslogd 623 root / 2 drwxr-xr-x 1024 r root syslogd 623 wd / 2 drwxr-xr-x 1024 r root syslogd 623 text /usr 21856598 -r-xr-xr-x 37008 r root syslogd 623 0 /dev 9 crw-rw-rw- null rw root syslogd 623 1 /dev 9 crw-rw-rw- null rw root syslogd 623 2 /dev 9 crw-rw-rw- null rw root syslogd 623 3 /var 188452 -rw------- 3 w root syslogd 623 4* local dgram fffffe0006459b40 root syslogd 623 5* local dgram fffffe0006459a50 root syslogd 623 6* internet dgram udp fffffe00061f6ab8 root syslogd 623 7 /dev 31 crw------- klog r root syslogd 623 9 - - bad - root syslogd 623 10 /var 212004 -rw-r--r-- 116447 w root syslogd 623 11 /var 211990 -rw------- 55 w root syslogd 623 12 /var 212283 -rw------- 10154 w root syslogd 623 13 /var 211980 -rw-r----- 2794 w root syslogd 623 14 /var 211984 -rw-r--r-- 60 w root syslogd 623 15 /var 211991 -rw------- 60 w root syslogd 623 16 /var 212002 -rw------- 78854 w root syslogd 623 17 /var 211994 -rw------- 60 w root syslogd 623 18 /var 211985 -rw-r----- 60 w root devd 436 root / 2 drwxr-xr-x 1024 r root devd 436 wd / 2 drwxr-xr-x 1024 r root devd 436 text / 22845452 -r-xr-xr-x 423504 r root devd 436 0 /dev 9 crw-rw-rw- null rw root devd 436 1 /dev 9 crw-rw-rw- null rw root devd 436 2 /dev 9 crw-rw-rw- null rw root devd 436 3 /dev 6 crw------- devctl r root devd 436 4* local stream fffffe00064b7000 root devd 436 5 /var 188436 -rw------- 3 w root devd 436 6* local stream fffffe00064b7d20 <-> fffffe00064b7e10 root wpa_supplicant 332 root / 2 drwxr-xr-x 1024 r root wpa_supplicant 332 wd / 2 drwxr-xr-x 1024 r root wpa_supplicant 332 text /usr 21856712 -r-xr-xr-x 341080 r root wpa_supplicant 332 0 /dev 9 crw-rw-rw- null rw root wpa_supplicant 332 1 /dev 9 crw-rw-rw- null rw root wpa_supplicant 332 2 /dev 9 crw-rw-rw- null rw root wpa_supplicant 332 3* internet dgram udp fffffe00061f5498 root wpa_supplicant 332 4* route raw 0 fffffe00061f42a8 root wpa_supplicant 332 5 /dev 29 crw------- bpf rw root wpa_supplicant 332 6* local dgram fffffe00064b71e0 root wpa_supplicant 332 7* local dgram fffffe000645a0f0 <-> fffffe0006459a50 root init 1 root / 2 drwxr-xr-x 1024 r root init 1 wd / 2 drwxr-xr-x 1024 r root init 1 text / 22845514 -r-xr-xr-x 411152 r ------------------------------------------------------------------------ dmesg Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-CURRENT #2 r234233=5c0394f-dirty: Fri Apr 13 22:00:03 CEST 2012 arundel@otaku:/usr/obj/usr/github-freebsd-head/sys/ARUNDEL amd64 CPU: Intel(R) Pentium(R) Dual CPU E2160 @ 1.80GHz (1800.00-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6fd Family = 6 Model = f Stepping = 13 Features=0xbfebfbff Features2=0xe39d AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 2147483648 (2048 MB) avail memory = 2038890496 (1944 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard acpi0: on motherboard acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 7fde0000 (3) failed cpu0: on acpi0 cpu1: on acpi0 attimer0: port 0x40-0x43 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 hpet0: iomem 0xfed00000-0xfed003ff irq 0,8 on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 450 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 atrtc0: port 0x70-0x73 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xb000-0xb07f mem 0xf6000000-0xf6ffffff,0xe0000000-0xefffffff,0xf4000000-0xf5ffffff irq 16 at device 0.0 on pci1 nvidia0: on vgapci0 vgapci0: child nvidia0 requested pci_enable_io vgapci0: child nvidia0 requested pci_enable_io uhci0: port 0xe100-0xe11f irq 16 at device 26.0 on pci0 usbus0 on uhci0 uhci1: port 0xe200-0xe21f irq 21 at device 26.1 on pci0 usbus1 on uhci1 uhci2: port 0xe000-0xe01f irq 18 at device 26.2 on pci0 usbus2 on uhci2 ehci0: mem 0xfa205000-0xfa2053ff irq 18 at device 26.7 on pci0 usbus3: EHCI version 1.0 usbus3 on ehci0 hdac0: mem 0xfa200000-0xfa203fff irq 22 at device 27.0 on pci0 pcib2: irq 16 at device 28.0 on pci0 pci2: on pcib2 pcib3: irq 19 at device 28.3 on pci0 pci3: on pcib3 pcib4: irq 16 at device 28.4 on pci0 pci4: on pcib4 uhci3: port 0xe300-0xe31f irq 23 at device 29.0 on pci0 usbus4 on uhci3 uhci4: port 0xe400-0xe41f irq 19 at device 29.1 on pci0 usbus5 on uhci4 uhci5: port 0xe500-0xe51f irq 18 at device 29.2 on pci0 usbus6 on uhci5 ehci1: mem 0xfa204000-0xfa2043ff irq 23 at device 29.7 on pci0 usbus7: EHCI version 1.0 usbus7 on ehci1 pcib5: at device 30.0 on pci0 pci5: on pcib5 ath0: mem 0xfa100000-0xfa10ffff irq 19 at device 1.0 on pci5 ath0: AR2413 mac 7.9 RF2413 phy 4.5 ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0056 isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0xe600-0xe607,0xe700-0xe703,0xe800-0xe807,0xe900-0xe903,0xea00-0xea1f mem 0xfa206000-0xfa2067ff irq 19 at device 31.2 on pci0 ahci0: AHCI v1.20 with 6 3Gbps ports, Port Multiplier supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich2: at channel 2 on ahci0 ahcich3: at channel 3 on ahci0 ahcich4: at channel 4 on ahci0 ahcich5: at channel 5 on ahci0 pci0: at device 31.3 (no driver attached) sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 acpi_perf0: on cpu0 coretemp0: on cpu0 p4tcc0: on cpu0 coretemp1: on cpu1 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 925092506000925 device_attach: est1 attach returned 6 p4tcc1: on cpu1 Timecounters tick every 1.000 msec hdacc0: at cad 2 on hdac0 hdaa0: at nid 1 on hdacc0 pcm0: at nid 20,22,21,23 and 24,26 on hdaa0 pcm1: at nid 27 and 25 on hdaa0 pcm2: at nid 30 and 31 on hdaa0 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 12Mbps Full Speed USB v1.0 usbus6: 12Mbps Full Speed USB v1.0 usbus7: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 ugen6.1: at usbus6 uhub6: on usbus6 ugen7.1: at usbus7 uhub7: on usbus7 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-7 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 238474MB (488395055 512 byte sectors: 16H 63S/T 16383C) ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 ada1: ATA-8 SATA 2.x device ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada1: Command Queueing enabled ada1: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) SMP: AP CPU #1 Launched! Timecounter "TSC-low" frequency 14062500 Hz quality 1000 cd0 at ahcich2 bus 0 scbus2 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub5: 2 ports with 2 removable, self powered uhub6: 2 ports with 2 removable, self powered Root mount waiting for: usbus7 usbus3 Root mount waiting for: usbus7 usbus3 Root mount waiting for: usbus7 usbus3 uhub3: 6 ports with 6 removable, self powered uhub7: 6 ports with 6 removable, self powered Root mount waiting for: usbus7 usbus3 Root mount waiting for: usbus7 usbus3 ugen3.2: at usbus3 umass0: on usbus3 da0 at umass-sim0 bus 0 scbus6 target 0 lun 0 da0: Fixed Direct Access SCSI-6 device da0: 40.000MB/s transfers da0: 953837MB (1953458176 512 byte sectors: 255H 63S/T 121597C) ugen7.2: at usbus7 umass1: on usbus7 da1 at umass-sim1 bus 1 scbus7 target 0 lun 0 da1: Removable Direct Access SCSI-2 device da1: 40.000MB/s transfers da1: 14877MB (30468303 512 byte sectors: 255H 63S/T 1896C) ugen0.2: at usbus0 ukbd0: on usbus0 kbd0 at ukbd0 ugen3.3: at usbus3 uhub8: on usbus3 uhub8: 4 ports with 4 removable, self powered ugen1.2: at usbus1 ums0: on usbus1 ums0: 7 buttons and [XYZ] coordinates ID=0 GEOM: da1: the secondary GPT header is not in the last LBA. Trying to mount root from ufs:/dev/ufs/rootfs [ro]... Setting hostuuid: 00000000-0000-0000-0000-001a4d4bb4eb. Setting hostid: 0x52f33628. Entropy harvesting: interrupts ethernet point_to_point kickstart. Starting file system checks: /dev/ufs/rootfs: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ufs/rootfs: clean, 113890993 free (977 frags, 14236252 blocks, 0.0% fragmentation) ** SU+J Recovering /dev/ufs/usrfs ** Reading 33554432 byte journal from inode 6. ** Building recovery table. ** Resolving unreferenced inode list. ** Processing journal entries. ** 1 journal records in 512 bytes for 6.25% utilization ** Freed 0 inodes (0 dirs) 0 blocks, and 0 frags. ***** FILE SYSTEM MARKED CLEAN ***** /dev/ufs/varfs: 29005 files, 344540 used, 668475 free (7083 frags, 82674 blocks, 0.7% fragmentation) Mounting local file systems:. Setting hostname: otaku. wlan0: Ethernet address: 00:0f:b5:82:07:c8 Starting wpa_supplicant. Starting Network: lo0 ath0. lo0: flags=8049 metric 0 mtu 16384 options=3 inet 127.0.0.1 netmask 0xff000000 ath0: flags=8802 metric 0 mtu 2290 ether 00:0f:b5:82:07:c8 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier Starting devd. Configuring keyboard: keymap keyrate keybell\^[[=0;0B. add net default: gateway 192.168.1.1 Generating host.conf. eval: cannot create /etc/host.conf: Read-only file system eval: cannot create /etc/host.conf: Read-only file system eval: cannot create /etc/host.conf: Read-only file system ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/lib/compat/pkg /usr/local/kde4/lib /usr/local/lib/gegl-0.1 /usr/local/lib/graphviz /usr/local/lib/nss /usr/local/lib/pidgin /usr/local/lib/pth /usr/local/lib/qt4 /usr/local/lib/virtualbox 32-bit compatibility ldconfig path: /usr/lib32 Creating and/or trimming log files. Starting syslogd. No core dumps found. Clearing /tmp (X related). Starting powerd. Starting smartd. Apr 14 12:10:39 otaku smartd[705]: Device: /dev/ada0, WARNING: May need -F samsung3 enabled; see manual for details. wlan0: link state changed to UP Starting dbus. Starting musicpd. Starting mpdscribble. /usr/local/etc/rc.d/linux_adobe: set_rcvar: not found Starting hald. Configuring keyboard: keymap keyrate keybell\^[[=0;0B. Configuring syscons: keymap keyrate keybell\^[[=0;0B cursor font8x16 font8x14 font8x8 blanktime. Starting cron. Local package initialization: fakeidentd. Sat Apr 14 12:10:46 CEST 2012 Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x100000f fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff804406ff stack pointer = 0x28:0xffffff8091e99760 frame pointer = 0x28:0xffffff8091e997d0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 902 (sysctl) Uptime: 40s Dumping 174 out of 2020 MB: ------------------------------------------------------------------------ kernel config config: File /boot/kernel/kernel doesn't contain configuration file. Either unsupported, or not compiled with INCLUDE_CONFIG_FILE ------------------------------------------------------------------------ ddb capture buffer --Nq2Wo0NMKNjxTN9z-- From owner-freebsd-current@FreeBSD.ORG Sat Apr 14 10:53:39 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C8D94106566B; Sat, 14 Apr 2012 10:53:39 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 95BE08FC0A; Sat, 14 Apr 2012 10:53:39 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q3EArcIx066220; Sat, 14 Apr 2012 06:53:38 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q3EArcSh066219; Sat, 14 Apr 2012 10:53:38 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 14 Apr 2012 10:53:38 GMT Message-Id: <201204141053.q3EArcSh066219@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 10:53:39 -0000 TB --- 2012-04-14 09:37:47 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-04-14 09:37:47 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-04-14 09:37:47 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2012-04-14 09:37:47 - cleaning the object tree TB --- 2012-04-14 09:38:58 - cvsupping the source tree TB --- 2012-04-14 09:38:58 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2012-04-14 09:39:30 - building world TB --- 2012-04-14 09:39:30 - CROSS_BUILD_TESTING=YES TB --- 2012-04-14 09:39:30 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-14 09:39:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-14 09:39:30 - SRCCONF=/dev/null TB --- 2012-04-14 09:39:30 - TARGET=sparc64 TB --- 2012-04-14 09:39:30 - TARGET_ARCH=sparc64 TB --- 2012-04-14 09:39:30 - TZ=UTC TB --- 2012-04-14 09:39:30 - __MAKE_CONF=/dev/null TB --- 2012-04-14 09:39:30 - cd /src TB --- 2012-04-14 09:39:30 - /usr/bin/make -B buildworld >>> World build started on Sat Apr 14 09:39:31 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 Sat Apr 14 10:47:03 UTC 2012 TB --- 2012-04-14 10:47:03 - generating LINT kernel config TB --- 2012-04-14 10:47:03 - cd /src/sys/sparc64/conf TB --- 2012-04-14 10:47:03 - /usr/bin/make -B LINT TB --- 2012-04-14 10:47:03 - cd /src/sys/sparc64/conf TB --- 2012-04-14 10:47:03 - /usr/sbin/config -m LINT TB --- 2012-04-14 10:47:03 - building LINT kernel TB --- 2012-04-14 10:47:03 - CROSS_BUILD_TESTING=YES TB --- 2012-04-14 10:47:03 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-14 10:47:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-14 10:47:03 - SRCCONF=/dev/null TB --- 2012-04-14 10:47:03 - TARGET=sparc64 TB --- 2012-04-14 10:47:03 - TARGET_ARCH=sparc64 TB --- 2012-04-14 10:47:03 - TZ=UTC TB --- 2012-04-14 10:47:03 - __MAKE_CONF=/dev/null TB --- 2012-04-14 10:47:03 - cd /src TB --- 2012-04-14 10:47:03 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Apr 14 10:47: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 -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/mxge/mxge_rss_eth_z8e.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/mxge/mxge_rss_ethp_z8e.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/my/if_my.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/netmap/netmap.c cc1: warnings being treated as errors In file included from /src/sys/dev/netmap/netmap.c:121: /src/sys/dev/netmap/netmap_mem2.c: In function 'netmap_ofstophys': /src/sys/dev/netmap/netmap_mem2.c:164: warning: format '%x' expects type 'unsigned int', but argument 6 has type 'vm_offset_t' [-Wformat] *** Error code 1 Stop in /obj/sparc64.sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-04-14 10:53:38 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-04-14 10:53:38 - ERROR: failed to build LINT kernel TB --- 2012-04-14 10:53:38 - 3286.13 user 592.57 system 4550.98 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sat Apr 14 10:56:40 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4D68C106564A; Sat, 14 Apr 2012 10:56:40 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 0454C8FC16; Sat, 14 Apr 2012 10:56:39 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q3EAudAb073539; Sat, 14 Apr 2012 06:56:39 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q3EAudcN073538; Sat, 14 Apr 2012 10:56:39 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 14 Apr 2012 10:56:39 GMT Message-Id: <201204141056.q3EAudcN073538@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 10:56:40 -0000 TB --- 2012-04-14 08:29:21 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-04-14 08:29:21 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-04-14 08:29:21 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2012-04-14 08:29:21 - cleaning the object tree TB --- 2012-04-14 08:30:31 - cvsupping the source tree TB --- 2012-04-14 08:30:31 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2012-04-14 08:31:13 - building world TB --- 2012-04-14 08:31:13 - CROSS_BUILD_TESTING=YES TB --- 2012-04-14 08:31:13 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-14 08:31:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-14 08:31:13 - SRCCONF=/dev/null TB --- 2012-04-14 08:31:13 - TARGET=powerpc TB --- 2012-04-14 08:31:13 - TARGET_ARCH=powerpc TB --- 2012-04-14 08:31:13 - TZ=UTC TB --- 2012-04-14 08:31:13 - __MAKE_CONF=/dev/null TB --- 2012-04-14 08:31:13 - cd /src TB --- 2012-04-14 08:31:13 - /usr/bin/make -B buildworld >>> World build started on Sat Apr 14 08:31: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 Sat Apr 14 10:42:42 UTC 2012 TB --- 2012-04-14 10:42:42 - generating LINT kernel config TB --- 2012-04-14 10:42:42 - cd /src/sys/powerpc/conf TB --- 2012-04-14 10:42:42 - /usr/bin/make -B LINT TB --- 2012-04-14 10:42:42 - cd /src/sys/powerpc/conf TB --- 2012-04-14 10:42:42 - /usr/sbin/config -m LINT TB --- 2012-04-14 10:42:42 - building LINT kernel TB --- 2012-04-14 10:42:42 - CROSS_BUILD_TESTING=YES TB --- 2012-04-14 10:42:42 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-14 10:42:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-14 10:42:42 - SRCCONF=/dev/null TB --- 2012-04-14 10:42:42 - TARGET=powerpc TB --- 2012-04-14 10:42:42 - TARGET_ARCH=powerpc TB --- 2012-04-14 10:42:42 - TZ=UTC TB --- 2012-04-14 10:42:42 - __MAKE_CONF=/dev/null TB --- 2012-04-14 10:42:42 - cd /src TB --- 2012-04-14 10:42:42 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Apr 14 10:42: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 [...] ld -Bshareable -d -warn-common -o ip_mroute.ko ip_mroute.kld objcopy --strip-debug ip_mroute.ko ===> iscsi (all) ===> iscsi/initiator (all) cc -O2 -pipe -DISCSI_INITIATOR_DEBUG=2 -DINVARIANTS -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/iscsi/initiator/../../.. -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc/src/sys/LINT -fno-builtin -msoft-float -mno-altivec -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -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 -c /src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/iscsi.c In file included from /src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/iscsi.c:34: ./opt_iscsi_initiator.h:1:1: error: "ISCSI_INITIATOR_DEBUG" redefined : error: this is the location of the previous definition *** Error code 1 Stop in /src/sys/modules/iscsi/initiator. *** Error code 1 Stop in /src/sys/modules/iscsi. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/powerpc.powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-04-14 10:56:39 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-04-14 10:56:39 - ERROR: failed to build LINT kernel TB --- 2012-04-14 10:56:39 - 6950.34 user 928.34 system 8838.30 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sat Apr 14 11:31:51 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7EE5810657B2; Sat, 14 Apr 2012 11:31:51 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 3FB128FC08; Sat, 14 Apr 2012 11:31:51 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q3EBVoSv067468; Sat, 14 Apr 2012 07:31:50 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q3EBVjWR067467; Sat, 14 Apr 2012 11:31:45 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 14 Apr 2012 11:31:45 GMT Message-Id: <201204141131.q3EBVjWR067467@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 11:31:51 -0000 TB --- 2012-04-14 08:48:17 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-04-14 08:48:17 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-04-14 08:48:17 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2012-04-14 08:48:17 - cleaning the object tree TB --- 2012-04-14 08:49:48 - cvsupping the source tree TB --- 2012-04-14 08:49:48 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2012-04-14 08:50:37 - building world TB --- 2012-04-14 08:50:37 - CROSS_BUILD_TESTING=YES TB --- 2012-04-14 08:50:37 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-14 08:50:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-14 08:50:37 - SRCCONF=/dev/null TB --- 2012-04-14 08:50:37 - TARGET=powerpc TB --- 2012-04-14 08:50:37 - TARGET_ARCH=powerpc64 TB --- 2012-04-14 08:50:37 - TZ=UTC TB --- 2012-04-14 08:50:37 - __MAKE_CONF=/dev/null TB --- 2012-04-14 08:50:37 - cd /src TB --- 2012-04-14 08:50:37 - /usr/bin/make -B buildworld >>> World build started on Sat Apr 14 08:50:38 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 Sat Apr 14 11:26:51 UTC 2012 TB --- 2012-04-14 11:26:51 - generating LINT kernel config TB --- 2012-04-14 11:26:51 - cd /src/sys/powerpc/conf TB --- 2012-04-14 11:26:51 - /usr/bin/make -B LINT TB --- 2012-04-14 11:26:51 - cd /src/sys/powerpc/conf TB --- 2012-04-14 11:26:51 - /usr/sbin/config -m LINT TB --- 2012-04-14 11:26:51 - building LINT kernel TB --- 2012-04-14 11:26:51 - CROSS_BUILD_TESTING=YES TB --- 2012-04-14 11:26:51 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-14 11:26:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-14 11:26:51 - SRCCONF=/dev/null TB --- 2012-04-14 11:26:51 - TARGET=powerpc TB --- 2012-04-14 11:26:51 - TARGET_ARCH=powerpc64 TB --- 2012-04-14 11:26:51 - TZ=UTC TB --- 2012-04-14 11:26:51 - __MAKE_CONF=/dev/null TB --- 2012-04-14 11:26:51 - cd /src TB --- 2012-04-14 11:26:51 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Apr 14 11:26:51 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/mxge/mxge_rss_eth_z8e.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/mxge/mxge_rss_ethp_z8e.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/my/if_my.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/netmap/netmap.c cc1: warnings being treated as errors In file included from /src/sys/dev/netmap/netmap.c:121: /src/sys/dev/netmap/netmap_mem2.c: In function 'netmap_ofstophys': /src/sys/dev/netmap/netmap_mem2.c:164: warning: format '%x' expects type 'unsigned int', but argument 6 has type 'vm_offset_t' [-Wformat] *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-04-14 11:31:45 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-04-14 11:31:45 - ERROR: failed to build LINT kernel TB --- 2012-04-14 11:31:45 - 7930.35 user 1095.79 system 9808.41 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sat Apr 14 13:00:14 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 77C261065670; Sat, 14 Apr 2012 13:00:14 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from smtp02.lnh.mail.rcn.net (smtp02.lnh.mail.rcn.net [207.172.157.102]) by mx1.freebsd.org (Postfix) with ESMTP id 08AEF8FC0C; Sat, 14 Apr 2012 13:00:13 +0000 (UTC) Received: from mr17.lnh.mail.rcn.net ([207.172.157.37]) by smtp02.lnh.mail.rcn.net with ESMTP; 14 Apr 2012 09:00:07 -0400 Received: from smtp04.lnh.mail.rcn.net (smtp04.lnh.mail.rcn.net [207.172.157.104]) by mr17.lnh.mail.rcn.net (MOS 4.3.4-GA) with ESMTP id BLC87494; Sat, 14 Apr 2012 09:00:03 -0400 Received: from 209-6-86-84.c3-0.smr-ubr2.sbo-smr.ma.cable.rcn.com (HELO jerusalem.litteratus.org.litteratus.org) ([209.6.86.84]) by smtp04.lnh.mail.rcn.net with ESMTP; 14 Apr 2012 08:59:43 -0400 From: Robert Huff MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20361.29886.740093.455933@jerusalem.litteratus.org> Date: Sat, 14 Apr 2012 08:59:42 -0400 To: Jeremie Le Hen In-Reply-To: <20120414090728.GA8798@felucia.tataz.chchile.org> References: <20120414090728.GA8798@felucia.tataz.chchile.org> X-Mailer: VM 7.17 under 21.5 (beta28) "fuki" XEmacs Lucid X-Junkmail-Whitelist: YES (by domain whitelist at mr17.lnh.mail.rcn.net) Cc: Alexander Best , freebsd-current@freebsd.org Subject: Re: howto debug a complete hard reset X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 13:00:14 -0000 Jeremie Le Hen writes: > This is probably a sysctl handler that is causing the reboot. You can > run this one-liner to spot the culprit (use sh): > > for i in $(sysctl -Na); do sysctl $i >> ~/sysctl.out; sync; done > > Each sysctl will be called in turn and the output is appended to > a file, but the file will forcibly written to the disk before the > next occurence. Um ... it is my understanding sync(8) does not guarantee pending i/o will be written before it returns, but merely requests this happen irrespective of when it would normally occur. An I mistaken? Robert Huff From owner-freebsd-current@FreeBSD.ORG Sat Apr 14 14:00:45 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 069C3106564A for ; Sat, 14 Apr 2012 14:00:45 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id B28348FC0A for ; Sat, 14 Apr 2012 14:00:44 +0000 (UTC) Received: from outgoing.leidinger.net (p5796CBEB.dip.t-dialin.net [87.150.203.235]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 20E3984401D; Sat, 14 Apr 2012 16:00:32 +0200 (CEST) Received: from unknown (IO.Leidinger.net [192.168.1.12]) by outgoing.leidinger.net (Postfix) with ESMTPS id 65B152DE8; Sat, 14 Apr 2012 16:00:29 +0200 (CEST) Date: Sat, 14 Apr 2012 16:00:28 +0200 From: Alexander Leidinger To: Sevan / Venture37 Message-ID: <20120414160028.00001573@unknown> In-Reply-To: <566771C2-84CA-4824-AE99-38EB5DE1F786@gmail.com> References: <566771C2-84CA-4824-AE99-38EB5DE1F786@gmail.com> X-Mailer: Claws Mail 3.7.10cvs42 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 20E3984401D.ABF7A X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.04, required 6, autolearn=disabled, ALL_TRUSTED -1.00, AWL -0.03, T_RP_MATCHES_RCVD -0.01) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1335016832.68998@8Wmbp5IDBNfTqLp/Mbi+0Q X-EBL-Spam-Status: No Cc: "freebsd-current@freebsd.org" Subject: Re: DTrace on FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 14:00:45 -0000 On Tue, 10 Apr 2012 02:18:38 +0100 Sevan / Venture37 wrote: > Hi, > Ryan Stone got a chance to give a brief talk at the dtrace.conf last > week where he covered the status of support on FreeBSD. > http://smartos.org/2012/04/09/dtrace-conf-2012-dtrace-on-freebsd/ > > I was wondering if the reason outlined by Ryan for why it DTrace > isn't switched on by default still hold true (licensing issue) or is > it just the case that it was forgotten about? I ask as It would be > nice to have DTrace on FreeBSD by default. As far as I remember the issue was that some people (maybe in behalf of companies) expressed their concern if the GENERIC kernel does not come with BSD-license-only code. For this reason jb@ worked on the KDTRACE_HOOKS code. What we need now is a verification, that this part of DTRACE is not "CDDL-infected". There was an internal discussion, triggered by the talk you mentioned above. A part (the simple one) of the code has been reviewed. Anyone interested in getting KDTRACE_HOOKS enabled by default is free to do an independent review and post it here. Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-current@FreeBSD.ORG Sat Apr 14 14:26:28 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A1908106564A; Sat, 14 Apr 2012 14:26:28 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 5A5318FC1B; Sat, 14 Apr 2012 14:26:28 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q3EEQMiN039817; Sat, 14 Apr 2012 10:26:22 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q3EEQMcN039808; Sat, 14 Apr 2012 14:26:22 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 14 Apr 2012 14:26:22 GMT Message-Id: <201204141426.q3EEQMcN039808@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 14:26:28 -0000 TB --- 2012-04-14 11:40:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-04-14 11:40:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-04-14 11:40:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2012-04-14 11:40:00 - cleaning the object tree TB --- 2012-04-14 11:46:28 - cvsupping the source tree TB --- 2012-04-14 11:46:28 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2012-04-14 11:48:41 - building world TB --- 2012-04-14 11:48:41 - CROSS_BUILD_TESTING=YES TB --- 2012-04-14 11:48:41 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-14 11:48:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-14 11:48:41 - SRCCONF=/dev/null TB --- 2012-04-14 11:48:41 - TARGET=pc98 TB --- 2012-04-14 11:48:41 - TARGET_ARCH=i386 TB --- 2012-04-14 11:48:41 - TZ=UTC TB --- 2012-04-14 11:48:41 - __MAKE_CONF=/dev/null TB --- 2012-04-14 11:48:41 - cd /src TB --- 2012-04-14 11:48:41 - /usr/bin/make -B buildworld >>> World build started on Sat Apr 14 11:48:42 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 Sat Apr 14 14:04:12 UTC 2012 TB --- 2012-04-14 14:04:12 - generating LINT kernel config TB --- 2012-04-14 14:04:12 - cd /src/sys/pc98/conf TB --- 2012-04-14 14:04:12 - /usr/bin/make -B LINT TB --- 2012-04-14 14:04:12 - cd /src/sys/pc98/conf TB --- 2012-04-14 14:04:12 - /usr/sbin/config -m LINT TB --- 2012-04-14 14:04:12 - building LINT kernel TB --- 2012-04-14 14:04:12 - CROSS_BUILD_TESTING=YES TB --- 2012-04-14 14:04:12 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-14 14:04:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-14 14:04:12 - SRCCONF=/dev/null TB --- 2012-04-14 14:04:12 - TARGET=pc98 TB --- 2012-04-14 14:04:12 - TARGET_ARCH=i386 TB --- 2012-04-14 14:04:12 - TZ=UTC TB --- 2012-04-14 14:04:12 - __MAKE_CONF=/dev/null TB --- 2012-04-14 14:04:12 - cd /src TB --- 2012-04-14 14:04:12 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Apr 14 14:04:12 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 [...] ld -Bshareable -d -warn-common -o ip_mroute.ko ip_mroute.kld objcopy --strip-debug ip_mroute.ko ===> iscsi (all) ===> iscsi/initiator (all) cc -O2 -pipe -DISCSI_INITIATOR_DEBUG=2 -DINVARIANTS -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/iscsi/initiator/../../.. -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98.i386/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/pc98.i386/src/sys/LINT -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -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 -c /src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/iscsi.c In file included from /src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/iscsi.c:34: ./opt_iscsi_initiator.h:1:1: error: "ISCSI_INITIATOR_DEBUG" redefined : error: this is the location of the previous definition *** Error code 1 Stop in /src/sys/modules/iscsi/initiator. *** Error code 1 Stop in /src/sys/modules/iscsi. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/pc98.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-04-14 14:26:22 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-04-14 14:26:22 - ERROR: failed to build LINT kernel TB --- 2012-04-14 14:26:22 - 7110.77 user 1024.44 system 9981.69 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sat Apr 14 14:30:59 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 83FF3106564A; Sat, 14 Apr 2012 14:30:59 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 421768FC14; Sat, 14 Apr 2012 14:30:59 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q3EEUwt9072159; Sat, 14 Apr 2012 10:30:58 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q3EEUwab072158; Sat, 14 Apr 2012 14:30:58 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 14 Apr 2012 14:30:58 GMT Message-Id: <201204141430.q3EEUwab072158@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 14:30:59 -0000 TB --- 2012-04-14 11:40:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-04-14 11:40:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-04-14 11:40:00 - starting HEAD tinderbox run for i386/i386 TB --- 2012-04-14 11:40:00 - cleaning the object tree TB --- 2012-04-14 11:47:20 - cvsupping the source tree TB --- 2012-04-14 11:47:20 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2012-04-14 11:49:01 - building world TB --- 2012-04-14 11:49:01 - CROSS_BUILD_TESTING=YES TB --- 2012-04-14 11:49:01 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-14 11:49:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-14 11:49:01 - SRCCONF=/dev/null TB --- 2012-04-14 11:49:01 - TARGET=i386 TB --- 2012-04-14 11:49:01 - TARGET_ARCH=i386 TB --- 2012-04-14 11:49:01 - TZ=UTC TB --- 2012-04-14 11:49:01 - __MAKE_CONF=/dev/null TB --- 2012-04-14 11:49:01 - cd /src TB --- 2012-04-14 11:49:01 - /usr/bin/make -B buildworld >>> World build started on Sat Apr 14 11:49:02 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 Sat Apr 14 14:04:37 UTC 2012 TB --- 2012-04-14 14:04:37 - generating LINT kernel config TB --- 2012-04-14 14:04:37 - cd /src/sys/i386/conf TB --- 2012-04-14 14:04:37 - /usr/bin/make -B LINT TB --- 2012-04-14 14:04:38 - cd /src/sys/i386/conf TB --- 2012-04-14 14:04:38 - /usr/sbin/config -m LINT TB --- 2012-04-14 14:04:38 - building LINT kernel TB --- 2012-04-14 14:04:38 - CROSS_BUILD_TESTING=YES TB --- 2012-04-14 14:04:38 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-14 14:04:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-14 14:04:38 - SRCCONF=/dev/null TB --- 2012-04-14 14:04:38 - TARGET=i386 TB --- 2012-04-14 14:04:38 - TARGET_ARCH=i386 TB --- 2012-04-14 14:04:38 - TZ=UTC TB --- 2012-04-14 14:04:38 - __MAKE_CONF=/dev/null TB --- 2012-04-14 14:04:38 - cd /src TB --- 2012-04-14 14:04:38 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Apr 14 14:04:38 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 [...] ld -Bshareable -d -warn-common -o isci.ko isci.kld objcopy --strip-debug isci.ko ===> iscsi (all) ===> iscsi/initiator (all) cc -O2 -pipe -DISCSI_INITIATOR_DEBUG=2 -DINVARIANTS -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/iscsi/initiator/../../.. -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386.i386/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/i386.i386/src/sys/LINT -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -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 -c /src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/iscsi.c In file included from /src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/iscsi.c:34: ./opt_iscsi_initiator.h:1:1: error: "ISCSI_INITIATOR_DEBUG" redefined : error: this is the location of the previous definition *** Error code 1 Stop in /src/sys/modules/iscsi/initiator. *** Error code 1 Stop in /src/sys/modules/iscsi. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/i386.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-04-14 14:30:58 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-04-14 14:30:58 - ERROR: failed to build LINT kernel TB --- 2012-04-14 14:30:58 - 7356.15 user 1053.84 system 10257.91 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sat Apr 14 14:50:26 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD3D5106566C; Sat, 14 Apr 2012 14:50:26 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id A44658FC19; Sat, 14 Apr 2012 14:50:26 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q3EEoQR9032336; Sat, 14 Apr 2012 10:50:26 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q3EEoQ1F032326; Sat, 14 Apr 2012 14:50:26 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 14 Apr 2012 14:50:26 GMT Message-Id: <201204141450.q3EEoQ1F032326@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 14:50:27 -0000 TB --- 2012-04-14 11:40:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-04-14 11:40:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-04-14 11:40:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2012-04-14 11:40:00 - cleaning the object tree TB --- 2012-04-14 11:49:18 - cvsupping the source tree TB --- 2012-04-14 11:49:18 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2012-04-14 11:49:47 - building world TB --- 2012-04-14 11:49:47 - CROSS_BUILD_TESTING=YES TB --- 2012-04-14 11:49:47 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-14 11:49:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-14 11:49:47 - SRCCONF=/dev/null TB --- 2012-04-14 11:49:47 - TARGET=amd64 TB --- 2012-04-14 11:49:47 - TARGET_ARCH=amd64 TB --- 2012-04-14 11:49:47 - TZ=UTC TB --- 2012-04-14 11:49:47 - __MAKE_CONF=/dev/null TB --- 2012-04-14 11:49:47 - cd /src TB --- 2012-04-14 11:49:47 - /usr/bin/make -B buildworld >>> World build started on Sat Apr 14 11:49:48 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 Sat Apr 14 14:39:21 UTC 2012 TB --- 2012-04-14 14:39:21 - generating LINT kernel config TB --- 2012-04-14 14:39:21 - cd /src/sys/amd64/conf TB --- 2012-04-14 14:39:21 - /usr/bin/make -B LINT TB --- 2012-04-14 14:39:21 - cd /src/sys/amd64/conf TB --- 2012-04-14 14:39:21 - /usr/sbin/config -m LINT TB --- 2012-04-14 14:39:21 - building LINT kernel TB --- 2012-04-14 14:39:21 - CROSS_BUILD_TESTING=YES TB --- 2012-04-14 14:39:21 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-14 14:39:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-14 14:39:21 - SRCCONF=/dev/null TB --- 2012-04-14 14:39:21 - TARGET=amd64 TB --- 2012-04-14 14:39:21 - TARGET_ARCH=amd64 TB --- 2012-04-14 14:39:21 - TZ=UTC TB --- 2012-04-14 14:39:21 - __MAKE_CONF=/dev/null TB --- 2012-04-14 14:39:21 - cd /src TB --- 2012-04-14 14:39:21 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Apr 14 14:39:21 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/my/if_my.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/ncv/ncr53c500.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/ncv/ncr53c500_pccard.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/netmap/netmap.c cc1: warnings being treated as errors In file included from /src/sys/dev/netmap/netmap.c:121: /src/sys/dev/netmap/netmap_mem2.c: In function 'netmap_ofstophys': /src/sys/dev/netmap/netmap_mem2.c:164: warning: format '%x' expects type 'unsigned int', but argument 6 has type 'vm_offset_t' [-Wformat] *** Error code 1 Stop in /obj/amd64.amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-04-14 14:50:25 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-04-14 14:50:25 - ERROR: failed to build LINT kernel TB --- 2012-04-14 14:50:25 - 7960.61 user 1274.02 system 11425.14 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Sat Apr 14 15:03:03 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C7295106566C; Sat, 14 Apr 2012 15:03:03 +0000 (UTC) (envelope-from jeremie@le-hen.org) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [IPv6:2a01:e0c:1:1599::14]) by mx1.freebsd.org (Postfix) with ESMTP id 82CBB8FC15; Sat, 14 Apr 2012 15:03:00 +0000 (UTC) Received: from endor.tataz.chchile.org (unknown [82.233.239.98]) by smtp5-g21.free.fr (Postfix) with ESMTP id CACADD48142; Sat, 14 Apr 2012 17:02:54 +0200 (CEST) Received: from felucia.tataz.chchile.org (felucia.tataz.chchile.org [192.168.1.9]) by endor.tataz.chchile.org (Postfix) with ESMTP id 9F3AC999; Sat, 14 Apr 2012 17:02:53 +0200 (CEST) Received: by felucia.tataz.chchile.org (Postfix, from userid 1000) id 76D2B658D; Sat, 14 Apr 2012 15:02:53 +0000 (UTC) Date: Sat, 14 Apr 2012 17:02:53 +0200 From: Jeremie Le Hen To: Robert Huff Message-ID: <20120414150253.GB71196@felucia.tataz.chchile.org> Mail-Followup-To: Robert Huff , Alexander Best , freebsd-current@freebsd.org References: <20120414090728.GA8798@felucia.tataz.chchile.org> <20361.29886.740093.455933@jerusalem.litteratus.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20361.29886.740093.455933@jerusalem.litteratus.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Alexander Best , freebsd-current@freebsd.org, Jeremie Le Hen Subject: Re: howto debug a complete hard reset X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 15:03:03 -0000 On Sat, Apr 14, 2012 at 08:59:42AM -0400, Robert Huff wrote: > > > This is probably a sysctl handler that is causing the reboot. You can > > run this one-liner to spot the culprit (use sh): > > > > for i in $(sysctl -Na); do sysctl $i >> ~/sysctl.out; sync; done > > > > Each sysctl will be called in turn and the output is appended to > > a file, but the file will forcibly written to the disk before the > > next occurence. > > Um ... it is my understanding sync(8) does not guarantee > pending i/o will be written before it returns, but merely requests > this happen irrespective of when it would normally occur. > An I mistaken? Honestly I don't know, but I have do admit that the small paragraph in the BUGS section of the sync(2) manpage is a little bit shivering: BUGS The sync() system call may return before the buffers are completely flushed. Can any enlightened person answer this? -- Jeremie Le Hen Men are born free and equal. Later on, they're on their own. Jean Yanne From owner-freebsd-current@FreeBSD.ORG Sat Apr 14 15:42:00 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8BAB4106564A; Sat, 14 Apr 2012 15:42:00 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 5A3218FC08; Sat, 14 Apr 2012 15:42:00 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q3EFfxUM023512; Sat, 14 Apr 2012 11:41:59 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q3EFfxjP023503; Sat, 14 Apr 2012 15:41:59 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 14 Apr 2012 15:41:59 GMT Message-Id: <201204141541.q3EFfxjP023503@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 15:42:00 -0000 TB --- 2012-04-14 13:56:27 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-04-14 13:56:27 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-04-14 13:56:27 - starting HEAD tinderbox run for ia64/ia64 TB --- 2012-04-14 13:56:28 - cleaning the object tree TB --- 2012-04-14 13:57:38 - cvsupping the source tree TB --- 2012-04-14 13:57:38 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2012-04-14 13:58:38 - building world TB --- 2012-04-14 13:58:38 - CROSS_BUILD_TESTING=YES TB --- 2012-04-14 13:58:38 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-14 13:58:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-14 13:58:38 - SRCCONF=/dev/null TB --- 2012-04-14 13:58:38 - TARGET=ia64 TB --- 2012-04-14 13:58:38 - TARGET_ARCH=ia64 TB --- 2012-04-14 13:58:38 - TZ=UTC TB --- 2012-04-14 13:58:38 - __MAKE_CONF=/dev/null TB --- 2012-04-14 13:58:38 - cd /src TB --- 2012-04-14 13:58:38 - /usr/bin/make -B buildworld >>> World build started on Sat Apr 14 13:58:39 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 Sat Apr 14 15:32:13 UTC 2012 TB --- 2012-04-14 15:32:13 - generating LINT kernel config TB --- 2012-04-14 15:32:13 - cd /src/sys/ia64/conf TB --- 2012-04-14 15:32:13 - /usr/bin/make -B LINT TB --- 2012-04-14 15:32:13 - cd /src/sys/ia64/conf TB --- 2012-04-14 15:32:13 - /usr/sbin/config -m LINT TB --- 2012-04-14 15:32:13 - building LINT kernel TB --- 2012-04-14 15:32:13 - CROSS_BUILD_TESTING=YES TB --- 2012-04-14 15:32:13 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-14 15:32:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-14 15:32:13 - SRCCONF=/dev/null TB --- 2012-04-14 15:32:13 - TARGET=ia64 TB --- 2012-04-14 15:32:13 - TARGET_ARCH=ia64 TB --- 2012-04-14 15:32:13 - TZ=UTC TB --- 2012-04-14 15:32:13 - __MAKE_CONF=/dev/null TB --- 2012-04-14 15:32:13 - cd /src TB --- 2012-04-14 15:32:13 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Apr 14 15:32:13 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/mxge/mxge_rss_eth_z8e.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/mxge/mxge_rss_ethp_z8e.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/my/if_my.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/netmap/netmap.c cc1: warnings being treated as errors In file included from /src/sys/dev/netmap/netmap.c:121: /src/sys/dev/netmap/netmap_mem2.c: In function 'netmap_ofstophys': /src/sys/dev/netmap/netmap_mem2.c:164: warning: format '%x' expects type 'unsigned int', but argument 6 has type 'vm_offset_t' [-Wformat] *** Error code 1 Stop in /obj/ia64.ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-04-14 15:41:59 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-04-14 15:41:59 - ERROR: failed to build LINT kernel TB --- 2012-04-14 15:41:59 - 4703.71 user 717.90 system 6332.11 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sat Apr 14 16:59:00 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6FFDC106566B; Sat, 14 Apr 2012 16:59:00 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 26BE48FC14; Sat, 14 Apr 2012 16:59:00 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q3EGwxap024101; Sat, 14 Apr 2012 12:58:59 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q3EGwxt2024100; Sat, 14 Apr 2012 16:58:59 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 14 Apr 2012 16:58:59 GMT Message-Id: <201204141658.q3EGwxt2024100@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 16:59:00 -0000 TB --- 2012-04-14 14:30:58 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-04-14 14:30:58 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-04-14 14:30:58 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2012-04-14 14:30:58 - cleaning the object tree TB --- 2012-04-14 14:32:53 - cvsupping the source tree TB --- 2012-04-14 14:32:53 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2012-04-14 14:33:39 - building world TB --- 2012-04-14 14:33:39 - CROSS_BUILD_TESTING=YES TB --- 2012-04-14 14:33:39 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-14 14:33:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-14 14:33:39 - SRCCONF=/dev/null TB --- 2012-04-14 14:33:39 - TARGET=powerpc TB --- 2012-04-14 14:33:39 - TARGET_ARCH=powerpc TB --- 2012-04-14 14:33:39 - TZ=UTC TB --- 2012-04-14 14:33:39 - __MAKE_CONF=/dev/null TB --- 2012-04-14 14:33:39 - cd /src TB --- 2012-04-14 14:33:39 - /usr/bin/make -B buildworld >>> World build started on Sat Apr 14 14:33:39 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 Sat Apr 14 16:45:06 UTC 2012 TB --- 2012-04-14 16:45:06 - generating LINT kernel config TB --- 2012-04-14 16:45:06 - cd /src/sys/powerpc/conf TB --- 2012-04-14 16:45:06 - /usr/bin/make -B LINT TB --- 2012-04-14 16:45:06 - cd /src/sys/powerpc/conf TB --- 2012-04-14 16:45:06 - /usr/sbin/config -m LINT TB --- 2012-04-14 16:45:06 - building LINT kernel TB --- 2012-04-14 16:45:06 - CROSS_BUILD_TESTING=YES TB --- 2012-04-14 16:45:06 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-14 16:45:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-14 16:45:06 - SRCCONF=/dev/null TB --- 2012-04-14 16:45:06 - TARGET=powerpc TB --- 2012-04-14 16:45:06 - TARGET_ARCH=powerpc TB --- 2012-04-14 16:45:06 - TZ=UTC TB --- 2012-04-14 16:45:06 - __MAKE_CONF=/dev/null TB --- 2012-04-14 16:45:06 - cd /src TB --- 2012-04-14 16:45:06 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Apr 14 16:45:06 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 [...] ld -Bshareable -d -warn-common -o ip_mroute.ko ip_mroute.kld objcopy --strip-debug ip_mroute.ko ===> iscsi (all) ===> iscsi/initiator (all) cc -O2 -pipe -DISCSI_INITIATOR_DEBUG=2 -DINVARIANTS -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/iscsi/initiator/../../.. -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc/src/sys/LINT -fno-builtin -msoft-float -mno-altivec -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -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 -c /src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/iscsi.c In file included from /src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/iscsi.c:34: ./opt_iscsi_initiator.h:1:1: error: "ISCSI_INITIATOR_DEBUG" redefined : error: this is the location of the previous definition *** Error code 1 Stop in /src/sys/modules/iscsi/initiator. *** Error code 1 Stop in /src/sys/modules/iscsi. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/powerpc.powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-04-14 16:58:59 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-04-14 16:58:59 - ERROR: failed to build LINT kernel TB --- 2012-04-14 16:58:59 - 6949.14 user 931.15 system 8880.22 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sat Apr 14 18:11:35 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id AA9351065670; Sat, 14 Apr 2012 18:11:35 +0000 (UTC) Date: Sat, 14 Apr 2012 18:11:35 +0000 From: Alexander Best To: Robert Huff , freebsd-current@freebsd.org Message-ID: <20120414181135.GA94130@freebsd.org> References: <20120414090728.GA8798@felucia.tataz.chchile.org> <20361.29886.740093.455933@jerusalem.litteratus.org> <20120414150253.GB71196@felucia.tataz.chchile.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120414150253.GB71196@felucia.tataz.chchile.org> Cc: Subject: Re: howto debug a complete hard reset X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 18:11:35 -0000 On Sat Apr 14 12, Jeremie Le Hen wrote: > On Sat, Apr 14, 2012 at 08:59:42AM -0400, Robert Huff wrote: > > > > > This is probably a sysctl handler that is causing the reboot. You can > > > run this one-liner to spot the culprit (use sh): > > > > > > for i in $(sysctl -Na); do sysctl $i >> ~/sysctl.out; sync; done > > > > > > Each sysctl will be called in turn and the output is appended to > > > a file, but the file will forcibly written to the disk before the > > > next occurence. > > > > Um ... it is my understanding sync(8) does not guarantee > > pending i/o will be written before it returns, but merely requests > > this happen irrespective of when it would normally occur. > > An I mistaken? > > Honestly I don't know, but I have do admit that the small paragraph in > the BUGS section of the sync(2) manpage is a little bit shivering: > > BUGS > The sync() system call may return before the buffers are completely > flushed. > > > Can any enlightened person answer this? sync(2) does REQUEST an immediate write to disk. however for this to actually be the case, one has to disable softupdates and disable the write cache of that particular disk. the write cache of hdds is enabled by default, because disabling it will give you a huge performance drop. there's a small section about this in tuning(7). cheers. alex ps: SU+J also mustn't be enabled for immediate writes to happen. > > -- > Jeremie Le Hen > > Men are born free and equal. Later on, they're on their own. > Jean Yanne From owner-freebsd-current@FreeBSD.ORG Sat Apr 14 22:01:11 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69686106566B for ; Sat, 14 Apr 2012 22:01:11 +0000 (UTC) (envelope-from andy@neu.net) Received: from mail.neu.net (unknown [IPv6:2607:fc50:0:d300:216:3eff:fe54:f1c6]) by mx1.freebsd.org (Postfix) with ESMTP id EDBE78FC1A for ; Sat, 14 Apr 2012 22:01:10 +0000 (UTC) Received: from neu.net (neu.net [199.48.129.194]) by mail.neu.net (8.14.5/8.14.5) with ESMTP id q3EM11La017738; Sat, 14 Apr 2012 18:01:08 -0400 (EDT) (envelope-from andy@neu.net) Date: Sat, 14 Apr 2012 18:01:01 -0400 (EDT) From: AN To: "O. Hartmann" In-Reply-To: <4F889381.6090808@zedat.fu-berlin.de> Message-ID: References: <4F889381.6090808@zedat.fu-berlin.de> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-0.0 required=5.0 tests=T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mail.neu.net Cc: freebsd-current@freebsd.org Subject: Re: kernel build failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 22:01:11 -0000 On Fri, 13 Apr 2012, O. Hartmann wrote: > Am 04/13/12 00:21, schrieb AN: >> At Thu Apr 12 17:52:05 EDT 2012: >> >> [root@FBSD10 /usr/src]# svn up >> Updating '.': >> At revision 234196. >> >> Trying to build the kernel I get the following failure: >> >> time make -j8 buildkernel KERNCONF=MYKERNEL >> >> >> >> ===> zlib (all) >> cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE >> -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include >> /usr/obj/usr/src/sys/MYKERNEL/opt_global.h -I. -I@ -I@/contrib/altq >> -finline-limit=8000 --param inline-unit-growth=100 --param >> large-function-growth=1000 -fno-common -g -fno-omit-frame-pointer >> -I/usr/obj/usr/src/sys/MYKERNEL -mcmodel=kernel -mno-red-zone -mno-mmx >> -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding >> -fstack-protector -std=iso9899:1999 -fstack-protector -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 -c /usr/src/sys/modules/zlib/../../net/zlib.c >> ld -d -warn-common -r -d -o zlib.ko.debug zlib.o >> :> export_syms >> awk -f /usr/src/sys/conf/kmod_syms.awk zlib.ko.debug export_syms | >> xargs -J% objcopy % zlib.ko.debug >> objcopy --only-keep-debug zlib.ko.debug zlib.ko.symbols >> objcopy --strip-debug --add-gnu-debuglink=zlib.ko.symbols zlib.ko.debug >> zlib.ko >> 1 error >> *** [buildkernel] Error code 2 >> 1 error >> *** [buildkernel] Error code 2 >> 1 error >> >> real 8m20.095s >> user 12m37.161s >> sys 6m59.844s >> >> I tried this 4 times, twice with MYKERNEL and twice with GENERIC. It >> failed in the same spot every time. Is anyone else seeing this? >> >> Also, I tried without -j8, and it fails with the following: >> >> cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -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/usr/src/sys >> -I/usr/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 >> -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse >> -msoft-float -fno-asynchronous-unwind-tables -ffreestanding >> -fstack-protector -Werror /usr/src/sys/kern/subr_turnstile.c >> cc1: warnings being treated as errors >> /usr/src/sys/kern/subr_turnstile.c: In function 'propagate_priority': >> /usr/src/sys/kern/subr_turnstile.c:220: warning: implicit declaration of >> function 'kdb_backtrace_thread' >> /usr/src/sys/kern/subr_turnstile.c:220: warning: nested extern >> declaration of 'kdb_backtrace_thread' [-Wnested-externs] >> *** [subr_turnstile.o] Error code 1 >> >> Stop in /usr/obj/usr/src/sys/MYKERNEL. >> *** [buildkernel] Error code 1 >> >> Stop in /usr/src. >> *** [buildkernel] Error code 1 >> >> Stop in /usr/src. >> >> real 5m19.701s >> user 4m33.051s >> sys 0m51.466s >> >> >> >> Here is /etc/make.conf >> >> # cat /etc/make.conf >> OVERRIDE_LINUX_BASE_PORT=f10 >> QT4_OPTIONS= QGTKSTYLE >> WITH_OPENSSL_PORT=yes >> # added by use.perl 2012-04-04 01:11:13 >> PERL_VERSION=5.14.2 >> >> The kernel previously built without problems with this same configuration. >> _______________________________________________ > > > clang -c -O2 -pipe -pipe -O3 -fno-strict-aliasing -march=native -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 -Wno-error-tautological-compare > -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. > -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL > -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h > -fno-omit-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone > -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables > -ffreestanding -fstack-protector -Werror /usr/src/sys/kern/subr_turnstile.c > /usr/src/sys/kern/subr_turnstile.c:220:4: error: implicit declaration of > function 'kdb_backtrace_thread' is invalid in C99 > [-Werror,-Wimplicit-function-declaration] > kdb_backtrace_thread(td); > ^ > 1 error generated. > *** [subr_turnstile.o] Error code 1 > 1 error > *** [buildkernel] Error code 2 > 1 error > *** [buildkernel] Error code 2 > 1 error > > > I still get this error on one of my boxes. Another, with almost the same > setup and config, build fine! > All systems build with CLANG. They share the same /etc/src.conf and have > the same /etc/make.conf. > > Before building kernel/world, I cleanup/delete /usr/obj. But the error > still persists. > > > Regards, > Oliver > > I updated source with svn within the last hour, and rebuilt world and kernel. When I tried to boot to single-user mode to installworld the machine panicked and rebooted. I needed to boot kernel.old to get machine back. Is anyone else seeing a problem with the kernel? It seems it is still broken for me.