From owner-freebsd-current@FreeBSD.ORG Sun Jul 3 03:26:00 2011 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 B2AD3106564A for ; Sun, 3 Jul 2011 03:26:00 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 748788FC14 for ; Sun, 3 Jul 2011 03:26:00 +0000 (UTC) Received: by iwr19 with SMTP id 19so5026040iwr.13 for ; Sat, 02 Jul 2011 20:25:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=DavkpUdU9mnfkKYnXBmWpRKlc1aC0oehCoVFRUVcV3Q=; b=iwCEeQmDUJdVBwiGqFVjvEWqnx/V+/a8j/1qM8EeoD2lWnNdx6k36ImfGJy1yDLti8 OGM62JiLjZe6Pj3O7oRbFGyhiGEmc9ACDySG9z2d8JWb5muwBr56fGLn4RzwCgVwW0TG LWTryx0uzGbnXfs0Lqu0jimCUw1lsqHq+wH7s= Received: by 10.42.90.9 with SMTP id i9mr4219290icm.528.1309663559775; Sat, 02 Jul 2011 20:25:59 -0700 (PDT) Received: from DataIX.net (adsl-99-190-86-179.dsl.klmzmi.sbcglobal.net [99.190.86.179]) by mx.google.com with ESMTPS id v16sm2792076ibe.34.2011.07.02.20.25.57 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 02 Jul 2011 20:25:58 -0700 (PDT) Sender: "J. Hellenthal" Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id p633Psba081657 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 2 Jul 2011 23:25:54 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id p633PrJ3081652; Sat, 2 Jul 2011 23:25:53 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Sat, 2 Jul 2011 23:25:53 -0400 From: jhell To: Vassilis Laganakos Message-ID: <20110703032553.GA77276@DataIX.net> References: <4E0F3A53.3040309@yahoo.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TB36FDmn/VVEgNH/" Content-Disposition: inline In-Reply-To: <4E0F3A53.3040309@yahoo.com> Cc: freebsd-current@freebsd.org Subject: Re: Problems with cvsup on FreeBSD 9, AMD64, osreldate: 900038 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, 03 Jul 2011 03:26:00 -0000 --TB36FDmn/VVEgNH/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 02, 2011 at 04:33:39PM +0100, Vassilis Laganakos wrote: > Hello, >=20 > I am facing the same problems as Holger here: >=20 > http://lists.freebsd.org/pipermail/freebsd-current/2011-June/025205.html >=20 > although CVSup dies in gmtime_r in libc.so.7: >=20 > ... > Updating collection src-all/cvs > Edit src/UPDATING >=20 > Program received signal SIGSEGV, Segmentation fault. > 0x000000002ca10fb9 in gmtime_r () from /lib/libc.so.7 > ... >=20 > See full gdb backtrace at: >=20 > http://www.pastie.org/pastes/2154271 >=20 > So I'm now stuck in osrel 900038... I guess I need to rebuild libc.so.7 > with debugging symbols to find out what is going wrong there. >=20 > Any quick ideas on how to correct this, or if someone else is seeing=20 > this issue? >=20 Use csup(1) in base. This is in 7, 8 & 9. cvsup has been deprecated for much longer than it really needed to be and should probably be removed =66rom use as a client entirely and links generated for installation of cvsup -> csup. Only drawback for you may be no X interface but it really was not that pretty in the first place and served no real good purpose over the functionality of the command line client. An alternative if you need and X interface is creating a icon on your desktop that runs ( xterm -e csup /path/to/supfile ) or something similiar. --TB36FDmn/VVEgNH/ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: http://bit.ly/0x89D8547E iQEcBAEBAgAGBQJOD+FAAAoJEJBXh4mJ2FR+anMH/R53/zpTZu2ic2VHI2tL70kp 57IIIvxFn5lnbF2XLJ9YHglUvNXGlDR7eu/FvjLrCtBjfzfihxjHgHEkF0z4gY29 2QKRlsbFj6DzVkRtT+7LJTAxCndUGDLalz0+SdgenJajPIzouGUVpHZz0xDhx++c p9Wk40XMFqCBYQbvoMunTOF4/pzPzOxvUx1LvJPxsWoi+3NKFyiLsOHJgBAaZ35t R/IGSFaBFcO+tPnMJM96Yf0/F+tsZFjpPdpyddY4L41PeekBYpZtaQcPUgT03gSB 1ZwAsLtAlxZKGK0FT6I3LZsmnmsWuLdqhIf0hVs0xoPcG7UgAgtPbxut8lWUkcM= =J23x -----END PGP SIGNATURE----- --TB36FDmn/VVEgNH/-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 3 05:39:19 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id ED6A8106564A for ; Sun, 3 Jul 2011 05:39:19 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-4.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 2F63D15105B for ; Sun, 3 Jul 2011 05:39:19 +0000 (UTC) Message-ID: <4E100086.7080105@FreeBSD.org> Date: Sat, 02 Jul 2011 22:39:18 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.18) Gecko/20110624 Thunderbird/3.1.11 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: cardbus panic: end address is not aligned 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, 03 Jul 2011 05:39:20 -0000 I have 2 ath-based pc-card adapters. If I put either one of them in the slot while the system is up, or if I try booting with them in the slot, I get an instant panic. The cards previously worked in -current, and continue to work in 8-stable and windows xp. I don't have any other pc-cards to compare with. Full core.txt.0 file is in my home directory on freefall. This problem persists on r223732 but happened to me for the first time a week or 2 ago (haven't had time to report it previously, apologies). It likely originated a while before though, I don't use these cards very often. panic: end address is not aligned #1 0xffffffff80426a8a in kern_reboot (howto=260) at /home/svn/head/sys/kern/kern_shutdown.c:430 #2 0xffffffff80426521 in panic (fmt=Variable "fmt" is not available. ) at /home/svn/head/sys/kern/kern_shutdown.c:604 #3 0xffffffff8032c648 in pcib_grow_window (sc=0xfffffe0002603400, w=0xfffffe0002603498, type=3, start=0, end=4294967295, count=65536, flags=Variable "flags" is not available. ) at /home/svn/head/sys/dev/pci/pci_pci.c:1018 #4 0xffffffff8032c8f7 in pcib_alloc_resource (dev=0xfffffe00026f2600, child=0xfffffe0002eaf800, type=Variable "type" is not available. ) at /home/svn/head/sys/dev/pci/pci_pci.c:1090 #5 0xffffffff80325bdd in pci_alloc_resource (dev=0xfffffe000279bd00, child=0xfffffe0002eaf800, type=3, rid=0xffffff8000309688, start=2281701376, end=18446744073709551615, count=65536, flags=16384) at bus_if.h:263 #6 0xffffffff8031bd25 in cbb_alloc_resource (brdev=Variable "brdev" is not available. ) at bus_if.h:263 #7 0xffffffff80325d8e in pci_alloc_resource (dev=0xfffffe000279ed00, child=0xfffffe0002eaf800, type=3, rid=0xffffff8000309688, start=0, end=18446744073709551615, count=1, flags=16384) at bus_if.h:263 #8 0xffffffff80456f39 in bus_alloc_resource (dev=0xfffffe0002eaf800, type=3, rid=0xffffff8000309688, start=0, end=18446744073709551615, count=1, flags=12290) at bus_if.h:263 #9 0xffffffff802faa60 in cardbus_parse_cis (cbdev=0xfffffe000279ed00, child=0xfffffe0002eaf800, callbacks=0xffffff8000309af0, argp=0xfffffe0002e2d140) at bus.h:415 #10 0xffffffff802fb0c1 in cardbus_device_create (sc=0xfffffe00025d8030, devi=0xfffffe0002e2d000, parent=Variable "parent" is not available. ) at /home/svn/head/sys/dev/cardbus/cardbus_device.c:105 #11 0xffffffff802f9c4e in cardbus_attach_card (cbdev=0xfffffe000279ed00) at /home/svn/head/sys/dev/cardbus/cardbus.c:191 #12 0xffffffff8031ba44 in cbb_event_thread (arg=Variable "arg" is not available. ) at card_if.h:83 #13 0xffffffff803fb355 in fork_exit ( callout=0xffffffff8031b660 , arg=0xfffffe0002599800, frame=0xffffff8000309c50) at /home/svn/head/sys/kern/kern_fork.c:920 #14 0xffffffff80666c4e in fork_trampoline () at /home/svn/head/sys/amd64/amd64/exception.S:603 -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Sun Jul 3 07:43:04 2011 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 6DB80106564A for ; Sun, 3 Jul 2011 07:43:04 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from inbound01.jnb1.gp-online.net (inbound01.jnb1.gp-online.net [41.154.0.151]) by mx1.freebsd.org (Postfix) with ESMTP id AE41D8FC16 for ; Sun, 3 Jul 2011 07:43:03 +0000 (UTC) Received: from [41.154.88.19] (helo=clue.co.za) by inbound01.jnb1.gp-online.net with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1QdHKW-0006kV-Qs; Sun, 03 Jul 2011 09:43:00 +0200 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1QdHKR-000Kkb-Hj; Sun, 03 Jul 2011 09:42:55 +0200 Message-Id: To: Gavin Atkinson From: Ian FREISLICH In-Reply-To: References: <4E0E1D59.3030003@gmail.com> X-Attribution: BOFH Date: Sun, 03 Jul 2011 09:42:55 +0200 Cc: Matt , current@freebsd.org Subject: Re: cvsup servers broken? 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, 03 Jul 2011 07:43:04 -0000 Gavin Atkinson wrote: > On Sat, 2 Jul 2011, Ian FREISLICH wrote: > > Matt wrote: > > > On 07/01/11 09:34, Ian FREISLICH wrote: > > > > It looks like the server is just exiting. I've tested cvsup4 and > > > > cvsup5 as well. Is cvsup deprecated these days or has something > > > > else broken it? > > > > > > > Try csup instead of cvsup...I've found it works better. Any possibility > > > of network issues? > > > > csup gets into an infinite loop near the end of the ports tree and > > starts growing in memory consumption. I killed it after it grew > > to about 500M resident. The following is a ktrace snippet after > > it stalls: > > > > 75390 csup RET ioctl -1 errno 25 Inappropriate ioctl for device > > 75390 csup CALL ioctl(0x4,TIOCGETA,0xbf5fac60) > > 75390 csup RET ioctl -1 errno 25 Inappropriate ioctl for device > > 75390 csup CALL ioctl(0x4,TIOCGETA,0xbf5fac60) > > 75390 csup RET ioctl -1 errno 25 Inappropriate ioctl for device > > 75390 csup CALL ioctl(0x4,TIOCGETA,0xbf5fac60) > > 75390 csup RET ioctl -1 errno 25 Inappropriate ioctl for device > > 75390 csup CALL ioctl(0x4,TIOCGETA,0xbf5fac60) > > 75390 csup RET ioctl -1 errno 25 Inappropriate ioctl for device > > 75390 csup CALL ioctl(0x4,TIOCGETA,0xbf5fac60) > > > > The first part of csup's stack trace. It appears to be corrupted > > with several null frames, and is very, very deep. > > > > (gdb) bt > > #0 0x2832c1f3 in ioctl () from /lib/libc.so.7 > > #1 0x2832bdbc in tcgetattr () from /lib/libc.so.7 > > #2 0x2832b7ea in isatty () from /lib/libc.so.7 > > #3 0x08051832 in fnmatch () > > #4 0x08051906 in fnmatch () > > #5 0x08052135 in fnmatch () > > #6 0x08059c19 in fnmatch () > > #7 0x08059a76 in fnmatch () > > #8 0x0804c1ff in ?? () > > #9 0x28c11380 in ?? () > > #10 0x2845f402 in ?? () > > > > [mini] /usr/home/ianf # procstat -f 75390 > > PID COMM FD T V FLAGS REF OFFSET PRO NAME > > 75390 csup text v r r------- - - - /usr/bin/csup > > 75390 csup ctty v c rw------ - - - /dev/pts/1 > > 75390 csup cwd v d r------- - - - /usr/src > > 75390 csup root v d r------- - - - / > > 75390 csup 0 v c rw------ 14 10464115 - /dev/pts/1 > > 75390 csup 1 v c rw------ 14 10464115 - /dev/pts/1 > > 75390 csup 2 v c rw------ 14 10464115 - /dev/pts/1 > > 75390 csup 3 s - rw------ 2 0 TCP 10.0.2.67:19238 12 8.205.32.24:5999 > > 75390 csup 4 v r r------- 1 0 - /usr/home/ncvs/por ts/x11/wbar/Makefile,v > > 75390 csup 5 v r r------- 1 1023 - /var/db/sup/ports- all/checkouts > > 75390 csup 6 v r r------- 1 24492073 - /var/db/sup/ports -all/checkouts > > 75390 csup 7 v r -w------ 1 24491389 - /var/db/sup/ports -all/#cvs.csup-75390.0 > > > > filedescriptor 4's directory listing: > > > > [mini] /usr/home/ncvs/ports/x11/wbar # ls -la > > total 24 > > drwxr-xr-x 3 root wheel 512 Jul 1 07:21 . > > drwxr-xr-x 694 root wheel 14848 Jun 28 16:29 .. > > -r--r--r-- 1 root wheel 0 Feb 8 22:51 Makefile,v > > -r--r--r-- 1 root wheel 0 Mar 19 14:38 distinfo,v > > drwxr-xr-x 2 root wheel 512 Jul 1 07:21 files > > -r--r--r-- 1 root wheel 0 Feb 8 22:51 pkg-descr,v > > -r--r--r-- 1 root wheel 0 Feb 8 22:51 pkg-plist,v > > > > After removing the zero sized files, csup continued until it hit > > x11-toolkits/Makefile,v and then ports/x11-wm/Makefile,v which was > > also zero sized. Having deleted all the zero files, both cvsup and > > csup complete their run. > > I don't think you'll get much interest in fixing cvsup, but if you can > recreate this at will with csup and haven't had a response in a few days, > could you please submit a PR? This debugging above was with csup. cvsup would cause the remote to exit (hence the RST). csup would just consume all RAM and CPU when it encounters an empty ,v file. Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Sun Jul 3 09:15:52 2011 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 60735106564A; Sun, 3 Jul 2011 09:15:52 +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 1C1808FC08; Sun, 3 Jul 2011 09:15:52 +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 <1QdImN-0006YT-3X>; Sun, 03 Jul 2011 11:15:51 +0200 Received: from e178033186.adsl.alicedsl.de ([85.178.33.186] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1QdImN-0003rn-0i>; Sun, 03 Jul 2011 11:15:51 +0200 Message-ID: <4E103346.1060206@zedat.fu-berlin.de> Date: Sun, 03 Jul 2011 11:15:50 +0200 From: "Hartmann, O." User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110630 Thunderbird/5.0 MIME-Version: 1.0 To: Alexander Kabaev References: <4E0EC86E.9050608@zedat.fu-berlin.de> <20110702144513.5c5b9f75@kan.dnsalias.net> In-Reply-To: <20110702144513.5c5b9f75@kan.dnsalias.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.33.186 Cc: FreeBSD Current , FreeBSD Stable Subject: Re: devel/subversion: svn: Couldn't perform atomic 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, 03 Jul 2011 09:15:52 -0000 On 07/02/11 20:45, Alexander Kabaev wrote: > On Sat, 02 Jul 2011 09:27:42 +0200 > "Hartmann, O." wrote: > >> Hello. >> Since two days now I realize on several recently ports-updated >> servers a failure of the subversion server running on those servers. >> Sneaking around the internet I found several issues exactly targeting >> this error with an sqlite 3.7.7/3.7.7.1 issue, which has been fixed >> in sqlite-3.7.7.2. At this very moment, our subversion servers in >> question has all recently been updated and it seems, they all fail >> the same way. Does anyone also realize this behaviour shown below >> when commiting? >> >> Is there a workaround? Any help or hint is appreciated. >> >> Thanks in advance, >> Oliver >> >> Transmitting file data .svn: Commit failed (details follow): >> svn: Couldn't perform atomic initialization >> svn: database schema has changed >> svn: Your commit message was left in a temporary file: >> > Update database/sqlite3 port to the 3.7.7.1 version committed today. > Done - and it works fine. Thanks. But why 3.7.7.1 and not 3.7.7.2? Thanks, anyway. Regards, Oliver From owner-freebsd-current@FreeBSD.ORG Sun Jul 3 10:05:37 2011 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 6BB2C106566B for ; Sun, 3 Jul 2011 10:05:37 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 159908FC15 for ; Sun, 3 Jul 2011 10:05:36 +0000 (UTC) Received: by gyf3 with SMTP id 3so2212583gyf.13 for ; Sun, 03 Jul 2011 03:05:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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=fPXRFlU3i1GVF9gkQi+HGM6VQI56UHW/qa0WtYWRuwg=; b=tD8uXvXVgR3fCiP8QAiVduayO/CJN5svPuB/seO2UBKa2r6BtDYjNqssEmoDsoQYsA 6UwizD20T37k1lgYLehn+0nu0OApIDLLvDQ+JaesC4IkkmaunTYF6USqZyUbiVqC+6Q6 PJiJAb04qi66az6ZTCT2yPmNx1B1PU3xauvgc= MIME-Version: 1.0 Received: by 10.150.208.8 with SMTP id f8mr4541959ybg.399.1309687533766; Sun, 03 Jul 2011 03:05:33 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.151.45.11 with HTTP; Sun, 3 Jul 2011 03:05:33 -0700 (PDT) In-Reply-To: <4E100086.7080105@FreeBSD.org> References: <4E100086.7080105@FreeBSD.org> Date: Sun, 3 Jul 2011 18:05:33 +0800 X-Google-Sender-Auth: srD5mtp43r2g-xFlJGqtqhKf0x4 Message-ID: From: Adrian Chadd To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: cardbus panic: end address is not aligned 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, 03 Jul 2011 10:05:37 -0000 The obvious question - can you bisect kernel versions to find out when it b= roke? Adrian On 3 July 2011 13:39, Doug Barton wrote: > I have 2 ath-based pc-card adapters. If I put either one of them in the s= lot > while the system is up, or if I try booting with them in the slot, I get = an > instant panic. The cards previously worked in -current, and continue to w= ork > in 8-stable and windows xp. I don't have any other pc-cards to compare wi= th. > Full core.txt.0 file is in my home directory on freefall. > > This problem persists on r223732 but happened to me for the first time a > week or 2 ago (haven't had time to report it previously, apologies). It > likely originated a while before though, I don't use these cards very oft= en. > > panic: end address is not aligned > > #1 =A00xffffffff80426a8a in kern_reboot (howto=3D260) > =A0 =A0at /home/svn/head/sys/kern/kern_shutdown.c:430 > #2 =A00xffffffff80426521 in panic (fmt=3DVariable "fmt" is not available. > ) > =A0 =A0at /home/svn/head/sys/kern/kern_shutdown.c:604 > #3 =A00xffffffff8032c648 in pcib_grow_window (sc=3D0xfffffe0002603400, > =A0 =A0w=3D0xfffffe0002603498, type=3D3, start=3D0, end=3D4294967295, cou= nt=3D65536, > flags=3DVariable "flags" is not available. > > ) at /home/svn/head/sys/dev/pci/pci_pci.c:1018 > #4 =A00xffffffff8032c8f7 in pcib_alloc_resource (dev=3D0xfffffe00026f2600= , > =A0 =A0child=3D0xfffffe0002eaf800, type=3DVariable "type" is not availabl= e. > ) > =A0 =A0at /home/svn/head/sys/dev/pci/pci_pci.c:1090 > #5 =A00xffffffff80325bdd in pci_alloc_resource (dev=3D0xfffffe000279bd00, > =A0 =A0child=3D0xfffffe0002eaf800, type=3D3, rid=3D0xffffff8000309688, > =A0 =A0start=3D2281701376, end=3D18446744073709551615, count=3D65536, fla= gs=3D16384) > =A0 =A0at bus_if.h:263 > #6 =A00xffffffff8031bd25 in cbb_alloc_resource (brdev=3DVariable "brdev" = is not > available. > ) at bus_if.h:263 > #7 =A00xffffffff80325d8e in pci_alloc_resource (dev=3D0xfffffe000279ed00, > =A0 =A0child=3D0xfffffe0002eaf800, type=3D3, rid=3D0xffffff8000309688, st= art=3D0, > =A0 =A0end=3D18446744073709551615, count=3D1, flags=3D16384) at bus_if.h:= 263 > #8 =A00xffffffff80456f39 in bus_alloc_resource (dev=3D0xfffffe0002eaf800, > type=3D3, > =A0 =A0rid=3D0xffffff8000309688, start=3D0, end=3D18446744073709551615, c= ount=3D1, > =A0 =A0flags=3D12290) at bus_if.h:263 > #9 =A00xffffffff802faa60 in cardbus_parse_cis (cbdev=3D0xfffffe000279ed00= , > =A0 =A0child=3D0xfffffe0002eaf800, callbacks=3D0xffffff8000309af0, > =A0 =A0argp=3D0xfffffe0002e2d140) at bus.h:415 > #10 0xffffffff802fb0c1 in cardbus_device_create (sc=3D0xfffffe00025d8030, > =A0 =A0devi=3D0xfffffe0002e2d000, parent=3DVariable "parent" is not avail= able. > ) > =A0 =A0at /home/svn/head/sys/dev/cardbus/cardbus_device.c:105 > #11 0xffffffff802f9c4e in cardbus_attach_card (cbdev=3D0xfffffe000279ed00= ) > =A0 =A0at /home/svn/head/sys/dev/cardbus/cardbus.c:191 > #12 0xffffffff8031ba44 in cbb_event_thread (arg=3DVariable "arg" is not > available. > ) at card_if.h:83 > #13 0xffffffff803fb355 in fork_exit ( > =A0 =A0callout=3D0xffffffff8031b660 , arg=3D0xfffffe000= 2599800, > =A0 =A0frame=3D0xffffff8000309c50) at /home/svn/head/sys/kern/kern_fork.c= :920 > #14 0xffffffff80666c4e in fork_trampoline () > =A0 =A0at /home/svn/head/sys/amd64/amd64/exception.S:603 > > > > -- > > =A0 =A0 =A0 =A0Nothin' ever doesn't change, but nothin' changes much. > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- OK Go > > =A0 =A0 =A0 =A0Breadth of IT experience, and depth of knowledge in the DN= S. > =A0 =A0 =A0 =A0Yours for the right price. =A0:) =A0http://SupersetSolutio= ns.com/ > > _______________________________________________ > 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 Sun Jul 3 11:24:16 2011 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 F0BF5106564A for ; Sun, 3 Jul 2011 11:24:16 +0000 (UTC) (envelope-from vassilis.laganakos@yahoo.com) Received: from nm20-vm0.bullet.mail.bf1.yahoo.com (nm20-vm0.bullet.mail.bf1.yahoo.com [98.139.213.165]) by mx1.freebsd.org (Postfix) with SMTP id 831BD8FC13 for ; Sun, 3 Jul 2011 11:24:16 +0000 (UTC) Received: from [98.139.212.144] by nm20.bullet.mail.bf1.yahoo.com with NNFMP; 03 Jul 2011 11:11:52 -0000 Received: from [98.139.211.200] by tm1.bullet.mail.bf1.yahoo.com with NNFMP; 03 Jul 2011 11:11:52 -0000 Received: from [127.0.0.1] by smtp209.mail.bf1.yahoo.com with NNFMP; 03 Jul 2011 11:11:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1309691512; bh=lLnm/8cvcKdX4rBrx2dLOklxPv0Z7MUeiDjK0ux4Xns=; h=X-Yahoo-Newman-Id:Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=CDyBI9wwgZ/vj2xm57U7o/S2H6R2LGv9eNQx1Nc8HxVDCEuxqAS3wEwT1O56Of/6hBn/dX5Od9TRVW5LbnLWA3XcLXt6AzGkwJtWjV1iVqsBM6coiGGaxDgGMsYjFbUw5Iqwz/Mfuc1/nhk7ZotzKwvZIhlJWgI5rGg80CEISp0= X-Yahoo-Newman-Id: 443890.29938.bm@smtp209.mail.bf1.yahoo.com Received: from [192.168.0.10] (vassilis.laganakos@82.26.1.108 with plain) by smtp209.mail.bf1.yahoo.com with SMTP; 03 Jul 2011 04:11:52 -0700 PDT X-Yahoo-SMTP: 1OHIhCeswBBeEv7nZbHf0yvkrPBhfPima6axnFX6oQ-- X-YMail-OSG: OoaIsMsVM1lf5nl_YetNm5zSphW7254EmyjVvq_fUj36cvy JPEmF1Yo95jrrxT1azAyFSIc3I32uR8eFrYqOd1GbU_wroxNx.eT5U8.mN.9 LKPRdW480uzsTbl0oQvMwe2ZZZfPZFFcxCpZvRdCLYbo7mnBKsciD2mbWGcs A08bYsZQsQ3VAI2DK2wtEzP.ozsrkJOA3GwNOrl50XAKSYliIqX05tVDXb1_ SAJwg_KawfaJsD.PDCULLsGSdtNVx1AFajYH1K8HoUvAxvO1HpKP0DhdtIRZ aO0UBA_uTaI._rdZTUOL1tF18L6kAERngBLJ0J4.kj1ijX2mGQJfsP0L.U68 SoeiZMZkgShjfCEzML15z_W4qI8e43PoPpF_ghNbR7eKAbAo_Tg.Qrx27S9n 547WqIfMZZhBI9jdgQ7CCgIZGrOCR1ofcLhnbprF2P5mPY.fgU3FwGjz03R9 AAxWiFi5ow.cTtxdqNQj2MY15Rf5dWTaOm0rvNEyFlB_NejGiQaTMfTrx598 N X-Yahoo-Newman-Property: ymail-3 Message-ID: <4E104E7A.7000308@yahoo.com> Date: Sun, 03 Jul 2011 12:11:54 +0100 From: Vassilis Laganakos User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110702 Thunderbird/5.0 MIME-Version: 1.0 To: Garrett Cooper , freebsd-current@freebsd.org References: <4E0F3A53.3040309@yahoo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Problems with cvsup on FreeBSD 9, AMD64, osreldate: 900038 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, 03 Jul 2011 11:24:17 -0000 On 02/07/2011 17:07, Garrett Cooper wrote: > On Sat, Jul 2, 2011 at 8:33 AM, Vassilis Laganakos > wrote: >> Hello, >> >> I am facing the same problems as Holger here: >> >> http://lists.freebsd.org/pipermail/freebsd-current/2011-June/025205.html >> >> although CVSup dies in gmtime_r in libc.so.7: >> >> ... >> Updating collection src-all/cvs >> Edit src/UPDATING >> >> Program received signal SIGSEGV, Segmentation fault. >> 0x000000002ca10fb9 in gmtime_r () from /lib/libc.so.7 >> ... >> >> See full gdb backtrace at: >> >> http://www.pastie.org/pastes/2154271 >> >> So I'm now stuck in osrel 900038... I guess I need to rebuild libc.so.7 >> with debugging symbols to find out what is going wrong there. >> >> Any quick ideas on how to correct this, or if someone else is seeing this >> issue? > > Have you tried recompiling cvsup and all of its dependencies? > Yeah, I rebuilt every port installed with "pormaster -dBfa", hoping that that would correct it, but that gave the same behaviour. Thanks, Vassilis L. From owner-freebsd-current@FreeBSD.ORG Sun Jul 3 11:30:14 2011 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 56CCD1065677 for ; Sun, 3 Jul 2011 11:30:14 +0000 (UTC) (envelope-from vassilis.laganakos@yahoo.com) Received: from nm27-vm0.bullet.mail.sp2.yahoo.com (nm27-vm0.bullet.mail.sp2.yahoo.com [98.139.91.232]) by mx1.freebsd.org (Postfix) with SMTP id 327868FC14 for ; Sun, 3 Jul 2011 11:30:14 +0000 (UTC) Received: from [98.139.91.63] by nm27.bullet.mail.sp2.yahoo.com with NNFMP; 03 Jul 2011 11:17:09 -0000 Received: from [208.71.42.192] by tm3.bullet.mail.sp2.yahoo.com with NNFMP; 03 Jul 2011 11:17:09 -0000 Received: from [127.0.0.1] by smtp203.mail.gq1.yahoo.com with NNFMP; 03 Jul 2011 11:17:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1309691829; bh=qBPntkOnNv464SWxoNJ294d/JMgAS1NxOWvzMTCxO+4=; h=X-Yahoo-Newman-Id:Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=dXY9rn5c5zo/CbHR6+vVuAaQegpzlEgV8Up7kTVAADn+u4ANNty3/hBodKBJwA/yuH8xy7hVdB4d06UDkIflckA8UEYyuKwc8GikUfH0VGfeKqOMbGgZ4jnIpJoPV388qpMKcETIQkOEbDSg1Xd+gnJz6JsXWOmgbpP8qe3lULM= X-Yahoo-Newman-Id: 129514.82311.bm@smtp203.mail.gq1.yahoo.com Received: from [192.168.0.10] (vassilis.laganakos@82.26.1.108 with plain) by smtp203.mail.gq1.yahoo.com with SMTP; 03 Jul 2011 04:17:08 -0700 PDT X-Yahoo-SMTP: 1OHIhCeswBBeEv7nZbHf0yvkrPBhfPima6axnFX6oQ-- X-YMail-OSG: nbQcX44VM1ko6Mg8WKWa5_BzrtdPfvIo2gifIea0JSN2mta gExe1TJdfulO6siOgYjtc1R3W0CXSvxgRxTDbTwVGTAvdVJuNs8foL28In93 OH2WQbbyBTGlyEI2CFNVIaeL.hdeRsW02u7KEu8uo4pV7dMHBLrquQXIS6vt gsgwg.u8qFAcDEFf38.ZxdTIAA05aGU43jxIGA5ybFyaNHqwRZS9oExJN6wH plWu02Po2ZA1ZuW8m6i7QVjBhkwZXULP2tDYpn8lqhSttOeT0EFcMoDiwqLr r28cEuNeLdKGd6os82UbdCvxFv_3T5M8uuspnHN.mcQM6Jjk- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4E104FB6.1070106@yahoo.com> Date: Sun, 03 Jul 2011 12:17:10 +0100 From: Vassilis Laganakos User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110702 Thunderbird/5.0 MIME-Version: 1.0 To: Kurt Jaeger , freebsd-current@freebsd.org References: <4E0F3A53.3040309@yahoo.com> <20110702165452.GK16648@home.opsec.eu> In-Reply-To: <20110702165452.GK16648@home.opsec.eu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Problems with cvsup on FreeBSD 9, AMD64, osreldate: 900038 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, 03 Jul 2011 11:30:14 -0000 On 02/07/2011 17:54, Kurt Jaeger wrote: > Hi! > >> Any quick ideas on how to correct this, or if someone else is seeing >> this issue? > > Does csup work ? > Yeah! That works! I see that csups is part of the build system. So is this to replace the cvsup port? Thanks, Vassilis L. From owner-freebsd-current@FreeBSD.ORG Sun Jul 3 11:37:34 2011 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 820F61065670 for ; Sun, 3 Jul 2011 11:37:34 +0000 (UTC) (envelope-from vassilis.laganakos@yahoo.com) Received: from nm3-vm0.bullet.mail.ne1.yahoo.com (nm3-vm0.bullet.mail.ne1.yahoo.com [98.138.91.55]) by mx1.freebsd.org (Postfix) with SMTP id EB0DA8FC0A for ; Sun, 3 Jul 2011 11:37:33 +0000 (UTC) Received: from [98.138.90.57] by nm3.bullet.mail.ne1.yahoo.com with NNFMP; 03 Jul 2011 11:37:33 -0000 Received: from [98.138.226.128] by tm10.bullet.mail.ne1.yahoo.com with NNFMP; 03 Jul 2011 11:37:33 -0000 Received: from [127.0.0.1] by smtp215.mail.ne1.yahoo.com with NNFMP; 03 Jul 2011 11:37:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1309693053; bh=IGwOnR25mOuqMkn8VGqQC26pcwhv++853dLDc/BQ03A=; h=X-Yahoo-Newman-Id:Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=5cbwRzZOQkQwo0DiEJtStNryCcm94Jr/sbGuSNH3Cv5hngM2fmXdA3fqqvF2UyciT0Gb+Ac8KwK9xh743MCdzXihz2Se1Cyj5n/lD7RTmic3UqF6hUZqbWulit5DTv40I1djPMYvG8DindxvQrPRkh/Cuf9aBfrtFX0H8h5hC4M= X-Yahoo-Newman-Id: 441774.61769.bm@smtp215.mail.ne1.yahoo.com Received: from [192.168.0.10] (vassilis.laganakos@82.26.1.108 with plain) by smtp215.mail.ne1.yahoo.com with SMTP; 03 Jul 2011 04:37:33 -0700 PDT X-Yahoo-SMTP: 1OHIhCeswBBeEv7nZbHf0yvkrPBhfPima6axnFX6oQ-- X-YMail-OSG: p4t8ohEVM1m2gTAlw1WmAxF9LkpPEUxlz5fTI9AgkwUI0mX aPtQ_rMDBCm6ofrXvoTFOi90P8w.Tcxr48w_TPGgSEAtEVMyddKyYVXASl6W hsOFc4MhOtLatNP5EjJ.Ce98V09aGUR8l0YlD3yTYwhqZgPvbWqDl7OC4zfc LxuFqLOD4SHTOQs9b6Rl7DFT3TLJydbnjtbGIrV7epGV_5hC786PBozxbelr 3uCOwNueM0Y76dTAOXgV0UWNdFEzBZeyFOq9x1c0UYeaIHK_6AuUXS.jYgHf 23V_iYuqRzhNRoMQEeAVX.fLBYPq5m.gLmtULwpIw9luzaakisrB7.wOjtbr Pt.oly4QALw14aOoyeyUlsrAE9s2ltCaq8lsscy6O8pK3vbjVoO1EoUgCxOu MDCAfNTRhOH2Y5r9OR1tyYc3xmPJpjFECLIngTlGPib8hTDD7U.hOdxmj_9u ruitnRhSsbuMM.mgC4aKxaQLffx8xbrUqcwN95WBPzZWlNkwWZ2jmaesZKXM - X-Yahoo-Newman-Property: ymail-3 Message-ID: <4E10547F.9090300@yahoo.com> Date: Sun, 03 Jul 2011 12:37:35 +0100 From: Vassilis Laganakos User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110702 Thunderbird/5.0 MIME-Version: 1.0 To: jhell References: <4E0F3A53.3040309@yahoo.com> <20110703032553.GA77276@DataIX.net> In-Reply-To: <20110703032553.GA77276@DataIX.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Problems with cvsup on FreeBSD 9, AMD64, osreldate: 900038 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, 03 Jul 2011 11:37:34 -0000 On 03/07/2011 04:25, jhell wrote: > > > On Sat, Jul 02, 2011 at 04:33:39PM +0100, Vassilis Laganakos wrote: >> Hello, >> >> I am facing the same problems as Holger here: >> >> http://lists.freebsd.org/pipermail/freebsd-current/2011-June/025205.html >> >> although CVSup dies in gmtime_r in libc.so.7: >> >> ... >> Updating collection src-all/cvs >> Edit src/UPDATING >> >> Program received signal SIGSEGV, Segmentation fault. >> 0x000000002ca10fb9 in gmtime_r () from /lib/libc.so.7 >> ... >> >> See full gdb backtrace at: >> >> http://www.pastie.org/pastes/2154271 >> >> So I'm now stuck in osrel 900038... I guess I need to rebuild libc.so.7 >> with debugging symbols to find out what is going wrong there. >> >> Any quick ideas on how to correct this, or if someone else is seeing >> this issue? >> > > Use csup(1) in base. This is in 7, 8& 9. cvsup has been deprecated for > much longer than it really needed to be and should probably be removed > from use as a client entirely and links generated for installation of > cvsup -> csup. > Oh, I wasn't aware of that. csup worked sweet, thanks! So I'll remove the cvsup port and switch to using csup. > Only drawback for you may be no X interface but it really was not that > pretty in the first place and served no real good purpose over the > functionality of the command line client. > > An alternative if you need and X interface is creating a icon on your > desktop that runs ( xterm -e csup /path/to/supfile ) or something > similiar. Ok. I haven't been using the X interface, and I agree it hasn't been that great. Thanks for the information! Vassilis L. From owner-freebsd-current@FreeBSD.ORG Sun Jul 3 13:27:43 2011 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 6B0C21065686 for ; Sun, 3 Jul 2011 13:27:43 +0000 (UTC) (envelope-from eculp@encontacto.net) Received: from ns2.bafirst.com (ns2.bafirst.com [97.67.198.91]) by mx1.freebsd.org (Postfix) with ESMTP id F2FB88FC1C for ; Sun, 3 Jul 2011 13:27:42 +0000 (UTC) Received: from unixmania.com ([189.251.17.30]) by ns2.bafirst.com with esmtp; Sun, 03 Jul 2011 08:27:40 -0500 id 000DA802.4E106E4D.000157BD Received: from localhost (localhost [127.0.0.1]) (uid 80) by unixmania.com with local; Sun, 03 Jul 2011 08:27:40 -0500 id 000CF6E7.4E106E4C.00012526 Received: from dsl-187-153-244-134-dyn.prod-infinitum.com.mx (dsl-187-153-244-134-dyn.prod-infinitum.com.mx [187.153.244.134]) by econet.encontacto.net (Horde Framework) with HTTP; Sun, 03 Jul 2011 08:27:40 -0500 Message-ID: <20110703082740.65947mb8mt1g1dg0@econet.encontacto.net> Date: Sun, 03 Jul 2011 08:27:40 -0500 From: eculp To: freebsd-current MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (5.0-cvs) X-Remote-Browser: Mozilla/5.0 (X11; FreeBSD i386; rv:5.0) Gecko/20100101 Firefox/5.0 X-IMP-Server: 189.251.17.30 X-Originating-IP: 187.153.244.134 X-Originating-User: eculp@encontacto.net Subject: seeing pf: state key linking mismatch! with pf on up to date current but not on FreeBSD 7.4-STABLE 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, 03 Jul 2011 13:27:43 -0000 Something is strange with PF. I get the above error using pf on current but not on FreeBSD stable. The pf configuration hasn't changed for a couple of years on either and they are the same except for hardware names. The two machines are: 9.0-CURRENT FreeBSD 9.0-CURRENT #247: Wed Jun 29 04:49:16 CDT 2011 7.4-STABLE FreeBSD 7.4-STABLE #1228: Sat Jun 25 04:42:55 CDT 2011 Anyone else seeing this? Thanks, ed From owner-freebsd-current@FreeBSD.ORG Sun Jul 3 13:48:34 2011 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 0B6E7106566C for ; Sun, 3 Jul 2011 13:48:34 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.29.7]) by mx1.freebsd.org (Postfix) with ESMTP id BECBC8FC08 for ; Sun, 3 Jul 2011 13:48:33 +0000 (UTC) Received: from [87.79.152.98] (helo=fabiankeil.de) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1QdN2F-0002HK-VC; Sun, 03 Jul 2011 15:48:32 +0200 Date: Sun, 3 Jul 2011 15:48:26 +0200 From: Fabian Keil To: eculp Message-ID: <20110703154826.35225f9c@fabiankeil.de> In-Reply-To: <20110703082740.65947mb8mt1g1dg0@econet.encontacto.net> References: <20110703082740.65947mb8mt1g1dg0@econet.encontacto.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/b6L5cMUMYRuymHvs/63c8nK"; protocol="application/pgp-signature" X-Df-Sender: 775067 Cc: freebsd-current Subject: Re: seeing pf: state key linking mismatch! with pf on up to date current but not on FreeBSD 7.4-STABLE 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, 03 Jul 2011 13:48:34 -0000 --Sig_/b6L5cMUMYRuymHvs/63c8nK Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable eculp wrote: > Something is strange with PF. I get the above error using pf on =20 > current but not on FreeBSD stable. The pf configuration hasn't =20 > changed for a couple of years on either and they are the same except =20 > for hardware names. pf has recently been updated in CURRENT. > The two machines are: > 9.0-CURRENT FreeBSD 9.0-CURRENT #247: Wed Jun 29 04:49:16 CDT 2011 > 7.4-STABLE FreeBSD 7.4-STABLE #1228: Sat Jun 25 04:42:55 CDT 2011 >=20 > Anyone else seeing this? Yes: http://lists.freebsd.org/pipermail/freebsd-pf/2011-June/006191.html Fabian --Sig_/b6L5cMUMYRuymHvs/63c8nK Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iEYEARECAAYFAk4Qcy8ACgkQBYqIVf93VJ3ziQCfQY15GyouVW4Z3tb2+lbqgu98 1EwAoK2eYAfzoN+jXmvCX3rda+Qi4Aap =5/Nm -----END PGP SIGNATURE----- --Sig_/b6L5cMUMYRuymHvs/63c8nK-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 3 13:58:22 2011 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 51C52106566B for ; Sun, 3 Jul 2011 13:58:22 +0000 (UTC) (envelope-from eculp@encontacto.net) Received: from ns2.bafirst.com (ns2.bafirst.com [97.67.198.91]) by mx1.freebsd.org (Postfix) with ESMTP id D5E1F8FC0A for ; Sun, 3 Jul 2011 13:58:21 +0000 (UTC) Received: from unixmania.com ([189.251.17.30]) by ns2.bafirst.com with esmtp; Sun, 03 Jul 2011 08:58:20 -0500 id 000DA804.4E10757C.000157FC Received: from localhost (localhost [127.0.0.1]) (uid 80) by unixmania.com with local; Sun, 03 Jul 2011 08:58:19 -0500 id 000CF6ED.4E10757B.00012888 Received: from dsl-187-153-244-134-dyn.prod-infinitum.com.mx (dsl-187-153-244-134-dyn.prod-infinitum.com.mx [187.153.244.134]) by econet.encontacto.net (Horde Framework) with HTTP; Sun, 03 Jul 2011 08:58:19 -0500 Message-ID: <20110703085819.113551trbobk2hkw@econet.encontacto.net> Date: Sun, 03 Jul 2011 08:58:19 -0500 From: eculp To: Fabian Keil References: <20110703082740.65947mb8mt1g1dg0@econet.encontacto.net> <20110703154826.35225f9c@fabiankeil.de> In-Reply-To: <20110703154826.35225f9c@fabiankeil.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (5.0-cvs) X-Remote-Browser: Mozilla/5.0 (X11; FreeBSD i386; rv:5.0) Gecko/20100101 Firefox/5.0 X-IMP-Server: 189.251.17.30 X-Originating-IP: 187.153.244.134 X-Originating-User: eculp@encontacto.net Cc: freebsd-current Subject: Re: seeing pf: state key linking mismatch! with pf on up to date current but not on FreeBSD 7.4-STABLE 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, 03 Jul 2011 13:58:22 -0000 Quoting Fabian Keil : > eculp wrote: > >> Something is strange with PF. I get the above error using pf on >> current but not on FreeBSD stable. The pf configuration hasn't >> changed for a couple of years on either and they are the same except >> for hardware names. > > pf has recently been updated in CURRENT. > >> The two machines are: >> 9.0-CURRENT FreeBSD 9.0-CURRENT #247: Wed Jun 29 04:49:16 CDT 2011 >> 7.4-STABLE FreeBSD 7.4-STABLE #1228: Sat Jun 25 04:42:55 CDT 2011 >> >> Anyone else seeing this? > > Yes: > http://lists.freebsd.org/pipermail/freebsd-pf/2011-June/006191.html > > Fabian Thanks, Fabian. From what I understand, not officially fixed yet. Have a great weekend. ed > From owner-freebsd-current@FreeBSD.ORG Sun Jul 3 14:25:04 2011 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 1D8D51065672; Sun, 3 Jul 2011 14:25:04 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id ACBE58FC20; Sun, 3 Jul 2011 14:25:03 +0000 (UTC) Received: by qyk38 with SMTP id 38so2958897qyk.13 for ; Sun, 03 Jul 2011 07:25:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; bh=iWSHp/NyNlrkvgOJx1Awql2e09jri+6EuR6aZdCNfDc=; b=YBkvSv4pioCZneP0K7QYfw23EArd7VVDsw48TN/IOBgUXz+s1/GWaw4gDJ6eyeizE6 KgS0NfNnn9Xn8nOAKWbPza6RM+WRK4o/DnJZD/4yRpuqx/T/w03j6lcq+P9YF62xNOQc SNH/U6wl2V72bUyl98ZnDDrZiS+2Dj/ABnp5k= Received: by 10.224.106.1 with SMTP id v1mr4103906qao.195.1309703102783; Sun, 03 Jul 2011 07:25:02 -0700 (PDT) Received: from kan.dnsalias.net (c-24-63-226-98.hsd1.ma.comcast.net [24.63.226.98]) by mx.google.com with ESMTPS id g7sm4064203qck.44.2011.07.03.07.25.01 (version=SSLv3 cipher=OTHER); Sun, 03 Jul 2011 07:25:01 -0700 (PDT) Date: Sun, 3 Jul 2011 10:24:54 -0400 From: Alexander Kabaev To: "Hartmann, O." Message-ID: <20110703102454.5c96cbc9@kan.dnsalias.net> In-Reply-To: <4E103346.1060206@zedat.fu-berlin.de> References: <4E0EC86E.9050608@zedat.fu-berlin.de> <20110702144513.5c5b9f75@kan.dnsalias.net> <4E103346.1060206@zedat.fu-berlin.de> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/fOJJt/wm1fX=QF0oCDrMpXA"; protocol="application/pgp-signature" Cc: FreeBSD Current , FreeBSD Stable Subject: Re: devel/subversion: svn: Couldn't perform atomic 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, 03 Jul 2011 14:25:04 -0000 --Sig_/fOJJt/wm1fX=QF0oCDrMpXA Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sun, 03 Jul 2011 11:15:50 +0200 "Hartmann, O." wrote: > On 07/02/11 20:45, Alexander Kabaev wrote: > > On Sat, 02 Jul 2011 09:27:42 +0200 > > "Hartmann, O." wrote: > > > >> > > Update database/sqlite3 port to the 3.7.7.1 version committed today. > > >=20 > Done - and it works fine. Thanks. But why > 3.7.7.1 and not 3.7.7.2? >=20 > Thanks, anyway. >=20 > Regards, > Oliver No reason other than 3.7.7.1 appears to be the latest version currently in ports. --=20 Alexander Kabaev --Sig_/fOJJt/wm1fX=QF0oCDrMpXA Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iD8DBQFOEHu8Q6z1jMm+XZYRAm/nAKDPVX66aw7R+uJ6i5QoH4iWdxHwMgCdE/IQ iXT/CNkExRWX++ltgFc+Zg4= =dPTt -----END PGP SIGNATURE----- --Sig_/fOJJt/wm1fX=QF0oCDrMpXA-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 3 18:10:54 2011 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 D26F5106566B for ; Sun, 3 Jul 2011 18:10:54 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id A8F558FC08 for ; Sun, 3 Jul 2011 18:10:40 +0000 (UTC) Received: by pzk27 with SMTP id 27so2308959pzk.13 for ; Sun, 03 Jul 2011 11:10:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=3hR8oUsabmZpcccQQQA8DWtuRy5ROGew64xlLMS2nXo=; b=ggEYQkc1+apsV/l1F5FA6t2l/l9ytSMiSgrL1s58VipGBBnmrnjdD1otQREtEGFikl GDPXS0bqBik0e4DWA0VIMRTpjKRaZsOMLOY9fz7/1HXByfDPf5Mx4q4f71JG2Fu/EBN2 +Jq50wPuT+IN/DOA5Wc2jzS8Ej1ULFDp8Mzr4= Received: by 10.68.6.228 with SMTP id e4mr5937817pba.216.1309716639621; Sun, 03 Jul 2011 11:10:39 -0700 (PDT) Received: from sidhe.local ([75.111.38.94]) by mx.google.com with ESMTPS id q5sm3413126pbk.58.2011.07.03.11.10.37 (version=SSLv3 cipher=OTHER); Sun, 03 Jul 2011 11:10:38 -0700 (PDT) Message-ID: <4E10B09E.40309@gmail.com> Date: Sun, 03 Jul 2011 11:10:38 -0700 From: Matt User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.18) Gecko/20110624 Thunderbird/3.1.11 MIME-Version: 1.0 To: eculp References: <20110703082740.65947mb8mt1g1dg0@econet.encontacto.net> In-Reply-To: <20110703082740.65947mb8mt1g1dg0@econet.encontacto.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current Subject: Re: seeing pf: state key linking mismatch! with pf on up to date current but not on FreeBSD 7.4-STABLE 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, 03 Jul 2011 18:10:54 -0000 On 07/03/11 06:27, eculp wrote: > Something is strange with PF. I get the above error using pf on > current but not on FreeBSD stable. The pf configuration hasn't > changed for a couple of years on either and they are the same except > for hardware names. > > The two machines are: > 9.0-CURRENT FreeBSD 9.0-CURRENT #247: Wed Jun 29 04:49:16 CDT 2011 > 7.4-STABLE FreeBSD 7.4-STABLE #1228: Sat Jun 25 04:42:55 CDT 2011 > > Anyone else seeing this? > > Thanks, > > ed > _______________________________________________ > I am also seeing this, especially when a website/browser/tab is closed but the remote site is still sending data I think. I am using the same basic pf.conf I have used for client machines for a while, but there is not much other than pf options and allowing traffic out (modulate state for tcp, keep state for everything else). I do have scrub, and antispoof rules for the interfaces, as well as a block log all at the top. For now, like i said, I've only seen the state key mismatches with web traffic. Also, synproxy state seems to hang all traffic. Matt From owner-freebsd-current@FreeBSD.ORG Sun Jul 3 21:08:17 2011 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 5F1B61065670 for ; Sun, 3 Jul 2011 21:08:17 +0000 (UTC) (envelope-from stephen@missouri.edu) Received: from wilberforce.math.missouri.edu (wilberforce.math.missouri.edu [128.206.184.213]) by mx1.freebsd.org (Postfix) with ESMTP id 29AB78FC21 for ; Sun, 3 Jul 2011 21:08:16 +0000 (UTC) Received: from [127.0.0.1] (wilberforce.math.missouri.edu [128.206.184.213]) by wilberforce.math.missouri.edu (8.14.4/8.14.4) with ESMTP id p63Kp6Yl085833; Sun, 3 Jul 2011 15:51:07 -0500 (CDT) (envelope-from stephen@missouri.edu) Message-ID: <4E10D63A.5000706@missouri.edu> Date: Sun, 03 Jul 2011 15:51:06 -0500 From: Stephen Montgomery-Smith User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: jhell References: <4E0F3A53.3040309@yahoo.com> <20110703032553.GA77276@DataIX.net> In-Reply-To: <20110703032553.GA77276@DataIX.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-current@freebsd.org" Subject: Re: Problems with cvsup on FreeBSD 9, AMD64, osreldate: 900038 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, 03 Jul 2011 21:08:17 -0000 On 07/02/2011 10:25 PM, jhell wrote: > Use csup(1) in base. This is in 7, 8& 9. cvsup has been deprecated for > much longer than it really needed to be and should probably be removed > from use as a client entirely and links generated for installation of > cvsup -> csup. > > Only drawback for you may be no X interface but it really was not that > pretty in the first place and served no real good purpose over the > functionality of the command line client. Another drawback to csup is that csup doesn't seem to recognize the .cvsup/auth file. At least not on FreeBSD 7 of a few months ago. I run CTM generation, and I need access to cvsup-master. From owner-freebsd-current@FreeBSD.ORG Mon Jul 4 07:40:18 2011 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 D1204106564A; Mon, 4 Jul 2011 07:40:18 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe02.c2i.net [212.247.154.34]) by mx1.freebsd.org (Postfix) with ESMTP id 277E58FC16; Mon, 4 Jul 2011 07:40:17 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=vrJF5kjXe35rRze0mxLgGFcjILUNrTxl1QHeo1urnh8= c=1 sm=1 a=SvYTsOw2Z4kA:10 a=dq2f58wT9zoA:10 a=WQU8e4WWZSUA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=6I5d2MoRAAAA:8 a=IuAMIfKwbXqFb76IdqQA:9 a=wPNLvfGTeEIA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe02.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 148658760; Mon, 04 Jul 2011 09:40:16 +0200 From: Hans Petter Selasky To: ti bugmenot Date: Mon, 4 Jul 2011 09:38:26 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: <201107011851.00989.hselasky@c2i.net> In-Reply-To: X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201107040938.26373.hselasky@c2i.net> Cc: freebsd-current@freebsd.org, David Storm , freebsd-usb@freebsd.org Subject: Re: keyboard driver problem? 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, 04 Jul 2011 07:40:18 -0000 Hi, I've committed a larger patch to UKBD to make it more HID compliant. Please try the following patch and report back if you see any regression issues with your USB keyboard. http://svn.freebsd.org/changeset/base/223755 --HPS From owner-freebsd-current@FreeBSD.ORG Mon Jul 4 08:37:13 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 439221065673; Mon, 4 Jul 2011 08:37:13 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-4.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 9CFF814DD9F; Mon, 4 Jul 2011 08:37:12 +0000 (UTC) Message-ID: <4E117BB8.1010105@FreeBSD.org> Date: Mon, 04 Jul 2011 01:37:12 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.18) Gecko/20110624 Thunderbird/3.1.11 MIME-Version: 1.0 To: Adrian Chadd References: <4E100086.7080105@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: cardbus panic: end address is not aligned 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, 04 Jul 2011 08:37:13 -0000 On 07/03/2011 03:05, Adrian Chadd wrote: > The obvious question - can you bisect kernel versions to find out when it broke? Sorry, I thought the answer to that was obvious from my message. I have no idea how far back the breakage goes since I don't use the cards often. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Mon Jul 4 12:33:42 2011 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 96F65106564A; Mon, 4 Jul 2011 12:33:42 +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 6A42A8FC13; Mon, 4 Jul 2011 12:33:42 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p64CXfdE011813; Mon, 4 Jul 2011 08:33:41 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p64CXfVB011780; Mon, 4 Jul 2011 12:33:41 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 4 Jul 2011 12:33:41 GMT Message-Id: <201107041233.p64CXfVB011780@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: Mon, 04 Jul 2011 12:33:42 -0000 TB --- 2011-07-04 10:30:00 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-07-04 10:30:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2011-07-04 10:30:00 - cleaning the object tree TB --- 2011-07-04 10:30:35 - cvsupping the source tree TB --- 2011-07-04 10:30:35 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2011-07-04 10:30:53 - building world TB --- 2011-07-04 10:30:53 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-04 10:30:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-04 10:30:53 - TARGET=pc98 TB --- 2011-07-04 10:30:53 - TARGET_ARCH=i386 TB --- 2011-07-04 10:30:53 - TZ=UTC TB --- 2011-07-04 10:30:53 - __MAKE_CONF=/dev/null TB --- 2011-07-04 10:30:53 - cd /src TB --- 2011-07-04 10:30:53 - /usr/bin/make -B buildworld >>> World build started on Mon Jul 4 10:30:53 UTC 2011 >>> 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 Mon Jul 4 12:29:13 UTC 2011 TB --- 2011-07-04 12:29:13 - generating LINT kernel config TB --- 2011-07-04 12:29:13 - cd /src/sys/pc98/conf TB --- 2011-07-04 12:29:13 - /usr/bin/make -B LINT TB --- 2011-07-04 12:29:13 - building LINT kernel TB --- 2011-07-04 12:29:13 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-04 12:29:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-04 12:29:13 - TARGET=pc98 TB --- 2011-07-04 12:29:13 - TARGET_ARCH=i386 TB --- 2011-07-04 12:29:13 - TZ=UTC TB --- 2011-07-04 12:29:13 - __MAKE_CONF=/dev/null TB --- 2011-07-04 12:29:13 - cd /src TB --- 2011-07-04 12:29:13 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jul 4 12:29:13 UTC 2011 >>> 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-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/contrib/ipfilter/netinet/ip_sync.c -I/src/sys/contrib/ipfilter 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-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/contrib/ipfilter/netinet/mlfk_ipl.c -I/src/sys/contrib/ipfilter 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-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -pg -mprofiler-epilogue /src/sys/contrib/ngatm/netnatm/api/cc_conn.c -I/src/sys/contrib/ngatm In file included from /src/sys/netgraph/atm/ccatm/ng_ccatm_cust.h:43, from /src/sys/contrib/ngatm/netnatm/api/ccpriv.h:38, from /src/sys/contrib/ngatm/netnatm/api/cc_conn.c:47: /src/sys/netgraph/netgraph.h: In function '_ng_node_unref': /src/sys/netgraph/netgraph.h:500: error: void value not ignored as it ought to be *** Error code 1 Stop in /obj/pc98.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-07-04 12:33:40 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-07-04 12:33:40 - ERROR: failed to build lint kernel TB --- 2011-07-04 12:33:40 - 5810.89 user 1116.02 system 7420.38 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Mon Jul 4 12:40:44 2011 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 E39BC106566C; Mon, 4 Jul 2011 12:40:44 +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 B221B8FC18; Mon, 4 Jul 2011 12:40:44 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p64CehAD093265; Mon, 4 Jul 2011 08:40:43 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p64Ceho4093256; Mon, 4 Jul 2011 12:40:43 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 4 Jul 2011 12:40:43 GMT Message-Id: <201107041240.p64Ceho4093256@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: Mon, 04 Jul 2011 12:40:45 -0000 TB --- 2011-07-04 10:30:00 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-07-04 10:30:00 - starting HEAD tinderbox run for i386/i386 TB --- 2011-07-04 10:30:00 - cleaning the object tree TB --- 2011-07-04 10:30:45 - cvsupping the source tree TB --- 2011-07-04 10:30:45 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-07-04 10:36:09 - building world TB --- 2011-07-04 10:36:09 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-04 10:36:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-04 10:36:09 - TARGET=i386 TB --- 2011-07-04 10:36:09 - TARGET_ARCH=i386 TB --- 2011-07-04 10:36:09 - TZ=UTC TB --- 2011-07-04 10:36:09 - __MAKE_CONF=/dev/null TB --- 2011-07-04 10:36:09 - cd /src TB --- 2011-07-04 10:36:09 - /usr/bin/make -B buildworld >>> World build started on Mon Jul 4 10:36:10 UTC 2011 >>> 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 Mon Jul 4 12:35:50 UTC 2011 TB --- 2011-07-04 12:35:50 - generating LINT kernel config TB --- 2011-07-04 12:35:50 - cd /src/sys/i386/conf TB --- 2011-07-04 12:35:50 - /usr/bin/make -B LINT TB --- 2011-07-04 12:35:50 - building LINT kernel TB --- 2011-07-04 12:35:50 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-04 12:35:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-04 12:35:50 - TARGET=i386 TB --- 2011-07-04 12:35:50 - TARGET_ARCH=i386 TB --- 2011-07-04 12:35:50 - TZ=UTC TB --- 2011-07-04 12:35:50 - __MAKE_CONF=/dev/null TB --- 2011-07-04 12:35:50 - cd /src TB --- 2011-07-04 12:35:50 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jul 4 12:35:50 UTC 2011 >>> 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-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/contrib/ipfilter/netinet/ip_sync.c -I/src/sys/contrib/ipfilter 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-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/contrib/ipfilter/netinet/mlfk_ipl.c -I/src/sys/contrib/ipfilter 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-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -pg -mprofiler-epilogue /src/sys/contrib/ngatm/netnatm/api/cc_conn.c -I/src/sys/contrib/ngatm In file included from /src/sys/netgraph/atm/ccatm/ng_ccatm_cust.h:43, from /src/sys/contrib/ngatm/netnatm/api/ccpriv.h:38, from /src/sys/contrib/ngatm/netnatm/api/cc_conn.c:47: /src/sys/netgraph/netgraph.h: In function '_ng_node_unref': /src/sys/netgraph/netgraph.h:500: error: void value not ignored as it ought to be *** Error code 1 Stop in /obj/i386.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-07-04 12:40:43 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-07-04 12:40:43 - ERROR: failed to build lint kernel TB --- 2011-07-04 12:40:43 - 5867.49 user 1113.62 system 7842.94 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Mon Jul 4 13:05:23 2011 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 44C83106566B; Mon, 4 Jul 2011 13:05: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 18C048FC0A; Mon, 4 Jul 2011 13:05:22 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p64D5Mw0031832; Mon, 4 Jul 2011 09:05:22 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p64D5Mbi031795; Mon, 4 Jul 2011 13:05:22 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 4 Jul 2011 13:05:22 GMT Message-Id: <201107041305.p64D5Mbi031795@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: Mon, 04 Jul 2011 13:05:23 -0000 TB --- 2011-07-04 10:30:00 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-07-04 10:30:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2011-07-04 10:30:00 - cleaning the object tree TB --- 2011-07-04 10:30:44 - cvsupping the source tree TB --- 2011-07-04 10:30:44 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2011-07-04 10:30:57 - building world TB --- 2011-07-04 10:30:57 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-04 10:30:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-04 10:30:57 - TARGET=amd64 TB --- 2011-07-04 10:30:57 - TARGET_ARCH=amd64 TB --- 2011-07-04 10:30:57 - TZ=UTC TB --- 2011-07-04 10:30:57 - __MAKE_CONF=/dev/null TB --- 2011-07-04 10:30:57 - cd /src TB --- 2011-07-04 10:30:57 - /usr/bin/make -B buildworld >>> World build started on Mon Jul 4 10:30:58 UTC 2011 >>> 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 Mon Jul 4 13:00:33 UTC 2011 TB --- 2011-07-04 13:00:34 - generating LINT kernel config TB --- 2011-07-04 13:00:34 - cd /src/sys/amd64/conf TB --- 2011-07-04 13:00:34 - /usr/bin/make -B LINT TB --- 2011-07-04 13:00:34 - building LINT kernel TB --- 2011-07-04 13:00:34 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-04 13:00:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-04 13:00:34 - TARGET=amd64 TB --- 2011-07-04 13:00:34 - TARGET_ARCH=amd64 TB --- 2011-07-04 13:00:34 - TZ=UTC TB --- 2011-07-04 13:00:34 - __MAKE_CONF=/dev/null TB --- 2011-07-04 13:00:34 - cd /src TB --- 2011-07-04 13:00:34 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jul 4 13:00:34 UTC 2011 >>> 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 -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/contrib/ipfilter/netinet/ip_sync.c -I/src/sys/contrib/ipfilter 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 -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/contrib/ipfilter/netinet/mlfk_ipl.c -I/src/sys/contrib/ipfilter 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 -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -pg -mprofiler-epilogue /src/sys/contrib/ngatm/netnatm/api/cc_conn.c -I/src/sys/contrib/ngatm In file included from /src/sys/netgraph/atm/ccatm/ng_ccatm_cust.h:43, from /src/sys/contrib/ngatm/netnatm/api/ccpriv.h:38, from /src/sys/contrib/ngatm/netnatm/api/cc_conn.c:47: /src/sys/netgraph/netgraph.h: In function '_ng_node_unref': /src/sys/netgraph/netgraph.h:500: error: void value not ignored as it ought to be *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-07-04 13:05:21 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-07-04 13:05:21 - ERROR: failed to build lint kernel TB --- 2011-07-04 13:05:21 - 7210.56 user 1482.70 system 9321.35 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Mon Jul 4 13:50:35 2011 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 A6B891065678; Mon, 4 Jul 2011 13:50:35 +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 799B98FC18; Mon, 4 Jul 2011 13:50:35 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p64DoYEu036578; Mon, 4 Jul 2011 09:50:34 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p64DoYbF036565; Mon, 4 Jul 2011 13:50:34 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 4 Jul 2011 13:50:34 GMT Message-Id: <201107041350.p64DoYbF036565@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: Mon, 04 Jul 2011 13:50:35 -0000 TB --- 2011-07-04 12:20:19 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-07-04 12:20:19 - starting HEAD tinderbox run for ia64/ia64 TB --- 2011-07-04 12:20:19 - cleaning the object tree TB --- 2011-07-04 12:20:40 - cvsupping the source tree TB --- 2011-07-04 12:20:40 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2011-07-04 12:20:52 - building world TB --- 2011-07-04 12:20:52 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-04 12:20:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-04 12:20:52 - TARGET=ia64 TB --- 2011-07-04 12:20:52 - TARGET_ARCH=ia64 TB --- 2011-07-04 12:20:52 - TZ=UTC TB --- 2011-07-04 12:20:52 - __MAKE_CONF=/dev/null TB --- 2011-07-04 12:20:52 - cd /src TB --- 2011-07-04 12:20:52 - /usr/bin/make -B buildworld >>> World build started on Mon Jul 4 12:20:53 UTC 2011 >>> 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 Mon Jul 4 13:46:29 UTC 2011 TB --- 2011-07-04 13:46:29 - generating LINT kernel config TB --- 2011-07-04 13:46:29 - cd /src/sys/ia64/conf TB --- 2011-07-04 13:46:29 - /usr/bin/make -B LINT TB --- 2011-07-04 13:46:29 - building LINT kernel TB --- 2011-07-04 13:46:29 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-04 13:46:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-04 13:46:29 - TARGET=ia64 TB --- 2011-07-04 13:46:29 - TARGET_ARCH=ia64 TB --- 2011-07-04 13:46:29 - TZ=UTC TB --- 2011-07-04 13:46:29 - __MAKE_CONF=/dev/null TB --- 2011-07-04 13:46:29 - cd /src TB --- 2011-07-04 13:46:29 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jul 4 13:46:29 UTC 2011 >>> 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/contrib/ipfilter/netinet/ip_sync.c -I/src/sys/contrib/ipfilter 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/contrib/ipfilter/netinet/mlfk_ipl.c -I/src/sys/contrib/ipfilter 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 /src/sys/contrib/ngatm/netnatm/api/cc_conn.c -I/src/sys/contrib/ngatm In file included from /src/sys/netgraph/atm/ccatm/ng_ccatm_cust.h:43, from /src/sys/contrib/ngatm/netnatm/api/ccpriv.h:38, from /src/sys/contrib/ngatm/netnatm/api/cc_conn.c:47: /src/sys/netgraph/netgraph.h: In function '_ng_node_unref': /src/sys/netgraph/netgraph.h:500: error: void value not ignored as it ought to be *** Error code 1 Stop in /obj/ia64.ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-07-04 13:50:34 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-07-04 13:50:34 - ERROR: failed to build lint kernel TB --- 2011-07-04 13:50:34 - 4221.88 user 876.72 system 5414.38 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Mon Jul 4 14:31:30 2011 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 09E2A1065672; Mon, 4 Jul 2011 14:31:30 +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 BB9E88FC13; Mon, 4 Jul 2011 14:31:29 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p64EVTMi001609; Mon, 4 Jul 2011 10:31:29 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p64EVTd3001601; Mon, 4 Jul 2011 14:31:29 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 4 Jul 2011 14:31:29 GMT Message-Id: <201107041431.p64EVTd3001601@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: Mon, 04 Jul 2011 14:31:30 -0000 TB --- 2011-07-04 12:40:43 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-07-04 12:40:43 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2011-07-04 12:40:43 - cleaning the object tree TB --- 2011-07-04 12:41:03 - cvsupping the source tree TB --- 2011-07-04 12:41:03 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2011-07-04 12:41:17 - building world TB --- 2011-07-04 12:41:17 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-04 12:41:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-04 12:41:17 - TARGET=powerpc TB --- 2011-07-04 12:41:17 - TARGET_ARCH=powerpc TB --- 2011-07-04 12:41:17 - TZ=UTC TB --- 2011-07-04 12:41:17 - __MAKE_CONF=/dev/null TB --- 2011-07-04 12:41:17 - cd /src TB --- 2011-07-04 12:41:17 - /usr/bin/make -B buildworld >>> World build started on Mon Jul 4 12:41:18 UTC 2011 >>> 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 Mon Jul 4 14:28:31 UTC 2011 TB --- 2011-07-04 14:28:32 - generating LINT kernel config TB --- 2011-07-04 14:28:32 - cd /src/sys/powerpc/conf TB --- 2011-07-04 14:28:32 - /usr/bin/make -B LINT TB --- 2011-07-04 14:28:32 - building LINT kernel TB --- 2011-07-04 14:28:32 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-04 14:28:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-04 14:28:32 - TARGET=powerpc TB --- 2011-07-04 14:28:32 - TARGET_ARCH=powerpc TB --- 2011-07-04 14:28:32 - TZ=UTC TB --- 2011-07-04 14:28:32 - __MAKE_CONF=/dev/null TB --- 2011-07-04 14:28:32 - cd /src TB --- 2011-07-04 14:28:32 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jul 4 14:28:32 UTC 2011 >>> 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/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/contrib/ipfilter/netinet/ip_sync.c -I/src/sys/contrib/ipfilter 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/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/contrib/ipfilter/netinet/mlfk_ipl.c -I/src/sys/contrib/ipfilter 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/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 /src/sys/contrib/ngatm/netnatm/api/cc_conn.c -I/src/sys/contrib/ngatm In file included from /src/sys/netgraph/atm/ccatm/ng_ccatm_cust.h:43, from /src/sys/contrib/ngatm/netnatm/api/ccpriv.h:38, from /src/sys/contrib/ngatm/netnatm/api/cc_conn.c:47: /src/sys/netgraph/netgraph.h: In function '_ng_node_unref': /src/sys/netgraph/netgraph.h:500: error: void value not ignored as it ought to be *** Error code 1 Stop in /obj/powerpc.powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-07-04 14:31:28 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-07-04 14:31:28 - ERROR: failed to build lint kernel TB --- 2011-07-04 14:31:28 - 5361.84 user 1015.84 system 6644.75 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Mon Jul 4 14:34:23 2011 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 CB00A106564A; Mon, 4 Jul 2011 14:34: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 3CA1E8FC0A; Mon, 4 Jul 2011 14:34:22 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p64EYMYt021837; Mon, 4 Jul 2011 10:34:22 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p64EYMjJ021830; Mon, 4 Jul 2011 14:34:22 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 4 Jul 2011 14:34:22 GMT Message-Id: <201107041434.p64EYMjJ021830@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: Mon, 04 Jul 2011 14:34:23 -0000 TB --- 2011-07-04 13:32:06 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-07-04 13:32:06 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2011-07-04 13:32:06 - cleaning the object tree TB --- 2011-07-04 13:32:21 - cvsupping the source tree TB --- 2011-07-04 13:32:21 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2011-07-04 13:32:34 - building world TB --- 2011-07-04 13:32:34 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-04 13:32:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-04 13:32:34 - TARGET=sparc64 TB --- 2011-07-04 13:32:34 - TARGET_ARCH=sparc64 TB --- 2011-07-04 13:32:34 - TZ=UTC TB --- 2011-07-04 13:32:34 - __MAKE_CONF=/dev/null TB --- 2011-07-04 13:32:34 - cd /src TB --- 2011-07-04 13:32:34 - /usr/bin/make -B buildworld >>> World build started on Mon Jul 4 13:32:34 UTC 2011 >>> 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 Mon Jul 4 14:31:32 UTC 2011 TB --- 2011-07-04 14:31:32 - generating LINT kernel config TB --- 2011-07-04 14:31:32 - cd /src/sys/sparc64/conf TB --- 2011-07-04 14:31:32 - /usr/bin/make -B LINT TB --- 2011-07-04 14:31:32 - building LINT kernel TB --- 2011-07-04 14:31:32 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-04 14:31:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-04 14:31:32 - TARGET=sparc64 TB --- 2011-07-04 14:31:32 - TARGET_ARCH=sparc64 TB --- 2011-07-04 14:31:32 - TZ=UTC TB --- 2011-07-04 14:31:32 - __MAKE_CONF=/dev/null TB --- 2011-07-04 14:31:32 - cd /src TB --- 2011-07-04 14:31:32 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jul 4 14:31:32 UTC 2011 >>> 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/contrib/ipfilter/netinet/ip_sync.c -I/src/sys/contrib/ipfilter 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/contrib/ipfilter/netinet/mlfk_ipl.c -I/src/sys/contrib/ipfilter 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 /src/sys/contrib/ngatm/netnatm/api/cc_conn.c -I/src/sys/contrib/ngatm In file included from /src/sys/netgraph/atm/ccatm/ng_ccatm_cust.h:43, from /src/sys/contrib/ngatm/netnatm/api/ccpriv.h:38, from /src/sys/contrib/ngatm/netnatm/api/cc_conn.c:47: /src/sys/netgraph/netgraph.h: In function '_ng_node_unref': /src/sys/netgraph/netgraph.h:500: error: void value not ignored as it ought to be *** Error code 1 Stop in /obj/sparc64.sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-07-04 14:34:22 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-07-04 14:34:22 - ERROR: failed to build lint kernel TB --- 2011-07-04 14:34:22 - 2887.96 user 715.31 system 3735.96 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Mon Jul 4 14:41:43 2011 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 BAEB61065679; Mon, 4 Jul 2011 14:41: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 89F328FC1B; Mon, 4 Jul 2011 14:41:43 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p64Efg9d051259; Mon, 4 Jul 2011 10:41:42 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p64Efgjr051258; Mon, 4 Jul 2011 14:41:42 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 4 Jul 2011 14:41:42 GMT Message-Id: <201107041441.p64Efgjr051258@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: Mon, 04 Jul 2011 14:41:43 -0000 TB --- 2011-07-04 13:05:22 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-07-04 13:05:22 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2011-07-04 13:05:22 - cleaning the object tree TB --- 2011-07-04 13:05:46 - cvsupping the source tree TB --- 2011-07-04 13:05:46 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2011-07-04 13:05:59 - building world TB --- 2011-07-04 13:05:59 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-04 13:05:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-04 13:05:59 - TARGET=powerpc TB --- 2011-07-04 13:05:59 - TARGET_ARCH=powerpc64 TB --- 2011-07-04 13:05:59 - TZ=UTC TB --- 2011-07-04 13:05:59 - __MAKE_CONF=/dev/null TB --- 2011-07-04 13:05:59 - cd /src TB --- 2011-07-04 13:05:59 - /usr/bin/make -B buildworld >>> World build started on Mon Jul 4 13:06:00 UTC 2011 >>> 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 Mon Jul 4 14:38:50 UTC 2011 TB --- 2011-07-04 14:38:50 - generating LINT kernel config TB --- 2011-07-04 14:38:50 - cd /src/sys/powerpc/conf TB --- 2011-07-04 14:38:50 - /usr/bin/make -B LINT TB --- 2011-07-04 14:38:50 - building LINT kernel TB --- 2011-07-04 14:38:50 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-04 14:38:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-04 14:38:50 - TARGET=powerpc TB --- 2011-07-04 14:38:50 - TARGET_ARCH=powerpc64 TB --- 2011-07-04 14:38:50 - TZ=UTC TB --- 2011-07-04 14:38:50 - __MAKE_CONF=/dev/null TB --- 2011-07-04 14:38:50 - cd /src TB --- 2011-07-04 14:38:50 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jul 4 14:38:50 UTC 2011 >>> 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/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/contrib/ipfilter/netinet/ip_sync.c -I/src/sys/contrib/ipfilter 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/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/contrib/ipfilter/netinet/mlfk_ipl.c -I/src/sys/contrib/ipfilter 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/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 /src/sys/contrib/ngatm/netnatm/api/cc_conn.c -I/src/sys/contrib/ngatm In file included from /src/sys/netgraph/atm/ccatm/ng_ccatm_cust.h:43, from /src/sys/contrib/ngatm/netnatm/api/ccpriv.h:38, from /src/sys/contrib/ngatm/netnatm/api/cc_conn.c:47: /src/sys/netgraph/netgraph.h: In function '_ng_node_unref': /src/sys/netgraph/netgraph.h:500: error: void value not ignored as it ought to be *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-07-04 14:41:42 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-07-04 14:41:42 - ERROR: failed to build lint kernel TB --- 2011-07-04 14:41:42 - 4448.76 user 1083.21 system 5780.16 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Mon Jul 4 15:11:11 2011 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 7C4EC1065670 for ; Mon, 4 Jul 2011 15:11:11 +0000 (UTC) (envelope-from damjan.marion@gmail.com) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by mx1.freebsd.org (Postfix) with ESMTP id 0C8DA8FC15 for ; Mon, 4 Jul 2011 15:11:10 +0000 (UTC) Received: by fxe6 with SMTP id 6so4297873fxe.17 for ; Mon, 04 Jul 2011 08:11:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=fRsO9K15twpjWypdmBX+Sgj4KqRrlQvJ0sVxpMtygoQ=; b=RUVk8r6F9bfffjFs0CfASXyCCBz0BlyN5ySIMqDSSsGov7HA49kuCKVl75yhu/+biz fwRAs5EUhUiw7bP6pp8y31fy7QRsqWf9Vbsk8b6oso7B3OsJ+v4MiYQDokNjFeGzhaJ4 05Ma6/oIB82K8fYNwx9tMVNNMCmIn1/hKpIZg= Received: by 10.223.4.209 with SMTP id 17mr9757405fas.35.1309792269907; Mon, 04 Jul 2011 08:11:09 -0700 (PDT) Received: from damarion-mac.home (cpe-109-60-79-155.zg3.cable.xnet.hr [109.60.79.155]) by mx.google.com with ESMTPS id o23sm4613400faa.9.2011.07.04.08.11.08 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 04 Jul 2011 08:11:09 -0700 (PDT) From: Damjan Marion Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 4 Jul 2011 17:11:07 +0200 Message-Id: To: current@freebsd.org Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) Cc: Subject: Status of clang/llvm cross-compiling for ARM 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, 04 Jul 2011 15:11:11 -0000 Hi, Just to briefly share with wider audience progress on cross-compiling = for=20 ARM using llvm/clang. I managed to cross-compile kernel with clang for Marvel SoC and run = world=20 compiled with gcc in multiuser. It works stable and I didn't notice any=20= issues so far. Cross compiling even works from MacOS. Caveat is that it=20= still requires binutils as integrated assembler is not stable enough. The real benefit of having clang in place is support of new ARM=20 architectures (ARMv6, ARMv7) which are not supported in last GPLv2 = gcc/binutils. With regards to building world, main issue is ARM ABI. FreeBSD uses=20 ATPCS[1] procedure call standard which is older one. New one is called=20= AAPCS [2] and introduces some important performance related stuff. = llvm/clang=20 doesn't support older ATPCS standard so it fails to build some = libraries. Andrew already did some work on moving to AAPCS[3]. When we will have = AAPCS=20 implemented then I expect that building of world should work without any = major=20 issues. Damjan [1] http://infocenter.arm.com/help/topic/com.arm.doc.espc0002/ATPCS.pdf [2] = http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042d/IHI0042D_aapcs.p= df [3] http://svnweb.freebsd.org/base/projects/arm_eabi/ From owner-freebsd-current@FreeBSD.ORG Mon Jul 4 15:52:59 2011 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 08F191065679 for ; Mon, 4 Jul 2011 15:52:59 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: from vlakno.cz (lev.vlakno.cz [46.28.110.116]) by mx1.freebsd.org (Postfix) with ESMTP id C23648FC1C for ; Mon, 4 Jul 2011 15:52:58 +0000 (UTC) Received: by vlakno.cz (Postfix, from userid 1002) id B2A317F4A48; Mon, 4 Jul 2011 17:37:20 +0200 (CEST) Date: Mon, 4 Jul 2011 17:37:20 +0200 From: Roman Divacky To: Damjan Marion Message-ID: <20110704153720.GA72021@freebsd.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org Subject: Re: Status of clang/llvm cross-compiling for ARM 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, 04 Jul 2011 15:52:59 -0000 On Mon, Jul 04, 2011 at 05:11:07PM +0200, Damjan Marion wrote: > > Hi, > > Just to briefly share with wider audience progress on cross-compiling for > ARM using llvm/clang. > > I managed to cross-compile kernel with clang for Marvel SoC and run world > compiled with gcc in multiuser. It works stable and I didn't notice any > issues so far. Cross compiling even works from MacOS. Caveat is that it > still requires binutils as integrated assembler is not stable enough. To make it absolutely clear - Damjan booted kernel built with clang and reports that it's even running stable. I think it's a very nice milestone. Congrats! roman From owner-freebsd-current@FreeBSD.ORG Mon Jul 4 16:51:07 2011 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 A07E8106566B; Mon, 4 Jul 2011 16:51: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 6C7EE8FC13; Mon, 4 Jul 2011 16:51:07 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p64Gp61G013611; Mon, 4 Jul 2011 12:51:06 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p64Gp6dP013564; Mon, 4 Jul 2011 16:51:06 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 4 Jul 2011 16:51:06 GMT Message-Id: <201107041651.p64Gp6dP013564@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: Mon, 04 Jul 2011 16:51:07 -0000 TB --- 2011-07-04 14:50:00 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-07-04 14:50:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2011-07-04 14:50:00 - cleaning the object tree TB --- 2011-07-04 14:50:21 - cvsupping the source tree TB --- 2011-07-04 14:50:21 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2011-07-04 14:50:39 - building world TB --- 2011-07-04 14:50:39 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-04 14:50:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-04 14:50:39 - TARGET=pc98 TB --- 2011-07-04 14:50:39 - TARGET_ARCH=i386 TB --- 2011-07-04 14:50:39 - TZ=UTC TB --- 2011-07-04 14:50:39 - __MAKE_CONF=/dev/null TB --- 2011-07-04 14:50:39 - cd /src TB --- 2011-07-04 14:50:39 - /usr/bin/make -B buildworld >>> World build started on Mon Jul 4 14:50:39 UTC 2011 >>> 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 Mon Jul 4 16:46:51 UTC 2011 TB --- 2011-07-04 16:46:51 - generating LINT kernel config TB --- 2011-07-04 16:46:51 - cd /src/sys/pc98/conf TB --- 2011-07-04 16:46:51 - /usr/bin/make -B LINT TB --- 2011-07-04 16:46:51 - building LINT kernel TB --- 2011-07-04 16:46:51 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-04 16:46:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-04 16:46:51 - TARGET=pc98 TB --- 2011-07-04 16:46:51 - TARGET_ARCH=i386 TB --- 2011-07-04 16:46:51 - TZ=UTC TB --- 2011-07-04 16:46:51 - __MAKE_CONF=/dev/null TB --- 2011-07-04 16:46:51 - cd /src TB --- 2011-07-04 16:46:51 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jul 4 16:46:51 UTC 2011 >>> 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-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/contrib/ipfilter/netinet/ip_sync.c -I/src/sys/contrib/ipfilter 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-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/contrib/ipfilter/netinet/mlfk_ipl.c -I/src/sys/contrib/ipfilter 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-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -pg -mprofiler-epilogue /src/sys/contrib/ngatm/netnatm/api/cc_conn.c -I/src/sys/contrib/ngatm In file included from /src/sys/netgraph/atm/ccatm/ng_ccatm_cust.h:43, from /src/sys/contrib/ngatm/netnatm/api/ccpriv.h:38, from /src/sys/contrib/ngatm/netnatm/api/cc_conn.c:47: /src/sys/netgraph/netgraph.h: In function '_ng_node_unref': /src/sys/netgraph/netgraph.h:500: error: void value not ignored as it ought to be *** Error code 1 Stop in /obj/pc98.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-07-04 16:51:05 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-07-04 16:51:05 - ERROR: failed to build lint kernel TB --- 2011-07-04 16:51:06 - 5693.16 user 1099.80 system 7265.68 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Mon Jul 4 16:52:06 2011 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 D8F3E106566C; Mon, 4 Jul 2011 16:52:06 +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 AD64C8FC16; Mon, 4 Jul 2011 16:52:06 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p64Gq6rx021599; Mon, 4 Jul 2011 12:52:06 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p64Gq6Tv021593; Mon, 4 Jul 2011 16:52:06 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 4 Jul 2011 16:52:06 GMT Message-Id: <201107041652.p64Gq6Tv021593@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: Mon, 04 Jul 2011 16:52:07 -0000 TB --- 2011-07-04 14:50:00 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-07-04 14:50:00 - starting HEAD tinderbox run for i386/i386 TB --- 2011-07-04 14:50:00 - cleaning the object tree TB --- 2011-07-04 14:50:21 - cvsupping the source tree TB --- 2011-07-04 14:50:21 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-07-04 14:50:39 - building world TB --- 2011-07-04 14:50:39 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-04 14:50:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-04 14:50:39 - TARGET=i386 TB --- 2011-07-04 14:50:39 - TARGET_ARCH=i386 TB --- 2011-07-04 14:50:39 - TZ=UTC TB --- 2011-07-04 14:50:39 - __MAKE_CONF=/dev/null TB --- 2011-07-04 14:50:39 - cd /src TB --- 2011-07-04 14:50:39 - /usr/bin/make -B buildworld >>> World build started on Mon Jul 4 14:50:39 UTC 2011 >>> 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 Mon Jul 4 16:47:13 UTC 2011 TB --- 2011-07-04 16:47:13 - generating LINT kernel config TB --- 2011-07-04 16:47:13 - cd /src/sys/i386/conf TB --- 2011-07-04 16:47:13 - /usr/bin/make -B LINT TB --- 2011-07-04 16:47:14 - building LINT kernel TB --- 2011-07-04 16:47:14 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-04 16:47:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-04 16:47:14 - TARGET=i386 TB --- 2011-07-04 16:47:14 - TARGET_ARCH=i386 TB --- 2011-07-04 16:47:14 - TZ=UTC TB --- 2011-07-04 16:47:14 - __MAKE_CONF=/dev/null TB --- 2011-07-04 16:47:14 - cd /src TB --- 2011-07-04 16:47:14 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jul 4 16:47:15 UTC 2011 >>> 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-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/contrib/ipfilter/netinet/ip_sync.c -I/src/sys/contrib/ipfilter 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-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/contrib/ipfilter/netinet/mlfk_ipl.c -I/src/sys/contrib/ipfilter 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-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -pg -mprofiler-epilogue /src/sys/contrib/ngatm/netnatm/api/cc_conn.c -I/src/sys/contrib/ngatm In file included from /src/sys/netgraph/atm/ccatm/ng_ccatm_cust.h:43, from /src/sys/contrib/ngatm/netnatm/api/ccpriv.h:38, from /src/sys/contrib/ngatm/netnatm/api/cc_conn.c:47: /src/sys/netgraph/netgraph.h: In function '_ng_node_unref': /src/sys/netgraph/netgraph.h:500: error: void value not ignored as it ought to be *** Error code 1 Stop in /obj/i386.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-07-04 16:52:05 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-07-04 16:52:05 - ERROR: failed to build lint kernel TB --- 2011-07-04 16:52:05 - 5747.40 user 1100.35 system 7325.50 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Mon Jul 4 17:28:26 2011 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 ED8271065675; Mon, 4 Jul 2011 17:28: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 BBCCA8FC0A; Mon, 4 Jul 2011 17:28:26 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p64HSPM3069085; Mon, 4 Jul 2011 13:28:25 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p64HSPe8069047; Mon, 4 Jul 2011 17:28:25 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 4 Jul 2011 17:28:25 GMT Message-Id: <201107041728.p64HSPe8069047@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: Mon, 04 Jul 2011 17:28:27 -0000 TB --- 2011-07-04 14:50:00 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-07-04 14:50:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2011-07-04 14:50:00 - cleaning the object tree TB --- 2011-07-04 14:50:29 - cvsupping the source tree TB --- 2011-07-04 14:50:29 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2011-07-04 14:55:53 - building world TB --- 2011-07-04 14:55:53 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-04 14:55:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-04 14:55:53 - TARGET=amd64 TB --- 2011-07-04 14:55:53 - TARGET_ARCH=amd64 TB --- 2011-07-04 14:55:53 - TZ=UTC TB --- 2011-07-04 14:55:53 - __MAKE_CONF=/dev/null TB --- 2011-07-04 14:55:53 - cd /src TB --- 2011-07-04 14:55:53 - /usr/bin/make -B buildworld >>> World build started on Mon Jul 4 14:55:54 UTC 2011 >>> 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 Mon Jul 4 17:23:37 UTC 2011 TB --- 2011-07-04 17:23:37 - generating LINT kernel config TB --- 2011-07-04 17:23:37 - cd /src/sys/amd64/conf TB --- 2011-07-04 17:23:37 - /usr/bin/make -B LINT TB --- 2011-07-04 17:23:37 - building LINT kernel TB --- 2011-07-04 17:23:37 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-04 17:23:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-04 17:23:37 - TARGET=amd64 TB --- 2011-07-04 17:23:37 - TARGET_ARCH=amd64 TB --- 2011-07-04 17:23:37 - TZ=UTC TB --- 2011-07-04 17:23:37 - __MAKE_CONF=/dev/null TB --- 2011-07-04 17:23:37 - cd /src TB --- 2011-07-04 17:23:37 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jul 4 17:23:37 UTC 2011 >>> 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 -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/contrib/ipfilter/netinet/ip_sync.c -I/src/sys/contrib/ipfilter 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 -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/contrib/ipfilter/netinet/mlfk_ipl.c -I/src/sys/contrib/ipfilter 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 -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -pg -mprofiler-epilogue /src/sys/contrib/ngatm/netnatm/api/cc_conn.c -I/src/sys/contrib/ngatm In file included from /src/sys/netgraph/atm/ccatm/ng_ccatm_cust.h:43, from /src/sys/contrib/ngatm/netnatm/api/ccpriv.h:38, from /src/sys/contrib/ngatm/netnatm/api/cc_conn.c:47: /src/sys/netgraph/netgraph.h: In function '_ng_node_unref': /src/sys/netgraph/netgraph.h:500: error: void value not ignored as it ought to be *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-07-04 17:28:25 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-07-04 17:28:25 - ERROR: failed to build lint kernel TB --- 2011-07-04 17:28:25 - 7084.56 user 1459.00 system 9505.04 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Mon Jul 4 18:07:02 2011 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 9B0A81065672; Mon, 4 Jul 2011 18:07:02 +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 6AFC58FC0A; Mon, 4 Jul 2011 18:07:02 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p64I711t021824; Mon, 4 Jul 2011 14:07:01 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p64I71ei021798; Mon, 4 Jul 2011 18:07:01 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 4 Jul 2011 18:07:01 GMT Message-Id: <201107041807.p64I71ei021798@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: Mon, 04 Jul 2011 18:07:02 -0000 TB --- 2011-07-04 16:37:55 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-07-04 16:37:55 - starting HEAD tinderbox run for ia64/ia64 TB --- 2011-07-04 16:37:55 - cleaning the object tree TB --- 2011-07-04 16:38:07 - cvsupping the source tree TB --- 2011-07-04 16:38:07 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2011-07-04 16:38:19 - building world TB --- 2011-07-04 16:38:19 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-04 16:38:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-04 16:38:19 - TARGET=ia64 TB --- 2011-07-04 16:38:19 - TARGET_ARCH=ia64 TB --- 2011-07-04 16:38:19 - TZ=UTC TB --- 2011-07-04 16:38:19 - __MAKE_CONF=/dev/null TB --- 2011-07-04 16:38:19 - cd /src TB --- 2011-07-04 16:38:19 - /usr/bin/make -B buildworld >>> World build started on Mon Jul 4 16:38:20 UTC 2011 >>> 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 Mon Jul 4 18:03:04 UTC 2011 TB --- 2011-07-04 18:03:04 - generating LINT kernel config TB --- 2011-07-04 18:03:04 - cd /src/sys/ia64/conf TB --- 2011-07-04 18:03:04 - /usr/bin/make -B LINT TB --- 2011-07-04 18:03:04 - building LINT kernel TB --- 2011-07-04 18:03:04 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-04 18:03:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-04 18:03:04 - TARGET=ia64 TB --- 2011-07-04 18:03:04 - TARGET_ARCH=ia64 TB --- 2011-07-04 18:03:04 - TZ=UTC TB --- 2011-07-04 18:03:04 - __MAKE_CONF=/dev/null TB --- 2011-07-04 18:03:04 - cd /src TB --- 2011-07-04 18:03:04 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jul 4 18:03:04 UTC 2011 >>> 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/contrib/ipfilter/netinet/ip_sync.c -I/src/sys/contrib/ipfilter 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/contrib/ipfilter/netinet/mlfk_ipl.c -I/src/sys/contrib/ipfilter 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 /src/sys/contrib/ngatm/netnatm/api/cc_conn.c -I/src/sys/contrib/ngatm In file included from /src/sys/netgraph/atm/ccatm/ng_ccatm_cust.h:43, from /src/sys/contrib/ngatm/netnatm/api/ccpriv.h:38, from /src/sys/contrib/ngatm/netnatm/api/cc_conn.c:47: /src/sys/netgraph/netgraph.h:498: error: conflicting types for '_ng_node_unref' /src/sys/netgraph/netgraph.h:445: error: previous declaration of '_ng_node_unref' was here *** Error code 1 Stop in /obj/ia64.ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-07-04 18:07:01 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-07-04 18:07:01 - ERROR: failed to build lint kernel TB --- 2011-07-04 18:07:01 - 4170.34 user 866.60 system 5345.93 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Mon Jul 4 18:42:52 2011 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 D282D106564A; Mon, 4 Jul 2011 18:42: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 937B98FC13; Mon, 4 Jul 2011 18:42:52 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p64IgpfM060078; Mon, 4 Jul 2011 14:42:51 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p64IgpYD060062; Mon, 4 Jul 2011 18:42:51 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 4 Jul 2011 18:42:51 GMT Message-Id: <201107041842.p64IgpYD060062@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: Mon, 04 Jul 2011 18:42:52 -0000 TB --- 2011-07-04 16:52:06 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-07-04 16:52:06 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2011-07-04 16:52:06 - cleaning the object tree TB --- 2011-07-04 16:52:18 - cvsupping the source tree TB --- 2011-07-04 16:52:18 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2011-07-04 16:52:31 - building world TB --- 2011-07-04 16:52:31 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-04 16:52:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-04 16:52:31 - TARGET=powerpc TB --- 2011-07-04 16:52:31 - TARGET_ARCH=powerpc TB --- 2011-07-04 16:52:31 - TZ=UTC TB --- 2011-07-04 16:52:31 - __MAKE_CONF=/dev/null TB --- 2011-07-04 16:52:31 - cd /src TB --- 2011-07-04 16:52:31 - /usr/bin/make -B buildworld >>> World build started on Mon Jul 4 16:52:31 UTC 2011 >>> 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 Mon Jul 4 18:39:51 UTC 2011 TB --- 2011-07-04 18:39:51 - generating LINT kernel config TB --- 2011-07-04 18:39:51 - cd /src/sys/powerpc/conf TB --- 2011-07-04 18:39:51 - /usr/bin/make -B LINT TB --- 2011-07-04 18:39:51 - building LINT kernel TB --- 2011-07-04 18:39:51 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-04 18:39:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-04 18:39:51 - TARGET=powerpc TB --- 2011-07-04 18:39:51 - TARGET_ARCH=powerpc TB --- 2011-07-04 18:39:51 - TZ=UTC TB --- 2011-07-04 18:39:51 - __MAKE_CONF=/dev/null TB --- 2011-07-04 18:39:51 - cd /src TB --- 2011-07-04 18:39:51 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jul 4 18:39:51 UTC 2011 >>> 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/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/contrib/ipfilter/netinet/ip_sync.c -I/src/sys/contrib/ipfilter 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/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/contrib/ipfilter/netinet/mlfk_ipl.c -I/src/sys/contrib/ipfilter 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/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 /src/sys/contrib/ngatm/netnatm/api/cc_conn.c -I/src/sys/contrib/ngatm In file included from /src/sys/netgraph/atm/ccatm/ng_ccatm_cust.h:43, from /src/sys/contrib/ngatm/netnatm/api/ccpriv.h:38, from /src/sys/contrib/ngatm/netnatm/api/cc_conn.c:47: /src/sys/netgraph/netgraph.h:498: error: conflicting types for '_ng_node_unref' /src/sys/netgraph/netgraph.h:445: error: previous declaration of '_ng_node_unref' was here *** Error code 1 Stop in /obj/powerpc.powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-07-04 18:42:51 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-07-04 18:42:51 - ERROR: failed to build lint kernel TB --- 2011-07-04 18:42:51 - 5341.34 user 1021.81 system 6645.02 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Mon Jul 4 18:51:57 2011 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 C1A161065673; Mon, 4 Jul 2011 18:51:57 +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 91E3D8FC08; Mon, 4 Jul 2011 18:51:57 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p64IpuNU010539; Mon, 4 Jul 2011 14:51:56 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p64Ipumh010538; Mon, 4 Jul 2011 18:51:56 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 4 Jul 2011 18:51:56 GMT Message-Id: <201107041851.p64Ipumh010538@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: Mon, 04 Jul 2011 18:51:57 -0000 TB --- 2011-07-04 17:49:27 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-07-04 17:49:27 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2011-07-04 17:49:27 - cleaning the object tree TB --- 2011-07-04 17:49:38 - cvsupping the source tree TB --- 2011-07-04 17:49:38 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2011-07-04 17:50:22 - building world TB --- 2011-07-04 17:50:22 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-04 17:50:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-04 17:50:22 - TARGET=sparc64 TB --- 2011-07-04 17:50:22 - TARGET_ARCH=sparc64 TB --- 2011-07-04 17:50:22 - TZ=UTC TB --- 2011-07-04 17:50:22 - __MAKE_CONF=/dev/null TB --- 2011-07-04 17:50:22 - cd /src TB --- 2011-07-04 17:50:22 - /usr/bin/make -B buildworld >>> World build started on Mon Jul 4 17:50:23 UTC 2011 >>> 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 Mon Jul 4 18:49:06 UTC 2011 TB --- 2011-07-04 18:49:06 - generating LINT kernel config TB --- 2011-07-04 18:49:06 - cd /src/sys/sparc64/conf TB --- 2011-07-04 18:49:06 - /usr/bin/make -B LINT TB --- 2011-07-04 18:49:06 - building LINT kernel TB --- 2011-07-04 18:49:06 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-04 18:49:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-04 18:49:06 - TARGET=sparc64 TB --- 2011-07-04 18:49:06 - TARGET_ARCH=sparc64 TB --- 2011-07-04 18:49:06 - TZ=UTC TB --- 2011-07-04 18:49:06 - __MAKE_CONF=/dev/null TB --- 2011-07-04 18:49:06 - cd /src TB --- 2011-07-04 18:49:06 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jul 4 18:49:06 UTC 2011 >>> 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/contrib/ipfilter/netinet/ip_sync.c -I/src/sys/contrib/ipfilter 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/contrib/ipfilter/netinet/mlfk_ipl.c -I/src/sys/contrib/ipfilter 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 /src/sys/contrib/ngatm/netnatm/api/cc_conn.c -I/src/sys/contrib/ngatm In file included from /src/sys/netgraph/atm/ccatm/ng_ccatm_cust.h:43, from /src/sys/contrib/ngatm/netnatm/api/ccpriv.h:38, from /src/sys/contrib/ngatm/netnatm/api/cc_conn.c:47: /src/sys/netgraph/netgraph.h:498: error: conflicting types for '_ng_node_unref' /src/sys/netgraph/netgraph.h:445: error: previous declaration of '_ng_node_unref' was here *** Error code 1 Stop in /obj/sparc64.sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-07-04 18:51:56 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-07-04 18:51:56 - ERROR: failed to build lint kernel TB --- 2011-07-04 18:51:56 - 2879.98 user 712.33 system 3749.77 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Mon Jul 4 19:02:53 2011 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 654C1106564A; Mon, 4 Jul 2011 19:02:53 +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 3A1AC8FC12; Mon, 4 Jul 2011 19:02:52 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p64J2q8A044773; Mon, 4 Jul 2011 15:02:52 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p64J2qQW044772; Mon, 4 Jul 2011 19:02:52 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 4 Jul 2011 19:02:52 GMT Message-Id: <201107041902.p64J2qQW044772@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: Mon, 04 Jul 2011 19:02:53 -0000 TB --- 2011-07-04 17:28:26 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-07-04 17:28:26 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2011-07-04 17:28:26 - cleaning the object tree TB --- 2011-07-04 17:28:41 - cvsupping the source tree TB --- 2011-07-04 17:28:41 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2011-07-04 17:28:55 - building world TB --- 2011-07-04 17:28:55 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-04 17:28:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-04 17:28:55 - TARGET=powerpc TB --- 2011-07-04 17:28:55 - TARGET_ARCH=powerpc64 TB --- 2011-07-04 17:28:55 - TZ=UTC TB --- 2011-07-04 17:28:55 - __MAKE_CONF=/dev/null TB --- 2011-07-04 17:28:55 - cd /src TB --- 2011-07-04 17:28:55 - /usr/bin/make -B buildworld >>> World build started on Mon Jul 4 17:28:56 UTC 2011 >>> 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 Mon Jul 4 18:59:58 UTC 2011 TB --- 2011-07-04 18:59:58 - generating LINT kernel config TB --- 2011-07-04 18:59:58 - cd /src/sys/powerpc/conf TB --- 2011-07-04 18:59:58 - /usr/bin/make -B LINT TB --- 2011-07-04 18:59:59 - building LINT kernel TB --- 2011-07-04 18:59:59 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-04 18:59:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-04 18:59:59 - TARGET=powerpc TB --- 2011-07-04 18:59:59 - TARGET_ARCH=powerpc64 TB --- 2011-07-04 18:59:59 - TZ=UTC TB --- 2011-07-04 18:59:59 - __MAKE_CONF=/dev/null TB --- 2011-07-04 18:59:59 - cd /src TB --- 2011-07-04 18:59:59 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jul 4 18:59:59 UTC 2011 >>> 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/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/contrib/ipfilter/netinet/ip_sync.c -I/src/sys/contrib/ipfilter 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/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/contrib/ipfilter/netinet/mlfk_ipl.c -I/src/sys/contrib/ipfilter 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/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 /src/sys/contrib/ngatm/netnatm/api/cc_conn.c -I/src/sys/contrib/ngatm In file included from /src/sys/netgraph/atm/ccatm/ng_ccatm_cust.h:43, from /src/sys/contrib/ngatm/netnatm/api/ccpriv.h:38, from /src/sys/contrib/ngatm/netnatm/api/cc_conn.c:47: /src/sys/netgraph/netgraph.h:498: error: conflicting types for '_ng_node_unref' /src/sys/netgraph/netgraph.h:445: error: previous declaration of '_ng_node_unref' was here *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-07-04 19:02:52 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-07-04 19:02:52 - ERROR: failed to build lint kernel TB --- 2011-07-04 19:02:52 - 4425.05 user 1055.30 system 5665.88 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Mon Jul 4 21:13:06 2011 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 7B64A106564A; Mon, 4 Jul 2011 21:13:06 +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 4C1D78FC12; Mon, 4 Jul 2011 21:13:06 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p64LD579007494; Mon, 4 Jul 2011 17:13:05 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p64LD564007456; Mon, 4 Jul 2011 21:13:05 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 4 Jul 2011 21:13:05 GMT Message-Id: <201107042113.p64LD564007456@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: Mon, 04 Jul 2011 21:13:06 -0000 TB --- 2011-07-04 19:10:00 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-07-04 19:10:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2011-07-04 19:10:00 - cleaning the object tree TB --- 2011-07-04 19:10:23 - cvsupping the source tree TB --- 2011-07-04 19:10:23 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2011-07-04 19:10:46 - building world TB --- 2011-07-04 19:10:46 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-04 19:10:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-04 19:10:46 - TARGET=pc98 TB --- 2011-07-04 19:10:46 - TARGET_ARCH=i386 TB --- 2011-07-04 19:10:46 - TZ=UTC TB --- 2011-07-04 19:10:46 - __MAKE_CONF=/dev/null TB --- 2011-07-04 19:10:46 - cd /src TB --- 2011-07-04 19:10:46 - /usr/bin/make -B buildworld >>> World build started on Mon Jul 4 19:10:46 UTC 2011 >>> 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 Mon Jul 4 21:08:48 UTC 2011 TB --- 2011-07-04 21:08:48 - generating LINT kernel config TB --- 2011-07-04 21:08:49 - cd /src/sys/pc98/conf TB --- 2011-07-04 21:08:49 - /usr/bin/make -B LINT TB --- 2011-07-04 21:08:49 - building LINT kernel TB --- 2011-07-04 21:08:49 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-04 21:08:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-04 21:08:49 - TARGET=pc98 TB --- 2011-07-04 21:08:49 - TARGET_ARCH=i386 TB --- 2011-07-04 21:08:49 - TZ=UTC TB --- 2011-07-04 21:08:49 - __MAKE_CONF=/dev/null TB --- 2011-07-04 21:08:49 - cd /src TB --- 2011-07-04 21:08:49 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jul 4 21:08:49 UTC 2011 >>> 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-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/contrib/ipfilter/netinet/ip_sync.c -I/src/sys/contrib/ipfilter 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-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/contrib/ipfilter/netinet/mlfk_ipl.c -I/src/sys/contrib/ipfilter 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-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -pg -mprofiler-epilogue /src/sys/contrib/ngatm/netnatm/api/cc_conn.c -I/src/sys/contrib/ngatm In file included from /src/sys/netgraph/atm/ccatm/ng_ccatm_cust.h:43, from /src/sys/contrib/ngatm/netnatm/api/ccpriv.h:38, from /src/sys/contrib/ngatm/netnatm/api/cc_conn.c:47: /src/sys/netgraph/netgraph.h:498: error: conflicting types for '_ng_node_unref' /src/sys/netgraph/netgraph.h:445: error: previous declaration of '_ng_node_unref' was here *** Error code 1 Stop in /obj/pc98.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-07-04 21:13:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-07-04 21:13:04 - ERROR: failed to build lint kernel TB --- 2011-07-04 21:13:05 - 5782.05 user 1118.15 system 7384.04 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Mon Jul 4 21:14:14 2011 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 7F65A106566B; Mon, 4 Jul 2011 21:14:14 +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 50E298FC0A; Mon, 4 Jul 2011 21:14:14 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p64LEDcu016624; Mon, 4 Jul 2011 17:14:13 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p64LEDdS016619; Mon, 4 Jul 2011 21:14:13 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 4 Jul 2011 21:14:13 GMT Message-Id: <201107042114.p64LEDdS016619@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: Mon, 04 Jul 2011 21:14:14 -0000 TB --- 2011-07-04 19:10:00 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-07-04 19:10:00 - starting HEAD tinderbox run for i386/i386 TB --- 2011-07-04 19:10:00 - cleaning the object tree TB --- 2011-07-04 19:10:23 - cvsupping the source tree TB --- 2011-07-04 19:10:23 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-07-04 19:10:46 - building world TB --- 2011-07-04 19:10:46 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-04 19:10:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-04 19:10:46 - TARGET=i386 TB --- 2011-07-04 19:10:46 - TARGET_ARCH=i386 TB --- 2011-07-04 19:10:46 - TZ=UTC TB --- 2011-07-04 19:10:46 - __MAKE_CONF=/dev/null TB --- 2011-07-04 19:10:46 - cd /src TB --- 2011-07-04 19:10:46 - /usr/bin/make -B buildworld >>> World build started on Mon Jul 4 19:10:46 UTC 2011 >>> 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 Mon Jul 4 21:09:15 UTC 2011 TB --- 2011-07-04 21:09:15 - generating LINT kernel config TB --- 2011-07-04 21:09:15 - cd /src/sys/i386/conf TB --- 2011-07-04 21:09:15 - /usr/bin/make -B LINT TB --- 2011-07-04 21:09:15 - building LINT kernel TB --- 2011-07-04 21:09:15 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-04 21:09:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-04 21:09:15 - TARGET=i386 TB --- 2011-07-04 21:09:15 - TARGET_ARCH=i386 TB --- 2011-07-04 21:09:15 - TZ=UTC TB --- 2011-07-04 21:09:15 - __MAKE_CONF=/dev/null TB --- 2011-07-04 21:09:15 - cd /src TB --- 2011-07-04 21:09:15 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jul 4 21:09:15 UTC 2011 >>> 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-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/contrib/ipfilter/netinet/ip_sync.c -I/src/sys/contrib/ipfilter 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-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/contrib/ipfilter/netinet/mlfk_ipl.c -I/src/sys/contrib/ipfilter 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-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -pg -mprofiler-epilogue /src/sys/contrib/ngatm/netnatm/api/cc_conn.c -I/src/sys/contrib/ngatm In file included from /src/sys/netgraph/atm/ccatm/ng_ccatm_cust.h:43, from /src/sys/contrib/ngatm/netnatm/api/ccpriv.h:38, from /src/sys/contrib/ngatm/netnatm/api/cc_conn.c:47: /src/sys/netgraph/netgraph.h:498: error: conflicting types for '_ng_node_unref' /src/sys/netgraph/netgraph.h:445: error: previous declaration of '_ng_node_unref' was here *** Error code 1 Stop in /obj/i386.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-07-04 21:14:13 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-07-04 21:14:13 - ERROR: failed to build lint kernel TB --- 2011-07-04 21:14:13 - 5841.50 user 1112.55 system 7452.41 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Mon Jul 4 21:37:42 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id DC4E6106564A; Mon, 4 Jul 2011 21:37:42 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-4.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 4547514EF2B; Mon, 4 Jul 2011 21:37:42 +0000 (UTC) Message-ID: <4E1232A5.3030004@FreeBSD.org> Date: Mon, 04 Jul 2011 14:37:41 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.18) Gecko/20110624 Thunderbird/3.1.11 MIME-Version: 1.0 To: Alexander Motin References: <4DC25396.1070909@dougbarton.us> <4DCA1C06.6040505@FreeBSD.org> <4DCA73F6.70707@FreeBSD.org> In-Reply-To: <4DCA73F6.70707@FreeBSD.org> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: My problems with stability on -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: Mon, 04 Jul 2011 21:37:42 -0000 On 05/11/2011 04:33, Alexander Motin wrote: > On 11.05.2011 08:17, Doug Barton wrote: >> I had an interesting result doing nothing but switching from HPET to >> LAPIC ... no crash. Still on the same version of -current (r221566) the >> only thing I've done is to add kern.eventtimer.timer="LAPIC" to >> /boot/loader.conf, and so far I haven't been able to get it to crash no >> matter how much I compile, or how much other stuff I do in the >> background. I _can_ get the system heavily loaded enough so that the >> mouse can drag across the screen, windows take visible time to repaint, >> etc. That happens with a load average of 4+ on this core 2 duo. But >> other than that (which is not altogether unreasonable) the system has >> been very stable for a couple of days now. >> >> Does that suggest a next step in terms of what to test? > > The fact that LAPIC is working fine can mean that problem is either HPET > specific or non-per-CPU timers specific. To check that you could try to > use i8254 timer in one-shot mode: > hint.attimer.0.timecounter=0 > kern.eventtimer.timer="i8254" > > , or use HPET in per-CPU mode: > hint.atrtc.0.clock=0 > hint.attimer.0.clock=0 > hint.hpet.X.legacy_route=1 > > But the most informative would be to see what's going on with HPET > interrupts during the freezes. With HPET hardware it is very easy to > loose interrupt. And the lost interrupt means problem for many things. > There are some workarounds made for that, but I can't be sure. For that > case you could experiment with this patch: > --- acpi_hpet.c.prev 2010-12-25 11:28:45.000000000 +0200 > +++ acpi_hpet.c 2011-05-11 14:30:59.000000000 +0300 > @@ -190,7 +190,7 @@ restart: > bus_write_4(sc->mem_res, HPET_TIMER_COMPARATOR(t->num), > t->next); > } > - if (fdiv < 5000) { > + if (1 || fdiv < 5000) { > bus_read_4(sc->mem_res, HPET_TIMER_COMPARATOR(t->num)); > now = bus_read_4(sc->mem_res, HPET_MAIN_COUNTER); FYI, I have been running this patch since you sent it, and haven't crashed under high load since. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Mon Jul 4 21:50:22 2011 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 0491E1065673; Mon, 4 Jul 2011 21:50: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 C70A08FC17; Mon, 4 Jul 2011 21:50:21 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p64LoK4Y061704; Mon, 4 Jul 2011 17:50:20 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p64LoKXq061689; Mon, 4 Jul 2011 21:50:20 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 4 Jul 2011 21:50:20 GMT Message-Id: <201107042150.p64LoKXq061689@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: Mon, 04 Jul 2011 21:50:22 -0000 TB --- 2011-07-04 19:10:00 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-07-04 19:10:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2011-07-04 19:10:00 - cleaning the object tree TB --- 2011-07-04 19:10:29 - cvsupping the source tree TB --- 2011-07-04 19:10:29 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2011-07-04 19:15:54 - building world TB --- 2011-07-04 19:15:54 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-04 19:15:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-04 19:15:54 - TARGET=amd64 TB --- 2011-07-04 19:15:54 - TARGET_ARCH=amd64 TB --- 2011-07-04 19:15:54 - TZ=UTC TB --- 2011-07-04 19:15:54 - __MAKE_CONF=/dev/null TB --- 2011-07-04 19:15:54 - cd /src TB --- 2011-07-04 19:15:54 - /usr/bin/make -B buildworld >>> World build started on Mon Jul 4 19:15:55 UTC 2011 >>> 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 Mon Jul 4 21:45:35 UTC 2011 TB --- 2011-07-04 21:45:35 - generating LINT kernel config TB --- 2011-07-04 21:45:35 - cd /src/sys/amd64/conf TB --- 2011-07-04 21:45:35 - /usr/bin/make -B LINT TB --- 2011-07-04 21:45:35 - building LINT kernel TB --- 2011-07-04 21:45:35 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-04 21:45:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-04 21:45:35 - TARGET=amd64 TB --- 2011-07-04 21:45:35 - TARGET_ARCH=amd64 TB --- 2011-07-04 21:45:35 - TZ=UTC TB --- 2011-07-04 21:45:35 - __MAKE_CONF=/dev/null TB --- 2011-07-04 21:45:35 - cd /src TB --- 2011-07-04 21:45:35 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jul 4 21:45:35 UTC 2011 >>> 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 -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/contrib/ipfilter/netinet/ip_sync.c -I/src/sys/contrib/ipfilter 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 -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/contrib/ipfilter/netinet/mlfk_ipl.c -I/src/sys/contrib/ipfilter 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 -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -pg -mprofiler-epilogue /src/sys/contrib/ngatm/netnatm/api/cc_conn.c -I/src/sys/contrib/ngatm In file included from /src/sys/netgraph/atm/ccatm/ng_ccatm_cust.h:43, from /src/sys/contrib/ngatm/netnatm/api/ccpriv.h:38, from /src/sys/contrib/ngatm/netnatm/api/cc_conn.c:47: /src/sys/netgraph/netgraph.h:498: error: conflicting types for '_ng_node_unref' /src/sys/netgraph/netgraph.h:445: error: previous declaration of '_ng_node_unref' was here *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-07-04 21:50:20 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-07-04 21:50:20 - ERROR: failed to build lint kernel TB --- 2011-07-04 21:50:20 - 7178.37 user 1478.95 system 9619.25 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Mon Jul 4 22:29:07 2011 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 B11E31065674; Mon, 4 Jul 2011 22:29: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 7B9318FC08; Mon, 4 Jul 2011 22:29:07 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p64MT6VQ016877; Mon, 4 Jul 2011 18:29:06 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p64MT6NZ016858; Mon, 4 Jul 2011 22:29:06 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 4 Jul 2011 22:29:06 GMT Message-Id: <201107042229.p64MT6NZ016858@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: Mon, 04 Jul 2011 22:29:07 -0000 TB --- 2011-07-04 20:59:51 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-07-04 20:59:51 - starting HEAD tinderbox run for ia64/ia64 TB --- 2011-07-04 20:59:51 - cleaning the object tree TB --- 2011-07-04 21:00:03 - cvsupping the source tree TB --- 2011-07-04 21:00:03 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2011-07-04 21:00:16 - building world TB --- 2011-07-04 21:00:16 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-04 21:00:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-04 21:00:16 - TARGET=ia64 TB --- 2011-07-04 21:00:16 - TARGET_ARCH=ia64 TB --- 2011-07-04 21:00:16 - TZ=UTC TB --- 2011-07-04 21:00:16 - __MAKE_CONF=/dev/null TB --- 2011-07-04 21:00:16 - cd /src TB --- 2011-07-04 21:00:16 - /usr/bin/make -B buildworld >>> World build started on Mon Jul 4 21:00:17 UTC 2011 >>> 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 Mon Jul 4 22:25:06 UTC 2011 TB --- 2011-07-04 22:25:06 - generating LINT kernel config TB --- 2011-07-04 22:25:06 - cd /src/sys/ia64/conf TB --- 2011-07-04 22:25:06 - /usr/bin/make -B LINT TB --- 2011-07-04 22:25:06 - building LINT kernel TB --- 2011-07-04 22:25:06 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-04 22:25:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-04 22:25:06 - TARGET=ia64 TB --- 2011-07-04 22:25:06 - TARGET_ARCH=ia64 TB --- 2011-07-04 22:25:06 - TZ=UTC TB --- 2011-07-04 22:25:06 - __MAKE_CONF=/dev/null TB --- 2011-07-04 22:25:06 - cd /src TB --- 2011-07-04 22:25:06 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jul 4 22:25:07 UTC 2011 >>> 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/contrib/ipfilter/netinet/ip_sync.c -I/src/sys/contrib/ipfilter 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/contrib/ipfilter/netinet/mlfk_ipl.c -I/src/sys/contrib/ipfilter 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 /src/sys/contrib/ngatm/netnatm/api/cc_conn.c -I/src/sys/contrib/ngatm In file included from /src/sys/netgraph/atm/ccatm/ng_ccatm_cust.h:43, from /src/sys/contrib/ngatm/netnatm/api/ccpriv.h:38, from /src/sys/contrib/ngatm/netnatm/api/cc_conn.c:47: /src/sys/netgraph/netgraph.h:498: error: conflicting types for '_ng_node_unref' /src/sys/netgraph/netgraph.h:445: error: previous declaration of '_ng_node_unref' was here *** Error code 1 Stop in /obj/ia64.ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-07-04 22:29:06 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-07-04 22:29:06 - ERROR: failed to build lint kernel TB --- 2011-07-04 22:29:06 - 4169.61 user 873.48 system 5355.01 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Mon Jul 4 22:55:02 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 7B9CB106566C; Mon, 4 Jul 2011 22:55:02 +0000 (UTC) Date: Mon, 4 Jul 2011 22:55:02 +0000 From: Alexander Best To: freebsd-current@freebsd.org Message-ID: <20110704225502.GA24773@freebsd.org> References: <20110616102601.GA68610@freebsd.org> <20110617080925.GA68431@freebsd.org> <20110625103824.GA87124@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110625103824.GA87124@freebsd.org> Cc: freebsd-toolchain@freebsd.org Subject: Re: -128 errors after compiling kernel with clang tot (was: two issues after upgrading to a more up-to-date HEAD) 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, 04 Jul 2011 22:55:02 -0000 On Sat Jun 25 11, Alexander Best wrote: > On Fri Jun 17 11, Alexander Best wrote: > > On Thu Jun 16 11, Alexander Best wrote: > > > hi there, > > > > i reverted my kernel back to r222890. everything works fine now and both issues > > i mentioned below dissapeared. > > the previous issues (xpt_action_default and DIOCSKERNELDUMP) have been fixed. > however this one, where a lot of apps fail with errno -128 when accessing the > disk, still exists. this really needs to be fixed before 9.0! > > ...again...reverting to r222890 solves this completely. so it's not a problem > with the disk or anything. > > ..i'm guessing this is ahci related, but i'm not sure. i was able to solve the issue. it seems clang tot was responsible for the problem. i reverted back to compiling the kernel with gcc and the issue dissapeared. i haven't tried with the clang revision that ships with world. i think this problem only occurs with a more recent version of clang though. cheers. alex ps: i've added freebsd-toolchain to CC. maybe some of the freebsd clang people could confirm the issues with clang tot i was seeing. > > cheers. > alex > > > > > i also discovered another issue with the more recent kernel: > > > > i was getting errno -128 with a lot of apps. but only the first time i ran > > them. e.g. with git: > > > > 1) -128 > > 2) OK > > 3) -128 > > 4) OK > > 5) ... > > > > the same with stuff like ./configure or ee(1). first time failures while > > running or saving; second time it works. > > > > this as well was fixed by reverting back to r222890. > > > > cheers. > > alex > > > > > > > > i'm running HEAD on amd64. yesterday i updated my kernel to r223109. i'm now > > > seeing two issues, which weren't there beforehand: > > > > > > 1) > > > 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) > > > xpt_action_default: CCB type 0xe not supported > > > xpt_action_default: CCB type 0xe not supported > > > xpt_action_default: CCB type 0xe not supported > > > cd0 at ahcich2 bus 0 scbus2 target 0 lun 0 > > > cd0: Removable CD-ROM SCSI-0 device > > > SMP: AP CPU #1 Launched! > > > cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) > > > cd0: cd present [2291664 x 2048 byte records] > > > > > > ^^ i suspect the xpt_action_default messages have been introduced by the recent > > > CAM changes. they appear to be harmless though. > > > > > > 2) > > > dumpon: ioctl(DIOCSKERNELDUMP): Device not configured > > > /etc/rc: WARNING: unable to specify /dev/label/swapfs as a dump device > > > > > > /dev/label/swapfs is a perfect swap partition and worked without any problems > > > beforehand. specifying the device node instead of the label makes no > > > difference: > > > > > > taku% dumpon /dev/ada1p1 > > > dumpon: ioctl(DIOCSKERNELDUMP): Device not configured > > > otaku% gpart show > > > => 34 488394988 ada0 GPT (232G) > > > 34 128 1 freebsd-boot (64k) > > > 162 16777216 - free - (8.0G) > > > 16777378 471617644 3 freebsd-ufs (224G) > > > > > > => 34 1953525101 ada1 GPT (931G) > > > 34 20971520 1 freebsd-swap (10G) > > > 20971554 4194304 2 freebsd-ufs (2.0G) > > > 25165858 1928359277 3 freebsd-ufs (919G) > > > > > > otaku% glabel status > > > Name Status Components > > > label/boot N/A ada0p1 > > > gptid/e52df583-e446-11de-bb92-000fb58207c8 N/A ada0p1 > > > ufs/rootfs N/A ada0p3 > > > label/swapfs N/A ada1p1 > > > ufs/varfs N/A ada1p2 > > > ufs/usrfs N/A ada1p3 > > > iso9660/Futurama Season 6 Ep 1-8 720p N/A cd0 > > > > > > cheers. > > > alex > > > > > > -- > > > a13x > > > > -- > > a13x From owner-freebsd-current@FreeBSD.ORG Mon Jul 4 23:04:56 2011 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 22B551065673; Mon, 4 Jul 2011 23:04:56 +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 D7E788FC08; Mon, 4 Jul 2011 23:04:55 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p64N4t4H054672; Mon, 4 Jul 2011 19:04:55 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p64N4tBD054652; Mon, 4 Jul 2011 23:04:55 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 4 Jul 2011 23:04:55 GMT Message-Id: <201107042304.p64N4tBD054652@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: Mon, 04 Jul 2011 23:04:56 -0000 TB --- 2011-07-04 21:14:14 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-07-04 21:14:14 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2011-07-04 21:14:14 - cleaning the object tree TB --- 2011-07-04 21:14:27 - cvsupping the source tree TB --- 2011-07-04 21:14:27 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2011-07-04 21:14:39 - building world TB --- 2011-07-04 21:14:39 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-04 21:14:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-04 21:14:39 - TARGET=powerpc TB --- 2011-07-04 21:14:39 - TARGET_ARCH=powerpc TB --- 2011-07-04 21:14:39 - TZ=UTC TB --- 2011-07-04 21:14:39 - __MAKE_CONF=/dev/null TB --- 2011-07-04 21:14:39 - cd /src TB --- 2011-07-04 21:14:39 - /usr/bin/make -B buildworld >>> World build started on Mon Jul 4 21:14:40 UTC 2011 >>> 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 Mon Jul 4 23:01:55 UTC 2011 TB --- 2011-07-04 23:01:55 - generating LINT kernel config TB --- 2011-07-04 23:01:55 - cd /src/sys/powerpc/conf TB --- 2011-07-04 23:01:55 - /usr/bin/make -B LINT TB --- 2011-07-04 23:01:55 - building LINT kernel TB --- 2011-07-04 23:01:55 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-04 23:01:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-04 23:01:55 - TARGET=powerpc TB --- 2011-07-04 23:01:55 - TARGET_ARCH=powerpc TB --- 2011-07-04 23:01:55 - TZ=UTC TB --- 2011-07-04 23:01:55 - __MAKE_CONF=/dev/null TB --- 2011-07-04 23:01:55 - cd /src TB --- 2011-07-04 23:01:55 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jul 4 23:01:55 UTC 2011 >>> 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/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/contrib/ipfilter/netinet/ip_sync.c -I/src/sys/contrib/ipfilter 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/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/contrib/ipfilter/netinet/mlfk_ipl.c -I/src/sys/contrib/ipfilter 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/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 /src/sys/contrib/ngatm/netnatm/api/cc_conn.c -I/src/sys/contrib/ngatm In file included from /src/sys/netgraph/atm/ccatm/ng_ccatm_cust.h:43, from /src/sys/contrib/ngatm/netnatm/api/ccpriv.h:38, from /src/sys/contrib/ngatm/netnatm/api/cc_conn.c:47: /src/sys/netgraph/netgraph.h:498: error: conflicting types for '_ng_node_unref' /src/sys/netgraph/netgraph.h:445: error: previous declaration of '_ng_node_unref' was here *** Error code 1 Stop in /obj/powerpc.powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-07-04 23:04:54 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-07-04 23:04:54 - ERROR: failed to build lint kernel TB --- 2011-07-04 23:04:54 - 5346.51 user 1019.84 system 6640.90 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 5 01:05:05 2011 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 DD0791065673 for ; Tue, 5 Jul 2011 01:05:05 +0000 (UTC) (envelope-from stephen@missouri.edu) Received: from wilberforce.math.missouri.edu (wilberforce.math.missouri.edu [128.206.184.213]) by mx1.freebsd.org (Postfix) with ESMTP id 9FEF18FC17 for ; Tue, 5 Jul 2011 01:05:05 +0000 (UTC) Received: from [127.0.0.1] (wilberforce.math.missouri.edu [128.206.184.213]) by wilberforce.math.missouri.edu (8.14.4/8.14.4) with ESMTP id p65153nM092239; Mon, 4 Jul 2011 20:05:03 -0500 (CDT) (envelope-from stephen@missouri.edu) Message-ID: <4E12633F.9010608@missouri.edu> Date: Mon, 04 Jul 2011 20:05:03 -0500 From: Stephen Montgomery-Smith User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: jhell References: <4E0F3A53.3040309@yahoo.com> <20110703032553.GA77276@DataIX.net> <4E10D63A.5000706@missouri.edu> In-Reply-To: <4E10D63A.5000706@missouri.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-current@freebsd.org" Subject: Re: Problems with cvsup on FreeBSD 9, AMD64, osreldate: 900038 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, 05 Jul 2011 01:05:05 -0000 On 07/03/2011 03:51 PM, Stephen Montgomery-Smith wrote: > On 07/02/2011 10:25 PM, jhell wrote: > >> Use csup(1) in base. This is in 7, 8& 9. cvsup has been deprecated for >> much longer than it really needed to be and should probably be removed >> from use as a client entirely and links generated for installation of >> cvsup -> csup. >> >> Only drawback for you may be no X interface but it really was not that >> pretty in the first place and served no real good purpose over the >> functionality of the command line client. > > Another drawback to csup is that csup doesn't seem to recognize the > .cvsup/auth file. At least not on FreeBSD 7 of a few months ago. > > I run CTM generation, and I need access to cvsup-master. > My mistake. I found that in FreeBSD-CURRENT that csup does recognize .csup/auth. Any timetable on when this will by MFCed to FreeBSD 7 and 8? Incidentally, csup needs the following diff applied, so that I can continue to use "FreeBSD" in my auth file: 195c195 < if (strcmp(auth->server, server) != 0) --- > if (strcasecmp(auth->server, server) != 0) I'll file a PR. From owner-freebsd-current@FreeBSD.ORG Tue Jul 5 01:45:43 2011 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 6BD1B106564A for ; Tue, 5 Jul 2011 01:45:43 +0000 (UTC) (envelope-from ti.bugmenot@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2B9C88FC08 for ; Tue, 5 Jul 2011 01:45:42 +0000 (UTC) Received: by ywf7 with SMTP id 7so2712064ywf.13 for ; Mon, 04 Jul 2011 18:45:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:x-google-sender-delegation:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type; bh=D3Ia0bKDPPhupM8WsDJPfaXYgi8OWC0Pn5q2w2jBfaU=; b=J0pF5En/l8HvPTGDtvxz4iUeNxUTQXTGEE30n67nvzCQ+//Jpm+KoBqN6rToQPah1U eXdjINEI76vpe0zfHwpftL1C6RW2Nh4esjp2tLT3/Tvki+ag4ENqDY0uxxy8bh9WZw7m 0uKPsjZmRiZj09rjim5xywX2qafwT4mak8CE8= MIME-Version: 1.0 Received: by 10.236.185.3 with SMTP id t3mr8258808yhm.175.1309830342219; Mon, 04 Jul 2011 18:45:42 -0700 (PDT) Sender: ti.webdev@gmail.com X-Google-Sender-Delegation: ti.webdev@gmail.com Received: by 10.147.82.1 with HTTP; Mon, 4 Jul 2011 18:45:42 -0700 (PDT) In-Reply-To: <201107040938.26373.hselasky@c2i.net> References: <201107011851.00989.hselasky@c2i.net> <201107040938.26373.hselasky@c2i.net> Date: Tue, 5 Jul 2011 07:45:42 +0600 X-Google-Sender-Auth: HdRP_dLZt1WFQwC2-T7GZyqmx9M Message-ID: From: ti bugmenot To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Tue, 05 Jul 2011 04:34:06 +0000 Cc: Subject: Re: keyboard driver problem? 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, 05 Jul 2011 01:45:43 -0000 works well From owner-freebsd-current@FreeBSD.ORG Tue Jul 5 04:57:52 2011 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 152CB106564A; Tue, 5 Jul 2011 04:57:52 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id CC6D98FC0A; Tue, 5 Jul 2011 04:57:51 +0000 (UTC) Received: by pvg11 with SMTP id 11so6882532pvg.13 for ; Mon, 04 Jul 2011 21:57:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=FUOo9RBoxHrBhjD+eAXYODJtPuls4mjhBvSiJ4aczJc=; b=JIdgj7+kqi+z7/mblJfOSXSBZXoMm4tN5sWhFYIKv44jz1HPsZvpS7snPfk9X2vBS0 04Ju7lLhG8RANXBKQK8QcV5vENzAMW/751PVTTde5iNUdt7UlwD2kRKkqSNGGmfLcHgO I8unazVk/8SC8sluQXKD9Yj9o6R/PIE6HSkNY= MIME-Version: 1.0 Received: by 10.68.54.6 with SMTP id f6mr5366666pbp.139.1309841870971; Mon, 04 Jul 2011 21:57:50 -0700 (PDT) Received: by 10.68.64.200 with HTTP; Mon, 4 Jul 2011 21:57:50 -0700 (PDT) In-Reply-To: References: Date: Tue, 5 Jul 2011 00:57:50 -0400 Message-ID: From: Arnaud Lacombe To: freebsd-current@freebsd.org, ae@freebsd.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, Emil Muratov , Paolo Pisati Subject: Re: nfe taskq kernel panic 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, 05 Jul 2011 04:57:52 -0000 Hi, [Moving thread to -current, added ae@freebsd.org to the Cc: list as he changed that code recently.] On Wed, Jun 8, 2011 at 1:25 AM, Arnaud Lacombe wrote: > Hi, > > On Thu, May 5, 2011 at 2:49 PM, Arnaud Lacombe wrote= : >> Hi, >> >> On Thu, May 5, 2011 at 2:22 PM, Arnaud Lacombe wrot= e: >>> Hi, >>> >>> On Thu, May 5, 2011 at 1:37 PM, Emil Muratov wrote: >>>> >>>> >>>> Hi all. >>>> >>>> I have a small home router/nas running nvidia ion platform with onboar= d nfe >>>> LAN adapter. >>>> About a month ago I changed ISP and setup pppoe client with mpd5.5. Si= nce >>>> that time my router >>>> issues kernel panic once or twice a day with "Fatal trap 12: page faul= t >>>> while in kernel mode" and (nfe0 taskq) is the current process. >>>> Updating to the latest stable doesn't help. I don=92t know what to do = next, >>>> any help would be much appreciated. Below is kgdb backtrace, dmesg out= put, >>>> kernel config file, if anything is missing just let me know. >>>> >>> Your error looks like a nice use-after-free. Could you 'disassemble >>> 0xffffffff8037d7bb' in gdb, and find the matching faulty dereference ? >>> I'd tend not to trust code relying on "big hack", as per the preamble >>> of m_megapullup(): >>> >> There is a stale reference to the mbuf passed to, and freed in >> m_megapullup(); could you test the following patch ? >> >> diff --git a/sys/netinet/ipfw/ip_fw_nat.c b/sys/netinet/ipfw/ip_fw_nat.c >> index f8c3e63..80c13dc 100644 >> --- a/sys/netinet/ipfw/ip_fw_nat.c >> +++ b/sys/netinet/ipfw/ip_fw_nat.c >> @@ -263,7 +263,7 @@ ipfw_nat(struct ip_fw_args *args, struct cfg_nat >> *t, struct mbuf *m) >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0retval =3D LibAliasOut(t->lib, c, >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0mcl->m_len + M_TRAILINGSP= ACE(mcl)); >> =A0 =A0 =A0 =A0if (retval =3D=3D PKT_ALIAS_RESPOND) { >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 m->m_flags |=3D M_SKIP_FIREWALL; >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 mcl->m_flags |=3D M_SKIP_FIREWALL; >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0retval =3D PKT_ALIAS_OK; >> =A0 =A0 =A0 =A0} >> =A0 =A0 =A0 =A0if (retval !=3D PKT_ALIAS_OK && >> >> This was introduced in r188294 by piso@ (added to the CC: list). >> > piso@, could you please _fix_ that code ? > Can someone fix this obvious use-after-free, please ? the mbuf passed to m_megapullup() cannot be re-used as it might ends up being freed. This conditional is the sole conditional still using `m' after the call to m_megapullup(). diff --git a/sys/netinet/ipfw/ip_fw_nat.c b/sys/netinet/ipfw/ip_fw_nat.c index 1679a97..dbeb254 100644 --- a/sys/netinet/ipfw/ip_fw_nat.c +++ b/sys/netinet/ipfw/ip_fw_nat.c @@ -315,7 +315,7 @@ ipfw_nat(struct ip_fw_args *args, struct cfg_nat *t, struct mbuf *m) } if (retval =3D=3D PKT_ALIAS_RESPOND) - m->m_flags |=3D M_SKIP_FIREWALL; + mcl->m_flags |=3D M_SKIP_FIREWALL; mcl->m_pkthdr.len =3D mcl->m_len =3D ntohs(ip->ip_len); /* Thanks, - Arnaud > Thanks, > =A0- Arnaud > > >> =A0- Arnaud >> >> >>> /* >>> =A0* m_megapullup() - this function is a big hack. >>> =A0* Thankfully, it's only used in ng_nat and ipfw+nat. >>> =A0*... >>> >>> which look like a re-invention of m_copydata()... >>> >>> =A0- Arnaud >>> >>>> Thanx. >>>> >>>> >>>> >>>> =3D=3D=3D=3D=3D >>>> epia.home.lan dumped core - see /crash/vmcore.15 >>>> >>>> Thu May =A05 18:29:58 MSD 2011 >>>> >>>> FreeBSD epia.home.lan 8.2-STABLE FreeBSD 8.2-STABLE #1: Tue May =A03 2= 2:11:56 >>>> MSD 2011 =A0 =A0 root@epia.home.lan:/usr/obj/usr/src/sys/ION4debug =A0= amd64 >>>> >>>> panic: page fault >>>> >>>> GNU gdb 6.1.1 [FreeBSD] >>>> Copyright 2004 Free Software Foundation, Inc. >>>> GDB is free software, covered by the GNU General Public License, and y= ou 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. =A0Type "show warranty" for d= etails. >>>> 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 =3D 0; apic id =3D 00 >>>> fault virtual address =A0 =3D 0xffffff800ff02ac8 >>>> fault code =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D supervisor write data, page = not present >>>> instruction pointer =A0 =A0 =3D 0x20:0xffffffff8037d7bb >>>> stack pointer =A0 =A0 =A0 =A0 =A0 =3D 0x28:0xffffff80000fde20 >>>> frame pointer =A0 =A0 =A0 =A0 =A0 =3D 0x28:0xffffff80000fde60 >>>> code segment =A0 =A0 =A0 =A0 =A0 =A0=3D base 0x0, limit 0xfffff, type = 0x1b >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D DPL 0, pres 1, long= 1, def32 0, gran 1 >>>> processor eflags =A0 =A0 =A0 =A0=3D interrupt enabled, resume, IOPL = =3D 0 >>>> current process =A0 =A0 =A0 =A0 =3D 0 (nfe0 taskq) >>>> trap number =A0 =A0 =A0 =A0 =A0 =A0 =3D 12 >>>> panic: page fault >>>> cpuid =3D 0 >>>> KDB: stack backtrace: >>>> #0 0xffffffff802a97a3 at kdb_backtrace+0x5e >>>> #1 0xffffffff8027aa98 at panic+0x182 >>>> #2 0xffffffff804466d0 at trap_fatal+0x292 >>>> #3 0xffffffff80446a85 at trap_pfault+0x286 >>>> #4 0xffffffff80446f2f at trap+0x3cb >>>> #5 0xffffffff8042ff54 at calltrap+0x8 >>>> #6 0xffffffff8035ceb4 at ipfw_nat+0x20a >>>> #7 0xffffffff803547e3 at ipfw_chk+0xbaf >>>> #8 0xffffffff8035977c at ipfw_check_hook+0xf9 >>>> #9 0xffffffff8032a221 at pfil_run_hooks+0x9c >>>> #10 0xffffffff8035fe84 at ip_input+0x2d0 >>>> #11 0xffffffff8032947f at netisr_dispatch_src+0x71 >>>> #12 0xffffffff80c22cab at ng_iface_rcvdata+0xdc >>>> #13 0xffffffff80c18964 at ng_apply_item+0x20a >>>> #14 0xffffffff80c17afd at ng_snd_item+0x2a1 >>>> #15 0xffffffff80c18964 at ng_apply_item+0x20a >>>> #16 0xffffffff80c17afd at ng_snd_item+0x2a1 >>>> #17 0xffffffff80c25305 at ng_ppp_rcvdata+0x202 >>>> Uptime: 18h57m47s >>>> Physical memory: 2005 MB >>>> Dumping 1644 MB: 1629 1613 1597 1581 1565 1549 1533 1517 1501 1485 146= 9 1453 >>>> 1437 1421 1405 1389 1373 1357 1341 1325 1309 1293 1277 1261 1245 1229 = 1213 >>>> 1197 1181 1165 1149 1133 1117 1101 1085 1069 1053 1037 1021 1005 989 9= 73 957 >>>> 941 925 909 893 877 861 845 829 813 797 781 765 749 733 717 701 685 66= 9 653 >>>> 637 621 605 589 573 557 541 525 509 493 477 461 445 429 413 397 381 36= 5 349 >>>> 333 317 301 285 269 253 237 221 205 189 173 157 141 125 109 93 77 61 4= 5 29 >>>> 13 >>>> >>>> Reading symbols from /boot/kernel/zfs.ko...Reading symbols from >>>> /boot/kernel/zfs.ko.symbols...done. >>>> done. >>>> Loaded symbols for /boot/kernel/zfs.ko >>>> Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols fro= m >>>> /boot/kernel/opensolaris.ko.symbols...done. >>>> done. >>>> Loaded symbols for /boot/kernel/opensolaris.ko >>>> Reading symbols from /boot/kernel/krpc.ko...Reading symbols from >>>> /boot/kernel/krpc.ko.symbols...done. >>>> done. >>>> Loaded symbols for /boot/kernel/krpc.ko >>>> Reading symbols from /boot/kernel/if_nfe.ko...Reading symbols from >>>> /boot/kernel/if_nfe.ko.symbols...done. >>>> done. >>>> Loaded symbols for /boot/kernel/if_nfe.ko >>>> Reading symbols from /boot/kernel/aio.ko...Reading symbols from >>>> /boot/kernel/aio.ko.symbols...done. >>>> done. >>>> Loaded symbols for /boot/kernel/aio.ko >>>> Reading symbols from /boot/kernel/alias_ftp.ko...Reading symbols from >>>> /boot/kernel/alias_ftp.ko.symbols...done. >>>> done. >>>> Loaded symbols for /boot/kernel/alias_ftp.ko >>>> Reading symbols from /boot/kernel/if_stf.ko...Reading symbols from >>>> /boot/kernel/if_stf.ko.symbols...done. >>>> done. >>>> Loaded symbols for /boot/kernel/if_stf.ko >>>> Reading symbols from /boot/kernel/ng_socket.ko...Reading symbols from >>>> /boot/kernel/ng_socket.ko.symbols...done. >>>> done. >>>> Loaded symbols for /boot/kernel/ng_socket.ko >>>> Reading symbols from /boot/kernel/netgraph.ko...Reading symbols from >>>> /boot/kernel/netgraph.ko.symbols...done. >>>> done. >>>> Loaded symbols for /boot/kernel/netgraph.ko >>>> Reading symbols from /boot/kernel/ng_mppc.ko...Reading symbols from >>>> /boot/kernel/ng_mppc.ko.symbols...done. >>>> done. >>>> Loaded symbols for /boot/kernel/ng_mppc.ko >>>> Reading symbols from /boot/kernel/rc4.ko...Reading symbols from >>>> /boot/kernel/rc4.ko.symbols...done. >>>> done. >>>> Loaded symbols for /boot/kernel/rc4.ko >>>> Reading symbols from /boot/kernel/ng_iface.ko...Reading symbols from >>>> /boot/kernel/ng_iface.ko.symbols...done. >>>> done. >>>> Loaded symbols for /boot/kernel/ng_iface.ko >>>> Reading symbols from /boot/kernel/ng_ppp.ko...Reading symbols from >>>> /boot/kernel/ng_ppp.ko.symbols...done. >>>> done. >>>> Loaded symbols for /boot/kernel/ng_ppp.ko >>>> Reading symbols from /boot/kernel/ng_tee.ko...Reading symbols from >>>> /boot/kernel/ng_tee.ko.symbols...done. >>>> done. >>>> Loaded symbols for /boot/kernel/ng_tee.ko >>>> Reading symbols from /boot/kernel/ng_ether.ko...Reading symbols from >>>> /boot/kernel/ng_ether.ko.symbols...done. >>>> done. >>>> Loaded symbols for /boot/kernel/ng_ether.ko >>>> Reading symbols from /boot/kernel/ng_pppoe.ko...Reading symbols from >>>> /boot/kernel/ng_pppoe.ko.symbols...done. >>>> done. >>>> Loaded symbols for /boot/kernel/ng_pppoe.ko >>>> Reading symbols from /boot/kernel/accf_http.ko...Reading symbols from >>>> /boot/kernel/accf_http.ko.symbols...done. >>>> done. >>>> Loaded symbols for /boot/kernel/accf_http.ko >>>> Reading symbols from /boot/kernel/accf_data.ko...Reading symbols from >>>> /boot/kernel/accf_data.ko.symbols...done. >>>> done. >>>> Loaded symbols for /boot/kernel/accf_data.ko >>>> Reading symbols from /boot/kernel/ng_tcpmss.ko...Reading symbols from >>>> /boot/kernel/ng_tcpmss.ko.symbols...done. >>>> done. >>>> Loaded symbols for /boot/kernel/ng_tcpmss.ko >>>> #0 =A0doadump () at pcpu.h:224 >>>> 224 =A0 =A0 pcpu.h: No such file or directory. >>>> =A0 =A0 =A0 =A0in pcpu.h >>>> (kgdb) #0 =A0doadump () at pcpu.h:224 >>>> #1 =A00xffffffff8027a615 in boot (howto=3D260) >>>> =A0 =A0at /usr/src/sys/kern/kern_shutdown.c:419 >>>> #2 =A00xffffffff8027aa82 in panic (fmt=3DVariable "fmt" is not availab= le.) >>>> =A0 =A0at /usr/src/sys/kern/kern_shutdown.c:592 >>>> #3 =A00xffffffff804466d0 in trap_fatal (frame=3D0xc, eva=3DVariable "e= va" is not >>>> available.) >>>> =A0 =A0at /usr/src/sys/amd64/amd64/trap.c:811 >>>> #4 =A00xffffffff80446a85 in trap_pfault (frame=3D0xffffff80000fe720, u= sermode=3D0) >>>> =A0 =A0at /usr/src/sys/amd64/amd64/trap.c:727 >>>> #5 =A00xffffffff80446f2f in trap (frame=3D0xffffff80000fe720) >>>> =A0 =A0at /usr/src/sys/amd64/amd64/trap.c:477 >>>> #6 =A00xffffffff8042ff54 in calltrap () >>>> =A0 =A0at /usr/src/sys/amd64/amd64/exception.S:228 >>>> #7 =A00xffffffff80c2c8ce in pppoe_findsession (privp=3DVariable "privp= " is not >>>> available.) >>>> =A0 =A0at /usr/src/sys/modules/netgraph/pppoe/../../../netgraph/ng_ppp= oe.c:566 >>>> #8 =A00xffffffff80c2cfe7 in ng_pppoe_rcvdata_ether (hook=3DVariable "h= ook" is >>>> not available.) >>>> =A0 =A0at /usr/src/sys/modules/netgraph/pppoe/../../../netgraph/ng_ppp= oe.c:1613 >>>> #9 =A00xffffffff80c18964 in ng_apply_item (node=3D0xffffff002105ec00, >>>> =A0 =A0item=3D0xffffff0054a36500, rw=3D0) >>>> =A0 =A0at >>>> /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:232= 7 >>>> #10 0xffffffff80c17afd in ng_snd_item (item=3D0xffffff0054a36500, flag= s=3D0) >>>> =A0 =A0at >>>> /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:224= 4 >>>> #11 0xffffffff80320b5a in ether_demux (ifp=3D0xffffff0006862800, >>>> =A0 =A0m=3D0xffffff0039907700) at /usr/src/sys/net/if_ethersubr.c:911 >>>> #12 0xffffffff80320f41 in ether_input (ifp=3D0xffffff0006862800, >>>> =A0 =A0m=3D0xffffff0039907700) at /usr/src/sys/net/if_ethersubr.c:753 >>>> #13 0xffffffff80320aa2 in ether_demux (ifp=3D0xffffff0001676800, >>>> =A0 =A0m=3D0xffffff0039907700) at /usr/src/sys/net/if_ethersubr.c:803 >>>> #14 0xffffffff80320f41 in ether_input (ifp=3D0xffffff0001676800, >>>> =A0 =A0m=3D0xffffff0039907700) at /usr/src/sys/net/if_ethersubr.c:753 >>>> #15 0xffffffff809eb76e in nfe_jrxeof (sc=3D0xffffff80003ae000, count= =3D185, >>>> =A0 =A0rx_npktsp=3D0x0) at /usr/src/sys/modules/nfe/../../dev/nfe/if_n= fe.c:2303 >>>> #16 0xffffffff809effea in nfe_int_task (arg=3DVariable "arg" is not >>>> available.) >>>> =A0 =A0at /usr/src/sys/modules/nfe/../../dev/nfe/if_nfe.c:1899 >>>> #17 0xffffffff802b3f7e in taskqueue_run_locked (queue=3D0xffffff000172= 2700) >>>> =A0 =A0at /usr/src/sys/kern/subr_taskqueue.c:248 >>>> #18 0xffffffff802b410c in taskqueue_thread_loop (arg=3DVariable "arg" = is not >>>> available.) >>>> =A0 =A0at /usr/src/sys/kern/subr_taskqueue.c:385 >>>> #19 0xffffffff80252d5d in fork_exit ( >>>> =A0 =A0callout=3D0xffffffff802b40c4 , >>>> =A0 =A0arg=3D0xffffff80003ae1b8, frame=3D0xffffff80000fec50) >>>> =A0 =A0at /usr/src/sys/kern/kern_fork.c:865 >>>> #20 0xffffffff8043049e in fork_trampoline () >>>> =A0 =A0at /usr/src/sys/amd64/amd64/exception.S:603 >>>> #21 0x0000000000000000 in ?? () >>>> #22 0x0000000000000000 in ?? () >>>> #23 0x0000000000000000 in ?? () >>>> #24 0x0000000000000000 in ?? () >>>> #25 0x0000000000000000 in ?? () >>>> #26 0x0000000000000000 in ?? () >>>> #27 0x0000000000000000 in ?? () >>>> #28 0x0000000000000000 in ?? () >>>> #29 0x0000000000000000 in ?? () >>>> #30 0x0000000000000000 in ?? () >>>> #31 0x0000000000000000 in ?? () >>>> #32 0x0000000000000000 in ?? () >>>> #33 0x0000000000000000 in ?? () >>>> #34 0x0000000000000000 in ?? () >>>> #35 0x0000000000000000 in ?? () >>>> #36 0x0000000000000000 in ?? () >>>> #37 0x0000000000000000 in ?? () >>>> #38 0x0000000000000000 in ?? () >>>> #39 0x0000000000000000 in ?? () >>>> #40 0x0000000000000000 in ?? () >>>> #41 0x0000000000000000 in ?? () >>>> #42 0x0000000000000000 in ?? () >>>> #43 0x0000000000000000 in ?? () >>>> #44 0x0000000000000000 in ?? () >>>> #45 0xffffffff80665140 in affinity () >>>> #46 0x0000000000000000 in ?? () >>>> #47 0x0000000000000000 in ?? () >>>> #48 0xffffff0001741460 in ?? () >>>> #49 0xffffff80000fe380 in ?? () >>>> #50 0xffffff80000fe328 in ?? () >>>> #51 0xffffff00015b8000 in ?? () >>>> #52 0xffffffff8029d819 in sched_switch (td=3D0xffffffff802b40c4, >>>> =A0 =A0newtd=3D0xffffff80003ae1b8, flags=3DVariable "flags" is not ava= ilable. >>>> ) at /usr/src/sys/kern/sched_ule.c:1859 >>>> Previous frame inner to this frame (corrupt stack?) >>>> (kgdb) >>>> >>>> >>>> DMESG >>>> --- >>>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 19= 94 >>>> =A0 =A0 =A0 =A0The Regents of the University of California. All rights= reserved. >>>> FreeBSD is a registered trademark of The FreeBSD Foundation. >>>> FreeBSD 8.2-STABLE #1: Tue May =A03 22:11:56 MSD 2011 >>>> =A0 =A0root@epia.home.lan:/usr/obj/usr/src/sys/ION4debug amd64 >>>> Timecounter "i8254" frequency 1193182 Hz quality 0 >>>> CPU: Intel(R) Atom(TM) CPU =A0330 =A0 @ 1.60GHz (1600.01-MHz K8-class = CPU) >>>> =A0Origin =3D "GenuineIntel" =A0Id =3D 0x106c2 =A0Family =3D 6 =A0Mode= l =3D 1c =A0Stepping =3D 2 >>>> =A0Features=3D0xbfe9fbff >>>> =A0Features2=3D0x40e31d >>>> =A0AMD Features=3D0x20000800 >>>> =A0AMD Features2=3D0x1 >>>> =A0TSC: P-state invariant >>>> real memory =A0=3D 2147483648 (2048 MB) >>>> avail memory =3D 2025250816 (1931 MB) >>>> ACPI APIC Table: <072310 APIC1353> >>>> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs >>>> FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 HTT threads >>>> =A0cpu0 (BSP): APIC ID: =A00 >>>> =A0cpu1 (AP/HT): APIC ID: =A01 >>>> =A0cpu2 (AP): APIC ID: =A02 >>>> =A0cpu3 (AP/HT): APIC ID: =A03 >>>> ioapic0: Changing APIC ID to 4 >>>> ioapic0 irqs 0-23 on motherboard >>>> kbd1 at kbdmux0 >>>> cryptosoft0: on motherboard >>>> acpi0: <072310 RSDT1353> on motherboard >>>> acpi0: [ITHREAD] >>>> acpi0: Power Button (fixed) >>>> acpi0: reservation of fefe1000, 1000 (3) failed >>>> acpi0: reservation of fee01000, ff000 (3) failed >>>> acpi0: reservation of fec00000, 1000 (3) failed >>>> acpi0: reservation of fee00000, 1000 (3) failed >>>> acpi0: reservation of 0, a0000 (3) failed >>>> acpi0: reservation of 100000, 7ff00000 (3) failed >>>> Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 >>>> acpi_timer0: <32-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 >>>> cpu0: on acpi0 >>>> cpu1: on acpi0 >>>> cpu2: on acpi0 >>>> cpu3: on acpi0 >>>> pcib0: port 0xcf8-0xcff on acpi0 >>>> pci0: on pcib0 >>>> pci0: at device 0.1 (no driver attached) >>>> isab0: port 0x4f00-0x4fff at device 3.0 on pci0 >>>> isa0: on isab0 >>>> pci0: at device 3.1 (no driver attached) >>>> pci0: at device 3.2 (no driver attached) >>>> pci0: at device 3.3 (no driver attached) >>>> pci0: at device 3.5 (no driver attached) >>>> ohci0: mem 0xfae7f000-0xfae7ffff = irq 16 >>>> at device 4.0 on pci0 >>>> ohci0: [ITHREAD] >>>> usbus0: on ohci0 >>>> ehci0: mem 0xfae7ec00-0xfae7e= cff >>>> irq 18 at device 4.1 on pci0 >>>> ehci0: [ITHREAD] >>>> usbus1: EHCI version 1.0 >>>> usbus1: on ehci0 >>>> pcib1: at device 9.0 on pci0 >>>> pci3: on pcib1 >>>> nfe0: port 0xd080-0xd087 mem >>>> 0xfae7d000-0xfae7dfff,0xfae7e800-0xfae7e8ff,0xfae7e400-0xfae7e40f irq = 22 at >>>> device 10.0 on pci0 >>>> miibus0: on nfe0 >>>> rgephy0: PHY 3 on miibus0 >>>> rgephy0: =A010baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100base= TX-FDX, >>>> 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, >>>> 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, a= uto, >>>> auto-flow >>>> nfe0: Ethernet address: 00:25:22:21:86:89 >>>> nfe0: [FILTER] >>>> ahci0: port >>>> 0xd000-0xd007,0xcc00-0xcc03,0xc880-0xc887,0xc800-0xc803,0xc480-0xc48f = mem >>>> 0xfae76000-0xfae77fff irq 23 at device 11.0 on pci0 >>>> ahci0: [ITHREAD] >>>> ahci0: AHCI v1.20 with 6 3Gbps ports, Port Multiplier supported >>>> ahcich0: at channel 0 on ahci0 >>>> ahcich0: [ITHREAD] >>>> ahcich1: at channel 1 on ahci0 >>>> ahcich1: [ITHREAD] >>>> ahcich2: at channel 2 on ahci0 >>>> ahcich2: [ITHREAD] >>>> ahcich3: at channel 3 on ahci0 >>>> ahcich3: [ITHREAD] >>>> ahcich4: at channel 4 on ahci0 >>>> ahcich4: [ITHREAD] >>>> ahcich5: at channel 5 on ahci0 >>>> ahcich5: [ITHREAD] >>>> pcib2: irq 20 at device 12.0 on pci0 >>>> pci2: on pcib2 >>>> pcib3: at device 16.0 on pci0 >>>> pci1: on pcib3 >>>> vgapci0: port 0xec00-0xec7f mem >>>> 0xfb000000-0xfbffffff,0xe0000000-0xefffffff,0xf6000000-0xf7ffffff irq = 21 at >>>> device 0.0 on pci1 >>>> acpi_button0: on acpi0 >>>> acpi_hpet0: iomem 0xfed00000-0xfed00fff i= rq 2,8 >>>> on acpi0 >>>> Timecounter "HPET" frequency 25000000 Hz quality 900 >>>> atrtc0: port 0x70-0x71 on acpi0 >>>> uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi= 0 >>>> uart0: [FILTER] >>>> sc0: at flags 0x100 on isa0 >>>> sc0: VGA <16 virtual consoles, flags=3D0x300> >>>> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on i= sa0 >>>> atkbdc0: at port 0x60,0x64 on isa0 >>>> atkbd0: irq 1 on atkbdc0 >>>> kbd0 at atkbd0 >>>> atkbd0: [GIANT-LOCKED] >>>> atkbd0: [ITHREAD] >>>> p4tcc0: on cpu0 >>>> p4tcc1: on cpu1 >>>> p4tcc2: on cpu2 >>>> p4tcc3: on cpu3 >>>> ZFS filesystem version 5 >>>> ZFS storage pool version 28 >>>> Timecounters tick every 1.000 msec >>>> ipfw2 (+ipv6) initialized, divert enabled, nat enabled, rule-based >>>> forwarding enabled, default to deny, logging disabled >>>> load_dn_sched dn_sched FIFO loaded >>>> load_dn_sched dn_sched PRIO loaded >>>> load_dn_sched dn_sched QFQ loaded >>>> load_dn_sched dn_sched RR loaded >>>> load_dn_sched dn_sched WF2Q+ loaded >>>> usbus0: 12Mbps Full Speed USB v1.0 >>>> usbus1: 480Mbps High Speed USB v2.0 >>>> ugen0.1: at usbus0 >>>> uhub0: on usb= us0 >>>> ugen1.1: at usbus1 >>>> uhub1: on usb= us1 >>>> 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: 1430799MB (2930277168 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: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C) >>>> ada2 at ahcich2 bus 0 scbus2 target 0 lun 0 >>>> ada2: ATA-8 SATA 2.x device >>>> ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) >>>> ada2: Command Queueing enabled >>>> ada2: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) >>>> ada3 at ahcich3 bus 0 scbus3 target 0 lun 0 >>>> ada3: ATA-7 SATA 2.x device >>>> ada3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) >>>> ada3: Command Queueing enabled >>>> ada3: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C) >>>> SMP: AP CPU #3 Launched! >>>> SMP: AP CPU #1 Launched! >>>> SMP: AP CPU #2 Launched! >>>> uhub0: 10 ports with 10 removable, self powered >>>> Root mount waiting for: usbus1 >>>> Root mount waiting for: usbus1 >>>> Root mount waiting for: usbus1 >>>> Root mount waiting for: usbus1 >>>> uhub1: 10 ports with 10 removable, self powered >>>> Trying to mount root from zfs:rz >>>> >>>> >>>> KERNCONF >>>> -------- >>>>> >>>>> grep -v -e "^#" /root/conf/ION4debug >>>> >>>> cpu =A0 =A0 =A0 =A0 =A0 =A0 HAMMER >>>> ident =A0 =A0 =A0 =A0 =A0 ION4debug >>>> >>>> makeoptions =A0 =A0 DEBUG=3D-g =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# Build = kernel with gdb(1) debug >>>> symbols >>>> >>>> options =A0 =A0 =A0 =A0 SCHED_ULE =A0 =A0 =A0 =A0 =A0 =A0 =A0 # ULE sc= heduler >>>> options =A0 =A0 =A0 =A0 PREEMPTION =A0 =A0 =A0 =A0 =A0 =A0 =A0# Enable= kernel thread preemption >>>> options =A0 =A0 =A0 =A0 INET =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# = InterNETworking >>>> options =A0 =A0 =A0 =A0 INET6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # IP= v6 communications protocols >>>> options =A0 =A0 =A0 =A0 FFS =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # = Berkeley Fast Filesystem >>>> options =A0 =A0 =A0 =A0 SOFTUPDATES =A0 =A0 =A0 =A0 =A0 =A0 # Enable F= FS soft updates support >>>> options =A0 =A0 =A0 =A0 UFS_ACL =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # Supp= ort for access control lists >>>> options =A0 =A0 =A0 =A0 UFS_DIRHASH =A0 =A0 =A0 =A0 =A0 =A0 # Improve = performance on big >>>> directories >>>> options =A0 =A0 =A0 =A0 UFS_GJOURNAL =A0 =A0 =A0 =A0 =A0 =A0# Enable g= journal-based UFS >>>> journaling >>>> options =A0 =A0 =A0 =A0 PROCFS =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# Pr= ocess filesystem (requires >>>> PSEUDOFS) >>>> options =A0 =A0 =A0 =A0 PSEUDOFS =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# Pseu= do-filesystem framework >>>> options =A0 =A0 =A0 =A0 GEOM_PART_GPT =A0 =A0 =A0 =A0 =A0 # GUID Parti= tion Tables. >>>> options =A0 =A0 =A0 =A0 GEOM_LABEL =A0 =A0 =A0 =A0 =A0 =A0 =A0# Provid= es labelization >>>> options =A0 =A0 =A0 =A0 COMPAT_43TTY =A0 =A0 =A0 =A0 =A0 =A0# BSD 4.3 = TTY compat (sgtty) >>>> options =A0 =A0 =A0 =A0 SCSI_DELAY=3D5000 =A0 =A0 =A0 =A0 # Delay (in = ms) before probing SCSI >>>> options =A0 =A0 =A0 =A0 KTRACE =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# kt= race(1) support >>>> options =A0 =A0 =A0 =A0 STACK =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # st= ack(9) support >>>> options =A0 =A0 =A0 =A0 SYSVSHM =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # SYSV= -style shared memory >>>> options =A0 =A0 =A0 =A0 SYSVMSG =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # SYSV= -style message queues >>>> options =A0 =A0 =A0 =A0 SYSVSEM =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # SYSV= -style semaphores >>>> options =A0 =A0 =A0 =A0 P1003_1B_SEMAPHORES =A0 =A0 # POSIX-style sema= phores >>>> options =A0 =A0 =A0 =A0 _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B r= eal-time >>>> extensions >>>> options =A0 =A0 =A0 =A0 PRINTF_BUFR_SIZE=3D128 =A0 =A0# Prevent printf= output being >>>> interspersed. >>>> options =A0 =A0 =A0 =A0 KBD_INSTALL_CDEV =A0 =A0 =A0 =A0# install a CD= EV entry in /dev >>>> options =A0 =A0 =A0 =A0 HWPMC_HOOKS =A0 =A0 =A0 =A0 =A0 =A0 # Necessar= y kernel hooks for >>>> hwpmc(4) >>>> options =A0 =A0 =A0 =A0 AUDIT =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # Se= curity event auditing >>>> options =A0 =A0 =A0 =A0 MAC =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # = TrustedBSD MAC Framework >>>> options =A0 =A0 =A0 =A0 FLOWTABLE =A0 =A0 =A0 =A0 =A0 =A0 =A0 # per-cp= u routing cache >>>> options =A0 =A0 =A0 =A0 INCLUDE_CONFIG_FILE =A0 =A0 # Include this fil= e in kernel >>>> >>>> options =A0 =A0 =A0 =A0 KDB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # = Kernel debugger related code >>>> options =A0 =A0 =A0 =A0 KDB_TRACE =A0 =A0 =A0 =A0 =A0 =A0 =A0 # Print = a stack trace for a panic >>>> >>>> options =A0 =A0 =A0 =A0 SMP =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # = Symmetric MultiProcessor Kernel >>>> >>>> device =A0 =A0 =A0 =A0 =A0cpufreq >>>> >>>> options =A0 =A0 =A0 =A0 DEVICE_POLLING >>>> options =A0 =A0 =A0 =A0 IPFIREWALL >>>> options =A0 =A0 =A0 =A0 IPDIVERT >>>> options =A0 =A0 =A0 =A0 IPFIREWALL_FORWARD >>>> options =A0 =A0 =A0 =A0 IPFIREWALL_NAT >>>> options =A0 =A0 =A0 =A0 IPSTEALTH >>>> options =A0 =A0 =A0 =A0 DUMMYNET >>>> >>>> options =A0 =A0 =A0 =A0 LIBALIAS >>>> >>>> device =A0 =A0 =A0 =A0 =A0crypto >>>> >>>> device =A0 =A0 =A0 =A0 =A0acpi >>>> device =A0 =A0 =A0 =A0 =A0pci >>>> >>>> device =A0 =A0 =A0 =A0 =A0ahci >>>> >>>> device =A0 =A0 =A0 =A0 =A0scbus =A0 =A0 =A0 =A0 =A0 # SCSI bus (requir= ed for SCSI) >>>> device =A0 =A0 =A0 =A0 =A0da =A0 =A0 =A0 =A0 =A0 =A0 =A0# Direct Acces= s (disks) >>>> device =A0 =A0 =A0 =A0 =A0pass =A0 =A0 =A0 =A0 =A0 =A0# Passthrough de= vice (direct SCSI access) >>>> >>>> device =A0 =A0 =A0 =A0 =A0atkbdc =A0 =A0 =A0 =A0 =A0# AT keyboard cont= roller >>>> device =A0 =A0 =A0 =A0 =A0atkbd =A0 =A0 =A0 =A0 =A0 # AT keyboard >>>> device =A0 =A0 =A0 =A0 =A0psm =A0 =A0 =A0 =A0 =A0 =A0 # PS/2 mouse >>>> >>>> device =A0 =A0 =A0 =A0 =A0kbdmux =A0 =A0 =A0 =A0 =A0# keyboard multipl= exer >>>> >>>> device =A0 =A0 =A0 =A0 =A0vga =A0 =A0 =A0 =A0 =A0 =A0 # VGA video card= driver >>>> >>>> device =A0 =A0 =A0 =A0 =A0sc >>>> >>>> device =A0 =A0 =A0 =A0 =A0uart =A0 =A0 =A0 =A0 =A0 =A0# Generic UART d= river >>>> >>>> device =A0 =A0 =A0 =A0 =A0miibus =A0 =A0 =A0 =A0 =A0# MII bus support >>>> >>>> device =A0 =A0 =A0 =A0 =A0loop =A0 =A0 =A0 =A0 =A0 =A0# Network loopba= ck >>>> device =A0 =A0 =A0 =A0 =A0random =A0 =A0 =A0 =A0 =A0# Entropy device >>>> device =A0 =A0 =A0 =A0 =A0ether =A0 =A0 =A0 =A0 =A0 # Ethernet support >>>> device =A0 =A0 =A0 =A0 =A0vlan =A0 =A0 =A0 =A0 =A0 =A0# 802.1Q VLAN su= pport >>>> device =A0 =A0 =A0 =A0 =A0tun =A0 =A0 =A0 =A0 =A0 =A0 # Packet tunnel. >>>> device =A0 =A0 =A0 =A0 =A0pty =A0 =A0 =A0 =A0 =A0 =A0 # BSD-style comp= atibility pseudo ttys >>>> device =A0 =A0 =A0 =A0 =A0md =A0 =A0 =A0 =A0 =A0 =A0 =A0# Memory "disk= s" >>>> device =A0 =A0 =A0 =A0 =A0gif =A0 =A0 =A0 =A0 =A0 =A0 # IPv6 and IPv4 = tunneling >>>> device =A0 =A0 =A0 =A0 =A0faith =A0 =A0 =A0 =A0 =A0 # IPv6-to-IPv4 rel= aying (translation) >>>> device =A0 =A0 =A0 =A0 =A0firmware =A0 =A0 =A0 =A0# firmware assist mo= dule >>>> >>>> device =A0 =A0 =A0 =A0 =A0bpf =A0 =A0 =A0 =A0 =A0 =A0 # Berkeley packe= t filter >>>> >>>> device =A0 =A0 =A0 =A0 =A0uhci =A0 =A0 =A0 =A0 =A0 =A0# UHCI PCI->USB = interface >>>> device =A0 =A0 =A0 =A0 =A0ohci =A0 =A0 =A0 =A0 =A0 =A0# OHCI PCI->USB = interface >>>> device =A0 =A0 =A0 =A0 =A0ehci =A0 =A0 =A0 =A0 =A0 =A0# EHCI PCI->USB = interface (USB 2.0) >>>> device =A0 =A0 =A0 =A0 =A0usb =A0 =A0 =A0 =A0 =A0 =A0 # USB Bus (requi= red) >>>> device =A0 =A0 =A0 =A0 =A0uhid =A0 =A0 =A0 =A0 =A0 =A0# "Human Interfa= ce Devices" >>>> device =A0 =A0 =A0 =A0 =A0ukbd =A0 =A0 =A0 =A0 =A0 =A0# Keyboard >>>> device =A0 =A0 =A0 =A0 =A0umass =A0 =A0 =A0 =A0 =A0 # Disks/Mass stora= ge - Requires scbus and da >>>> device =A0 =A0 =A0 =A0 =A0ums =A0 =A0 =A0 =A0 =A0 =A0 # Mouse >>>> _______________________________________________ >>>> 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" >>>> >>> >> > From owner-freebsd-current@FreeBSD.ORG Tue Jul 5 06:20:58 2011 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 A6F8A106564A; Tue, 5 Jul 2011 06:20:58 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 56E1D8FC0A; Tue, 5 Jul 2011 06:20:58 +0000 (UTC) Received: by gxk28 with SMTP id 28so2736335gxk.13 for ; Mon, 04 Jul 2011 23:20:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=bVHeXpNZY+JTFTfTX+edhydcRBXy1O3qvGj5oI9ATpk=; b=tS+nkrnxe1HSZDj+YBDMSKRwCxQGYOp7z52ezz7FoR/zDuXrqF9OeYrxVTK1agYsUJ GE4IFT9785c4uDqHocirNtt6A8hqFY84MjkqB3hkrRl75VOFIgF3W1GgxMeBdBtys1uu 3hwqwEbN7HF0INg3DrzAP3bgS1leqH1M1B8io= MIME-Version: 1.0 Received: by 10.150.160.21 with SMTP id i21mr5951941ybe.57.1309846857625; Mon, 04 Jul 2011 23:20:57 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.151.45.11 with HTTP; Mon, 4 Jul 2011 23:20:57 -0700 (PDT) In-Reply-To: <4E117BB8.1010105@FreeBSD.org> References: <4E100086.7080105@FreeBSD.org> <4E117BB8.1010105@FreeBSD.org> Date: Tue, 5 Jul 2011 14:20:57 +0800 X-Google-Sender-Auth: deXCNuhPz38dCSkrqAu2SABOXFc Message-ID: From: Adrian Chadd To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: cardbus panic: end address is not aligned 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, 05 Jul 2011 06:20:58 -0000 On 4 July 2011 16:37, Doug Barton wrote: > On 07/03/2011 03:05, Adrian Chadd wrote: >> >> The obvious question - can you bisect kernel versions to find out when it >> broke? > > Sorry, I thought the answer to that was obvious from my message. I have no > idea how far back the breakage goes since I don't use the cards often. Right. Well, are you able to boot some vintage kernels going back 12 months and see whether it's still broken? Adrian From owner-freebsd-current@FreeBSD.ORG Tue Jul 5 06:35:28 2011 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 C8ED1106566C; Tue, 5 Jul 2011 06:35:28 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 30F058FC12; Tue, 5 Jul 2011 06:35:27 +0000 (UTC) Received: by bwa20 with SMTP id 20so6505060bwa.13 for ; Mon, 04 Jul 2011 23:35:26 -0700 (PDT) Received: by 10.204.138.142 with SMTP id a14mr6126575bku.195.1309847726401; Mon, 04 Jul 2011 23:35:26 -0700 (PDT) Received: from jessie.localnet (p5B2EC622.dip0.t-ipconnect.de [91.46.198.34]) by mx.google.com with ESMTPS id c13sm6235135bkc.2.2011.07.04.23.35.25 (version=SSLv3 cipher=OTHER); Mon, 04 Jul 2011 23:35:25 -0700 (PDT) Sender: Bernhard Schmidt From: Bernhard Schmidt To: Doug Barton Date: Tue, 5 Jul 2011 08:35:21 +0200 User-Agent: KMail/1.13.5 (Linux/2.6.32-32-generic; KDE/4.4.5; i686; ; ) References: <4E100086.7080105@FreeBSD.org> <4E117BB8.1010105@FreeBSD.org> In-Reply-To: <4E117BB8.1010105@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201107050835.22299.bschmidt@freebsd.org> Cc: Adrian Chadd , freebsd-current@freebsd.org Subject: Re: cardbus panic: end address is not aligned X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bschmidt@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: Tue, 05 Jul 2011 06:35:28 -0000 On Monday, July 04, 2011 10:37:12 Doug Barton wrote: > On 07/03/2011 03:05, Adrian Chadd wrote: > > The obvious question - can you bisect kernel versions to find out when it broke? > > Sorry, I thought the answer to that was obvious from my message. I have > no idea how far back the breakage goes since I don't use the cards often. Try at least r222753, which worked for me [tm]. -- Bernhard From owner-freebsd-current@FreeBSD.ORG Tue Jul 5 08:39:38 2011 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 6B2F9106566B; Tue, 5 Jul 2011 08:39:38 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirj.bris.ac.uk (dirj.bris.ac.uk [137.222.10.78]) by mx1.freebsd.org (Postfix) with ESMTP id 172118FC13; Tue, 5 Jul 2011 08:39:37 +0000 (UTC) Received: from ncsc.bris.ac.uk ([137.222.10.41]) by dirj.bris.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1Qe1AO-0001kv-NZ; Tue, 05 Jul 2011 09:39:36 +0100 Received: from mech-cluster241.men.bris.ac.uk ([137.222.187.241]) by ncsc.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Qe1AO-000630-4C; Tue, 05 Jul 2011 09:39:36 +0100 Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.4/8.14.4) with ESMTP id p658dZFQ009247; Tue, 5 Jul 2011 09:39:35 +0100 (BST) (envelope-from mexas@bristol.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.4/8.14.4/Submit) id p658dZuo009246; Tue, 5 Jul 2011 09:39:35 +0100 (BST) (envelope-from mexas@bristol.ac.uk) X-Authentication-Warning: mech-cluster241.men.bris.ac.uk: mexas set sender to mexas@bristol.ac.uk using -f Date: Tue, 5 Jul 2011 09:39:35 +0100 From: Anton Shterenlikht To: Matthew Jacob Message-ID: <20110705083935.GA9094@mech-cluster241.men.bris.ac.uk> Mail-Followup-To: Matthew Jacob , freebsd-current@freebsd.org, freebsd-ia64@freebsd.org References: <20110630102544.GA97559@mech-cluster241.men.bris.ac.uk> <4E0C67EC.8020609@feral.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E0C67EC.8020609@feral.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org, freebsd-ia64@freebsd.org Subject: Re: isp(4) timeout 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, 05 Jul 2011 08:39:38 -0000 On Thu, Jun 30, 2011 at 05:11:24AM -0700, Matthew Jacob wrote: > On 6/30/2011 3:25 AM, Anton Shterenlikht wrote: > >I see in my logs: > > > >isp0: Polled Mailbox Command (0x54) Timeout (500000us) (started @ > >isp_plogx:2122) > >isp0: Mailbox Command 'EXECUTE IOCB A64' failed (TIMEOUT) > >isp0: Chan 0 PLOGI 0x010500 failed > >isp0: Polled Mailbox Command (0x64) Timeout (250000us) (started @ > >isp_getpdb:2307) > >isp0: Mailbox Command 'GET PORT DATABASE' failed (TIMEOUT) > > More details please. > > These errors indicate failures to execute commands that try and figure > out what's on a fabric and then log into devices on the fabric. Knowing > what hardware you have (QLogic card version), what FreeBSD release you > are running, would help. A verbose dmesg would be useful. I got it again. But this time the network seems fine. ZEEV> uname -a FreeBSD mech-as28.men.bris.ac.uk 9.0-CURRENT FreeBSD 9.0-CURRENT #2 r221340: Mon May 2 23:27:58 BST 2011 root@mech-as28.men.bris.ac.uk:/usr/obj/usr/src/sys/ZEEV ia64 ZEEV> isp0@pci0:192:1:0: class=0x0c0400 card=0x12d6103c chip=0x24221077 rev=0x02 hdr=0x00 vendor = 'QLogic Corporation' device = 'QLogic PCI to Fibre Channel Host Adapter for QLA2460 (ISP2422)' class = serial bus subclass = Fibre Channel >From the logs: +isp0: Polled Mailbox Command (0x54) Timeout (500000us) (started @ isp_plogx:2122) +isp0: Mailbox Command 'EXECUTE IOCB A64' failed (TIMEOUT) +isp0: Chan 0 PLOGI 0x010500 failed +isp0: Polled Mailbox Command (0x64) Timeout (250000us) (started @ isp_getpdb:2307) +isp0: Mailbox Command 'GET PORT DATABASE' failed (TIMEOUT) +isp0: Polled Mailbox Command (0x64) Timeout (250000us) (started @ isp_getpdb:2307) +isp0: Mailbox Command 'GET PORT DATABASE' failed (TIMEOUT) +isp0: Polled Mailbox Command (0x64) Timeout (250000us) (started @ isp_getpdb:2307) +isp0: Mailbox Command 'GET PORT DATABASE' failed (TIMEOUT) +isp0: Polled Mailbox Command (0x64) Timeout (250000us) (started @ isp_getpdb:2307) +isp0: Mailbox Command 'GET PORT DATABASE' failed (TIMEOUT) +isp0: Polled Mailbox Command (0x64) Timeout (250000us) (started @ isp_getpdb:2307) +isp0: Mailbox Command 'GET PORT DATABASE' failed (TIMEOUT) +isp0: Polled Mailbox Command (0x64) Timeout (250000us) (started @ isp_getpdb:2307) +isp0: Mailbox Command 'GET PORT DATABASE' failed (TIMEOUT) +isp0: Polled Mailbox Command (0x64) Timeout (250000us) (started @ isp_getpdb:2307) +isp0: Mailbox Command 'GET PORT DATABASE' failed (TIMEOUT) +isp0: Polled Mailbox Command (0x64) Timeout (250000us) (started @ isp_getpdb:2307) +isp0: Mailbox Command 'GET PORT DATABASE' failed (TIMEOUT) +isp0: Polled Mailbox Command (0x64) Timeout (250000us) (started @ isp_getpdb:2307) +isp0: Mailbox Command 'GET PORT DATABASE' failed (TIMEOUT) +isp0: Polled Mailbox Command (0x64) Timeout (250000us) (started @ isp_getpdb:2307) +isp0: Mailbox Command 'GET PORT DATABASE' failed (TIMEOUT) +isp0: Polled Mailbox Command (0x64) Timeout (250000us) (started @ isp_getpdb:2307) +isp0: Mailbox Command 'GET PORT DATABASE' failed (TIMEOUT) +isp0: Polled Mailbox Command (0x64) Timeout (250000us) (started @ isp_getpdb:2307) +isp0: Mailbox Command 'GET PORT DATABASE' failed (TIMEOUT) +isp0: mailbox cmd (0x4000) with no waiters +isp0: Polled Mailbox Command (0x54) Timeout (500000us) (started @ isp_plogx:2122) +isp0: Mailbox Command 'EXECUTE IOCB A64' failed (TIMEOUT) +isp0: Chan 0 PLOGI 0x010500 failed +isp0: Polled Mailbox Command (0x64) Timeout (250000us) (started @ isp_getpdb:2307) +isp0: Mailbox Command 'GET PORT DATABASE' failed (TIMEOUT) +isp0: Polled Mailbox Command (0x64) Timeout (250000us) (started @ isp_getpdb:2307) +isp0: Mailbox Command 'GET PORT DATABASE' failed (TIMEOUT) +isp0: Polled Mailbox Command (0x64) Timeout (250000us) (started @ isp_getpdb:2307) +isp0: Mailbox Command 'GET PORT DATABASE' failed (TIMEOUT) +isp0: Polled Mailbox Command (0x64) Timeout (250000us) (started @ isp_getpdb:2307) +isp0: Mailbox Command 'GET PORT DATABASE' failed (TIMEOUT) +isp0: Polled Mailbox Command (0x64) Timeout (250000us) (started @ isp_getpdb:2307) +isp0: Mailbox Command 'GET PORT DATABASE' failed (TIMEOUT) +isp0: Polled Mailbox Command (0x64) Timeout (250000us) (started @ isp_getpdb:2307) +isp0: Mailbox Command 'GET PORT DATABASE' failed (TIMEOUT) +isp0: Polled Mailbox Command (0x64) Timeout (250000us) (started @ isp_getpdb:2307) +isp0: Mailbox Command 'GET PORT DATABASE' failed (TIMEOUT) +isp0: Polled Mailbox Command (0x64) Timeout (250000us) (started @ isp_getpdb:2307) +isp0: Mailbox Command 'GET PORT DATABASE' failed (TIMEOUT) +isp0: Polled Mailbox Command (0x64) Timeout (250000us) (started @ isp_getpdb:2307) +isp0: Mailbox Command 'GET PORT DATABASE' failed (TIMEOUT) +isp0: Polled Mailbox Command (0x64) Timeout (250000us) (started @ isp_getpdb:2307) +isp0: Mailbox Command 'GET PORT DATABASE' failed (TIMEOUT) +isp0: Polled Mailbox Command (0x64) Timeout (250000us) (started @ isp_getpdb:2307) +isp0: Mailbox Command 'GET PORT DATABASE' failed (TIMEOUT) +isp0: Polled Mailbox Command (0x64) Timeout (250000us) (started @ isp_getpdb:2307) +isp0: Mailbox Command 'GET PORT DATABASE' failed (TIMEOUT) +isp0: mailbox cmd (0x4000) with no waiters dmesg: http://seis.bris.ac.uk/~mexas/freebsd/ia64/rx2620/ZEEV/dmesg.boot Many thanks Anton -- 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 Tue Jul 5 14:34:48 2011 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 9D5411065673 for ; Tue, 5 Jul 2011 14:34:48 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id 68BF78FC1C for ; Tue, 5 Jul 2011 14:34:48 +0000 (UTC) Received: from [192.168.135.103] (c-24-7-47-62.hsd1.ca.comcast.net [24.7.47.62]) (authenticated bits=0) by ns1.feral.com (8.14.4/8.14.4) with ESMTP id p65EYk92068950 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 5 Jul 2011 07:34:47 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4E132104.2060900@feral.com> Date: Tue, 05 Jul 2011 07:34:44 -0700 From: Matthew Jacob Organization: Feral Software User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20110630102544.GA97559@mech-cluster241.men.bris.ac.uk> <4E0C67EC.8020609@feral.com> <20110705083935.GA9094@mech-cluster241.men.bris.ac.uk> In-Reply-To: <20110705083935.GA9094@mech-cluster241.men.bris.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (ns1.feral.com [192.67.166.1]); Tue, 05 Jul 2011 07:34:47 -0700 (PDT) Subject: Re: isp(4) timeout 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, 05 Jul 2011 14:34:48 -0000 On 7/5/2011 1:39 AM, Anton Shterenlikht wrote: > ... > dmesg: > > http://seis.bris.ac.uk/~mexas/freebsd/ia64/rx2620/ZEEV/dmesg.boot > > Many thanks > Anton > >isp0: Board Type 2422, Chip Revision 0x2, resident F/W Revision 4.0.90 Add the line isp_2400_load="YES" to /boot/loader.conf. From owner-freebsd-current@FreeBSD.ORG Tue Jul 5 15:13:39 2011 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 358C8106564A; Tue, 5 Jul 2011 15:13:39 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id 04AC18FC18; Tue, 5 Jul 2011 15:13:38 +0000 (UTC) Received: from [172.23.7.81] (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id p65FD75K075418 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 5 Jul 2011 08:13:14 -0700 (PDT) (envelope-from marcel@xcllnt.net) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Marcel Moolenaar In-Reply-To: <20110705083935.GA9094@mech-cluster241.men.bris.ac.uk> Date: Tue, 5 Jul 2011 08:13:02 -0700 Content-Transfer-Encoding: 7bit Message-Id: <783405F6-2417-4E5B-B1F8-B8EC0113B73A@xcllnt.net> References: <20110630102544.GA97559@mech-cluster241.men.bris.ac.uk> <4E0C67EC.8020609@feral.com> <20110705083935.GA9094@mech-cluster241.men.bris.ac.uk> To: Anton Shterenlikht X-Mailer: Apple Mail (2.1084) Cc: freebsd-current@freebsd.org, Matthew Jacob , freebsd-ia64@freebsd.org Subject: Re: isp(4) timeout 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, 05 Jul 2011 15:13:39 -0000 On Jul 5, 2011, at 1:39 AM, Anton Shterenlikht wrote: > On Thu, Jun 30, 2011 at 05:11:24AM -0700, Matthew Jacob wrote: >> On 6/30/2011 3:25 AM, Anton Shterenlikht wrote: >>> I see in my logs: >>> >>> isp0: Polled Mailbox Command (0x54) Timeout (500000us) (started @ >>> isp_plogx:2122) >>> isp0: Mailbox Command 'EXECUTE IOCB A64' failed (TIMEOUT) >>> isp0: Chan 0 PLOGI 0x010500 failed >>> isp0: Polled Mailbox Command (0x64) Timeout (250000us) (started @ >>> isp_getpdb:2307) >>> isp0: Mailbox Command 'GET PORT DATABASE' failed (TIMEOUT) >> >> More details please. >> >> These errors indicate failures to execute commands that try and figure >> out what's on a fabric and then log into devices on the fabric. Knowing >> what hardware you have (QLogic card version), what FreeBSD release you >> are running, would help. A verbose dmesg would be useful. > > I got it again. But this time the network seems fine. If you haven't updated to the latest sources, please do so. If you did already, please make sure you don't have PREEMPTION configured. FYI, -- Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Tue Jul 5 22:23:51 2011 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 A97201065774; Tue, 5 Jul 2011 22:23:51 +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 628C28FC0C; Tue, 5 Jul 2011 22:23:51 +0000 (UTC) Received: from ncsc.bris.ac.uk ([137.222.10.41]) by dirg.bris.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1QeE1c-0003j6-8q; Tue, 05 Jul 2011 23:23:34 +0100 Received: from mech-cluster241.men.bris.ac.uk ([137.222.187.241]) by ncsc.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1QeE11-0006ZR-8f; Tue, 05 Jul 2011 23:22:47 +0100 Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.4/8.14.4) with ESMTP id p65MMkq4032503; Tue, 5 Jul 2011 23:22:46 +0100 (BST) (envelope-from mexas@bristol.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.4/8.14.4/Submit) id p65MMiKJ032502; Tue, 5 Jul 2011 23:22:44 +0100 (BST) (envelope-from mexas@bristol.ac.uk) X-Authentication-Warning: mech-cluster241.men.bris.ac.uk: mexas set sender to mexas@bristol.ac.uk using -f Date: Tue, 5 Jul 2011 23:22:42 +0100 From: Anton Shterenlikht To: Marcel Moolenaar Message-ID: <20110705222242.GA27743@mech-cluster241.men.bris.ac.uk> Mail-Followup-To: Marcel Moolenaar , Anton Shterenlikht , Matthew Jacob , freebsd-current@freebsd.org, freebsd-ia64@freebsd.org References: <20110630102544.GA97559@mech-cluster241.men.bris.ac.uk> <4E0C67EC.8020609@feral.com> <20110705083935.GA9094@mech-cluster241.men.bris.ac.uk> <783405F6-2417-4E5B-B1F8-B8EC0113B73A@xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <783405F6-2417-4E5B-B1F8-B8EC0113B73A@xcllnt.net> User-Agent: Mutt/1.4.2.3i Cc: Matthew Jacob , freebsd-current@freebsd.org, Anton Shterenlikht , freebsd-ia64@freebsd.org Subject: Re: isp(4) timeout 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, 05 Jul 2011 22:23:51 -0000 On Tue, Jul 05, 2011 at 08:13:02AM -0700, Marcel Moolenaar wrote: > > On Jul 5, 2011, at 1:39 AM, Anton Shterenlikht wrote: > > > On Thu, Jun 30, 2011 at 05:11:24AM -0700, Matthew Jacob wrote: > >> On 6/30/2011 3:25 AM, Anton Shterenlikht wrote: > >>> I see in my logs: > >>> > >>> isp0: Polled Mailbox Command (0x54) Timeout (500000us) (started @ > >>> isp_plogx:2122) > >>> isp0: Mailbox Command 'EXECUTE IOCB A64' failed (TIMEOUT) > >>> isp0: Chan 0 PLOGI 0x010500 failed > >>> isp0: Polled Mailbox Command (0x64) Timeout (250000us) (started @ > >>> isp_getpdb:2307) > >>> isp0: Mailbox Command 'GET PORT DATABASE' failed (TIMEOUT) > >> > >> More details please. > >> > >> These errors indicate failures to execute commands that try and figure > >> out what's on a fabric and then log into devices on the fabric. Knowing > >> what hardware you have (QLogic card version), what FreeBSD release you > >> are running, would help. A verbose dmesg would be useful. > > > > I got it again. But this time the network seems fine. > > If you haven't updated to the latest sources, please do so. > If you did already, please make sure you don't have PREEMPTION > configured. updated to r223796 (no PREEMPTION in kernel). Had this hang on reboot: KDB: stack backtrace: getenv with the following non-sleepable locks held: exclusive sleep mutex vnode interlock (vnode interlock) r = 0 (0xe000000011587ce8) locked @ /usr/src/sys/fs/devfs/devfs_vnops.c:405 KDB: stack backtrace: getenv with the following non-sleepable locks held: exclusive sleep mutex vnode interlock (vnode interlock) r = 0 (0xe000000011587ce8) locked @ /usr/src/sys/fs/devfs/devfs_vnops.c:405 KDB: stack backtrace: (repeated lots of times) no panic, just hang. Had to reset power via MP. Seems fine after reboot. Anything else I should check? Many thanks Anton -- 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 Tue Jul 5 22:25:05 2011 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 E833B1065679 for ; Tue, 5 Jul 2011 22:25:05 +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 A3DA88FC14 for ; Tue, 5 Jul 2011 22:25:05 +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 1QeE34-0003mc-Qx; Tue, 05 Jul 2011 23:25:00 +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 1QeE2m-00030S-I0; Tue, 05 Jul 2011 23:24:36 +0100 Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.4/8.14.4) with ESMTP id p65MOZXp032520; Tue, 5 Jul 2011 23:24:35 +0100 (BST) (envelope-from mexas@bristol.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.4/8.14.4/Submit) id p65MOZln032519; Tue, 5 Jul 2011 23:24:35 +0100 (BST) (envelope-from mexas@bristol.ac.uk) X-Authentication-Warning: mech-cluster241.men.bris.ac.uk: mexas set sender to mexas@bristol.ac.uk using -f Date: Tue, 5 Jul 2011 23:24:35 +0100 From: Anton Shterenlikht To: Matthew Jacob Message-ID: <20110705222435.GA32508@mech-cluster241.men.bris.ac.uk> Mail-Followup-To: Matthew Jacob , freebsd-current@freebsd.org References: <20110630102544.GA97559@mech-cluster241.men.bris.ac.uk> <4E0C67EC.8020609@feral.com> <20110705083935.GA9094@mech-cluster241.men.bris.ac.uk> <4E132104.2060900@feral.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E132104.2060900@feral.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: isp(4) timeout 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, 05 Jul 2011 22:25:06 -0000 On Tue, Jul 05, 2011 at 07:34:44AM -0700, Matthew Jacob wrote: > On 7/5/2011 1:39 AM, Anton Shterenlikht wrote: > > ... > >dmesg: > > > >http://seis.bris.ac.uk/~mexas/freebsd/ia64/rx2620/ZEEV/dmesg.boot > > > >Many thanks > >Anton > > > > >isp0: Board Type 2422, Chip Revision 0x2, resident F/W Revision 4.0.90 > > Add the line > > isp_2400_load="YES" > > to /boot/loader.conf. I somehow missed ispfw(4). Now added device ispfw to the kernel. Is this sufficient? Many thanks Anton -- 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 Tue Jul 5 22:51:03 2011 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 797C8106564A for ; Tue, 5 Jul 2011 22:51:03 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id 3EE858FC12 for ; Tue, 5 Jul 2011 22:51:03 +0000 (UTC) Received: from ns1.feral.com (localhost [127.0.0.1]) by ns1.feral.com (8.14.4/8.14.4) with ESMTP id p65Moj7B074714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Jul 2011 15:50:45 -0700 (PDT) (envelope-from mj@feral.com) Received: from localhost (mjacob@localhost) by ns1.feral.com (8.14.4/8.14.4/Submit) with ESMTP id p65Mojrf074711; Tue, 5 Jul 2011 15:50:45 -0700 (PDT) (envelope-from mj@feral.com) X-Authentication-Warning: ns1.feral.com: mjacob owned process doing -bs Date: Tue, 5 Jul 2011 15:50:45 -0700 (PDT) From: Matthew Jacob To: Anton Shterenlikht In-Reply-To: <20110705222435.GA32508@mech-cluster241.men.bris.ac.uk> Message-ID: References: <20110630102544.GA97559@mech-cluster241.men.bris.ac.uk> <4E0C67EC.8020609@feral.com> <20110705083935.GA9094@mech-cluster241.men.bris.ac.uk> <4E132104.2060900@feral.com> <20110705222435.GA32508@mech-cluster241.men.bris.ac.uk> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (ns1.feral.com [127.0.0.1]); Tue, 05 Jul 2011 15:50:45 -0700 (PDT) Cc: freebsd-current@freebsd.org Subject: Re: isp(4) timeout X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mj@feral.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 22:51:03 -0000 On Tue, 5 Jul 2011, Anton Shterenlikht wrote: > I somehow missed ispfw(4). > Now added > > device ispfw > > to the kernel. > > Is this sufficient? Overkill, but sufficient. From owner-freebsd-current@FreeBSD.ORG Wed Jul 6 00:55:17 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 4E4FC106564A for ; Wed, 6 Jul 2011 00:55:17 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-4.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id A199B14E7C2; Wed, 6 Jul 2011 00:55:09 +0000 (UTC) Message-ID: <4E13B26D.6060203@FreeBSD.org> Date: Tue, 05 Jul 2011 17:55:09 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.18) Gecko/20110624 Thunderbird/3.1.11 MIME-Version: 1.0 To: Marius Strobl References: <20110628155802.GA26562@alchemy.franken.de> In-Reply-To: <20110628155802.GA26562@alchemy.franken.de> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: KOT MATPOCKuH , FreeBSD Current Subject: Re: named crashes on assertion in rbtdb.c o? sparc64/SMP 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, 06 Jul 2011 00:55:17 -0000 On 06/28/2011 08:58, Marius Strobl wrote: > Uhm, we once fixed a problem in the MD atomic implementation which > still seems to present in the ISC copy. Could you please test whether > the following patch makes a difference? > http://people.freebsd.org/~marius/sparc64_isc_atomic.h.diff I haven't seen any verification from the OP that this patch solved the problem, however it did pass 'make universe' on both 9-current and RELENG_8, so I've committed it to those 2 branches along with the recent update. I'll also submit it upstream. Thanks, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Wed Jul 6 00:42:14 2011 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 8DA6E1065678 for ; Wed, 6 Jul 2011 00:42:14 +0000 (UTC) (envelope-from jdc@koitsu.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 784B38FC17 for ; Wed, 6 Jul 2011 00:42:14 +0000 (UTC) Received: from omta17.emeryville.ca.mail.comcast.net ([76.96.30.73]) by qmta12.emeryville.ca.mail.comcast.net with comcast id 4Q3T1h0071afHeLACQV2tx; Wed, 06 Jul 2011 00:29:02 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta17.emeryville.ca.mail.comcast.net with comcast id 4Qak1h01X1t3BNj8dQallH; Wed, 06 Jul 2011 00:34:46 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id D555D102C36; Tue, 5 Jul 2011 17:29:00 -0700 (PDT) Date: Tue, 5 Jul 2011 17:29:00 -0700 From: Jeremy Chadwick To: John Message-ID: <20110706002900.GA70126@icarus.home.lan> References: <20110706002155.GB12224@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110706002155.GB12224@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Wed, 06 Jul 2011 01:39:23 +0000 Cc: freebsd-fs@FreeBSD.org, freebsd-current@freebsd.org Subject: Re: avl_find() panic 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, 06 Jul 2011 00:42:14 -0000 On Wed, Jul 06, 2011 at 12:21:55AM +0000, John wrote: > I have a system that panic'd this morning, 4 day old current > (2011-07-01_11.45pm). Message typed in from the console immediately > after reboot. OS on ufs, data volumes on zfs. > > ZFS filesystem version 5 > ZFS storage pool version 28 > panic: avl_find() succedded inside avl_find() > > Unfortunately, I don't have a traceback for this. > > The comment in avl.c makes it seem like the avl code is enforcing > uniqueness in calling code, esp. where it talks about kernel vs > userland. > > I'll followup with more info if this replicates. Cross-posting is generally shunned, but since this is a current thing, adding freebsd-current to the CC list. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-current@FreeBSD.ORG Wed Jul 6 00:51:34 2011 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 524B0106566B; Wed, 6 Jul 2011 00:51:34 +0000 (UTC) (envelope-from jwd@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 38DA78FC1B; Wed, 6 Jul 2011 00:51:34 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p660pYZV069625; Wed, 6 Jul 2011 00:51:34 GMT (envelope-from jwd@freefall.freebsd.org) Received: (from jwd@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p660pYl7069624; Wed, 6 Jul 2011 00:51:34 GMT (envelope-from jwd) Date: Wed, 6 Jul 2011 00:51:34 +0000 From: John To: freebsd-current@freebsd.org, freebsd-fs@freebsd.org Message-ID: <20110706005134.GA60868@FreeBSD.org> References: <20110618043100.GA40745@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110618043100.GA40745@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Mailman-Approved-At: Wed, 06 Jul 2011 01:45:09 +0000 Cc: Subject: Re: LOR: vfs_lookup.c:501 ffs_vnops.c:261 vfs_subr.c:2134 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, 06 Jul 2011 00:51:34 -0000 Hi Folks, I just updated this particular systems to current as of this evening (2011-07-05 7:22pm EDT) and am still seeing this LOR. lock order reversal: 1st 0xfffffe003c893818 ufs (ufs) @ /usr/src.2011-07-05_7.22pm_EDT/sys/kern/vfs_lookup.c:501 2nd 0xffffff9f0c7eeef8 bufwait (bufwait) @ /usr/src.2011-07-05_7.22pm_EDT/sys/ufs/ffs/ffs_vnops.c:261 3rd 0xfffffe003c8689f8 ufs (ufs) @ /usr/src.2011-07-05_7.22pm_EDT/sys/kern/vfs_subr.c:2134 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x807 __lockmgr_args() at __lockmgr_args+0xd42 ffs_lock() at ffs_lock+0x8c VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x47 vget() at vget+0x7b vfs_hash_get() at vfs_hash_get+0xd5 ffs_vgetf() at ffs_vgetf+0x48 softdep_sync_buf() at softdep_sync_buf+0x568 ffs_syncvnode() at ffs_syncvnode+0x293 ffs_truncate() at ffs_truncate+0x4c4 ufs_direnter() at ufs_direnter+0x6ed ufs_makeinode() at ufs_makeinode+0x250 VOP_CREATE_APV() at VOP_CREATE_APV+0x8d vn_open_cred() at vn_open_cred+0x46a kern_openat() at kern_openat+0x17f syscallenter() at syscallenter+0x1aa syscall() at syscall+0x4c Xfast_syscall() at Xfast_syscall+0xdd --- syscall (5, FreeBSD ELF64, open), rip = 0x800936b9c, rsp = 0x7fffffffdac8, rbp = 0 --- Cross-posting to -fs for more visibility. Thoughts welcome. -John ----- John's Original Message ----- > Hi folks, > > I'm seeing the following LOR in dmesg after my latest update this evening. > > # uname -a > FreeBSD zfscarp3p 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Fri Jun 17 22:36:45 EDT 2011 root@zfscarp3p/usr/obj/usr/src.2011-06-17_9.36pm_EDT/sys/GENERIC amd6 > > WARNING: WITNESS option enabled, expect reduced performance. > Trying to mount root from ufs:/dev/da56s1a [rw]... > lock order reversal: > 1st 0xfffffe003d2f9278 ufs (ufs) @ /usr/src.2011-06-17_9.36pm_EDT/sys/kern/vfs_lookup.c:501 > 2nd 0xffffff9f0c7f0e58 bufwait (bufwait) @ /usr/src.2011-06-17_9.36pm_EDT/sys/ufs/ffs/ffs_vnops.c:261 > 3rd 0xfffffe003d371278 ufs (ufs) @ /usr/src.2011-06-17_9.36pm_EDT/sys/kern/vfs_subr.c:2134 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > kdb_backtrace() at kdb_backtrace+0x37 > _witness_debugger() at _witness_debugger+0x2e > witness_checkorder() at witness_checkorder+0x807 > __lockmgr_args() at __lockmgr_args+0xd42 > ffs_lock() at ffs_lock+0x8c > VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b > _vn_lock() at _vn_lock+0x47 > vget() at vget+0x7b > vfs_hash_get() at vfs_hash_get+0xd5 > ffs_vgetf() at ffs_vgetf+0x48 > softdep_sync_buf() at softdep_sync_buf+0x56a > ffs_syncvnode() at ffs_syncvnode+0x293 > ffs_truncate() at ffs_truncate+0x4c4 > ufs_direnter() at ufs_direnter+0x6ed > ufs_makeinode() at ufs_makeinode+0x250 > VOP_CREATE_APV() at VOP_CREATE_APV+0x8d > vn_open_cred() at vn_open_cred+0x46a > kern_openat() at kern_openat+0x17f > syscallenter() at syscallenter+0x1aa > syscall() at syscall+0x4c > Xfast_syscall() at Xfast_syscall+0xdd > --- syscall (5, FreeBSD ELF64, open), rip = 0x800936b7c, rsp = 0x7fffffffdac8, rbp = 0 --- > bce1: Gigabit link up! > > Only seems to happen once at boot time. > > Thanks, > John From owner-freebsd-current@FreeBSD.ORG Wed Jul 6 08:50:34 2011 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 95E0F1065672; Wed, 6 Jul 2011 08:50:34 +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 558758FC15; Wed, 6 Jul 2011 08:50:34 +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 <1QeNoX-0000ve-5b>; Wed, 06 Jul 2011 10:50:33 +0200 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1QeNoX-0001CJ-3Y>; Wed, 06 Jul 2011 10:50:33 +0200 Message-ID: <4E1421D9.7080808@zedat.fu-berlin.de> Date: Wed, 06 Jul 2011 10:50:33 +0200 From: "O. Hartmann" Organization: Freie =?ISO-8859-1?Q?Universit=E4t_Berlin?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110701 Thunderbird/5.0 MIME-Version: 1.0 To: freebsd-questions@FreeBSD.ORG, FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 130.133.86.198 Cc: Subject: Heavy I/O blocks FreeBSD box for several seconds 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, 06 Jul 2011 08:50:34 -0000 When performing an update on the ports tree via "portsnap fetch update" or when checking out (or) large Subversion repositories or when copying large data files (~ 50 to 250 GB in size, results from numerical modelings) or when compiling world, FreeBD 9.0 and FreeBSD 8.2-STABLE tend to "freeze" for several seconds or drop overall performance dramatically for seconds. On boxes with only console- or terminal access (no GUI) a running 'vi' gets stuck for seconds while one of the processes producing heavy I/O is running, or the output of a 'cat' of a large file stops for several seconds. Using X11, this phenomenon gets even worse and the 'freezing' tends to persist sometimes for more than 10 or 15 seconds. The boxes in question are all 64Bit, do have 2 to 8 CPUs/cores (no SMT) and not less than 8 GB of RAM (the 8 core box is a dual socket Dell server with two 4-core C2D-type XEON CPUs and 16 GB of RAM). All these boxes uses ZFS filesystems for data along with UFS2 for the OS. On a notebook with a relative modern Core-5 dual core CPU and 4 GB RAM (running FreeBSD 9.0-CURRENT/amd64), not ZFS, all UFS, with a 500GB harddrive at 5400 upm (Dell Latitude E6510), this phenomenon is even worse. Heavy disk I/O blocks the GUI for nearly half a minute, even when no X11 is activated, the console gets stuck for a while. First I thought this could be a problem with the "slow" harddrive, but I tried also a Linux Ubuntu 11.04 on the box and forcing heavy I/O by copying the large files in question from one location on the disk to another is performed even faster and without any freezing of a console or GUI (used EXT4 filesystem). I'm curious about this behavior. I use FreeBSD as my favourite HPC platform as far as this is possible with FreeBSD, but I realized this bottleneck when it comes to heavy I/O and I'd like to know whether this is only a "superficial" phenomenon (like caused by the outdated X11 version FreeBSD use or a low priorized tty handling, means only the observer "realize" a performance drop). I've got not the time to investigate this deeper (I'd like to perform some benchmarks on the notebook if it is available again, but my knowledge on Linux/Ubuntu is very limited and the how-to setting up FreeBSD and Linux to match each other on the same hardware could be tricky). My kernel setups on FreeBSD are mostly the GENERIC kernel with extracted drivers I do not use (like some USB devices, SAS/SCSI adaptors etc. we do not use, et cetera), nothing special. Either way I follow the tips presented in "tuning(7)" or not, the phenomenon is present. Thanks, Oliver From owner-freebsd-current@FreeBSD.ORG Wed Jul 6 09:19:45 2011 Return-Path: Delivered-To: current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id E0B8A1065673; Wed, 6 Jul 2011 09:19:45 +0000 (UTC) Date: Wed, 6 Jul 2011 09:19:45 +0000 From: Alexander Best To: current@freebsd.org Message-ID: <20110706091945.GA64202@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Cc: Subject: displaying thread id in top -H 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, 06 Jul 2011 09:19:46 -0000 hi there, any reason why bin/139389 hasn't been committed, yet? i think seeing the thread id in top -H output is extremely useful! cheers. alex From owner-freebsd-current@FreeBSD.ORG Wed Jul 6 09:55:18 2011 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 85730106564A; Wed, 6 Jul 2011 09:55:18 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 1CE0A8FC08; Wed, 6 Jul 2011 09:55:17 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id p669tFng084067; Wed, 6 Jul 2011 11:55:15 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id p669tFpT084066; Wed, 6 Jul 2011 11:55:15 +0200 (CEST) (envelope-from marius) Date: Wed, 6 Jul 2011 11:55:15 +0200 From: Marius Strobl To: Doug Barton Message-ID: <20110706095514.GF14797@alchemy.franken.de> References: <20110628155802.GA26562@alchemy.franken.de> <4E13B26D.6060203@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E13B26D.6060203@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: KOT MATPOCKuH , FreeBSD Current Subject: Re: named crashes on assertion in rbtdb.c o? sparc64/SMP 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, 06 Jul 2011 09:55:18 -0000 On Tue, Jul 05, 2011 at 05:55:09PM -0700, Doug Barton wrote: > On 06/28/2011 08:58, Marius Strobl wrote: > >Uhm, we once fixed a problem in the MD atomic implementation which > >still seems to present in the ISC copy. Could you please test whether > >the following patch makes a difference? > >http://people.freebsd.org/~marius/sparc64_isc_atomic.h.diff > > I haven't seen any verification from the OP that this patch solved the > problem, It simply doesn't so apparently there's another bug in other parts of BIND causing it to trip over that assertion. Still, the clobber lists of the sparc64 atomic bits were incomplete and fixing that IMO was the right thing to do. > however it did pass 'make universe' on both 9-current and > RELENG_8, so I've committed it to those 2 branches along with the recent > update. I'll also submit it upstream. > Thanks! Marius From owner-freebsd-current@FreeBSD.ORG Wed Jul 6 10:14:14 2011 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 0C7B2106566C for ; Wed, 6 Jul 2011 10:14:14 +0000 (UTC) (envelope-from christer.solskogen@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id BF48D8FC08 for ; Wed, 6 Jul 2011 10:14:13 +0000 (UTC) Received: by vxg33 with SMTP id 33so6584394vxg.13 for ; Wed, 06 Jul 2011 03:14:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ivHSALzoX6tVE8TxkFLLxqF/I0+dcPu0ADWciI+8AeU=; b=voEucPOLBk6DZTwjfqN3aFajM9h3U9bLpXj0kQILTHeuBalGylk9fLPt7AaDgVDq7A wIotm3PVVZTqR736iiiPXcGNQJmm9vz24WBhhRGe5CPkXwJvOMbhaVqtBw8R9uQc7Nm6 p3laxRzKmF/0Wd8NpAAICMnXG+HKrKHanr85A= Received: by 10.52.99.67 with SMTP id eo3mr2544918vdb.89.1309945529055; Wed, 06 Jul 2011 02:45:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.116.74 with HTTP; Wed, 6 Jul 2011 02:45:09 -0700 (PDT) In-Reply-To: <4E1421D9.7080808@zedat.fu-berlin.de> References: <4E1421D9.7080808@zedat.fu-berlin.de> From: Christer Solskogen Date: Wed, 6 Jul 2011 11:45:09 +0200 Message-ID: To: "O. Hartmann" Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Current , freebsd-questions@freebsd.org Subject: Re: Heavy I/O blocks FreeBSD box for several seconds 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, 06 Jul 2011 10:14:14 -0000 2011/7/6 O. Hartmann : Could you post /etc/sysctl.conf and /boot/loader.conf? Also, the output of uname -a on all machines would be nice. And since you don't use GENERIC, could you also tell us what difference your setup is from a GENERIC kernel? -- chs, From owner-freebsd-current@FreeBSD.ORG Wed Jul 6 11:01:49 2011 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 E8B48106566B; Wed, 6 Jul 2011 11:01:48 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8374C8FC1C; Wed, 6 Jul 2011 11:01:48 +0000 (UTC) Received: by pvg11 with SMTP id 11so8441311pvg.13 for ; Wed, 06 Jul 2011 04:01:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=MrflcYng5AKSefEZJoq0SdFWDIyIuNpeFo1YWsjf+WI=; b=jMeGqmivS9a9J8Wuies+iRAnn45SMFs3Qo6MN2skiUrg6ZyVfbyWDMurhQ4S5HeEEE Bf9BWzrN2v9DdAGHUj4aczHsPuU0/GMycx99IJXqltTJm2qHVsqwQMW6H9hfteoq7xlg nHt7DWilGrYFbf6QTnc+X6c+cpwKKjXMAdX8I= Received: by 10.142.242.12 with SMTP id p12mr3808209wfh.346.1309948672321; Wed, 06 Jul 2011 03:37:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.186.20 with HTTP; Wed, 6 Jul 2011 03:37:32 -0700 (PDT) In-Reply-To: <4E1421D9.7080808@zedat.fu-berlin.de> References: <4E1421D9.7080808@zedat.fu-berlin.de> From: arrowdodger <6yearold@gmail.com> Date: Wed, 6 Jul 2011 14:37:32 +0400 Message-ID: To: freebsd-questions@freebsd.org, FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: Heavy I/O blocks FreeBSD box for several seconds 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, 06 Jul 2011 11:01:49 -0000 2011/7/6 O. Hartmann > When performing an update on the ports tree via "portsnap fetch update" or > when checking out (or) large Subversion repositories or when copying large > data files (~ 50 to 250 GB in size, results from numerical modelings) or > when compiling world, FreeBD 9.0 and FreeBSD 8.2-STABLE tend to "freeze" for > several seconds or drop overall performance dramatically for seconds. On > boxes with only console- or terminal access (no GUI) a running 'vi' gets > stuck for seconds while one of the processes producing heavy I/O is running, > or the output of a 'cat' of a large file stops for several seconds. > > Using X11, this phenomenon gets even worse and the 'freezing' tends to > persist sometimes for more than 10 or 15 seconds. > I've also had (and still having) this problem on FreeBSD 7.2-RELEASE and 8-STABLE with both UFS and ZFS. Though, i've been running FreeBSD not on powerful servers, but on laptops (2-core CPU's, 2 GB of RAM). But still, KDE4 on Linux performs much better during high disk IO. From owner-freebsd-current@FreeBSD.ORG Wed Jul 6 11:38:02 2011 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 6A512106566B for ; Wed, 6 Jul 2011 11:38:02 +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 B5CAC8FC0A for ; Wed, 6 Jul 2011 11:38:01 +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 OAA28399; Wed, 06 Jul 2011 14:37:57 +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 1QeQQX-0005nu-47; Wed, 06 Jul 2011 14:37:57 +0300 Message-ID: <4E144913.3060503@FreeBSD.org> Date: Wed, 06 Jul 2011 14:37:55 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.18) Gecko/20110626 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: arrowdodger <6yearold@gmail.com>, "O. Hartmann" References: <4E1421D9.7080808@zedat.fu-berlin.de> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: Heavy I/O blocks FreeBSD box for several seconds 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, 06 Jul 2011 11:38:02 -0000 on 06/07/2011 13:37 arrowdodger said the following: > 2011/7/6 O. Hartmann > >> When performing an update on the ports tree via "portsnap fetch update" or >> when checking out (or) large Subversion repositories or when copying large >> data files (~ 50 to 250 GB in size, results from numerical modelings) or >> when compiling world, FreeBD 9.0 and FreeBSD 8.2-STABLE tend to "freeze" for >> several seconds or drop overall performance dramatically for seconds. On >> boxes with only console- or terminal access (no GUI) a running 'vi' gets >> stuck for seconds while one of the processes producing heavy I/O is running, >> or the output of a 'cat' of a large file stops for several seconds. >> >> Using X11, this phenomenon gets even worse and the 'freezing' tends to >> persist sometimes for more than 10 or 15 seconds. >> > > I've also had (and still having) this problem on FreeBSD 7.2-RELEASE and > 8-STABLE with both UFS and ZFS. Though, i've been running FreeBSD not on > powerful servers, but on laptops (2-core CPU's, 2 GB of RAM). But still, > KDE4 on Linux performs much better during high disk IO. Just curious what your current value of sysctl kern.sched.preempt_thresh is. And if it's not 224 and if you haven't tried 224 yet, then could you please try it and see if there is any improvement? This assumes that you use SCHED_ULE (kern.sched.name is "ULE"). -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Jul 6 12:36:07 2011 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 BAF001065673 for ; Wed, 6 Jul 2011 12:36:07 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8CB2A8FC12 for ; Wed, 6 Jul 2011 12:36:07 +0000 (UTC) Received: by pvg11 with SMTP id 11so8534107pvg.13 for ; Wed, 06 Jul 2011 05:36:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=y9Fm3dsFd8sJHevYAt7WvBgCLi3DYZtll5+/vx9coa8=; b=f3uQdJodL9iWQ+GudJqqTLejoky9EBGG391Zf2ZSJzn7g13LtCP450goRyni1QE2ce SIdi3eKm8aF4a4b/G4bYIPXw/u9eftPeq8yFlomHAlbUhognQ3v8pXcs0NgwlcTpo5M5 juQMdp3d62EIVye7Innoq4QowjoJTwVYZqsy0= Received: by 10.142.114.18 with SMTP id m18mr4062995wfc.403.1309955767117; Wed, 06 Jul 2011 05:36:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.186.20 with HTTP; Wed, 6 Jul 2011 05:35:47 -0700 (PDT) In-Reply-To: <4E144913.3060503@FreeBSD.org> References: <4E1421D9.7080808@zedat.fu-berlin.de> <4E144913.3060503@FreeBSD.org> From: arrowdodger <6yearold@gmail.com> Date: Wed, 6 Jul 2011 16:35:47 +0400 Message-ID: To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Current , "O. Hartmann" Subject: Re: Heavy I/O blocks FreeBSD box for several seconds 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, 06 Jul 2011 12:36:07 -0000 On Wed, Jul 6, 2011 at 3:37 PM, Andriy Gapon wrote: > Just curious what your current value of sysctl kern.sched.preempt_thresh > is. > And if it's not 224 and if you haven't tried 224 yet, then could you please > try > it and see if there is any improvement? > > This assumes that you use SCHED_ULE (kern.sched.name is "ULE"). > > -- > Andriy Gapon > Whoa, it's definitely better! Thanks a lot. But still, when IO causes system to use swap, X11 became completely unusable. From owner-freebsd-current@FreeBSD.ORG Wed Jul 6 13:33:37 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id C9438106566B; Wed, 6 Jul 2011 13:33:37 +0000 (UTC) Date: Wed, 6 Jul 2011 13:33:37 +0000 From: Alexander Best To: arrowdodger <6yearold@gmail.com> Message-ID: <20110706133337.GA89910@freebsd.org> References: <4E1421D9.7080808@zedat.fu-berlin.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: FreeBSD Current , freebsd-questions@freebsd.org Subject: Re: Heavy I/O blocks FreeBSD box for several seconds 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, 06 Jul 2011 13:33:37 -0000 On Wed Jul 6 11, arrowdodger wrote: > 2011/7/6 O. Hartmann > > > When performing an update on the ports tree via "portsnap fetch update" or > > when checking out (or) large Subversion repositories or when copying large > > data files (~ 50 to 250 GB in size, results from numerical modelings) or > > when compiling world, FreeBD 9.0 and FreeBSD 8.2-STABLE tend to "freeze" for > > several seconds or drop overall performance dramatically for seconds. On > > boxes with only console- or terminal access (no GUI) a running 'vi' gets > > stuck for seconds while one of the processes producing heavy I/O is running, > > or the output of a 'cat' of a large file stops for several seconds. this might be a scheduling issue. iirc i/o intensive tasks have higher priority than cpu intensive tasks, because they are expected to only issue a i/o request and then free the processor, while cpu intensive tasks occupy the cpu a lot longer. so maybe a process whith cyclic i/o requests blocks processes which aren't doing i/o. maybe playing with ULE's options can improve the situation. since you're running GENERIC, preemption *should* be enabled. however you should double check. i once tried running ULE without preemption and experienced exactly the same situation you described in your mail. for ULE preemption is pretty much mandatory. for the old 4bsd scheduler, running without preemtion doesn't really make that much of a difference, compared to running with preemption. you might also want to try enabling options IPI_PREEMPTION. no idea, if this improves your situation, though. cheers. alex > > > > Using X11, this phenomenon gets even worse and the 'freezing' tends to > > persist sometimes for more than 10 or 15 seconds. > > > > I've also had (and still having) this problem on FreeBSD 7.2-RELEASE and > 8-STABLE with both UFS and ZFS. Though, i've been running FreeBSD not on > powerful servers, but on laptops (2-core CPU's, 2 GB of RAM). But still, > KDE4 on Linux performs much better during high disk IO. From owner-freebsd-current@FreeBSD.ORG Wed Jul 6 14:26:48 2011 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 27A14106566B for ; Wed, 6 Jul 2011 14:26:48 +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 74E5D8FC14 for ; Wed, 6 Jul 2011 14:26:47 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA00895; Wed, 06 Jul 2011 17:26:44 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4E1470A3.30607@FreeBSD.org> Date: Wed, 06 Jul 2011 17:26:43 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110705 Thunderbird/5.0 MIME-Version: 1.0 To: arrowdodger <6yearold@gmail.com> References: <4E1421D9.7080808@zedat.fu-berlin.de> <4E144913.3060503@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.2pre Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , "O. Hartmann" Subject: Re: Heavy I/O blocks FreeBSD box for several seconds 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, 06 Jul 2011 14:26:48 -0000 on 06/07/2011 15:35 arrowdodger said the following: > On Wed, Jul 6, 2011 at 3:37 PM, Andriy Gapon > wrote: > > Just curious what your current value of sysctl kern.sched.preempt_thresh is. > And if it's not 224 and if you haven't tried 224 yet, then could you please try > it and see if there is any improvement? > > This assumes that you use SCHED_ULE (kern.sched.name > is "ULE"). > > Whoa, it's definitely better! Thanks a lot. Thank you for the report. I guess I will try to push for this value to become the default. > But still, when IO causes system to > use swap, X11 became completely unusable. Swap is a bit different issue. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Jul 6 14:33:35 2011 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 5222A106564A; Wed, 6 Jul 2011 14:33: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 5ECE88FC19; Wed, 6 Jul 2011 14:33:33 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA00995; Wed, 06 Jul 2011 17:33:32 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4E14723C.4020704@FreeBSD.org> Date: Wed, 06 Jul 2011 17:33:32 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110705 Thunderbird/5.0 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org, freebsd-ports@FreeBSD.org X-Enigmail-Version: 1.2pre Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: cpumask_t/cpuset_t changes in CURRENT and non-base gcc 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, 06 Jul 2011 14:33:35 -0000 I think that if you use non-base gcc for ports on CURRENT, then you need to follow this procedure after upgrading world to a revision after the cpumask_t/cpuset_t change: 1. upgrade/re-install gccXX using base gcc as a bootstrap compiler (make CC=gcc) 2. everything else... :) -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Jul 6 14:36:36 2011 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 489A1106568F; Wed, 6 Jul 2011 14:36:36 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id D066A8FC21; Wed, 6 Jul 2011 14:36:35 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id p66EaXqA085206; Wed, 6 Jul 2011 16:36:34 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id p66EaXRL085205; Wed, 6 Jul 2011 16:36:33 +0200 (CEST) (envelope-from marius) Date: Wed, 6 Jul 2011 16:36:33 +0200 From: Marius Strobl To: KOT MATPOCKuH Message-ID: <20110706143632.GA85141@alchemy.franken.de> References: <20110628155802.GA26562@alchemy.franken.de> <4E13B26D.6060203@FreeBSD.org> <20110706095514.GF14797@alchemy.franken.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110706095514.GF14797@alchemy.franken.de> User-Agent: Mutt/1.4.2.3i Cc: Doug Barton , FreeBSD Current Subject: Re: named crashes on assertion in rbtdb.c o? sparc64/SMP 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, 06 Jul 2011 14:36:36 -0000 On Wed, Jul 06, 2011 at 11:55:15AM +0200, Marius Strobl wrote: > On Tue, Jul 05, 2011 at 05:55:09PM -0700, Doug Barton wrote: > > On 06/28/2011 08:58, Marius Strobl wrote: > > >Uhm, we once fixed a problem in the MD atomic implementation which > > >still seems to present in the ISC copy. Could you please test whether > > >the following patch makes a difference? > > >http://people.freebsd.org/~marius/sparc64_isc_atomic.h.diff > > > > I haven't seen any verification from the OP that this patch solved the > > problem, > > It simply doesn't so apparently there's another bug in other parts of > BIND causing it to trip over that assertion. Still, the clobber lists > of the sparc64 atomic bits were incomplete and fixing that IMO was the > right thing to do. > MATPOCKuH, could you please test the following patch? http://people.freebsd.org/~marius/sparc64_isc_disable_atomic.diff That one simple disables the use of atomic operations for sparc64 as I doubt that these have seen much testing except on x86, be it on sparc64 or in general; given that they are also used for reference counting they should provide acquire and release semantics for that purpose which include the necessary memory barriers for these but the ISC atomic API simply doesn't account for that. Moreover, the sparc64 implementation of the ISC atomic operations is FreeBSD-specific as it's the only OS I'm aware of using the primary instead of the secondary MMU context for the userland (i.e. ASI_P; generally this is a wise choice though), i.e. don't work on the other *BSDs, Linux or Solaris. Marius From owner-freebsd-current@FreeBSD.ORG Wed Jul 6 14:59:11 2011 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 66FF91065674 for ; Wed, 6 Jul 2011 14:59:11 +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 6B6C18FC08 for ; Wed, 6 Jul 2011 14:59:10 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA01373; Wed, 06 Jul 2011 17:59:08 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4E14783C.9030909@FreeBSD.org> Date: Wed, 06 Jul 2011 17:59:08 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110705 Thunderbird/5.0 MIME-Version: 1.0 To: Alexander Best References: <4E1421D9.7080808@zedat.fu-berlin.de> <20110706133337.GA89910@freebsd.org> In-Reply-To: <20110706133337.GA89910@freebsd.org> X-Enigmail-Version: 1.2pre Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , arrowdodger <6yearold@gmail.com> Subject: Re: Heavy I/O blocks FreeBSD box for several seconds 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, 06 Jul 2011 14:59:11 -0000 on 06/07/2011 16:33 Alexander Best said the following: > you might also want to try enabling options IPI_PREEMPTION. no idea, if this > improves your situation, though. Just in case, this option has effect for 4BSD scheduler only. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Jul 6 15:21:28 2011 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 92D4A106564A; Wed, 6 Jul 2011 15:21:28 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe05.c2i.net [212.247.154.130]) by mx1.freebsd.org (Postfix) with ESMTP id B3EAA8FC12; Wed, 6 Jul 2011 15:21:27 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=7KD0iiTHYGd0xbPMAUtcJ3OZoqPCTpa2X22hnPESm4A= c=1 sm=1 a=SvYTsOw2Z4kA:10 a=8GCaWQNJa_IA:10 a=WQU8e4WWZSUA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=N3vH5299AAAA:8 a=Rs8qNeDbJxh9QatkLV8A:9 a=wPNLvfGTeEIA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe05.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 147541652; Wed, 06 Jul 2011 17:21:26 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Wed, 6 Jul 2011 17:19:38 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: <1309237117.88943.YahooMailNeo@web39307.mail.mud.yahoo.com> <201106280850.57645.hselasky@c2i.net> In-Reply-To: <201106280850.57645.hselasky@c2i.net> X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201107061719.38445.hselasky@c2i.net> Cc: PseudoCylon , "freebsd-wireless@freebsd.org" Subject: Re: [CFT] Sierra Wireless HSPA+ USB modem 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, 06 Jul 2011 15:21:28 -0000 > > Hi, > > I'm going to review and import your driver. > > --HPS Hi, The intial patch had some bad code and didn't compile on 9-current. I've tried to clean it up. Please test and report back if I didn't break anything. http://hselasky.homeunix.org:8192/usie_for_FreeBSD_9_current.patch --HPS From owner-freebsd-current@FreeBSD.ORG Wed Jul 6 15:28:50 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 8BB741065670; Wed, 6 Jul 2011 15:28:50 +0000 (UTC) Date: Wed, 6 Jul 2011 15:28:50 +0000 From: Alexander Best To: Andriy Gapon Message-ID: <20110706152850.GA4139@freebsd.org> References: <4E1421D9.7080808@zedat.fu-berlin.de> <20110706133337.GA89910@freebsd.org> <4E14783C.9030909@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E14783C.9030909@FreeBSD.org> Cc: FreeBSD Current , arrowdodger <6yearold@gmail.com> Subject: Re: Heavy I/O blocks FreeBSD box for several seconds 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, 06 Jul 2011 15:28:50 -0000 On Wed Jul 6 11, Andriy Gapon wrote: > on 06/07/2011 16:33 Alexander Best said the following: > > you might also want to try enabling options IPI_PREEMPTION. no idea, if this > > improves your situation, though. > > Just in case, this option has effect for 4BSD scheduler only. thanks. i did not know that. maybe we could add a small note to NOTES or even mention in sched_ule(4) and sched_4bsd(4), which kernel options affect the according scheduler. sched_ule(4) e.g. doesn't mention kern.sched.preemption, so one can assume that defining PREEMPTION in the kernel or not doesn't make a difference. however it *does* make a huge difference. i believe sched_ule(4) in general needs a lot more details about the various sysctl vars available and their semantics. cheers. alex > > -- > Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Jul 6 15:29:25 2011 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 2C583106566B; Wed, 6 Jul 2011 15:29:25 +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 DD2E58FC19; Wed, 6 Jul 2011 15:29:24 +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 <1QeU2W-0004p4-5t>; Wed, 06 Jul 2011 17:29:24 +0200 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1QeU2W-0007a1-3s>; Wed, 06 Jul 2011 17:29:24 +0200 Message-ID: <4E147F54.40908@zedat.fu-berlin.de> Date: Wed, 06 Jul 2011 17:29:24 +0200 From: "O. Hartmann" Organization: Freie =?ISO-8859-1?Q?Universit=E4t_Berlin?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110701 Thunderbird/5.0 MIME-Version: 1.0 To: arrowdodger <6yearold@gmail.com> References: <4E1421D9.7080808@zedat.fu-berlin.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 130.133.86.198 Cc: FreeBSD Current , freebsd-questions@freebsd.org Subject: Re: Heavy I/O blocks FreeBSD box for several seconds 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, 06 Jul 2011 15:29:25 -0000 On 07/06/11 12:37, arrowdodger wrote: > 2011/7/6 O. Hartmann > >> When performing an update on the ports tree via "portsnap fetch update" or >> when checking out (or) large Subversion repositories or when copying large >> data files (~ 50 to 250 GB in size, results from numerical modelings) or >> when compiling world, FreeBD 9.0 and FreeBSD 8.2-STABLE tend to "freeze" for >> several seconds or drop overall performance dramatically for seconds. On >> boxes with only console- or terminal access (no GUI) a running 'vi' gets >> stuck for seconds while one of the processes producing heavy I/O is running, >> or the output of a 'cat' of a large file stops for several seconds. >> >> Using X11, this phenomenon gets even worse and the 'freezing' tends to >> persist sometimes for more than 10 or 15 seconds. >> > > I've also had (and still having) this problem on FreeBSD 7.2-RELEASE and > 8-STABLE with both UFS and ZFS. Though, i've been running FreeBSD not on > powerful servers, but on laptops (2-core CPU's, 2 GB of RAM). But still, > KDE4 on Linux performs much better during high disk IO. I read about issues with the old codebase of X11 in FreeBSD's ports used, which could be the cause of some performance problems, but I wouldn't expect those I/O-triggered blockings on boxes without any GUI. I saw Linux very often performing tremendously better when used as a workstation or desktop, but this is often gained on the costs of other subsystems. I followed a very hard-to-understand discussion about grouping threads related to ttys which seems to get higher priorized in Linux to make the GUI more fluent, but this is definitely on cost of other subsystems, which in consequence gets less priorized. But even without GUI, Linux seems to perform I/O much better on multicore-/multiprocessor boxes than FreeBSD *.X and 9.X). Today I looked at some benchmarks performed by Phoronix/openbenchmark.org (http://www.phoronix.com/scan.php?page=article&item=freebsd8_ubuntu910&num=9) and it seems that threaded I/O is an issue in FreeBSD (compared to Linux). I have no glue how to "tune" those bottlenecks away in FBSD. I use SCHED_ULE on all machines, since it is supposed to be performing better on multicore boxes, but there are lots of suggestions switching back to the old SCHED_4BSD scheduler. Oliver From owner-freebsd-current@FreeBSD.ORG Wed Jul 6 15:33:03 2011 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 053D110656D3; Wed, 6 Jul 2011 15:33:03 +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 676A88FC0A; Wed, 6 Jul 2011 15:33:01 +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 <1QeU60-0005Wo-L5>; Wed, 06 Jul 2011 17:33:00 +0200 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1QeU60-0007nh-JE>; Wed, 06 Jul 2011 17:33:00 +0200 Message-ID: <4E14802C.70907@zedat.fu-berlin.de> Date: Wed, 06 Jul 2011 17:33:00 +0200 From: "O. Hartmann" Organization: Freie =?ISO-8859-1?Q?Universit=E4t_Berlin?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110701 Thunderbird/5.0 MIME-Version: 1.0 To: arrowdodger <6yearold@gmail.com> References: <4E1421D9.7080808@zedat.fu-berlin.de> <4E144913.3060503@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 130.133.86.198 Cc: FreeBSD Current , Andriy Gapon Subject: Re: Heavy I/O blocks FreeBSD box for several seconds 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, 06 Jul 2011 15:33:03 -0000 On 07/06/11 14:35, arrowdodger wrote: > On Wed, Jul 6, 2011 at 3:37 PM, Andriy Gapon wrote: > >> Just curious what your current value of sysctl kern.sched.preempt_thresh >> is. >> And if it's not 224 and if you haven't tried 224 yet, then could you please >> try >> it and see if there is any improvement? >> >> This assumes that you use SCHED_ULE (kern.sched.name is "ULE"). >> >> -- >> Andriy Gapon >> > > Whoa, it's definitely better! Thanks a lot. But still, when IO causes system > to use swap, X11 became completely unusable. I had tkern.sched.preempt_thresh already set to 96. From owner-freebsd-current@FreeBSD.ORG Wed Jul 6 13:55:20 2011 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 DD746106566C for ; Wed, 6 Jul 2011 13:55:20 +0000 (UTC) (envelope-from Daan@vitsch.nl) Received: from VM01.VEHosting.nl (VM016.VEHosting.nl [IPv6:2001:1af8:2100:b020::140]) by mx1.freebsd.org (Postfix) with ESMTP id 810EB8FC1B for ; Wed, 6 Jul 2011 13:55:20 +0000 (UTC) Received: from [2001:470:d233:11:224:8cff:fe82:66cd] ([IPv6:2001:470:d233:11:224:8cff:fe82:66cd]) (authenticated bits=0) by VM01.VEHosting.nl (8.14.3/8.13.8) with ESMTP id p66DtL01011391 for ; Wed, 6 Jul 2011 15:55:21 +0200 (CEST) (envelope-from Daan@vitsch.nl) From: Daan Vreeken Organization: Vitsch Electronics To: FreeBSD Current Date: Wed, 6 Jul 2011 15:55:18 +0200 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201107061555.18570.Daan@vitsch.nl> x-ve-auth-version: mi-1.1.5 2011-02-07 - Copyright (c) 2008, 2011 - Daan Vreeken - VEHosting x-ve-auth: authenticated as 'pa4dan' on VM01.VEHosting.nl X-Mailman-Approved-At: Wed, 06 Jul 2011 15:35:42 +0000 Subject: if_tap VIMAGE 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: Wed, 06 Jul 2011 13:55:20 -0000 Hi all, I have been experimenting with a VIMAGE kernel and noticed that it can be panic()'d by opening and closing an if_tap device. I've submitted a PR with a possible patch as kern/158686 . Could anyone have a look at it? Thanks, -- Daan Vreeken Vitsch Electronics http://Vitsch.nl tel: +31-(0)40-7113051 / +31-(0)6-46210825 KvK nr: 17174380 From owner-freebsd-current@FreeBSD.ORG Wed Jul 6 15:41:03 2011 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 CC921106566B for ; Wed, 6 Jul 2011 15:41:03 +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 2490D8FC12 for ; Wed, 6 Jul 2011 15:41:02 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA02017; Wed, 06 Jul 2011 18:41:00 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4E14820C.7080006@FreeBSD.org> Date: Wed, 06 Jul 2011 18:41:00 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110705 Thunderbird/5.0 MIME-Version: 1.0 To: "O. Hartmann" References: <4E1421D9.7080808@zedat.fu-berlin.de> <4E144913.3060503@FreeBSD.org> <4E14802C.70907@zedat.fu-berlin.de> In-Reply-To: <4E14802C.70907@zedat.fu-berlin.de> X-Enigmail-Version: 1.2pre Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: Heavy I/O blocks FreeBSD box for several seconds 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, 06 Jul 2011 15:41:03 -0000 on 06/07/2011 18:33 O. Hartmann said the following: > On 07/06/11 14:35, arrowdodger wrote: >> On Wed, Jul 6, 2011 at 3:37 PM, Andriy Gapon wrote: >> >>> Just curious what your current value of sysctl kern.sched.preempt_thresh >>> is. >>> And if it's not 224 and if you haven't tried 224 yet, then could you please >>> try >>> it and see if there is any improvement? >>> >>> This assumes that you use SCHED_ULE (kern.sched.name is "ULE"). >>> >>> -- >>> Andriy Gapon >>> >> >> Whoa, it's definitely better! Thanks a lot. But still, when IO causes system >> to use swap, X11 became completely unusable. > > I had tkern.sched.preempt_thresh already set to 96. In what sense 'already'? -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Jul 6 15:44:43 2011 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 CBF501065672 for ; Wed, 6 Jul 2011 15:44:43 +0000 (UTC) (envelope-from freebsd@berczi.be) Received: from macsec.hu (cl-23.bud-01.hu.sixxs.net [IPv6:2a01:368:e000:16::2]) by mx1.freebsd.org (Postfix) with ESMTP id 91AB98FC19 for ; Wed, 6 Jul 2011 15:44:43 +0000 (UTC) Received: from [10.11.0.1] by macsec.hu with esmtp (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QeUHJ-000CUG-I1 for freebsd-current@freebsd.org; Wed, 06 Jul 2011 17:44:41 +0200 From: Berczi Gabor Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 6 Jul 2011 17:44:41 +0200 Message-Id: <12DA9EAC-8677-49AD-BA6C-5A155D2A6122@berczi.be> To: freebsd-current@freebsd.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: ZFS boot fails with two pools 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, 06 Jul 2011 15:44:43 -0000 Greets, For some reason FreeBSD can't boot automatically: ZFS: i/o error - all block copies unavailable ZFS: can't read MOS object directory Can't find root filesystem - giving up ZFS: unexpected object set type 0 ZFS: unexpected object set type 0 FreeBSD/x86 boot Default: data:/boot/kernel/kernel boot: ZFS: unexpected object set type 0 FreeBSD/x86 boot Default: data:/boot/kernel/kernel boot: I have two pools, pool2 which is a mirrored zpool, and data being a = raid-z pool. Note how the default should be "pool2:/boot/zfsloader". How = can I fix this? Thx. From owner-freebsd-current@FreeBSD.ORG Wed Jul 6 16:25:44 2011 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 5E0B5106566B for ; Wed, 6 Jul 2011 16:25:44 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 091888FC19 for ; Wed, 6 Jul 2011 16:25:43 +0000 (UTC) Received: by gwb15 with SMTP id 15so63480gwb.13 for ; Wed, 06 Jul 2011 09:25:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=wWI9eMscC1XLzrTPEmedbTrWNHA1CNtlfDAJNQPzrbQ=; b=h1/o7xStsfnSJM8cdvS/gBhdUyIRwAfBtskxuqJyAjpO5tlKYwYfaRvDOgKPa5xOrR yZ4xTvhHylGFz5yVwHceNN6BnWWF7armrtC9V756hUyzKgN4RFmx1GOS+caeJT+Uo5LQ 0cwvmnTXtZEJwohTbdqBhB/tgiwuSLcifVR/g= MIME-Version: 1.0 Received: by 10.150.179.2 with SMTP id b2mr7152186ybf.410.1309969543074; Wed, 06 Jul 2011 09:25:43 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.151.45.11 with HTTP; Wed, 6 Jul 2011 09:25:43 -0700 (PDT) In-Reply-To: <4E147F54.40908@zedat.fu-berlin.de> References: <4E1421D9.7080808@zedat.fu-berlin.de> <4E147F54.40908@zedat.fu-berlin.de> Date: Thu, 7 Jul 2011 00:25:43 +0800 X-Google-Sender-Auth: 8nObOuO4iMSAsoX23760fo-XSf8 Message-ID: From: Adrian Chadd To: "O. Hartmann" Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Current , arrowdodger <6yearold@gmail.com>, freebsd-questions@freebsd.org Subject: Re: Heavy I/O blocks FreeBSD box for several seconds 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, 06 Jul 2011 16:25:44 -0000 Has anyone re-run those IO benchmarks? Something smells fishy there.. (with the benchmarking.) adrian 2011/7/6 O. Hartmann : > On 07/06/11 12:37, arrowdodger wrote: >> >> 2011/7/6 O. Hartmann >> >>> When performing an update on the ports tree via "portsnap fetch update" >>> or >>> when checking out (or) large Subversion repositories or when copying >>> large >>> data files (~ 50 to 250 GB in size, results from numerical modelings) or >>> when compiling world, FreeBD 9.0 and FreeBSD 8.2-STABLE tend to "freeze" >>> for >>> several seconds or drop overall performance dramatically for seconds. On >>> boxes with only console- or terminal access (no GUI) a running 'vi' gets >>> stuck for seconds while one of the processes producing heavy I/O is >>> running, >>> or the output of a 'cat' of a large file stops for several seconds. >>> >>> Using X11, this phenomenon gets even worse and the 'freezing' tends to >>> persist sometimes for more than 10 or 15 seconds. >>> >> >> I've also had (and still having) this problem on FreeBSD 7.2-RELEASE and >> 8-STABLE with both UFS and ZFS. Though, i've been running FreeBSD not on >> powerful servers, but on laptops (2-core CPU's, 2 GB of RAM). But still, >> KDE4 on Linux performs much better during high disk IO. > > I read about issues with the old codebase of X11 in FreeBSD's ports used, > which could be the cause of some performance problems, but I wouldn't expect > those I/O-triggered blockings on boxes without any GUI. > > I saw Linux very often performing tremendously better when used as a > workstation or desktop, but this is often gained on the costs of other > subsystems. I followed a very hard-to-understand discussion about grouping > threads related to ttys which seems to get higher priorized in Linux to make > the GUI more fluent, but this is definitely on cost of other subsystems, > which in consequence gets less priorized. > But even without GUI, Linux seems to perform I/O much better on > multicore-/multiprocessor boxes than FreeBSD *.X and 9.X). > > Today I looked at some benchmarks performed by Phoronix/openbenchmark.org > (http://www.phoronix.com/scan.php?page=article&item=freebsd8_ubuntu910&num=9) > and it seems that threaded I/O is an issue in FreeBSD (compared to Linux). I > have no glue how to "tune" those bottlenecks away in FBSD. > > I use SCHED_ULE on all machines, since it is supposed to be performing > better on multicore boxes, but there are lots of suggestions switching back > to the old SCHED_4BSD scheduler. > > Oliver > > _______________________________________________ > 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 Wed Jul 6 16:28:12 2011 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 474CC1065675; Wed, 6 Jul 2011 16:28:12 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id 279F38FC1B; Wed, 6 Jul 2011 16:28:12 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.4/8.14.4) with ESMTP id p66GSBxi068608; Wed, 6 Jul 2011 09:28:11 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.4/8.14.4/Submit) id p66GSBCU068607; Wed, 6 Jul 2011 09:28:11 -0700 (PDT) (envelope-from sgk) Date: Wed, 6 Jul 2011 09:28:11 -0700 From: Steve Kargl To: "O. Hartmann" Message-ID: <20110706162811.GA68436@troutmask.apl.washington.edu> References: <4E1421D9.7080808@zedat.fu-berlin.de> <4E147F54.40908@zedat.fu-berlin.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E147F54.40908@zedat.fu-berlin.de> User-Agent: Mutt/1.4.2.3i Cc: FreeBSD Current , arrowdodger <6yearold@gmail.com>, freebsd-questions@freebsd.org Subject: Re: Heavy I/O blocks FreeBSD box for several seconds 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, 06 Jul 2011 16:28:12 -0000 On Wed, Jul 06, 2011 at 05:29:24PM +0200, O. Hartmann wrote: > > I use SCHED_ULE on all machines, since it is supposed to be performing > better on multicore boxes, but there are lots of suggestions switching > back to the old SCHED_4BSD scheduler. > If you are using MPI in numerical codes, then you want to use SCHED_4BSD. I've posted numerous times about ULE and its very poor performance when using MPI. http://lists.freebsd.org/pipermail/freebsd-hackers/2008-October/026375.html -- Steve From owner-freebsd-current@FreeBSD.ORG Wed Jul 6 16:38:27 2011 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 F3A421065679; Wed, 6 Jul 2011 16:38:26 +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 AD7368FC1F; Wed, 6 Jul 2011 16:38:26 +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 <1QeV7J-00017N-Cf>; Wed, 06 Jul 2011 18:38:25 +0200 Received: from e178039240.adsl.alicedsl.de ([85.178.39.240] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1QeV7J-0003jY-8v>; Wed, 06 Jul 2011 18:38:25 +0200 Message-ID: <4E148F7F.5020209@zedat.fu-berlin.de> Date: Wed, 06 Jul 2011 18:38:23 +0200 From: "Hartmann, O." User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110630 Thunderbird/5.0 MIME-Version: 1.0 To: Steve Kargl References: <4E1421D9.7080808@zedat.fu-berlin.de> <4E147F54.40908@zedat.fu-berlin.de> <20110706162811.GA68436@troutmask.apl.washington.edu> In-Reply-To: <20110706162811.GA68436@troutmask.apl.washington.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.39.240 Cc: FreeBSD Current , arrowdodger <6yearold@gmail.com>, freebsd-questions@freebsd.org Subject: Re: Heavy I/O blocks FreeBSD box for several seconds 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, 06 Jul 2011 16:38:27 -0000 On 07/06/11 18:28, Steve Kargl wrote: > On Wed, Jul 06, 2011 at 05:29:24PM +0200, O. Hartmann wrote: >> I use SCHED_ULE on all machines, since it is supposed to be performing >> better on multicore boxes, but there are lots of suggestions switching >> back to the old SCHED_4BSD scheduler. >> > If you are using MPI in numerical codes, then you want > to use SCHED_4BSD. I've posted numerous times about ULE > and its very poor performance when using MPI. > > http://lists.freebsd.org/pipermail/freebsd-hackers/2008-October/026375.html > Worth a try, but most of my code I use is OpenMP, not MPI. The post is of 2008, that's three years ago and 9.0 is on the brink to become released ... From owner-freebsd-current@FreeBSD.ORG Wed Jul 6 17:01:33 2011 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 103B2106566C; Wed, 6 Jul 2011 17:01:33 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id E2C888FC08; Wed, 6 Jul 2011 17:01:32 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.4/8.14.4) with ESMTP id p66H1W9s068818; Wed, 6 Jul 2011 10:01:32 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.4/8.14.4/Submit) id p66H1Wgc068817; Wed, 6 Jul 2011 10:01:32 -0700 (PDT) (envelope-from sgk) Date: Wed, 6 Jul 2011 10:01:32 -0700 From: Steve Kargl To: "Hartmann, O." Message-ID: <20110706170132.GA68775@troutmask.apl.washington.edu> References: <4E1421D9.7080808@zedat.fu-berlin.de> <4E147F54.40908@zedat.fu-berlin.de> <20110706162811.GA68436@troutmask.apl.washington.edu> <4E148F7F.5020209@zedat.fu-berlin.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E148F7F.5020209@zedat.fu-berlin.de> User-Agent: Mutt/1.4.2.3i Cc: FreeBSD Current , arrowdodger <6yearold@gmail.com>, freebsd-questions@freebsd.org Subject: Re: Heavy I/O blocks FreeBSD box for several seconds 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, 06 Jul 2011 17:01:33 -0000 On Wed, Jul 06, 2011 at 06:38:23PM +0200, Hartmann, O. wrote: > On 07/06/11 18:28, Steve Kargl wrote: > >On Wed, Jul 06, 2011 at 05:29:24PM +0200, O. Hartmann wrote: > >>I use SCHED_ULE on all machines, since it is supposed to be performing > >>better on multicore boxes, but there are lots of suggestions switching > >>back to the old SCHED_4BSD scheduler. > >> > >If you are using MPI in numerical codes, then you want > >to use SCHED_4BSD. I've posted numerous times about ULE > >and its very poor performance when using MPI. > > > >http://lists.freebsd.org/pipermail/freebsd-hackers/2008-October/026375.html > > > > Worth a try, > but most of my code I use is OpenMP, not MPI. It may impact OpenMP. I don't have any OpenMP to test. But, if OpenMP is spawning as many or more threads than the number of available processors/cores, then I think you will have problems. > The post is of 2008, that's three years ago and 9.0 is on the brink to > become released ... I periodically ran the same type test in the 2008 post over the last three years. Nothing has changed. I even set up an account on one node in my cluster for jeffr to use. He was too busy to investigate at that time. -- Steve From owner-freebsd-current@FreeBSD.ORG Wed Jul 6 17:04:53 2011 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 CBF54106566C for ; Wed, 6 Jul 2011 17:04:53 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 911C88FC17 for ; Wed, 6 Jul 2011 17:04:53 +0000 (UTC) Received: by yxl31 with SMTP id 31so86463yxl.13 for ; Wed, 06 Jul 2011 10:04:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WVjKwPFr5LQf/Ljr7NoXVgFhffcwc9pzVJU+dK/Gukw=; b=Vjf4f5uAEZsyb4dqcKl/Jz+Upa+DObHW6ry5ft1OKZdMuihsVCMeAWkbuAsr/WPbe9 nhHGPJF/S3BvST/jHoVIppETzyOsRcJjxHtD60y9wnclm2ucLRBWpmtTVtZO4+xirlJC djcphdhE+LeIhXyoXRERL/nQbTs6O02ezJQes= MIME-Version: 1.0 Received: by 10.150.243.6 with SMTP id q6mr32911ybh.129.1309970418755; Wed, 06 Jul 2011 09:40:18 -0700 (PDT) Received: by 10.150.92.6 with HTTP; Wed, 6 Jul 2011 09:40:18 -0700 (PDT) In-Reply-To: <20110706091945.GA64202@freebsd.org> References: <20110706091945.GA64202@freebsd.org> Date: Wed, 6 Jul 2011 20:40:18 +0400 Message-ID: From: Sergey Kandaurov To: Alexander Best Content-Type: text/plain; charset=ISO-8859-1 Cc: current@freebsd.org Subject: Re: displaying thread id in top -H 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, 06 Jul 2011 17:04:53 -0000 On 6 July 2011 13:19, Alexander Best wrote: > hi there, > > any reason why bin/139389 hasn't been committed, yet? i think seeing the thread > id in top -H output is extremely useful! I think the main reason is that tid takes a log of space (6 digits + 2 spaces), and top already suffers from a lack of free columns. -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Wed Jul 6 17:05:45 2011 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 BC40E1065670 for ; Wed, 6 Jul 2011 17:05:45 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 776FE8FC12 for ; Wed, 6 Jul 2011 17:05:45 +0000 (UTC) Received: from critter.freebsd.dk (critter-phk.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id E6BA45E20; Wed, 6 Jul 2011 17:05:42 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.4/8.14.4) with ESMTP id p66H5fU9005081; Wed, 6 Jul 2011 17:05:42 GMT (envelope-from phk@critter.freebsd.dk) To: Steve Kargl From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 06 Jul 2011 10:01:32 MST." <20110706170132.GA68775@troutmask.apl.washington.edu> Content-Type: text/plain; charset=ISO-8859-1 Date: Wed, 06 Jul 2011 17:05:41 +0000 Message-ID: <5080.1309971941@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: FreeBSD Current , "Hartmann, O." , arrowdodger <6yearold@gmail.com>, freebsd-questions@freebsd.org Subject: Re: Heavy I/O blocks FreeBSD box for several seconds 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, 06 Jul 2011 17:05:45 -0000 In message <20110706170132.GA68775@troutmask.apl.washington.edu>, Steve Kargl w rites: >I periodically ran the same type test in the 2008 post over the >last three years. Nothing has changed. I even set up an account >on one node in my cluster for jeffr to use. He was too busy to >investigate at that time. Isn't this just the lemming-syncer hurling every dirty block over the cliff at the same time ? To find out: Run gstat and keep and eye on the leftmost column The road map for fixing that has been known for years... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Wed Jul 6 18:00:02 2011 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 3722E106564A; Wed, 6 Jul 2011 18:00:02 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id 174C98FC1F; Wed, 6 Jul 2011 18:00:02 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.4/8.14.4) with ESMTP id p66I01CY069240; Wed, 6 Jul 2011 11:00:01 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.4/8.14.4/Submit) id p66I01sb069239; Wed, 6 Jul 2011 11:00:01 -0700 (PDT) (envelope-from sgk) Date: Wed, 6 Jul 2011 11:00:01 -0700 From: Steve Kargl To: Poul-Henning Kamp Message-ID: <20110706180001.GA69157@troutmask.apl.washington.edu> References: <20110706170132.GA68775@troutmask.apl.washington.edu> <5080.1309971941@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5080.1309971941@critter.freebsd.dk> User-Agent: Mutt/1.4.2.3i Cc: FreeBSD Current , "Hartmann, O." , arrowdodger <6yearold@gmail.com>, freebsd-questions@freebsd.org Subject: Re: Heavy I/O blocks FreeBSD box for several seconds 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, 06 Jul 2011 18:00:02 -0000 On Wed, Jul 06, 2011 at 05:05:41PM +0000, Poul-Henning Kamp wrote: > In message <20110706170132.GA68775@troutmask.apl.washington.edu>, Steve Kargl w > rites: > > >I periodically ran the same type test in the 2008 post over the > >last three years. Nothing has changed. I even set up an account > >on one node in my cluster for jeffr to use. He was too busy to > >investigate at that time. > > Isn't this just the lemming-syncer hurling every dirty block over > the cliff at the same time ? I don't know the answer. Of course, having no experience in processing scheduling, I don't understand the question either ;-) AFAICT, it is a cpu affinity issue. If I launch n+1 MPI images on a system with n cpus/cores, then 2 (and sometimes 3) images are stuck on a cpu and those 2 (or 3) images ping-pong on that cpu. I recall trying to use renice(8) to force some load balancing, but vaguely remember that it did not help. > To find out: Run gstat and keep and eye on the leftmost column > > The road map for fixing that has been known for years... I'll keep this in mind, the next time I upgrade the cluster. It's currently running a Feb 10th vintage kernel, and is under fairly heavy use at the moment. -- Steve From owner-freebsd-current@FreeBSD.ORG Wed Jul 6 18:11:24 2011 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 0AC58106564A for ; Wed, 6 Jul 2011 18:11:24 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from mail.icecube.wisc.edu (trout.icecube.wisc.edu [128.104.255.119]) by mx1.freebsd.org (Postfix) with ESMTP id 9AE848FC14 for ; Wed, 6 Jul 2011 18:11:23 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.icecube.wisc.edu (Postfix) with ESMTP id B0F9358139; Wed, 6 Jul 2011 13:11:22 -0500 (CDT) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from mail.icecube.wisc.edu ([127.0.0.1]) by localhost (trout.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id X5dPG3QJKonj; Wed, 6 Jul 2011 13:11:22 -0500 (CDT) Received: from wanderer.tachypleus.net (i3-dhcp-172-16-223-128.icecube.wisc.edu [172.16.223.128]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 8FA315811D; Wed, 6 Jul 2011 13:11:22 -0500 (CDT) Message-ID: <4E14A54A.4050106@freebsd.org> Date: Wed, 06 Jul 2011 13:11:22 -0500 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.18) Gecko/20110624 Thunderbird/3.1.11 MIME-Version: 1.0 To: Steve Kargl References: <20110706170132.GA68775@troutmask.apl.washington.edu> <5080.1309971941@critter.freebsd.dk> <20110706180001.GA69157@troutmask.apl.washington.edu> In-Reply-To: <20110706180001.GA69157@troutmask.apl.washington.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Poul-Henning Kamp , FreeBSD Current , "Hartmann, O." , arrowdodger <6yearold@gmail.com>, freebsd-questions@freebsd.org Subject: Re: Heavy I/O blocks FreeBSD box for several seconds 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, 06 Jul 2011 18:11:24 -0000 On 07/06/11 13:00, Steve Kargl wrote: > On Wed, Jul 06, 2011 at 05:05:41PM +0000, Poul-Henning Kamp wrote: >> In message<20110706170132.GA68775@troutmask.apl.washington.edu>, Steve Kargl w >> rites: >> >>> I periodically ran the same type test in the 2008 post over the >>> last three years. Nothing has changed. I even set up an account >>> on one node in my cluster for jeffr to use. He was too busy to >>> investigate at that time. >> >> Isn't this just the lemming-syncer hurling every dirty block over >> the cliff at the same time ? > > I don't know the answer. Of course, having no experience in > processing scheduling, I don't understand the question either ;-) > > AFAICT, it is a cpu affinity issue. If I launch n+1 MPI images > on a system with n cpus/cores, then 2 (and sometimes 3) images > are stuck on a cpu and those 2 (or 3) images ping-pong on that > cpu. I recall trying to use renice(8) to force some load > balancing, but vaguely remember that it did not help. I've seen exactly this problem with multi-threaded math libraries, as well. Using parallel GotoBLAS on FreeBSD gives terrible performance because the threads keep migrating between CPUs, causing frequent cache misses. -Nathan From owner-freebsd-current@FreeBSD.ORG Wed Jul 6 18:36:07 2011 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 D1CA9106566C for ; Wed, 6 Jul 2011 18:36:07 +0000 (UTC) (envelope-from freebsd@berczi.be) Received: from macsec.hu (cl-23.bud-01.hu.sixxs.net [IPv6:2a01:368:e000:16::2]) by mx1.freebsd.org (Postfix) with ESMTP id 976B78FC19 for ; Wed, 6 Jul 2011 18:36:07 +0000 (UTC) Received: from [10.11.0.1] by macsec.hu with esmtp (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QeWxC-000EOP-DM; Wed, 06 Jul 2011 20:36:06 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Berczi Gabor In-Reply-To: <864o2z2wxi.fsf@gmail.com> Date: Wed, 6 Jul 2011 20:36:06 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <12DA9EAC-8677-49AD-BA6C-5A155D2A6122@berczi.be> <864o2z2wxi.fsf@gmail.com> To: freebsd-current@freebsd.org X-Mailer: Apple Mail (2.1084) Cc: Pan Tsu Subject: Re: ZFS boot fails with two pools 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, 06 Jul 2011 18:36:07 -0000 Thanks, but that did not help. On Jul 6, 2011, at 6:31 PM, Pan Tsu wrote: > If you're using gptzfsboot try tricking it by marking > partitions with `data' pool as freebsd-ufs, e.g. > > $ gpart modify -t freebsd-ufs -iY adX From owner-freebsd-current@FreeBSD.ORG Wed Jul 6 18:53:34 2011 Return-Path: Delivered-To: current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 4E3D11065672; Wed, 6 Jul 2011 18:53:34 +0000 (UTC) Date: Wed, 6 Jul 2011 18:53:34 +0000 From: Alexander Best To: Sergey Kandaurov Message-ID: <20110706185334.GA33031@freebsd.org> References: <20110706091945.GA64202@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: current@freebsd.org Subject: Re: displaying thread id in top -H 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, 06 Jul 2011 18:53:34 -0000 On Wed Jul 6 11, Sergey Kandaurov wrote: > On 6 July 2011 13:19, Alexander Best wrote: > > hi there, > > > > any reason why bin/139389 hasn't been committed, yet? i think seeing the thread > > id in top -H output is extremely useful! > > I think the main reason is that tid takes a log of space (6 digits + 2 spaces), > and top already suffers from a lack of free columns. ah i see. thanks for the info. i think i'll suspend or even close that PR then. cheers. alex > > -- > wbr, > pluknet From owner-freebsd-current@FreeBSD.ORG Wed Jul 6 19:18:36 2011 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 14C44106564A for ; Wed, 6 Jul 2011 19:18:36 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id D97E38FC1C for ; Wed, 6 Jul 2011 19:18:35 +0000 (UTC) Received: by pwi7 with SMTP id 7so175131pwi.13 for ; Wed, 06 Jul 2011 12:18:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=+NLBUqwjXrBnZSYeoXGQdLtf3ZkYyKFEU/GVbuye4TY=; b=qPvT83nmcgyjM6Xnxf65YcjeHtvx0CG1GzGx2kmInwkBXniwxcmpTXPMHruHKgFYGn z1F7iXG1jMtQFUCtKwN0ZNCrryXY0s9+jz1kcdMCqu5t7NnN/RUfJAblpR6JLXRMzaW0 OlsFkh2IbEzb3zb059xkW3rRxAidSkLKyykuc= MIME-Version: 1.0 Received: by 10.68.15.67 with SMTP id v3mr3198321pbc.5.1309979915391; Wed, 06 Jul 2011 12:18:35 -0700 (PDT) Received: by 10.68.64.200 with HTTP; Wed, 6 Jul 2011 12:18:35 -0700 (PDT) In-Reply-To: <20110706162811.GA68436@troutmask.apl.washington.edu> References: <4E1421D9.7080808@zedat.fu-berlin.de> <4E147F54.40908@zedat.fu-berlin.de> <20110706162811.GA68436@troutmask.apl.washington.edu> Date: Wed, 6 Jul 2011 15:18:35 -0400 Message-ID: From: Arnaud Lacombe To: Steve Kargl Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current , "O. Hartmann" , arrowdodger <6yearold@gmail.com>, freebsd-questions@freebsd.org Subject: Re: Heavy I/O blocks FreeBSD box for several seconds 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, 06 Jul 2011 19:18:36 -0000 Hi, On Wed, Jul 6, 2011 at 12:28 PM, Steve Kargl wrote: > On Wed, Jul 06, 2011 at 05:29:24PM +0200, O. Hartmann wrote: >> >> I use SCHED_ULE on all machines, since it is supposed to be performing >> better on multicore boxes, but there are lots of suggestions switching >> back to the old SCHED_4BSD scheduler. >> > > If you are using MPI in numerical codes, then you want > to use SCHED_4BSD. =A0I've posted numerous times about ULE > and its very poor performance when using MPI. > > http://lists.freebsd.org/pipermail/freebsd-hackers/2008-October/026375.ht= ml > [sarcasm] It is rather funny to see that the post you point out has generated exactly 0 meaningful follow-up then and as you mention later in this thread, the issue still remains today :-) [/sarcasm] - Arnaud From owner-freebsd-current@FreeBSD.ORG Wed Jul 6 19:36:37 2011 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 ED44B106566B; Wed, 6 Jul 2011 19:36:37 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id C906E8FC14; Wed, 6 Jul 2011 19:36:37 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.4/8.14.4) with ESMTP id p66Jabi4069729; Wed, 6 Jul 2011 12:36:37 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.4/8.14.4/Submit) id p66Jaa3d069728; Wed, 6 Jul 2011 12:36:36 -0700 (PDT) (envelope-from sgk) Date: Wed, 6 Jul 2011 12:36:36 -0700 From: Steve Kargl To: Arnaud Lacombe Message-ID: <20110706193636.GA69550@troutmask.apl.washington.edu> References: <4E1421D9.7080808@zedat.fu-berlin.de> <4E147F54.40908@zedat.fu-berlin.de> <20110706162811.GA68436@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: FreeBSD Current , "O. Hartmann" , arrowdodger <6yearold@gmail.com>, freebsd-questions@freebsd.org Subject: Re: Heavy I/O blocks FreeBSD box for several seconds 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, 06 Jul 2011 19:36:38 -0000 On Wed, Jul 06, 2011 at 03:18:35PM -0400, Arnaud Lacombe wrote: > Hi, > > On Wed, Jul 6, 2011 at 12:28 PM, Steve Kargl > wrote: > > On Wed, Jul 06, 2011 at 05:29:24PM +0200, O. Hartmann wrote: > >> > >> I use SCHED_ULE on all machines, since it is supposed to be performing > >> better on multicore boxes, but there are lots of suggestions switching > >> back to the old SCHED_4BSD scheduler. > >> > > > > If you are using MPI in numerical codes, then you want > > to use SCHED_4BSD. ?I've posted numerous times about ULE > > and its very poor performance when using MPI. > > > > http://lists.freebsd.org/pipermail/freebsd-hackers/2008-October/026375.html > > > [sarcasm] > It is rather funny to see that the post you point out has generated > exactly 0 meaningful follow-up then and as you mention later in this > thread, the issue still remains today :-) > [/sarcasm] > Apparently, you are privy to my private email exchanges with jeffr. I'm also not sure why you're being sarcastic here. The issue was and AFAIK still is a problem for anyone using FreeBSD in a HPC cluster. ULE simply performs worse than 4BSD. -- Steve From owner-freebsd-current@FreeBSD.ORG Wed Jul 6 19:47:30 2011 Return-Path: Delivered-To: current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 717C71065672; Wed, 6 Jul 2011 19:47:30 +0000 (UTC) Date: Wed, 6 Jul 2011 19:47:30 +0000 From: Alexander Best To: Sergey Kandaurov Message-ID: <20110706194730.GA39525@freebsd.org> References: <20110706091945.GA64202@freebsd.org> <20110706185334.GA33031@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110706185334.GA33031@freebsd.org> Cc: current@freebsd.org Subject: Re: displaying thread id in top -H 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, 06 Jul 2011 19:47:30 -0000 On Wed Jul 6 11, Alexander Best wrote: > On Wed Jul 6 11, Sergey Kandaurov wrote: > > On 6 July 2011 13:19, Alexander Best wrote: > > > hi there, > > > > > > any reason why bin/139389 hasn't been committed, yet? i think seeing the thread > > > id in top -H output is extremely useful! > > > > I think the main reason is that tid takes a log of space (6 digits + 2 spaces), > > and top already suffers from a lack of free columns. > > ah i see. thanks for the info. i think i'll suspend or even close that PR then. just seen that you're already taking care of it. ;) > > cheers. > alex > > > > > -- > > wbr, > > pluknet From owner-freebsd-current@FreeBSD.ORG Wed Jul 6 19:47:46 2011 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 8AC69106564A; Wed, 6 Jul 2011 19:47:46 +0000 (UTC) (envelope-from deeptech71@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3A3A18FC0C; Wed, 6 Jul 2011 19:47:45 +0000 (UTC) Received: by yxl31 with SMTP id 31so160673yxl.13 for ; Wed, 06 Jul 2011 12:47:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=S9UEnZmogMG+TWy1crpI9HjJSR21sJACp7IUcnHYI4M=; b=JoZPPueV4WIiu1msQfqGGUeaOA3Dl8DMgQsLkendZ0BVke9eC6OdZJJxVigQoh9+1r 7DjCMV/0CEvBmPFuvb1NI+jmNtkIk/x50xFt6WQmVKm53EZNtgKJqtfKfm+g1Q0o1kVc OiOjfaB3+Htk82070uXnuaDHdwLqbK9T+TCaw= MIME-Version: 1.0 Received: by 10.236.78.233 with SMTP id g69mr11468727yhe.298.1309981665332; Wed, 06 Jul 2011 12:47:45 -0700 (PDT) Received: by 10.236.203.6 with HTTP; Wed, 6 Jul 2011 12:47:45 -0700 (PDT) In-Reply-To: <44k4byunz2.fsf@lowell-desk.lan> References: <44k4byunz2.fsf@lowell-desk.lan> Date: Wed, 6 Jul 2011 21:47:45 +0200 Message-ID: From: "deeptech71@gmail.com" To: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Re: what is the RIGHT(TM) way to configure background DHCP? 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, 06 Jul 2011 19:47:46 -0000 (i intend the discussion to take place primarily on the freebsd-hackers list, i'm CCing the freebsd-current list for a reason stated below.) (original first post: http://lists.freebsd.org/pipermail/freebsd-questions/2011-June/231301.html) On Mon, Jul 4, 2011 at 4:20 PM, Lowell Gilbert wrote: > You might want to try rewording your question, because it didn't make > any sense the first time. very well. though the question should have made perfect sense the first time. > [All of your examples were commented out, so > it was no surprise that they didn't work.] i chose to use # characters to separate rc.conf snippets from the other sentences i wrote. though perhaps #s were an unfortunate choice, because a # has a comment-begins-here meaning in rc.conf. in any case, "attempt 1" and "attempt 2" didn't work, but "attempt 3" did work, and that rules out the use of # for comments in rc.conf. now i will use "===== rc.conf snippet begins =====" and "===== rc.conf snippet ends =====" instead of # characters. > I considered trying to use my chrystal ball to guess that you needed > "SYNCDHCP" in your interface config, but you had obviously read the > manual for rc.conf(5), so that seemed unlikely... and "SYNCDHCP" makes things even worse. (i have no idea what "SYNCDHCP" is supposed to do, but in my experience:) "SYNCDHCP" makes the boot process wait until DHCP server replies before proceeding. "SYNCDHCP" is actually almost the same as "DHCP", except that "SYNCDHCP" waits indefinitely, while "DHCP" waits for at most defaultroute_delay, and also, "DHCP" gets "Starting network: lo0 sk0. " printed *before* the IP address assignment process starts, while "SYNCDHCP" gets "Starting network: lo0 sk0. " printed *after* the IP address assignment process finishes. so here is the question rephrased: the boot process of my FreeBSD machines takes a relatively long time. it spends 30 seconds idling at some point, because my network interface (sk0) is supposed to have an IP address assigned via DHCP, and the DHCP server on my LAN takes an extremely long time (~40 seconds) to reply to IP address requests. this is unacceptable for me; i want the FreeBSD boot process to finish 30 seconds earlier, even if i won't get the chance to use the network for ~40 seconds after the booting has finished. this was the actual case when my rc.conf had the following options related to network interfaces: ===== rc.conf snippet begins ===== ifconfig_sk0="DHCP" ===== rc.conf snippet ends ===== it took me 3 rc.conf configuration attempts to find a configuration in which the boot process does not idle for 30 seconds. the following was the first attempt: ===== rc.conf snippet begins ===== background_dhclient="YES" background_dhclient_sk0="YES" ===== rc.conf snippet ends ===== with this configuration, the DHCP client isn't even started. ie., the boot process does not idle at all (that's good!), but the network interface will never receive an IP address automatically (that's very bad!). here is the second attempt: ===== rc.conf snippet begins ===== ifconfig_sk0="DHCP" background_dhclient="YES" background_dhclient_sk0="YES" ===== rc.conf snippet ends ===== with this configuration, the DHCP client is started, but the boot process still idles for 30 seconds at some point (as if the background_dhclient and background_dhclient_ variables had no effect). the final attempt is: ===== rc.conf snippet begins ===== ifconfig_sk0="DHCP" defaultroute_delay="0" ===== rc.conf snippet ends ===== this configuration works, ie., during the boot process, there is no idling related to waiting for a DHCP server to reply. but this configuration looks hacky. so what is the RIGHT(TM) way to configure the boot process not to idle much in case of a slow DHCP server, and why? i ask this question partially because there is an rc.conf option background_dhclient (also, background_dhclient_), which doesn't seem to do anything, though it should, since it exists (either that, or the option should be removed). (there has been a recent discussion on the freebsd-current list about rc.d parallelization; [reason for CCing:] could recent rc.d changes have made the background_dhclient option useless?) i'd like to have an in-depth explanation on what effect should any combination of the following options should have on the boot process: defaultroute_delay="0", background_dhclient="YES", synchronous_dhclient="YES". (for example, using both background_dhclient="YES" and synchronous_dhclient="YES" seems stupid; i need a clarification if that's not the case.) what's the explanation if there is more than 1 network card (all of which are to have IP addresses assigned via DHCP)? From owner-freebsd-current@FreeBSD.ORG Wed Jul 6 19:48:27 2011 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 442EB1065670 for ; Wed, 6 Jul 2011 19:48:27 +0000 (UTC) (envelope-from freebsd@berczi.be) Received: from macsec.hu (cl-23.bud-01.hu.sixxs.net [IPv6:2a01:368:e000:16::2]) by mx1.freebsd.org (Postfix) with ESMTP id 048028FC20 for ; Wed, 6 Jul 2011 19:48:27 +0000 (UTC) Received: from [10.11.0.1] by macsec.hu with esmtp (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QeY5B-000FAw-R4; Wed, 06 Jul 2011 21:48:26 +0200 Mime-Version: 1.0 (Apple Message framework v1084) From: Berczi Gabor In-Reply-To: <20110706224304.7fc1832d@desktop.pc> Date: Wed, 6 Jul 2011 21:48:24 +0200 Message-Id: <95C71897-BBC6-4429-82B0-07C68F0171A0@berczi.be> References: <12DA9EAC-8677-49AD-BA6C-5A155D2A6122@berczi.be> <20110706224304.7fc1832d@desktop.pc> To: Aldis Berjoza X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: ZFS boot fails with two pools 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, 06 Jul 2011 19:48:27 -0000 On Jul 6, 2011, at 9:43 PM, Aldis Berjoza wrote: > > Any chance, that you forgot to > # zpool set bootfs= ... > ? Nope. NAME PROPERTY VALUE SOURCE pool2 bootfs pool2 local NAME PROPERTY VALUE SOURCE data bootfs - default From owner-freebsd-current@FreeBSD.ORG Wed Jul 6 19:59:47 2011 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 8F49B106566B for ; Wed, 6 Jul 2011 19:59:47 +0000 (UTC) (envelope-from aldis@bsdroot.lv) Received: from smtp.bsdroot.lv (smtp.bsdroot.lv [83.241.11.135]) by mx1.freebsd.org (Postfix) with ESMTP id EAE158FC12 for ; Wed, 6 Jul 2011 19:59:46 +0000 (UTC) Received: from smtp.bsdroot.lv (root.bsdroot.lv [83.241.11.135]) by smtp.bsdroot.lv (Postfix) with ESMTP id 4D96C76DF4; Wed, 6 Jul 2011 22:43:02 +0300 (EEST) Received: from desktop.pc (mpe-11-155.mpe.lv [83.241.11.155]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.bsdroot.lv (Postfix) with ESMTPSA id 00B2476DF3; Wed, 6 Jul 2011 22:43:01 +0300 (EEST) Date: Wed, 6 Jul 2011 22:43:04 +0300 From: Aldis Berjoza To: Berczi Gabor Message-ID: <20110706224304.7fc1832d@desktop.pc> In-Reply-To: <12DA9EAC-8677-49AD-BA6C-5A155D2A6122@berczi.be> References: <12DA9EAC-8677-49AD-BA6C-5A155D2A6122@berczi.be> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.1; amd64-portbld-freebsd8.2) X-PGP-Key: 0xCCBA39FA X-PGP-Key-Fingerprint: 800C C77B A57E 98A0 821F 7D24 2AC0 DB19 CCBA 39FA X-PGP-PublicKey: http://files.bsdroot.lv/my/aldis_berjoza.asc Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/+SlfndRD3KQCAWZAO0oUS_o"; protocol="application/pgp-signature" X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-current@freebsd.org Subject: Re: ZFS boot fails with two pools 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, 06 Jul 2011 19:59:47 -0000 --Sig_/+SlfndRD3KQCAWZAO0oUS_o Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Wed, 6 Jul 2011 17:44:41 +0200 Berczi Gabor wrote: > Greets, >=20 > For some reason FreeBSD can't boot automatically: >=20 > ZFS: i/o error - all block copies unavailable > ZFS: can't read MOS object directory > Can't find root filesystem - giving up > ZFS: unexpected object set type 0 > ZFS: unexpected object set type 0 >=20 > FreeBSD/x86 boot > Default: data:/boot/kernel/kernel > boot: > ZFS: unexpected object set type 0 >=20 > FreeBSD/x86 boot > Default: data:/boot/kernel/kernel > boot: >=20 > I have two pools, pool2 which is a mirrored zpool, and data being a > raid-z pool. Note how the default should be "pool2:/boot/zfsloader". > How can I fix this? >=20 > Thx. >=20 Any chance, that you forgot to # zpool set bootfs=3D ... ? --=20 Aldis Berjoza http://www.bsdroot.lv/ --Sig_/+SlfndRD3KQCAWZAO0oUS_o Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iQEcBAEBAgAGBQJOFLrXAAoJECrA2xnMujn6+zkH+wSNbdAGAgIaSS+wEtXP3Pwb SmMIQXs2fqjuOI5FKUt3ZsQHElZuwRm7VEViVyz7hYpZgWnt5DrcFGEn91dWsCRq vQK7jk5GuvOa3akDrIx1EyrmmwndsuxqEyVElKT148ce6/Hm+bEo5wG8RW1S6F6k Ehfjv0uU8qydM5KWiu+m/d7GS7IsDug0hhUZ/PV6N5JHdDSRJxxChdCo1O0spNV2 JCo1zXZvz5Xf7C1PGYe38ylg26Vcj0HMjquGuSubGaI9Tz7efK5MEc4F7PPiAS7i gCsUCKKWOQmifw4fqW1Gi+qNjqdHzVQVWSKkIWJ73KNKbmER3ts/ngCZQH3s2NI= =tCo8 -----END PGP SIGNATURE----- --Sig_/+SlfndRD3KQCAWZAO0oUS_o-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 6 20:02:38 2011 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 591AE106566B; Wed, 6 Jul 2011 20:02:38 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id F1BF28FC13; Wed, 6 Jul 2011 20:02:37 +0000 (UTC) Received: by vxg33 with SMTP id 33so283558vxg.13 for ; Wed, 06 Jul 2011 13:02:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VRM9TyKj0tHdxSvPRWgtKeMdG/5PSY0QABr7c+voTtQ=; b=bvnCamJlti6WHtEfo5HS4fm73Q6194PU/LyUKO6hD3rkxoYzZ6N5Zf/tyovyA5ptwH YjbioyTbNGVqpyTIfbQy0gCObKsmkFEm5kyLjdnydnh+6yUHi1Id8Fb2hOdlsYzN4TJ9 rNLPy+EecD5T4SEL83fIGfFMAsabq3hrVdL2U= MIME-Version: 1.0 Received: by 10.220.7.79 with SMTP id c15mr810vcc.3.1309982556290; Wed, 06 Jul 2011 13:02:36 -0700 (PDT) Received: by 10.220.92.201 with HTTP; Wed, 6 Jul 2011 13:02:36 -0700 (PDT) In-Reply-To: References: <44k4byunz2.fsf@lowell-desk.lan> Date: Wed, 6 Jul 2011 13:02:36 -0700 Message-ID: From: Garrett Cooper To: "deeptech71@gmail.com" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: what is the RIGHT(TM) way to configure background DHCP? 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, 06 Jul 2011 20:02:38 -0000 On Wed, Jul 6, 2011 at 12:47 PM, deeptech71@gmail.com wrote: > (i intend the discussion to take place primarily on the > freebsd-hackers list, i'm CCing the freebsd-current list for a reason > stated below.) > > (original first post: > http://lists.freebsd.org/pipermail/freebsd-questions/2011-June/231301.html) > > On Mon, Jul 4, 2011 at 4:20 PM, Lowell Gilbert wrote: >> You might want to try rewording your question, because it didn't make >> any sense the first time. > > very well. though the question should have made perfect sense the first time. > >> [All of your examples were commented out, so >> it was no surprise that they didn't work.] > > i chose to use # characters to separate rc.conf snippets from the > other sentences i wrote. though perhaps #s were an unfortunate choice, > because a # has a comment-begins-here meaning in rc.conf. in any case, > "attempt 1" and "attempt 2" didn't work, but "attempt 3" did work, and > that rules out the use of # for comments in rc.conf. now i will use > "===== rc.conf snippet begins =====" and "===== rc.conf snippet ends > =====" instead of # characters. > >> I considered trying to use my chrystal ball to guess that you needed >> "SYNCDHCP" in your interface config, but you had obviously read the >> manual for rc.conf(5), so that seemed unlikely... > > and "SYNCDHCP" makes things even worse. (i have no idea what > "SYNCDHCP" is supposed to do, but in my experience:) "SYNCDHCP" makes > the boot process wait until DHCP server replies before proceeding. > "SYNCDHCP" is actually almost the same as "DHCP", except that > "SYNCDHCP" waits indefinitely, while "DHCP" waits for at most > defaultroute_delay, and also, "DHCP" gets "Starting network: lo0 sk0. > " printed *before* the IP address > assignment process starts, while "SYNCDHCP" gets "Starting network: > lo0 sk0. " printed *after* the IP > address assignment process finishes. > > so here is the question rephrased: > > the boot process of my FreeBSD machines takes a relatively long time. > it spends 30 seconds idling at some point, because my network > interface (sk0) is supposed to have an IP address assigned via DHCP, > and the DHCP server on my LAN takes an extremely long time (~40 > seconds) to reply to IP address requests. this is unacceptable for me; > i want the FreeBSD boot process to finish 30 seconds earlier, even if > i won't get the chance to use the network for ~40 seconds after the > booting has finished. > > this was the actual case when my rc.conf had the following options > related to network interfaces: > ===== rc.conf snippet begins ===== > ifconfig_sk0="DHCP" > ===== rc.conf snippet ends ===== > > it took me 3 rc.conf configuration attempts to find a configuration in > which the boot process does not idle for 30 seconds. > > the following was the first attempt: > ===== rc.conf snippet begins ===== > background_dhclient="YES" > background_dhclient_sk0="YES" > ===== rc.conf snippet ends ===== > with this configuration, the DHCP client isn't even started. ie., the > boot process does not idle at all (that's good!), but the network > interface will never receive an IP address automatically (that's very > bad!). > > here is the second attempt: > ===== rc.conf snippet begins ===== > ifconfig_sk0="DHCP" > background_dhclient="YES" > background_dhclient_sk0="YES" > ===== rc.conf snippet ends ===== > with this configuration, the DHCP client is started, but the boot > process still idles for 30 seconds at some point (as if the > background_dhclient and background_dhclient_ variables had no > effect). > > the final attempt is: > ===== rc.conf snippet begins ===== > ifconfig_sk0="DHCP" > defaultroute_delay="0" > ===== rc.conf snippet ends ===== > this configuration works, ie., during the boot process, there is no > idling related to waiting for a DHCP server to reply. but this > configuration looks hacky. > > so what is the RIGHT(TM) way to configure the boot process not to idle > much in case of a slow DHCP server, and why? > > i ask this question partially because there is an rc.conf option > background_dhclient (also, background_dhclient_), which doesn't > seem to do anything, though it should, since it exists (either that, > or the option should be removed). (there has been a recent discussion > on the freebsd-current list about rc.d parallelization; [reason for > CCing:] could recent rc.d changes have made the background_dhclient > option useless?) > > i'd like to have an in-depth explanation on what effect should any > combination of the following options should have on the boot process: > defaultroute_delay="0", background_dhclient="YES", > synchronous_dhclient="YES". (for example, using both > background_dhclient="YES" and synchronous_dhclient="YES" seems stupid; > i need a clarification if that's not the case.) what's the explanation > if there is more than 1 network card (all of which are to have IP > addresses assigned via DHCP)? Hi, You'll need ifconfig_sk0="DHCP" in order to get dhclient to work. Nothing more, nothing less. The rest of the variables just seem redundant to me (sans background_dhclient vs synchronous_dhclient, but it seems like that should be streamlined to one variable instead of being two anyhow as they're mutually exclusive options that should be fed into dhclient). I recommend bringing this up with rc@ because this is just inefficient and misleading. Look through /etc/network.subr // /etc/rc.d/dhclient if you're curious and capable of reading sh -- it's straightforward what's going on -- it's just that the method for doing it isn't clearcut and straightforward, and it looks like things need to be weedwacked a bit in that section of code. Thanks, -Garrett PS Please don't cross-post ;). From owner-freebsd-current@FreeBSD.ORG Wed Jul 6 20:09:02 2011 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 471E6106566B for ; Wed, 6 Jul 2011 20:09:02 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by mx1.freebsd.org (Postfix) with ESMTP id C88F78FC15 for ; Wed, 6 Jul 2011 20:09:01 +0000 (UTC) Received: by fxe6 with SMTP id 6so400834fxe.17 for ; Wed, 06 Jul 2011 13:09:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Mzucj3laDvlqVhlP1ryI2MDPossGpfL6r5NUDAvIgC8=; b=h5V1jpMiGhVl+dolYbHv2qsC7YFQ9wxOv2MIePkBorTvGjsLzalR2tIVulfzM6DRsm HN4OrKCtCVk7H7xDhHJ5+Mtjq9lo8UmmljGsBwSNo7jJIsB14ZR/hze5gwApqLG4NYJB Tjc28sUylq1txQwc2FDM8ApeW0pEfveQ2tNLQ= Received: by 10.223.16.136 with SMTP id o8mr13714794faa.21.1309982940794; Wed, 06 Jul 2011 13:09:00 -0700 (PDT) Received: from limbo.lan ([195.225.157.86]) by mx.google.com with ESMTPS id q14sm6253492faa.3.2011.07.06.13.08.58 (version=SSLv3 cipher=OTHER); Wed, 06 Jul 2011 13:08:59 -0700 (PDT) Message-ID: <4E14C0D9.9040503@gmail.com> Date: Wed, 06 Jul 2011 23:08:57 +0300 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:5.0) Gecko/20110702 Thunderbird/5.0 MIME-Version: 1.0 To: Berczi Gabor References: <12DA9EAC-8677-49AD-BA6C-5A155D2A6122@berczi.be> In-Reply-To: <12DA9EAC-8677-49AD-BA6C-5A155D2A6122@berczi.be> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: ZFS boot fails with two pools 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, 06 Jul 2011 20:09:02 -0000 06.07.2011 18:44, Berczi Gabor wrote: > Greets, > > For some reason FreeBSD can't boot automatically: > > ZFS: i/o error - all block copies unavailable > ZFS: can't read MOS object directory > Can't find root filesystem - giving up > ZFS: unexpected object set type 0 > ZFS: unexpected object set type 0 > > FreeBSD/x86 boot > Default: data:/boot/kernel/kernel > boot: > ZFS: unexpected object set type 0 > > FreeBSD/x86 boot > Default: data:/boot/kernel/kernel > boot: > > I have two pools, pool2 which is a mirrored zpool, and data being a raid-z pool. Note how the default should be "pool2:/boot/zfsloader". How can I fix this? 1. Check that pools have up-to-date boot code. 2. Try to convince bios to boot from the disk of pool2. 3. You can possibly try deploying /boot/boot0 MBR selector code over disks of data pool. Supplied boot0 code can be used to choose another disk to jump to it during boot process and will remember the last choice. -- Sphinx of black quartz judge my vow. From owner-freebsd-current@FreeBSD.ORG Wed Jul 6 21:00:23 2011 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 ED7DC106566C; Wed, 6 Jul 2011 21:00:23 +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 A5C4A8FC16; Wed, 6 Jul 2011 21:00:23 +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 <1QeZCo-0004VZ-18>; Wed, 06 Jul 2011 23:00:22 +0200 Received: from e178039240.adsl.alicedsl.de ([85.178.39.240] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1QeZCn-00026K-Tt>; Wed, 06 Jul 2011 23:00:22 +0200 Message-ID: <4E14CCE5.4050906@zedat.fu-berlin.de> Date: Wed, 06 Jul 2011 23:00:21 +0200 From: "Hartmann, O." User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110630 Thunderbird/5.0 MIME-Version: 1.0 To: Steve Kargl References: <4E1421D9.7080808@zedat.fu-berlin.de> <4E147F54.40908@zedat.fu-berlin.de> <20110706162811.GA68436@troutmask.apl.washington.edu> <20110706193636.GA69550@troutmask.apl.washington.edu> In-Reply-To: <20110706193636.GA69550@troutmask.apl.washington.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.39.240 Cc: FreeBSD Current , arrowdodger <6yearold@gmail.com>, Arnaud Lacombe , freebsd-questions@freebsd.org Subject: Re: Heavy I/O blocks FreeBSD box for several seconds 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, 06 Jul 2011 21:00:24 -0000 On 07/06/11 21:36, Steve Kargl wrote: > On Wed, Jul 06, 2011 at 03:18:35PM -0400, Arnaud Lacombe wrote: >> Hi, >> >> On Wed, Jul 6, 2011 at 12:28 PM, Steve Kargl >> wrote: >>> On Wed, Jul 06, 2011 at 05:29:24PM +0200, O. Hartmann wrote: >>>> I use SCHED_ULE on all machines, since it is supposed to be performing >>>> better on multicore boxes, but there are lots of suggestions switching >>>> back to the old SCHED_4BSD scheduler. >>>> >>> If you are using MPI in numerical codes, then you want >>> to use SCHED_4BSD. ?I've posted numerous times about ULE >>> and its very poor performance when using MPI. >>> >>> http://lists.freebsd.org/pipermail/freebsd-hackers/2008-October/026375.html >>> >> [sarcasm] >> It is rather funny to see that the post you point out has generated >> exactly 0 meaningful follow-up then and as you mention later in this >> thread, the issue still remains today :-) >> [/sarcasm] >> > Apparently, you are privy to my private email exchanges > with jeffr. > > I'm also not sure why you're being sarcastic here. The > issue was and AFAIK still is a problem for anyone using > FreeBSD in a HPC cluster. ULE simply performs worse than > 4BSD. > Well, I know only very little people using FreeBSD within a HPC cluster or even for scientific purposes, except myself and some people around here. From owner-freebsd-current@FreeBSD.ORG Wed Jul 6 21:11:17 2011 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 409411065672; Wed, 6 Jul 2011 21:11:17 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id F13EE8FC12; Wed, 6 Jul 2011 21:11:16 +0000 (UTC) Received: by iyb11 with SMTP id 11so402300iyb.13 for ; Wed, 06 Jul 2011 14:11:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=4n2QmDmTLnhcqQb8xQ1+IgGhrOeaRkAZj/tHKmVHedM=; b=xLiBDTWnlYg2vkDA2BNI7UeoNRoWqVSkACPYagPkejckOtked8tpKAe0/EGfUAk0uG uiExEc+/Mw0LbeyZU5b4QfgKOARcCdwlIYY6bAtnmdjCw0h6zjLSS0Hq7Nmz3oK3G1vY g3uG4AhSyLPMmJmq2Wgw05GEYXd2/rBPfErdo= Received: by 10.231.139.169 with SMTP id e41mr54387ibu.3.1309986676469; Wed, 06 Jul 2011 14:11:16 -0700 (PDT) Received: from sidhe.local ([75.101.87.90]) by mx.google.com with ESMTPS id my4sm5067476ibb.3.2011.07.06.14.11.11 (version=SSLv3 cipher=OTHER); Wed, 06 Jul 2011 14:11:12 -0700 (PDT) Message-ID: <4E14CF6C.4060104@gmail.com> Date: Wed, 06 Jul 2011 14:11:08 -0700 From: Matt User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.18) Gecko/20110624 Thunderbird/3.1.11 MIME-Version: 1.0 To: Jung-uk Kim , freebsd-current@freebsd.org References: <4E0B9E08.1090202@gmail.com> <4E0D4E37.3030105@gmail.com> <201107051352.29580.jkim@FreeBSD.org> <201107051448.47657.jkim@FreeBSD.org> In-Reply-To: <201107051448.47657.jkim@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Time keeping Issues with the low-resolution TSC timecounter 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, 06 Jul 2011 21:11:17 -0000 >> Hmm... GPF seems to be related to unclean %rcx. Can you please >> try the attached patch? Please note you have to rebuild kernel >> from scratch because this is a header file change. It may not fix >> "hang", though. Please let me know. > It is just committed at r223796. > > JK > This issue is resolved for me. Thanks Jung-uk! It's a far nicer fix than clobbering out TSC-low :). Matt From owner-freebsd-current@FreeBSD.ORG Wed Jul 6 21:20:35 2011 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 838BB106564A; Wed, 6 Jul 2011 21:20:35 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2CCC78FC12; Wed, 6 Jul 2011 21:20:34 +0000 (UTC) Received: by ywf7 with SMTP id 7so178391ywf.13 for ; Wed, 06 Jul 2011 14:20:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=81mb205TKuKWWVyA4HcldagJU8bhlumU0TQ+0I5foxU=; b=m2OX1XBouw1Uy/TJ9MLR8v+N5GqvFcdDh2zaaIYVdZ047J4L+cC9g1fxvVPdp6VoFn VzYoJahkWg8sYMtUplF2Q43D8fK8XfTxZZ62eWBOZqtRs8E0OXhlu7JIqMkXMEoMr6cT p74NvFRuvHsgwCicn2CChCE3mMvJwRIgiNdSo= MIME-Version: 1.0 Received: by 10.91.201.26 with SMTP id d26mr284873agq.97.1309985887388; Wed, 06 Jul 2011 13:58:07 -0700 (PDT) Received: by 10.90.15.24 with HTTP; Wed, 6 Jul 2011 13:58:07 -0700 (PDT) In-Reply-To: References: <44k4byunz2.fsf@lowell-desk.lan> Date: Wed, 6 Jul 2011 13:58:07 -0700 Message-ID: From: Freddie Cash To: "deeptech71@gmail.com" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: what is the RIGHT(TM) way to configure background DHCP? 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, 06 Jul 2011 21:20:35 -0000 On Wed, Jul 6, 2011 at 12:47 PM, deeptech71@gmail.com wrote: > the boot process of my FreeBSD machines takes a relatively long time. > it spends 30 seconds idling at some point, because my network > interface (sk0) is supposed to have an IP address assigned via DHCP, > and the DHCP server on my LAN takes an extremely long time (~40 > seconds) to reply to IP address requests. this is unacceptable for me; > i want the FreeBSD boot process to finish 30 seconds earlier, even if > i won't get the chance to use the network for ~40 seconds after the > booting has finished. > The simplest method would be to put into /etc/rc.conf: ifconfig_sk0="up" Then into /etc/rc.local: dhclient sk0 & That would bring your interface "up" during the boot process, then manually fire off dhclient once the normal boot process has ended (right before the login prompt appears) as a background process. By the time you login, the IP should be assigned. As for what's "the correct way" to do this via just rc.conf, I'll leave that up to others more "in the know" about how RC works. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-current@FreeBSD.ORG Wed Jul 6 22:13:21 2011 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 94AD2106566B; Wed, 6 Jul 2011 22:13:21 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 025EC8FC0A; Wed, 6 Jul 2011 22:13:20 +0000 (UTC) Received: by wyg24 with SMTP id 24so366252wyg.13 for ; Wed, 06 Jul 2011 15:13:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XY+VmAoMpY+1O8UkR/S28RxGOdNlEaBvSuOhmPwartU=; b=E6YxG2RT4AUrKkuNacez7AoSbYlLsoXPnKJxUu3kzT8ZWM6IshlC+cL2qpUZu5um0K L+N6ctlmDJaERYT5Paj3kZyICk/s+u/zNDCEiu+BcVBubgv1WL3DN0XTnk1nOVHThP0f VHdTSPsCEdRuoAKCTOhcNn1mgRlzLQQy2iOnM= MIME-Version: 1.0 Received: by 10.227.32.76 with SMTP id b12mr61518wbd.45.1309988997612; Wed, 06 Jul 2011 14:49:57 -0700 (PDT) Received: by 10.227.209.209 with HTTP; Wed, 6 Jul 2011 14:49:57 -0700 (PDT) In-Reply-To: <4E14CCE5.4050906@zedat.fu-berlin.de> References: <4E1421D9.7080808@zedat.fu-berlin.de> <4E147F54.40908@zedat.fu-berlin.de> <20110706162811.GA68436@troutmask.apl.washington.edu> <20110706193636.GA69550@troutmask.apl.washington.edu> <4E14CCE5.4050906@zedat.fu-berlin.de> Date: Wed, 6 Jul 2011 23:49:57 +0200 Message-ID: From: Oliver Pinter To: "Hartmann, O." Content-Type: text/plain; charset=ISO-8859-1 Cc: Arnaud Lacombe , FreeBSD Current , arrowdodger <6yearold@gmail.com>, Steve Kargl , freebsd-questions@freebsd.org Subject: Re: Heavy I/O blocks FreeBSD box for several seconds 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, 06 Jul 2011 22:13:21 -0000 On 7/6/11, Hartmann, O. wrote: > On 07/06/11 21:36, Steve Kargl wrote: >> On Wed, Jul 06, 2011 at 03:18:35PM -0400, Arnaud Lacombe wrote: >>> Hi, >>> >>> On Wed, Jul 6, 2011 at 12:28 PM, Steve Kargl >>> wrote: >>>> On Wed, Jul 06, 2011 at 05:29:24PM +0200, O. Hartmann wrote: >>>>> I use SCHED_ULE on all machines, since it is supposed to be performing >>>>> better on multicore boxes, but there are lots of suggestions switching >>>>> back to the old SCHED_4BSD scheduler. >>>>> >>>> If you are using MPI in numerical codes, then you want >>>> to use SCHED_4BSD. ?I've posted numerous times about ULE >>>> and its very poor performance when using MPI. >>>> >>>> http://lists.freebsd.org/pipermail/freebsd-hackers/2008-October/026375.html >>>> >>> [sarcasm] >>> It is rather funny to see that the post you point out has generated >>> exactly 0 meaningful follow-up then and as you mention later in this >>> thread, the issue still remains today :-) >>> [/sarcasm] >>> >> Apparently, you are privy to my private email exchanges >> with jeffr. >> >> I'm also not sure why you're being sarcastic here. The >> issue was and AFAIK still is a problem for anyone using >> FreeBSD in a HPC cluster. ULE simply performs worse than >> 4BSD. >> > Well, I know only very little people using FreeBSD within a HPC cluster > or even for scientific purposes, except myself and some people around here. > _______________________________________________ > 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" > http://lists.freebsd.org/pipermail/freebsd-stable/2010-September/thread.html#58537 From owner-freebsd-current@FreeBSD.ORG Wed Jul 6 23:57:34 2011 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 B302F1065672 for ; Wed, 6 Jul 2011 23:57:34 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id 7E2FE8FC14 for ; Wed, 6 Jul 2011 23:57:34 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.4/8.14.4) with ESMTP id p66NvYUd071344 for ; Wed, 6 Jul 2011 16:57:34 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.4/8.14.4/Submit) id p66NvYZK071343 for freebsd-current@freebsd.org; Wed, 6 Jul 2011 16:57:34 -0700 (PDT) (envelope-from sgk) Date: Wed, 6 Jul 2011 16:57:34 -0700 From: Steve Kargl To: freebsd-current@freebsd.org Message-ID: <20110706235733.GA71278@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: Can options NFSD and NFSSERVER exist in the same kernel? 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, 06 Jul 2011 23:57:34 -0000 So, I upgraded a system from Feb 10 -current to today's -current code. In doing so, I changed the kernel config options from options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server to options NFSCL # Network Filesystem Client options NFSD # Network Filesystem Server rebuild and install the kernel. Upon rebooting, I'm greeted with a Jul 6 16:09:41 node16 root: /etc/rc: WARNING: Unable to load kernel module nfsserver Of course, it can't load nfsserver because I don't use modules nor build them. So, why is the system trying to load a nfsserver module? Because, my /etc/rc.conf contains nfs_client_enable="YES" nfs_server_enable="YES" if I change this to nfs_client_enable="YES" nfsv4_server_enable="YES" The system no longer tries to load nfsserver upon rebooting. Unfortunately, this has the effect that no nfsd daemons are started. Well, I can start the daemons post-booting. node16:root[139] /etc/rc.d/nfsd start Cannot 'start' nfsd. Set nfs_server_enable to YES in /etc/rc.conf or use 'onestart' instead of 'start'. Whoops. -- Steve From owner-freebsd-current@FreeBSD.ORG Thu Jul 7 00:02:39 2011 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 D79D11065688 for ; Thu, 7 Jul 2011 00:02:39 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9131B8FC19 for ; Thu, 7 Jul 2011 00:02:38 +0000 (UTC) Received: by vws18 with SMTP id 18so492897vws.13 for ; Wed, 06 Jul 2011 17:02:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=K2NKZhmwEO4lDeAvgqmrSlBtrWMFI7dJ4UXVOJKyHSM=; b=axRJZRwpr6o3Tsa6aPYKd8aHbm8MPxjVgRW69U06qvEnQeI+YGY+vcmad1K99GtR0l leker/klbGL99UEzV1zv6D61jnI0lB4zKNMLmGthesidwYn5FJO+NDyUj/0jgxdQbLd8 iYeEpHFPBrZf6C/2KemsYeLO9qt2gxWMPamgA= MIME-Version: 1.0 Received: by 10.220.59.193 with SMTP id m1mr74037vch.38.1309996957706; Wed, 06 Jul 2011 17:02:37 -0700 (PDT) Received: by 10.220.92.201 with HTTP; Wed, 6 Jul 2011 17:02:37 -0700 (PDT) In-Reply-To: <20110706235733.GA71278@troutmask.apl.washington.edu> References: <20110706235733.GA71278@troutmask.apl.washington.edu> Date: Wed, 6 Jul 2011 17:02:37 -0700 Message-ID: From: Garrett Cooper To: Steve Kargl Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: Can options NFSD and NFSSERVER exist in the same kernel? 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, 07 Jul 2011 00:02:39 -0000 On Wed, Jul 6, 2011 at 4:57 PM, Steve Kargl wrote: > So, I upgraded a system from Feb 10 -current to today's > -current code. =A0In doing so, I changed the kernel config > options from > > options =A0 =A0 =A0 =A0 NFSCLIENT =A0 =A0 =A0 =A0 =A0 =A0 =A0 # Network F= ilesystem Client > options =A0 =A0 =A0 =A0 NFSSERVER =A0 =A0 =A0 =A0 =A0 =A0 =A0 # Network F= ilesystem Server > > to > > options =A0 =A0 =A0 =A0 NFSCL =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# Network Fi= lesystem Client > options =A0 =A0 =A0 =A0 NFSD =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # Network Fi= lesystem Server > > rebuild and install the kernel. =A0Upon rebooting, I'm greeted > with a > > Jul =A06 16:09:41 node16 root: /etc/rc: WARNING: Unable to load > kernel module nfsserver > > Of course, it can't load nfsserver because I don't use modules > nor build them. =A0So, why is the system trying to load a nfsserver > module? =A0Because, my /etc/rc.conf contains > > nfs_client_enable=3D"YES" > nfs_server_enable=3D"YES" > > if I change this to > > nfs_client_enable=3D"YES" > nfsv4_server_enable=3D"YES" > > The system no longer tries to load nfsserver upon rebooting. > Unfortunately, this has the effect that no nfsd daemons are > started. =A0Well, I can start the daemons post-booting. > > node16:root[139] /etc/rc.d/nfsd start > Cannot 'start' nfsd. Set nfs_server_enable to YES in /etc/rc.conf or use = 'onestart' instead of 'start'. Try nfsserver instead of nfsd. Here's the archived discussion of my foray into this territory a few months ago: http://www.mailinglistarchive.com/html/freebsd-current@freebsd.org/2011-05/= msg00008.html . Cheers! -Garrett From owner-freebsd-current@FreeBSD.ORG Thu Jul 7 00:14:11 2011 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 F35F7106566C for ; Thu, 7 Jul 2011 00:14:11 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id CF87A8FC12 for ; Thu, 7 Jul 2011 00:14:11 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.4/8.14.4) with ESMTP id p670EBVo071476; Wed, 6 Jul 2011 17:14:11 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.4/8.14.4/Submit) id p670EB0U071475; Wed, 6 Jul 2011 17:14:11 -0700 (PDT) (envelope-from sgk) Date: Wed, 6 Jul 2011 17:14:11 -0700 From: Steve Kargl To: Garrett Cooper Message-ID: <20110707001411.GA71351@troutmask.apl.washington.edu> References: <20110706235733.GA71278@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: Can options NFSD and NFSSERVER exist in the same kernel? 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, 07 Jul 2011 00:14:12 -0000 On Wed, Jul 06, 2011 at 05:02:37PM -0700, Garrett Cooper wrote: > On Wed, Jul 6, 2011 at 4:57 PM, Steve Kargl > wrote: > > So, I upgraded a system from Feb 10 -current to today's > > -current code. ?In doing so, I changed the kernel config > > options from > > > > options ? ? ? ? NFSCLIENT ? ? ? ? ? ? ? # Network Filesystem Client > > options ? ? ? ? NFSSERVER ? ? ? ? ? ? ? # Network Filesystem Server > > > > to > > > > options ? ? ? ? NFSCL ? ? ? ? ? ? ? ?# Network Filesystem Client > > options ? ? ? ? NFSD ? ? ? ? ? ? ? ? # Network Filesystem Server > > > > rebuild and install the kernel. ?Upon rebooting, I'm greeted > > with a > > > > Jul ?6 16:09:41 node16 root: /etc/rc: WARNING: Unable to load > > kernel module nfsserver > > > > Of course, it can't load nfsserver because I don't use modules > > nor build them. ?So, why is the system trying to load a nfsserver > > module? ?Because, my /etc/rc.conf contains > > > > nfs_client_enable="YES" > > nfs_server_enable="YES" > > > > if I change this to > > > > nfs_client_enable="YES" > > nfsv4_server_enable="YES" > > > > The system no longer tries to load nfsserver upon rebooting. > > Unfortunately, this has the effect that no nfsd daemons are > > started. ?Well, I can start the daemons post-booting. > > > > node16:root[139] /etc/rc.d/nfsd start > > Cannot 'start' nfsd. Set nfs_server_enable to YES in /etc/rc.conf or use 'onestart' instead of 'start'. > > Try nfsserver instead of nfsd. Here's the archived discussion of > my foray into this territory a few months ago: > http://www.mailinglistarchive.com/html/freebsd-current@freebsd.org/2011-05/msg00008.html > . Thanks for the pointer. Note, the 20110427 src/UPDATING entry indicates the NFSSERVER has been changed to NFSD in GENERIC. It seems that one needs to have both nfs_server_enable and nfsv4_server_enable set to "YES" in rc.conf to get nfsd daemons started. This is POLA violation for anyone upgrading from pre-20110427 -current and carrying over their old /etc/rc.conf. -- Steve From owner-freebsd-current@FreeBSD.ORG Thu Jul 7 00:57:55 2011 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 304B61065672 for ; Thu, 7 Jul 2011 00:57:55 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id E83D58FC12 for ; Thu, 7 Jul 2011 00:57:54 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAEUDFU6DaFvO/2dsb2JhbABTEIQypES7HJBogSuDf4ENBJJBkAZT X-IronPort-AV: E=Sophos;i="4.65,490,1304308800"; d="scan'208";a="126287930" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 06 Jul 2011 20:57:53 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 015A7B3F0F; Wed, 6 Jul 2011 20:57:54 -0400 (EDT) Date: Wed, 6 Jul 2011 20:57:53 -0400 (EDT) From: Rick Macklem To: Steve Kargl Message-ID: <167246498.291336.1310000273959.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20110706235733.GA71278@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE7 (Win)/6.0.10_GA_2692) Cc: freebsd-current@freebsd.org Subject: Re: Can options NFSD and NFSSERVER exist in the same kernel? 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, 07 Jul 2011 00:57:55 -0000 Steve Kargl wrote: > So, I upgraded a system from Feb 10 -current to today's > -current code. In doing so, I changed the kernel config > options from > > options NFSCLIENT # Network Filesystem Client > options NFSSERVER # Network Filesystem Server > > to > > options NFSCL # Network Filesystem Client > options NFSD # Network Filesystem Server > > rebuild and install the kernel. Upon rebooting, I'm greeted > with a > > Jul 6 16:09:41 node16 root: /etc/rc: WARNING: Unable to load > kernel module nfsserver > > Of course, it can't load nfsserver because I don't use modules > nor build them. So, why is the system trying to load a nfsserver > module? Because, my /etc/rc.conf contains > > nfs_client_enable="YES" > nfs_server_enable="YES" > > if I change this to > > nfs_client_enable="YES" > nfsv4_server_enable="YES" > > The system no longer tries to load nfsserver upon rebooting. > Unfortunately, this has the effect that no nfsd daemons are > started. Well, I can start the daemons post-booting. > > node16:root[139] /etc/rc.d/nfsd start > Cannot 'start' nfsd. Set nfs_server_enable to YES in /etc/rc.conf or > use 'onestart' instead of 'start'. > Assuming you've upgraded your /etc/rc.d scripts to those in head, then try deleting /etc/rc.d/nfsserver. (This script just tries to load the old server even though you don't need it unless you want to run the old one.) Or you can build a kernel with both options NFSD options NFSSERVER to make it happy. I'll try posting to rc@ to see if I can get rid of /etc/rc.d/nfsserver. Thanks for pointing this out. I had forgotten about deleting this (and was until recently confused about when obsolete files get deleted). If you still have problems after deleting /etc/rc.d/nfsserver (assuming your /etc/rc.d scripts are up-to-date), please let me know. rick From owner-freebsd-current@FreeBSD.ORG Thu Jul 7 01:07:48 2011 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 4CBAC106566B for ; Thu, 7 Jul 2011 01:07:48 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 071118FC0A for ; Thu, 7 Jul 2011 01:07:47 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAKEFFU6DaFvO/2dsb2JhbABTEIQypEa7E5BogSuDf4ENBJJBkAZT X-IronPort-AV: E=Sophos;i="4.65,490,1304308800"; d="scan'208";a="126288781" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 06 Jul 2011 21:07:47 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 0CCC8B3F2B; Wed, 6 Jul 2011 21:07:47 -0400 (EDT) Date: Wed, 6 Jul 2011 21:07:46 -0400 (EDT) From: Rick Macklem To: Steve Kargl Message-ID: <455800269.291497.1310000866965.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20110707001411.GA71351@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE7 (Win)/6.0.10_GA_2692) Cc: Garrett Cooper , freebsd-current@freebsd.org Subject: Re: Can options NFSD and NFSSERVER exist in the same kernel? 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, 07 Jul 2011 01:07:48 -0000 Steve Kargl wrote: > On Wed, Jul 06, 2011 at 05:02:37PM -0700, Garrett Cooper wrote: > > On Wed, Jul 6, 2011 at 4:57 PM, Steve Kargl > > wrote: > > > So, I upgraded a system from Feb 10 -current to today's > > > -current code. ?In doing so, I changed the kernel config > > > options from > > > > > > options ? ? ? ? NFSCLIENT ? ? ? ? ? ? ? # Network Filesystem > > > Client > > > options ? ? ? ? NFSSERVER ? ? ? ? ? ? ? # Network Filesystem > > > Server > > > > > > to > > > > > > options ? ? ? ? NFSCL ? ? ? ? ? ? ? ?# Network Filesystem Client > > > options ? ? ? ? NFSD ? ? ? ? ? ? ? ? # Network Filesystem Server > > > > > > rebuild and install the kernel. ?Upon rebooting, I'm greeted > > > with a > > > > > > Jul ?6 16:09:41 node16 root: /etc/rc: WARNING: Unable to load > > > kernel module nfsserver > > > > > > Of course, it can't load nfsserver because I don't use modules > > > nor build them. ?So, why is the system trying to load a nfsserver > > > module? ?Because, my /etc/rc.conf contains > > > > > > nfs_client_enable="YES" > > > nfs_server_enable="YES" > > > > > > if I change this to > > > > > > nfs_client_enable="YES" > > > nfsv4_server_enable="YES" > > > > > > The system no longer tries to load nfsserver upon rebooting. > > > Unfortunately, this has the effect that no nfsd daemons are > > > started. ?Well, I can start the daemons post-booting. > > > > > > node16:root[139] /etc/rc.d/nfsd start > > > Cannot 'start' nfsd. Set nfs_server_enable to YES in /etc/rc.conf > > > or use 'onestart' instead of 'start'. > > > > Try nfsserver instead of nfsd. Here's the archived discussion of > > my foray into this territory a few months ago: > > http://www.mailinglistarchive.com/html/freebsd-current@freebsd.org/2011-05/msg00008.html > > . > > Thanks for the pointer. > > Note, the 20110427 src/UPDATING entry indicates the NFSSERVER has > been changed to NFSD in GENERIC. It seems that one needs to have > both nfs_server_enable and nfsv4_server_enable set to "YES" in > rc.conf to get nfsd daemons started. This is POLA violation for > anyone upgrading from pre-20110427 -current and carrying over > their old /etc/rc.conf. > With -current /etc/rc.d/nfsd and /etc/rc.d/mountd, you shouldn't need to set nfsv4_server_enable="YES". The latter is only needed if you want to support NFSv4. I agree that /etc/rc.d/nfsserver will still try to load the old nfs server if it isn't built into the kernel and I'll look at getting rid of it. I was also trying to minimize the churn in head in case it was necessary to revert the change in default. I'm not sure that an upgrade that doesn't include building and installing new modules can be expected to work correctly when taken off of head when headed (no pun intended) into a major release. However, it is good that you reported this, so the /etc/rc.d/nfsserver issue can get resolved. rick From owner-freebsd-current@FreeBSD.ORG Thu Jul 7 01:17:53 2011 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 5B392106566B; Thu, 7 Jul 2011 01:17:53 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 042418FC12; Thu, 7 Jul 2011 01:17:52 +0000 (UTC) Received: by yxl31 with SMTP id 31so267877yxl.13 for ; Wed, 06 Jul 2011 18:17:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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=E9XOMdszKKqzGK1cYgELmkkcyQ8dYw5WfyPvaQqN5Ac=; b=ay/AoGRovVGYdFiDsXbpGfaTLQhBVId3nyN2nSfrMvW5VGp1KgwMFNB4QRsZYVcMlx irdLZ1qCeMzOJYPP+4zJqEycjOQjVJc4y6lwpngWwSGs1dSypbNpyjpgCUltEByqk/xF LFmY0Ov9Z5IQoQ2nJKrTx0Act3beit73p0TFA= MIME-Version: 1.0 Received: by 10.151.50.15 with SMTP id c15mr422480ybk.285.1310001471988; Wed, 06 Jul 2011 18:17:51 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.151.45.11 with HTTP; Wed, 6 Jul 2011 18:17:51 -0700 (PDT) In-Reply-To: <4E14CCE5.4050906@zedat.fu-berlin.de> References: <4E1421D9.7080808@zedat.fu-berlin.de> <4E147F54.40908@zedat.fu-berlin.de> <20110706162811.GA68436@troutmask.apl.washington.edu> <20110706193636.GA69550@troutmask.apl.washington.edu> <4E14CCE5.4050906@zedat.fu-berlin.de> Date: Thu, 7 Jul 2011 09:17:51 +0800 X-Google-Sender-Auth: EVssv602mp82_wZrdzCfA3SfsQU Message-ID: From: Adrian Chadd To: "Hartmann, O." Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Arnaud Lacombe , FreeBSD Current , arrowdodger <6yearold@gmail.com>, Steve Kargl , freebsd-questions@freebsd.org Subject: Re: Heavy I/O blocks FreeBSD box for several seconds 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, 07 Jul 2011 01:17:53 -0000 Offer a bounty for getting it fixed? thanks, Adrian On 7 July 2011 05:00, Hartmann, O. wrote: > On 07/06/11 21:36, Steve Kargl wrote: >> >> On Wed, Jul 06, 2011 at 03:18:35PM -0400, Arnaud Lacombe wrote: >>> >>> Hi, >>> >>> On Wed, Jul 6, 2011 at 12:28 PM, Steve Kargl >>> =A0wrote: >>>> >>>> On Wed, Jul 06, 2011 at 05:29:24PM +0200, O. Hartmann wrote: >>>>> >>>>> I use SCHED_ULE on all machines, since it is supposed to be performin= g >>>>> better on multicore boxes, but there are lots of suggestions switchin= g >>>>> back to the old SCHED_4BSD scheduler. >>>>> >>>> If you are using MPI in numerical codes, then you want >>>> to use SCHED_4BSD. ?I've posted numerous times about ULE >>>> and its very poor performance when using MPI. >>>> >>>> >>>> http://lists.freebsd.org/pipermail/freebsd-hackers/2008-October/026375= .html >>>> >>> [sarcasm] >>> It is rather funny to see that the post you point out has generated >>> exactly 0 meaningful follow-up then and as you mention later in this >>> thread, the issue still remains today :-) >>> [/sarcasm] >>> >> Apparently, you are privy to my private email exchanges >> with jeffr. >> >> I'm also not sure why you're being sarcastic here. =A0The >> issue was and AFAIK still is a problem for anyone using >> FreeBSD in a HPC cluster. =A0ULE simply performs worse than >> 4BSD. >> > Well, I know only very little people using FreeBSD within a HPC cluster o= r > even for scientific purposes, except myself and some people around here. > _______________________________________________ > 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 Thu Jul 7 01:33:22 2011 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 67784106566C for ; Thu, 7 Jul 2011 01:33:22 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 1EF368FC17 for ; Thu, 7 Jul 2011 01:33:21 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAHoLFU6DaFvO/2dsb2JhbABTEIQypEa7E5BmhSqBDQSSQZAGUw X-IronPort-AV: E=Sophos;i="4.65,490,1304308800"; d="scan'208";a="126291443" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 06 Jul 2011 21:33:21 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 372E9B3F34; Wed, 6 Jul 2011 21:33:21 -0400 (EDT) Date: Wed, 6 Jul 2011 21:33:21 -0400 (EDT) From: Rick Macklem To: Steve Kargl Message-ID: <178783682.291966.1310002401214.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <1978167896.291961.1310002395874.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_291965_1893481225.1310002401212" X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE7 (Win)/6.0.10_GA_2692) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD-Current Subject: Re: Can options NFSD and NFSSERVER exist in the same kernel 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, 07 Jul 2011 01:33:22 -0000 ------=_Part_291965_1893481225.1310002401212 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Although deleting /etc/rc.d/nfsserver is probably all you need to do if you have head/etc/rc.d/nfsd, I've attached an updated nfsd script that I am waiting for a review of. If you'd like to test this (when /etc/rc.d/nfsserver is deleted), it would be appreciated. I think it will work for your case, rick ------=_Part_291965_1893481225.1310002401212-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 7 01:48:06 2011 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 D4504106566B for ; Thu, 7 Jul 2011 01:48:06 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id B07BA8FC12 for ; Thu, 7 Jul 2011 01:48:06 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.4/8.14.4) with ESMTP id p671m66w071995; Wed, 6 Jul 2011 18:48:06 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.4/8.14.4/Submit) id p671m6PU071994; Wed, 6 Jul 2011 18:48:06 -0700 (PDT) (envelope-from sgk) Date: Wed, 6 Jul 2011 18:48:06 -0700 From: Steve Kargl To: Rick Macklem Message-ID: <20110707014806.GA71966@troutmask.apl.washington.edu> References: <20110706235733.GA71278@troutmask.apl.washington.edu> <167246498.291336.1310000273959.JavaMail.root@erie.cs.uoguelph.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <167246498.291336.1310000273959.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: Can options NFSD and NFSSERVER exist in the same kernel? 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, 07 Jul 2011 01:48:06 -0000 On Wed, Jul 06, 2011 at 08:57:53PM -0400, Rick Macklem wrote: > Steve Kargl wrote: > > So, I upgraded a system from Feb 10 -current to today's > > -current code. In doing so, I changed the kernel config > > options from > > > > options NFSCLIENT # Network Filesystem Client > > options NFSSERVER # Network Filesystem Server > > > > to > > > > options NFSCL # Network Filesystem Client > > options NFSD # Network Filesystem Server > > > > rebuild and install the kernel. Upon rebooting, I'm greeted > > with a > > > > Jul 6 16:09:41 node16 root: /etc/rc: WARNING: Unable to load > > kernel module nfsserver > > > > Of course, it can't load nfsserver because I don't use modules > > nor build them. So, why is the system trying to load a nfsserver > > module? Because, my /etc/rc.conf contains > > > > nfs_client_enable="YES" > > nfs_server_enable="YES" > > > > if I change this to > > > > nfs_client_enable="YES" > > nfsv4_server_enable="YES" > > > > The system no longer tries to load nfsserver upon rebooting. > > Unfortunately, this has the effect that no nfsd daemons are > > started. Well, I can start the daemons post-booting. > > > > node16:root[139] /etc/rc.d/nfsd start > > Cannot 'start' nfsd. Set nfs_server_enable to YES in /etc/rc.conf or > > use 'onestart' instead of 'start'. > > > Assuming you've upgraded your /etc/rc.d scripts to those in head, then > try deleting /etc/rc.d/nfsserver. (This script just tries to load the > old server even though you don't need it unless you want to run the old > one.) > > Or you can build a kernel with both > options NFSD > options NFSSERVER > to make it happy. Thanks for the quick response. I was not sure if these could co-exist in a kernel. Good know that they can. I found that if I include both nfs_server_enable="YES" nfsv4_server_enable="YES" I everything (obviously) works as expected. Perhaps, updating the UPDATING entry that notes that OPTIONS NFSD is now in generic is enough. > I'll try posting to rc@ to see if I can get rid of /etc/rc.d/nfsserver. > > Thanks for pointing this out. I had forgotten about deleting this (and > was until recently confused about when obsolete files get deleted). > > If you still have problems after deleting /etc/rc.d/nfsserver (assuming > your /etc/rc.d scripts are up-to-date), please let me know. I'll try deleting nfsserver tomorrow morning. PS: My intentions are to run your new server (and client) on my cluster to see if I can break them. Why else run -current? :-) -- Steve From owner-freebsd-current@FreeBSD.ORG Thu Jul 7 01:51:51 2011 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 7FE4C1065673; Thu, 7 Jul 2011 01:51:51 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id 5A27F8FC13; Thu, 7 Jul 2011 01:51:51 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.4/8.14.4) with ESMTP id p671ppfF072019; Wed, 6 Jul 2011 18:51:51 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.4/8.14.4/Submit) id p671ppc6072018; Wed, 6 Jul 2011 18:51:51 -0700 (PDT) (envelope-from sgk) Date: Wed, 6 Jul 2011 18:51:51 -0700 From: Steve Kargl To: Adrian Chadd Message-ID: <20110707015151.GB71966@troutmask.apl.washington.edu> References: <4E1421D9.7080808@zedat.fu-berlin.de> <4E147F54.40908@zedat.fu-berlin.de> <20110706162811.GA68436@troutmask.apl.washington.edu> <20110706193636.GA69550@troutmask.apl.washington.edu> <4E14CCE5.4050906@zedat.fu-berlin.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: FreeBSD Current , "Hartmann, O." , arrowdodger <6yearold@gmail.com>, Arnaud Lacombe , freebsd-questions@freebsd.org Subject: Re: Heavy I/O blocks FreeBSD box for several seconds 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, 07 Jul 2011 01:51:51 -0000 On Thu, Jul 07, 2011 at 09:17:51AM +0800, Adrian Chadd wrote: > Offer a bounty for getting it fixed? > steve == ENOMONEY && jeffr == ENOTIME And, 4BSD works. -- Steve From owner-freebsd-current@FreeBSD.ORG Thu Jul 7 01:56:33 2011 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 DF3CC106564A for ; Thu, 7 Jul 2011 01:56:33 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id C03E58FC08 for ; Thu, 7 Jul 2011 01:56:33 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.4/8.14.4) with ESMTP id p671uXI5072103; Wed, 6 Jul 2011 18:56:33 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.4/8.14.4/Submit) id p671uXVw072102; Wed, 6 Jul 2011 18:56:33 -0700 (PDT) (envelope-from sgk) Date: Wed, 6 Jul 2011 18:56:33 -0700 From: Steve Kargl To: Rick Macklem Message-ID: <20110707015633.GA72095@troutmask.apl.washington.edu> References: <1978167896.291961.1310002395874.JavaMail.root@erie.cs.uoguelph.ca> <178783682.291966.1310002401214.JavaMail.root@erie.cs.uoguelph.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <178783682.291966.1310002401214.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Mutt/1.4.2.3i Cc: FreeBSD-Current Subject: Re: Can options NFSD and NFSSERVER exist in the same kernel 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, 07 Jul 2011 01:56:34 -0000 On Wed, Jul 06, 2011 at 09:33:21PM -0400, Rick Macklem wrote: > Although deleting /etc/rc.d/nfsserver is probably all you need > to do if you have head/etc/rc.d/nfsd, I've attached an updated > nfsd script that I am waiting for a review of. > > If you'd like to test this (when /etc/rc.d/nfsserver is deleted), > it would be appreciated. > > I think it will work for your case, rick I can test this tomorrow. Thanks again for the quick response. -- Steve From owner-freebsd-current@FreeBSD.ORG Thu Jul 7 02:39:01 2011 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 F1787106566C; Thu, 7 Jul 2011 02:39:01 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 99A1C8FC0C; Thu, 7 Jul 2011 02:39:01 +0000 (UTC) Received: by yxl31 with SMTP id 31so287878yxl.13 for ; Wed, 06 Jul 2011 19:39:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ZMMmTYRUdB9tn45ZZ5ycagUvejDkmGHryKBxk6isIeY=; b=RGPnEjM1G+p5qlPjcAwkvt77J4+6z/UU3mMGLnqaAqSFudNG5Fd9AE7UOpetP+rZ1c UkQF0Vny1URXw7oeJ9SiO461/z2HPNwz4OREIC2l+AjCW4nvg8/ATOa3FYhCxU5sLWhS 5N9oMcCMtnxDKSLZnyBdo0oKW3h6S8YV6tNQU= MIME-Version: 1.0 Received: by 10.151.92.3 with SMTP id u3mr466501ybl.114.1310006340739; Wed, 06 Jul 2011 19:39:00 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.151.45.11 with HTTP; Wed, 6 Jul 2011 19:39:00 -0700 (PDT) In-Reply-To: <20110707015151.GB71966@troutmask.apl.washington.edu> References: <4E1421D9.7080808@zedat.fu-berlin.de> <4E147F54.40908@zedat.fu-berlin.de> <20110706162811.GA68436@troutmask.apl.washington.edu> <20110706193636.GA69550@troutmask.apl.washington.edu> <4E14CCE5.4050906@zedat.fu-berlin.de> <20110707015151.GB71966@troutmask.apl.washington.edu> Date: Thu, 7 Jul 2011 10:39:00 +0800 X-Google-Sender-Auth: SLcDSWBOnmLhpclo9BZmTY6XPPw Message-ID: From: Adrian Chadd To: Steve Kargl Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Current , "Hartmann, O." , arrowdodger <6yearold@gmail.com>, Arnaud Lacombe , freebsd-questions@freebsd.org Subject: Re: Heavy I/O blocks FreeBSD box for several seconds 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, 07 Jul 2011 02:39:02 -0000 On 7 July 2011 09:51, Steve Kargl wrote: > On Thu, Jul 07, 2011 at 09:17:51AM +0800, Adrian Chadd wrote: >> Offer a bounty for getting it fixed? >> > > steve == ENOMONEY && jeffr == ENOTIME > > And, 4BSD works. I meant it as a more general observation. If something doesn't work as needed, consider either diving in to fix it, or offering a bounty to someone to do so. It sounds like these scheduler issues (IO and threads) are well-known and reasonably well-understood. All that's lacking is the last bit of the puzzle - the actual developer to develop it. :) Adrian From owner-freebsd-current@FreeBSD.ORG Thu Jul 7 03:11:52 2011 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 A446E106564A; Thu, 7 Jul 2011 03:11:52 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id 5DB0C8FC15; Thu, 7 Jul 2011 03:11:52 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.4/8.14.4) with ESMTP id p673BpFc072517; Wed, 6 Jul 2011 20:11:51 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.4/8.14.4/Submit) id p673BpWr072516; Wed, 6 Jul 2011 20:11:51 -0700 (PDT) (envelope-from sgk) Date: Wed, 6 Jul 2011 20:11:51 -0700 From: Steve Kargl To: Adrian Chadd Message-ID: <20110707031151.GA72452@troutmask.apl.washington.edu> References: <4E1421D9.7080808@zedat.fu-berlin.de> <4E147F54.40908@zedat.fu-berlin.de> <20110706162811.GA68436@troutmask.apl.washington.edu> <20110706193636.GA69550@troutmask.apl.washington.edu> <4E14CCE5.4050906@zedat.fu-berlin.de> <20110707015151.GB71966@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: FreeBSD Current , "Hartmann, O." , arrowdodger <6yearold@gmail.com>, Arnaud Lacombe , freebsd-questions@freebsd.org Subject: Re: Heavy I/O blocks FreeBSD box for several seconds 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, 07 Jul 2011 03:11:52 -0000 On Thu, Jul 07, 2011 at 10:39:00AM +0800, Adrian Chadd wrote: > On 7 July 2011 09:51, Steve Kargl wrote: > > On Thu, Jul 07, 2011 at 09:17:51AM +0800, Adrian Chadd wrote: > >> Offer a bounty for getting it fixed? > >> > > > > steve == ENOMONEY && jeffr == ENOTIME > > > > And, 4BSD works. > > I meant it as a more general observation. > > If something doesn't work as needed, consider either diving in to fix > it, or offering a bounty to someone to do so. > Or take the path of least resistance, use 4BSD, and get my actual work. I diagnosed the problem. I gave a fairly easy method for reproducing the problem (including providing a statically linked MPI program, and a script and data files to launch it). I offered access to one of the nodes in my cluster (including root access to install new kernels and to reboot the node). Unfortunately, I have neither the brain capacity and time nor the money to fix the issue. To solve OP's problem in the short, the simplest solution may be to switch to 4BSD. Let's face, ULE is not a silver bullet. -- Steve From owner-freebsd-current@FreeBSD.ORG Thu Jul 7 04:08:02 2011 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 89C00106566B; Thu, 7 Jul 2011 04:08:02 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4F19D8FC1B; Thu, 7 Jul 2011 04:08:02 +0000 (UTC) Received: by pvg11 with SMTP id 11so209578pvg.13 for ; Wed, 06 Jul 2011 21:08:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5lJBqCpfDhmwKFUhwaniqUZuWibxK/gh36hFKntMvXc=; b=gc2hkDTezcB7jPWC8igmrBAUN2fyXF58gLZaYimnqkQ4NaXiiK17WOclFHi+hCcA7x vQ3cKAM0sIxCFbQHvEk7dXr13JgdLOFVy1CmYyEGphM2Loqxnvr05KLCunp5zaZJFeSg 7Ov548iWqGg/eSo1/KvAdTZJrUddN4bCzOlqg= MIME-Version: 1.0 Received: by 10.68.15.67 with SMTP id v3mr524039pbc.5.1310011681685; Wed, 06 Jul 2011 21:08:01 -0700 (PDT) Received: by 10.68.64.200 with HTTP; Wed, 6 Jul 2011 21:08:01 -0700 (PDT) In-Reply-To: References: <4E1421D9.7080808@zedat.fu-berlin.de> <4E147F54.40908@zedat.fu-berlin.de> <20110706162811.GA68436@troutmask.apl.washington.edu> <20110706193636.GA69550@troutmask.apl.washington.edu> <4E14CCE5.4050906@zedat.fu-berlin.de> <20110707015151.GB71966@troutmask.apl.washington.edu> Date: Thu, 7 Jul 2011 00:08:01 -0400 Message-ID: From: Arnaud Lacombe To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Current , "Hartmann, O." , arrowdodger <6yearold@gmail.com>, Steve Kargl , freebsd-questions@freebsd.org Subject: Re: Heavy I/O blocks FreeBSD box for several seconds 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, 07 Jul 2011 04:08:02 -0000 Hi, On Wed, Jul 6, 2011 at 10:39 PM, Adrian Chadd wrote: > On 7 July 2011 09:51, Steve Kargl wrote: >> On Thu, Jul 07, 2011 at 09:17:51AM +0800, Adrian Chadd wrote: >>> Offer a bounty for getting it fixed? >>> >> >> steve == ENOMONEY && jeffr == ENOTIME >> >> And, 4BSD works. > > I meant it as a more general observation. > > If something doesn't work as needed, consider either diving in to fix > it, or offering a bounty to someone to do so. > What would be the point to even start looking at an issue? You guys (by "you", I mean "official" committers on public list) don't care about people providing patches, might it be for trivial, obvious, fixes. I'm not even talking about complex patches ... When you eventually ends up providing a patch, you ends up being slammed a door at by maintainers asserting their code is perfect, until logic and user complaints prove them wrong. That said, this comment is off-topic, but I will certainly re-state this next month when I'll be ping'ing trivial patches. - Arnaud > It sounds like these scheduler issues (IO and threads) are well-known > and reasonably well-understood. > All that's lacking is the last bit of the puzzle - the actual > developer to develop it. :) > > > Adrian > From owner-freebsd-current@FreeBSD.ORG Thu Jul 7 05:52:44 2011 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 29D3F106564A; Thu, 7 Jul 2011 05:52:44 +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 D46018FC12; Thu, 7 Jul 2011 05:52:43 +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 <1QehVy-0000hP-PP>; Thu, 07 Jul 2011 07:52:42 +0200 Received: from e178008197.adsl.alicedsl.de ([85.178.8.197] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1QehVy-0001x6-Lm>; Thu, 07 Jul 2011 07:52:42 +0200 Message-ID: <4E1549AA.4060404@zedat.fu-berlin.de> Date: Thu, 07 Jul 2011 07:52:42 +0200 From: "Hartmann, O." User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110630 Thunderbird/5.0 MIME-Version: 1.0 To: Oliver Pinter References: <4E1421D9.7080808@zedat.fu-berlin.de> <4E147F54.40908@zedat.fu-berlin.de> <20110706162811.GA68436@troutmask.apl.washington.edu> <20110706193636.GA69550@troutmask.apl.washington.edu> <4E14CCE5.4050906@zedat.fu-berlin.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.8.197 Cc: FreeBSD Current , Steve Kargl , arrowdodger <6yearold@gmail.com>, Arnaud Lacombe , freebsd-questions@freebsd.org Subject: Re: Heavy I/O blocks FreeBSD box for several seconds 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, 07 Jul 2011 05:52:44 -0000 On 07/06/11 23:49, Oliver Pinter wrote: > On 7/6/11, Hartmann, O. wrote: >> On 07/06/11 21:36, Steve Kargl wrote: >>> On Wed, Jul 06, 2011 at 03:18:35PM -0400, Arnaud Lacombe wrote: >>>> Hi, >>>> >>>> On Wed, Jul 6, 2011 at 12:28 PM, Steve Kargl >>>> wrote: >>>>> On Wed, Jul 06, 2011 at 05:29:24PM +0200, O. Hartmann wrote: >>>>>> I use SCHED_ULE on all machines, since it is supposed to be performing >>>>>> better on multicore boxes, but there are lots of suggestions switching >>>>>> back to the old SCHED_4BSD scheduler. >>>>>> >>>>> If you are using MPI in numerical codes, then you want >>>>> to use SCHED_4BSD. ?I've posted numerous times about ULE >>>>> and its very poor performance when using MPI. >>>>> >>>>> http://lists.freebsd.org/pipermail/freebsd-hackers/2008-October/026375.html >>>>> >>>> [sarcasm] >>>> It is rather funny to see that the post you point out has generated >>>> exactly 0 meaningful follow-up then and as you mention later in this >>>> thread, the issue still remains today :-) >>>> [/sarcasm] >>>> >>> Apparently, you are privy to my private email exchanges >>> with jeffr. >>> >>> I'm also not sure why you're being sarcastic here. The >>> issue was and AFAIK still is a problem for anyone using >>> FreeBSD in a HPC cluster. ULE simply performs worse than >>> 4BSD. >>> >> Well, I know only very little people using FreeBSD within a HPC cluster >> or even for scientific purposes, except myself and some people around here. >> _______________________________________________ >> 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" >> > > http://lists.freebsd.org/pipermail/freebsd-stable/2010-September/thread.html#58537 The problem is not only related to desktop boxes, it involves servers with "big" hardware as well. From owner-freebsd-current@FreeBSD.ORG Thu Jul 7 05:55:43 2011 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 4AB781065674; Thu, 7 Jul 2011 05:55:43 +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 026338FC0A; Thu, 7 Jul 2011 05:55:42 +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 <1QehYs-00014g-2g>; Thu, 07 Jul 2011 07:55:42 +0200 Received: from e178008197.adsl.alicedsl.de ([85.178.8.197] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1QehYr-000276-VO>; Thu, 07 Jul 2011 07:55:42 +0200 Message-ID: <4E154A5D.8080009@zedat.fu-berlin.de> Date: Thu, 07 Jul 2011 07:55:41 +0200 From: "Hartmann, O." User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110630 Thunderbird/5.0 MIME-Version: 1.0 To: Arnaud Lacombe , FreeBSD Current , "freebsd-performance@freebsd.org" References: <4E1421D9.7080808@zedat.fu-berlin.de> <4E147F54.40908@zedat.fu-berlin.de> <20110706162811.GA68436@troutmask.apl.washington.edu> <20110706193636.GA69550@troutmask.apl.washington.edu> <4E14CCE5.4050906@zedat.fu-berlin.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.8.197 Cc: Subject: Re: Heavy I/O blocks FreeBSD box for several seconds 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, 07 Jul 2011 05:55:43 -0000 On 07/07/11 06:29, Arnaud Lacombe wrote: > Hi, > > On Wed, Jul 6, 2011 at 5:00 PM, Hartmann, O. > wrote: >> On 07/06/11 21:36, Steve Kargl wrote: >>> On Wed, Jul 06, 2011 at 03:18:35PM -0400, Arnaud Lacombe wrote: >>>> Hi, >>>> >>>> On Wed, Jul 6, 2011 at 12:28 PM, Steve Kargl >>>> wrote: >>>>> On Wed, Jul 06, 2011 at 05:29:24PM +0200, O. Hartmann wrote: >>>>>> I use SCHED_ULE on all machines, since it is supposed to be performing >>>>>> better on multicore boxes, but there are lots of suggestions switching >>>>>> back to the old SCHED_4BSD scheduler. >>>>>> >>>>> If you are using MPI in numerical codes, then you want >>>>> to use SCHED_4BSD. ?I've posted numerous times about ULE >>>>> and its very poor performance when using MPI. >>>>> >>>>> >>>>> http://lists.freebsd.org/pipermail/freebsd-hackers/2008-October/026375.html >>>>> >>>> [sarcasm] >>>> It is rather funny to see that the post you point out has generated >>>> exactly 0 meaningful follow-up then and as you mention later in this >>>> thread, the issue still remains today :-) >>>> [/sarcasm] >>>> >>> Apparently, you are privy to my private email exchanges >>> with jeffr. >>> >>> I'm also not sure why you're being sarcastic here. The >>> issue was and AFAIK still is a problem for anyone using >>> FreeBSD in a HPC cluster. ULE simply performs worse than >>> 4BSD. >>> >> Well, I know only very little people using FreeBSD within a HPC cluster or >> even for scientific purposes, except myself and some people around here. >> > Well, quad-core CPU, dual-socket machine are quite common these day, > even in non-HPC system. So, unless you understand enough the issue and > ULE to assert that this issue is tight to this workload only, I would > assume this issue to affect other ULE use-case and a broader user > spectrum than "you and some people around". > > - Arnaud Maybe this is a little misunderstanding. I complained about the fact that FreeBSD is more and more vanishing from HPC (it was very common in the mid 90s and at the beginning the 2000s). My former department banned after the introduction of Linux kernel 2.6 all FreeBSD boxes due to a much better performance (network) and the availability of HPC 64bit compilers. Nevertheless, nowadays the situation has turned even worse with GPGPU. As you said, multicores are very common and so the inabilities of the multicore-aware scheduler ULE become effective not even for a marginal group of users with a specific workload. From owner-freebsd-current@FreeBSD.ORG Thu Jul 7 06:22:36 2011 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 674A5106566B for ; Thu, 7 Jul 2011 06:22:36 +0000 (UTC) (envelope-from freebsd@berczi.be) Received: from macsec.hu (cl-23.bud-01.hu.sixxs.net [IPv6:2a01:368:e000:16::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2B8CC8FC17 for ; Thu, 7 Jul 2011 06:22:36 +0000 (UTC) Received: from [10.11.0.1] by macsec.hu with esmtp (Exim 4.75 (FreeBSD)) (envelope-from ) id 1Qehys-000MAq-EH; Thu, 07 Jul 2011 08:22:34 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Berczi Gabor In-Reply-To: <4E14C0D9.9040503@gmail.com> Date: Thu, 7 Jul 2011 08:22:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2040FCF6-2CA2-4CF3-BB78-F5A3069297FF@berczi.be> References: <12DA9EAC-8677-49AD-BA6C-5A155D2A6122@berczi.be> <4E14C0D9.9040503@gmail.com> To: freebsd-current@freebsd.org X-Mailer: Apple Mail (2.1084) Cc: Volodymyr Kostyrko Subject: Re: ZFS boot fails with two pools 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, 07 Jul 2011 06:22:36 -0000 On Jul 6, 2011, at 10:08 PM, Volodymyr Kostyrko wrote: > 1. Check that pools have up-to-date boot code. I tried 8.2 and HEAD. You mean gpart+gptzfsboot+pmbr, right? > 2. Try to convince bios to boot from the disk of pool2. There is no disk with a singular ZFS pool. > 3. You can possibly try deploying /boot/boot0 MBR selector code over = disks of data pool. Supplied boot0 code can be used to choose another = disk to jump to it during boot process and will remember the last = choice. I'm not really sure how to do this with GPT. Should I use boot0 instead = of pmbr? However, this = (http://freebsd.1045724.n5.nabble.com/Booting-from-ZFS-raidz-td4032461.htm= l) may be related to the problem: > You can boot from any of the drives and as long as the BIOS can see =20= > enough drives you should be able to boot. In my case, the BIOS certainly can not see all members of the raid-z = pool. The question is: why does it want to boot from raid-z at all, and = how could it be persuaded to use the mirrored pool instead? From owner-freebsd-current@FreeBSD.ORG Thu Jul 7 07:04:44 2011 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 4BE021065675 for ; Thu, 7 Jul 2011 07:04:44 +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 4B1A68FC12 for ; Thu, 7 Jul 2011 07:04:43 +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 KAA13473; Thu, 07 Jul 2011 10:04:37 +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 1QeidZ-00092h-Ab; Thu, 07 Jul 2011 10:04:37 +0300 Message-ID: <4E155A84.1010100@FreeBSD.org> Date: Thu, 07 Jul 2011 10:04:36 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.18) Gecko/20110626 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Steve Kargl References: <4E1421D9.7080808@zedat.fu-berlin.de> <4E147F54.40908@zedat.fu-berlin.de> <20110706162811.GA68436@troutmask.apl.washington.edu> <20110706193636.GA69550@troutmask.apl.washington.edu> <4E14CCE5.4050906@zedat.fu-berlin.de> <20110707015151.GB71966@troutmask.apl.washington.edu> <20110707031151.GA72452@troutmask.apl.washington.edu> In-Reply-To: <20110707031151.GA72452@troutmask.apl.washington.edu> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , FreeBSD Current , "Hartmann, O." , arrowdodger <6yearold@gmail.com>, Arnaud Lacombe Subject: Re: Heavy I/O blocks FreeBSD box for several seconds 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, 07 Jul 2011 07:04:44 -0000 on 07/07/2011 06:11 Steve Kargl said the following: > Unfortunately, I have neither the brain capacity and time nor > the money to fix the issue. To solve OP's problem in the > short, the simplest solution may be to switch to 4BSD. Let's > face, ULE is not a silver bullet. I think that piling up different problems into a single discussion, even if they involve a common component (to a certain degree), is not going to help anybody. If I have read this thread correctly (and taking the subject line as a witness) the OP had a problem with heavy I/O activity screwing up interactivity. I think that it's not the same problem as sub-optimal performance of heavy CPU-bound load, which is what you reported if I am not mistaken. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Jul 7 07:13:39 2011 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 DD07B106564A for ; Thu, 7 Jul 2011 07:13:39 +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 2D5678FC13 for ; Thu, 7 Jul 2011 07:13:38 +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 KAA13668; Thu, 07 Jul 2011 10:13:33 +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 1QeimD-00093I-FG; Thu, 07 Jul 2011 10:13:33 +0300 Message-ID: <4E155C9B.6020700@FreeBSD.org> Date: Thu, 07 Jul 2011 10:13:31 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.18) Gecko/20110626 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Steve Kargl , Poul-Henning Kamp References: <20110706170132.GA68775@troutmask.apl.washington.edu> <5080.1309971941@critter.freebsd.dk> <20110706180001.GA69157@troutmask.apl.washington.edu> In-Reply-To: <20110706180001.GA69157@troutmask.apl.washington.edu> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , "Hartmann, O." Subject: Re: Heavy I/O blocks FreeBSD box for several seconds 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, 07 Jul 2011 07:13:39 -0000 on 06/07/2011 21:00 Steve Kargl said the following: > On Wed, Jul 06, 2011 at 05:05:41PM +0000, Poul-Henning Kamp wrote: >> In message <20110706170132.GA68775@troutmask.apl.washington.edu>, Steve Kargl w >> rites: >> >>> I periodically ran the same type test in the 2008 post over the >>> last three years. Nothing has changed. I even set up an account >>> on one node in my cluster for jeffr to use. He was too busy to >>> investigate at that time. >> >> Isn't this just the lemming-syncer hurling every dirty block over >> the cliff at the same time ? > > I don't know the answer. Of course, having no experience in > processing scheduling, I don't understand the question either ;-) I think that Poul-Henning was speaking in the vein of the subject line where I/O is somehow involved. I admit I would also love to hear more details in more technical terms (without lemmings and cliffs) :-) > AFAICT, it is a cpu affinity issue. If I launch n+1 MPI images > on a system with n cpus/cores, then 2 (and sometimes 3) images > are stuck on a cpu and those 2 (or 3) images ping-pong on that > cpu. I recall trying to use renice(8) to force some load > balancing, but vaguely remember that it did not help. Your issue seems to be about a specific case of purely CPU-bound loads. It is very relevant to ULE, but perhaps not to this particular thread. >> To find out: Run gstat and keep and eye on the leftmost column >> >> The road map for fixing that has been known for years... I would love to hear more about this. A link to a past discussion, if any, would suffice. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Jul 7 07:27:56 2011 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 632A41065670; Thu, 7 Jul 2011 07:27:56 +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 74A1B8FC08; Thu, 7 Jul 2011 07:27:55 +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 KAA13869; Thu, 07 Jul 2011 10:27:53 +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 1Qej05-00093q-HS; Thu, 07 Jul 2011 10:27:53 +0300 Message-ID: <4E155FF9.5090905@FreeBSD.org> Date: Thu, 07 Jul 2011 10:27:53 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.18) Gecko/20110626 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Nathan Whitehorn References: <20110706170132.GA68775@troutmask.apl.washington.edu> <5080.1309971941@critter.freebsd.dk> <20110706180001.GA69157@troutmask.apl.washington.edu> <4E14A54A.4050106@freebsd.org> In-Reply-To: <4E14A54A.4050106@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , "Hartmann, O." , Steve Kargl Subject: Re: Heavy I/O blocks FreeBSD box for several seconds 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, 07 Jul 2011 07:27:56 -0000 on 06/07/2011 21:11 Nathan Whitehorn said the following: > On 07/06/11 13:00, Steve Kargl wrote: >> AFAICT, it is a cpu affinity issue. If I launch n+1 MPI images >> on a system with n cpus/cores, then 2 (and sometimes 3) images >> are stuck on a cpu and those 2 (or 3) images ping-pong on that >> cpu. I recall trying to use renice(8) to force some load >> balancing, but vaguely remember that it did not help. > > I've seen exactly this problem with multi-threaded math libraries, as well. Exactly the same? Let's see. > Using parallel GotoBLAS on FreeBSD gives terrible performance because the > threads keep migrating between CPUs, causing frequent cache misses. So Steve reports that if he has Nthr > Ncpu, then some threads are "over-glued" to a particular CPU, which results in sub-optimal scheduling for those threads. I have to guess that Steve would want to see the threads being shuffled between CPUs to produce more even CPU load. On the other hand, you report that your threads keep being shuffled between CPUs (I presume for Nthr == Ncpu case, where Nthr is a count of the number-crunching threads). And I guess that you want them to stay glued to particular CPUs. So how is this the same problem? In fact, it sounds like somewhat opposite. The only thing in common is that you both don't like how ULE works. ULE has many knobs to tune its behavior. Unfortunately they are not very well documented and there are too many of them. So, it's not easy to find which combination would be the best for a particular work-load. In your particular case you might want to try to increase value of kern.sched.affinity to increase affinity of threads to their CPUs. Also, please note that FreeBSD support in GotoBLAS is not equivalent to Linux support as I have pointed out before. On Linux they bind their threads to CPUs to avoid the situation that you describe. Apparently they didn't know how to do CPU-binding on FreeBSD, so this is not implemented. You may have a motivation to help them out with this. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Jul 7 09:46:24 2011 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 E0CD81065677 for ; Thu, 7 Jul 2011 09:46:24 +0000 (UTC) (envelope-from matpockuh@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id B52CB8FC13 for ; Thu, 7 Jul 2011 09:46:23 +0000 (UTC) Received: by pvg11 with SMTP id 11so391879pvg.13 for ; Thu, 07 Jul 2011 02:46:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iAUQwidtaGmehgqbhgwE59z21o1dQXjBT1B8U91UQqc=; b=cC8pCDsq/5TnqTcUiNNlkmkUZiTNPiI+oo8kHaEAqsw7u1Z5tK7IZXi77AMEyvFwpa TbmR7bt0JSPMWGmmzKS3XWclb/iuUIoIR8VHFU9rnHPYNOeA1L29LATnzJe92q9qIcLK NYOT58qvCN+6MFWgu3WMbbJXkZIuU/P7rMvks= MIME-Version: 1.0 Received: by 10.68.49.232 with SMTP id x8mr797136pbn.307.1310031983277; Thu, 07 Jul 2011 02:46:23 -0700 (PDT) Received: by 10.68.62.97 with HTTP; Thu, 7 Jul 2011 02:46:23 -0700 (PDT) In-Reply-To: <4E0B8F25.7090107@FreeBSD.org> References: <20110629134140.GF14797@alchemy.franken.de> <4E0B8F25.7090107@FreeBSD.org> Date: Thu, 7 Jul 2011 13:46:23 +0400 Message-ID: From: KOT MATPOCKuH To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Current , Marius Strobl Subject: Re: named crashes on assertion in rbtdb.c on sparc64/SMP 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, 07 Jul 2011 09:46:25 -0000 I updated system to r223824 and got named patched to 9.6.-ESV-R4-P3, but problem is still exists: 07-Jul-2011 13:24:22.765 general: /usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns/rbtdb.c:1622: REQUIRE(prev > 0) failed 07-Jul-2011 13:24:22.781 general: exiting (due to assertion failure) How can I find root cause of the problem? -- MATPOCKuH From owner-freebsd-current@FreeBSD.ORG Thu Jul 7 10:04:48 2011 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 DB61F1065674; Thu, 7 Jul 2011 10:04:48 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 72AA28FC18; Thu, 7 Jul 2011 10:04:48 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id p67A4lif089729; Thu, 7 Jul 2011 12:04:47 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id p67A4lar089728; Thu, 7 Jul 2011 12:04:47 +0200 (CEST) (envelope-from marius) Date: Thu, 7 Jul 2011 12:04:46 +0200 From: Marius Strobl To: KOT MATPOCKuH Message-ID: <20110707100446.GJ14797@alchemy.franken.de> References: <20110629134140.GF14797@alchemy.franken.de> <4E0B8F25.7090107@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: Doug Barton , FreeBSD Current Subject: Re: named crashes on assertion in rbtdb.c on sparc64/SMP 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, 07 Jul 2011 10:04:48 -0000 On Thu, Jul 07, 2011 at 01:46:23PM +0400, KOT MATPOCKuH wrote: > I updated system to r223824 and got named patched to 9.6.-ESV-R4-P3, > but problem is still exists: > 07-Jul-2011 13:24:22.765 general: > /usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns/rbtdb.c:1622: > REQUIRE(prev > 0) failed > 07-Jul-2011 13:24:22.781 general: exiting (due to assertion failure) > > How can I find root cause of the problem? > >From your description it's unclear whether you've built BIND with or without sparc64_isc_disable_atomic.diff. If it was built without that patch please give it a try. If you had applied it then this apparently is a generic bug in BIND and unrelated to the MD atomic implementation and I don't know how to proceed in order to get that fixed. Hopefully Doug can help you in that case. Marius From owner-freebsd-current@FreeBSD.ORG Thu Jul 7 10:20:09 2011 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 3F53E106564A for ; Thu, 7 Jul 2011 10:20:03 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 64C388FC12 for ; Thu, 7 Jul 2011 10:20:03 +0000 (UTC) Received: by bwa20 with SMTP id 20so1060445bwa.13 for ; Thu, 07 Jul 2011 03:20:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=F8uH5TAh28UDbareIf0EDkdYRhPdsneg01Q/BkNjNBs=; b=OagDRj6e9kAOGW6IHBPCLJRXXGFEjqS/71zX0joOQoG6kr1eKUpcNjWBTReX8vpe4f GD37+KUOa8iBIO7XRp6AbGEQwDuAy7cO38kNYtlByc8QZiB85DbMl2BNfcPA6pY6IXfN /mGYzeAe0bhnJ3rnt4WzDtzXfVAlsjwFuBYuU= Received: by 10.205.82.80 with SMTP id ab16mr555058bkc.66.1310034002323; Thu, 07 Jul 2011 03:20:02 -0700 (PDT) Received: from vux.3501.lan ([46.247.238.41]) by mx.google.com with ESMTPS id af13sm8390854bkc.7.2011.07.07.03.19.58 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Jul 2011 03:20:01 -0700 (PDT) Message-ID: <4E158846.4040807@gmail.com> Date: Thu, 07 Jul 2011 13:19:50 +0300 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110705 Thunderbird/5.0 MIME-Version: 1.0 To: Berczi Gabor References: <12DA9EAC-8677-49AD-BA6C-5A155D2A6122@berczi.be> <4E14C0D9.9040503@gmail.com> <2040FCF6-2CA2-4CF3-BB78-F5A3069297FF@berczi.be> In-Reply-To: <2040FCF6-2CA2-4CF3-BB78-F5A3069297FF@berczi.be> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org Subject: Re: ZFS boot fails with two pools 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, 07 Jul 2011 10:20:09 -0000 07.07.2011 09:22, Berczi Gabor нwrote: > > On Jul 6, 2011, at 10:08 PM, Volodymyr Kostyrko wrote: > >> 1. Check that pools have up-to-date boot code. > > I tried 8.2 and HEAD. You mean gpart+gptzfsboot+pmbr, right? Yep. >> 2. Try to convince bios to boot from the disk of pool2. > > There is no disk with a singular ZFS pool. Any disk from bootable pool. >> 3. You can possibly try deploying /boot/boot0 MBR selector code over disks of data pool. Supplied boot0 code can be used to choose another disk to jump to it during boot process and will remember the last choice. > > I'm not really sure how to do this with GPT. Should I use boot0 instead of pmbr? boot0cfg is your old friend > However, this (http://freebsd.1045724.n5.nabble.com/Booting-from-ZFS-raidz-td4032461.html) may be related to the problem: That one is too old, I have one machine running 8.2 on raidz2 pool. > >> You can boot from any of the drives and as long as the BIOS can see >> enough drives you should be able to boot. > > In my case, the BIOS certainly can not see all members of the raid-z pool. The question is: why does it want to boot from raid-z at all, and how could it be persuaded to use the mirrored pool instead? Actuall I think that code on that stages just tries to boot from the pool on the current disk. -- Sphinx of black quartz judge my vow. From owner-freebsd-current@FreeBSD.ORG Thu Jul 7 07:11:43 2011 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 C80AB106566C; Thu, 7 Jul 2011 07:11:43 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id 9E5C98FC08; Thu, 7 Jul 2011 07:11:43 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id p677Bckc071604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 7 Jul 2011 00:11:38 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id p677BcDO071603; Thu, 7 Jul 2011 00:11:38 -0700 (PDT) Received: from fbsd81 ([192.168.200.81]) by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA23084; Thu, 7 Jul 11 00:04:54 PDT Date: Thu, 07 Jul 2011 07:05:41 -0700 From: perryh@pluto.rain.com To: sgk@troutmask.apl.washington.edu Message-Id: <4e15bd35.r2TPH7JSMoyDg2ic%perryh@pluto.rain.com> References: <4E1421D9.7080808@zedat.fu-berlin.de> <4E147F54.40908@zedat.fu-berlin.de> <20110706162811.GA68436@troutmask.apl.washington.edu> <20110706193636.GA69550@troutmask.apl.washington.edu> <4E14CCE5.4050906@zedat.fu-berlin.de> <20110707015151.GB71966@troutmask.apl.washington.edu> <20110707031151.GA72452@troutmask.apl.washington.edu> In-Reply-To: <20110707031151.GA72452@troutmask.apl.washington.edu> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 07 Jul 2011 11:14:30 +0000 Cc: adrian@freebsd.org, 6yearold@gmail.com, freebsd-current@freebsd.org, lacombar@gmail.com, ohartman@zedat.fu-berlin.de, freebsd-questions@freebsd.org Subject: Re: Heavy I/O blocks FreeBSD box for several seconds 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, 07 Jul 2011 07:11:43 -0000 Steve Kargl wrote: > Let's face, ULE is not a silver bullet. Or perhaps it is, but this particular problem is so heavily armored as to demand depleted uranium :) From owner-freebsd-current@FreeBSD.ORG Thu Jul 7 09:00:24 2011 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 43698106564A for ; Thu, 7 Jul 2011 09:00:24 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id F1D9B8FC08 for ; Thu, 7 Jul 2011 09:00:17 +0000 (UTC) Received: by pvg11 with SMTP id 11so362798pvg.13 for ; Thu, 07 Jul 2011 02:00:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=VVFzO/nY9Lh8MxM59YgXnvMtcdxwITh5tg6k9OswGow=; b=rtVPmZ5lwaGtsv+WxjK4Xua6QI4bOnq1Samj1iDywft5RGt7V0KjaXledOWtaB3Uwi pW5yQBA2kK0PcZz5hY3TncJ2t8rdQ9k6dZddo7K8J8mtl3k0r4i8vstPt5Ic04GasoTr ynLOk2sf9Zk/bocx64UNYnBkHE1Z2i3/Qh5Cg= MIME-Version: 1.0 Received: by 10.142.112.15 with SMTP id k15mr300444wfc.405.1310027493689; Thu, 07 Jul 2011 01:31:33 -0700 (PDT) Received: by 10.142.156.20 with HTTP; Thu, 7 Jul 2011 01:31:33 -0700 (PDT) In-Reply-To: <4E11ECE2.9050402@freebsd.org> References: <4E11ECE2.9050402@freebsd.org> Date: Thu, 7 Jul 2011 04:31:33 -0400 Message-ID: From: grarpamp To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Thu, 07 Jul 2011 11:15:27 +0000 Cc: Subject: Re: Jails: Setting different times in jails 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, 07 Jul 2011 09:00:24 -0000 > possibly achievable in libc? I don't know. Where else would it be done? stat, utimes, gettimeofday, clock_gettime, adjtime, etc and their variations. I've not checked what currently happens, but I don't think root in a jail should be able to set any kernel time parameters, absent a syscall that says it should. > in any case file this idea somewhere.. :-) Don't know here either. I looked at the lists and hackers seemed closest. I'll bcc current. Someone could maybe todo-wiki this thread as low hanging fruit. Cheers. From owner-freebsd-current@FreeBSD.ORG Thu Jul 7 11:28:58 2011 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 F29D9106566C for ; Thu, 7 Jul 2011 11:28:58 +0000 (UTC) (envelope-from aldis@bsdroot.lv) Received: from smtp.bsdroot.lv (smtp.bsdroot.lv [83.241.11.135]) by mx1.freebsd.org (Postfix) with ESMTP id A8BE98FC1D for ; Thu, 7 Jul 2011 11:28:58 +0000 (UTC) Received: from smtp.bsdroot.lv (root.bsdroot.lv [83.241.11.135]) by smtp.bsdroot.lv (Postfix) with ESMTP id BE9A86163; Thu, 7 Jul 2011 14:28:37 +0300 (EEST) Received: from desktop.pc (mpe-11-155.mpe.lv [83.241.11.155]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.bsdroot.lv (Postfix) with ESMTPSA id 5005E6162; Thu, 7 Jul 2011 14:28:36 +0300 (EEST) Date: Thu, 7 Jul 2011 14:28:55 +0300 From: Aldis Berjoza To: Berczi Gabor Message-ID: <20110707142855.3000b528@desktop.pc> In-Reply-To: <4E158846.4040807@gmail.com> References: <12DA9EAC-8677-49AD-BA6C-5A155D2A6122@berczi.be> <4E14C0D9.9040503@gmail.com> <2040FCF6-2CA2-4CF3-BB78-F5A3069297FF@berczi.be> <4E158846.4040807@gmail.com> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.1; amd64-portbld-freebsd8.2) X-PGP-Key: 0xCCBA39FA X-PGP-Key-Fingerprint: 800C C77B A57E 98A0 821F 7D24 2AC0 DB19 CCBA 39FA X-PGP-PublicKey: http://files.bsdroot.lv/my/aldis_berjoza.asc Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-current@freebsd.org Subject: Re: ZFS boot fails with two pools 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, 07 Jul 2011 11:28:59 -0000 On Thu, 07 Jul 2011 13:19:50 +0300 Volodymyr Kostyrko wrote: > > > >> You can boot from any of the drives and as long as the BIOS can see > >> enough drives you should be able to boot. > > > > In my case, the BIOS certainly can not see all members of the > > raid-z pool. The question is: why does it want to boot from raid-z > > at all, and how could it be persuaded to use the mirrored pool > > instead? > > Actuall I think that code on that stages just tries to boot from the > pool on the current disk. > Does your /boot/loader.conf have: vfs.root.mountfrom="zfs:tank/root" zfs_load="YES" Does FreeBSD bootloader actually starts to load? (Do you get to FreeBSD boot menu?) Does your system pool use compression? Which compression? -- Aldis Berjoza http://www.bsdroot.lv/ From owner-freebsd-current@FreeBSD.ORG Thu Jul 7 11:44:32 2011 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 DB9B7106566C; Thu, 7 Jul 2011 11:44:32 +0000 (UTC) (envelope-from matpockuh@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id AE4D58FC15; Thu, 7 Jul 2011 11:44:32 +0000 (UTC) Received: by pwi7 with SMTP id 7so780272pwi.13 for ; Thu, 07 Jul 2011 04:44:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+VAWRS7jTSRCA2qu2WyIIpK5CWJEhjKOCyHLpadyvdc=; b=ebJVu76TN1gx1pSc7OBmOVfEIuG17G3EXd3wyPMjMzm+FEMhBjPlLT157Q8oqiw7ge al1ETBe1LqQJf9o22c4KdIOZpWTWtNRXk/u3uLxI0+o6TPDAW5R/qGUi/efujyyxU+Sa xYGgtNf4n6zM373c4q+5fitjzvFNf6VAYULnQ= MIME-Version: 1.0 Received: by 10.68.49.232 with SMTP id x8mr924269pbn.307.1310039072188; Thu, 07 Jul 2011 04:44:32 -0700 (PDT) Received: by 10.68.62.97 with HTTP; Thu, 7 Jul 2011 04:44:32 -0700 (PDT) In-Reply-To: <20110707100446.GJ14797@alchemy.franken.de> References: <20110629134140.GF14797@alchemy.franken.de> <4E0B8F25.7090107@FreeBSD.org> <20110707100446.GJ14797@alchemy.franken.de> Date: Thu, 7 Jul 2011 15:44:32 +0400 Message-ID: From: KOT MATPOCKuH To: Marius Strobl Content-Type: text/plain; charset=ISO-8859-1 Cc: Doug Barton , FreeBSD Current Subject: Re: named crashes on assertion in rbtdb.c on sparc64/SMP 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, 07 Jul 2011 11:44:32 -0000 2011/7/7 Marius Strobl : > On Thu, Jul 07, 2011 at 01:46:23PM +0400, KOT MATPOCKuH wrote: >> I updated system to r223824 and got named patched to 9.6.-ESV-R4-P3, >> but problem is still exists: >> 07-Jul-2011 13:24:22.765 general: >> /usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns/rbtdb.c:1622: >> REQUIRE(prev > 0) failed >> 07-Jul-2011 13:24:22.781 general: exiting (due to assertion failure) >> >> How can I find root cause of the problem? > From your description it's unclear whether you've built BIND with or > without sparc64_isc_disable_atomic.diff. If it was built without that > patch please give it a try. As You can see, Doug is already included your patch in head: http://svnweb.freebsd.org/base/head/contrib/bind9/lib/isc/sparc64/include/isc/atomic.h?r1=222395&r2=223811 And, of course, bind builded with your patch... > If you had applied it then this apparently > is a generic bug in BIND and unrelated to the MD atomic implementation > and I don't know how to proceed in order to get that fixed. Hopefully > Doug can help you in that case. Okey, I look forward to for guidance from Doug... -- MATPOCKuH From owner-freebsd-current@FreeBSD.ORG Thu Jul 7 12:21:16 2011 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 0D9AC1065672 for ; Thu, 7 Jul 2011 12:21:16 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 912E38FC12 for ; Thu, 7 Jul 2011 12:21:15 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QenZx-0005eO-52 for freebsd-current@freebsd.org; Thu, 07 Jul 2011 14:21:13 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Jul 2011 14:21:13 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Jul 2011 14:21:13 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Thu, 07 Jul 2011 14:20:59 +0200 Lines: 34 Message-ID: References: <20110706170132.GA68775@troutmask.apl.washington.edu> <5080.1309971941@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101102 Thunderbird/3.1.6 In-Reply-To: <5080.1309971941@critter.freebsd.dk> X-Enigmail-Version: 1.1.2 Cc: freebsd-questions@freebsd.org Subject: Re: Heavy I/O blocks FreeBSD box for several seconds 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, 07 Jul 2011 12:21:16 -0000 On 06/07/2011 19:05, Poul-Henning Kamp wrote: > In message<20110706170132.GA68775@troutmask.apl.washington.edu>, Steve Kargl w > rites: > >> I periodically ran the same type test in the 2008 post over the >> last three years. Nothing has changed. I even set up an account >> on one node in my cluster for jeffr to use. He was too busy to >> investigate at that time. > > Isn't this just the lemming-syncer hurling every dirty block over > the cliff at the same time ? Occasionally there have been reports of there being "something" (tm) which causes CPU-bound processes to stall / starve when heavy file system IO is present. I think I have also noticed this occasionally but it was never serious enough to pursue it - only X11 lagging. The problem is - all this is sporadic and thus anecdotal. AFAIK, the "lemming-syncer" behaviour shouldn't stall anything if it's the only thing which is "wrong", right? I know one issue which might seemingly stall all IO: since there is only one IO queue, if it is filled with requests which take a long time, all other IO is blocked; as an example: doing simultaneous writes on a slow USB flash stick and on a hard drive will soon result in the queue being filled with slow USB requests, which will by the nature of the queue "push out" fast disk requests, making the drive look very slow (this is most noticable with large hirunningspace). But this doesn't seem to directly correlate with the OP's problem. Maybe this particular problem can be tested by having two drives - one to provoke this kind of stalling, and one to test if any IO can be done on it while the stall happens on the first one. From owner-freebsd-current@FreeBSD.ORG Thu Jul 7 12:25:09 2011 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 133CA1065672 for ; Thu, 7 Jul 2011 12:25:09 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 3F55B8FC1C for ; Thu, 7 Jul 2011 12:25:07 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Qendh-0008AE-Rs for freebsd-current@freebsd.org; Thu, 07 Jul 2011 14:25:05 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Jul 2011 14:25:05 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Jul 2011 14:25:05 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Thu, 07 Jul 2011 14:21:27 +0200 Lines: 8 Message-ID: References: <20110706170132.GA68775@troutmask.apl.washington.edu> <5080.1309971941@critter.freebsd.dk> <20110706180001.GA69157@troutmask.apl.washington.edu> <4E14A54A.4050106@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101102 Thunderbird/3.1.6 In-Reply-To: <4E14A54A.4050106@freebsd.org> X-Enigmail-Version: 1.1.2 Cc: freebsd-questions@freebsd.org Subject: Re: Heavy I/O blocks FreeBSD box for several seconds 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, 07 Jul 2011 12:25:09 -0000 On 06/07/2011 20:11, Nathan Whitehorn wrote: > I've seen exactly this problem with multi-threaded math libraries, as > well. Using parallel GotoBLAS on FreeBSD gives terrible performance > because the threads keep migrating between CPUs, causing frequent cache > misses. On both schedulers? From owner-freebsd-current@FreeBSD.ORG Thu Jul 7 12:43:23 2011 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 CF3EE106564A for ; Thu, 7 Jul 2011 12:43:23 +0000 (UTC) (envelope-from moonlightakkiy@yahoo.ca) Received: from nm30-vm4.bullet.mail.ne1.yahoo.com (nm30-vm4.bullet.mail.ne1.yahoo.com [98.138.91.190]) by mx1.freebsd.org (Postfix) with SMTP id 871658FC0A for ; Thu, 7 Jul 2011 12:43:23 +0000 (UTC) Received: from [98.138.90.50] by nm30.bullet.mail.ne1.yahoo.com with NNFMP; 07 Jul 2011 12:43:23 -0000 Received: from [98.138.84.44] by tm3.bullet.mail.ne1.yahoo.com with NNFMP; 07 Jul 2011 12:43:23 -0000 Received: from [127.0.0.1] by smtp112.mail.ne1.yahoo.com with NNFMP; 07 Jul 2011 12:43:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.ca; s=s1024; t=1310042603; bh=3KQH8DpPJQG2es6X3rCQnOs1ctsX8p4T8szQBBMyMzQ=; h=X-Yahoo-Newman-Id:Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Received:MIME-Version:Received:Received:In-Reply-To:References:Date:Message-ID:Subject:From:To:Cc:Content-Type; b=Nj7O4ziPy6pk3GJHIRs0JtvxhQ6P/aDoj9XfFerXV920EJ/6A0JzquxIISz4ACWBFot1pOLHLaLESyRXb/Qu+9SBVHV71kFR/+a2LSsNU5V7b+pQF/j+aX/vZGTOn4eZqdCibZWEtg2RkaI+alibPJ4CRuOA1Z5+Vp81Wc/HVk0= X-Yahoo-Newman-Id: 146553.26040.bm@smtp112.mail.ne1.yahoo.com Received: from mail-vw0-f54.google.com (moonlightakkiy@209.85.212.54 with plain) by smtp112.mail.ne1.yahoo.com with SMTP; 07 Jul 2011 05:43:23 -0700 PDT X-Yahoo-SMTP: Xr6qjFWswBAEmd20sAvB4Q3keqXvXsIH9TjJ X-YMail-OSG: _x.QiigVM1kzqQ2xIJzb0Q2jrsreoDNSPW5w2Kt8UIXOQck _C63YjU4YEz13GUJm2XZbkJIk10TyLLBVKSUCoHrwoL6o279NndktcxO131w ONjE4NaCBunRe_cZ7xiwL0riylkq85nVVUUcTehXcQ.nuyIkBCT1rDwms423 UaL_A.uOBgERgPLmLYEqLmOkaPOOJhAre7qgV3..K4UVOjMUsWjBEftgE4KK U6aEy7PgPTJx3zFP1f086C37ZtlI._X6QyjUHL6k3alO99XLNDwC71yTVJHa W5zFRoCBpDxWPKV7i4UXpBoygClnWuuLSMzqRICGWoQXNBjNmoy5mlFtmMGQ Tdl713h7EiLL3SeBRYnh_FInQFwn64ZPzSY_NiWTcHhvxhJFmZuK46tX4xIe 3q1VHHLCdxu2GoRvyJNYXSs0PIwuhW2o4gUlDzH2uFR49i595rQrRWaU1YDI DoVzGYtyeIF2peL6VCFHvrXqG_KwdX4kFUFKpCsazPYQ- X-Yahoo-Newman-Property: ymail-3 Received: by vws18 with SMTP id 18so900260vws.13 for ; Thu, 07 Jul 2011 05:43:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.179.131 with SMTP id dg3mr1101300vdc.9.1310042602467; Thu, 07 Jul 2011 05:43:22 -0700 (PDT) Received: by 10.52.108.229 with HTTP; Thu, 7 Jul 2011 05:43:22 -0700 (PDT) In-Reply-To: <201107061719.38445.hselasky@c2i.net> References: <1309237117.88943.YahooMailNeo@web39307.mail.mud.yahoo.com> <201106280850.57645.hselasky@c2i.net> <201107061719.38445.hselasky@c2i.net> Date: Thu, 7 Jul 2011 06:43:22 -0600 Message-ID: From: PseudoCylon To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org, "freebsd-wireless@freebsd.org" Subject: Re: [CFT] Sierra Wireless HSPA+ USB modem 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, 07 Jul 2011 12:43:23 -0000 On Wed, Jul 6, 2011 at 9:19 AM, Hans Petter Selasky wrote: >> >> Hi, >> >> I'm going to review and import your driver. >> >> --HPS > > Hi, > > The intial patch had some bad code and didn't compile on 9-current. I've tried > to clean it up. Please test and report back if I didn't break anything. > > http://hselasky.homeunix.org:8192/usie_for_FreeBSD_9_current.patch > > --HPS > Hello, Thanks for the patch. if_usie.c 241 if (usbd_lookup_id_by_uaa(usie_devs, sizeof(usie_devs), uaa) != 0) 242 return; /* no device match */ It should return non-zero on success, but somehow this caused the process to exit, and modem stayed being a CD-ROM. The compiler complained about uninitialized int if_usie.c: 1484 - uint8_t pad; + uint8_t pad = 0; Otherwise it worked fine. AK From owner-freebsd-current@FreeBSD.ORG Thu Jul 7 12:49:46 2011 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 0E283106564A; Thu, 7 Jul 2011 12:49:46 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe04.c2i.net [212.247.154.98]) by mx1.freebsd.org (Postfix) with ESMTP id 536A18FC1A; Thu, 7 Jul 2011 12:49:45 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=Ki88u+3nwejNRg6MOseuLmL2vomBRNHvHPpCRMZep5s= c=1 sm=1 a=SvYTsOw2Z4kA:10 a=8GCaWQNJa_IA:10 a=WQU8e4WWZSUA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=8kQB0OdkAAAA:8 a=N3vH5299AAAA:8 a=Lx8nvDvfJ4C5hwmOibYA:9 a=wPNLvfGTeEIA:10 a=9aOQ2cSd83gA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe04.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 149462814; Thu, 07 Jul 2011 14:49:43 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Thu, 7 Jul 2011 14:47:52 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: <1309237117.88943.YahooMailNeo@web39307.mail.mud.yahoo.com> <201107061719.38445.hselasky@c2i.net> In-Reply-To: X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201107071447.53041.hselasky@c2i.net> Cc: PseudoCylon , "freebsd-wireless@freebsd.org" Subject: Re: [CFT] Sierra Wireless HSPA+ USB modem 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, 07 Jul 2011 12:49:46 -0000 On Thursday 07 July 2011 14:43:22 PseudoCylon wrote: > On Wed, Jul 6, 2011 at 9:19 AM, Hans Petter Selasky wrote: > >> Hi, > >> > >> I'm going to review and import your driver. > >> > >> --HPS > > > > Hi, > > > > The intial patch had some bad code and didn't compile on 9-current. I've > > tried to clean it up. Please test and report back if I didn't break > > anything. > > > > http://hselasky.homeunix.org:8192/usie_for_FreeBSD_9_current.patch > > > > --HPS > > Hello, > > Thanks for the patch. > > if_usie.c > 241 if (usbd_lookup_id_by_uaa(usie_devs, sizeof(usie_devs), uaa) != 0) > 242 return; /* no device match */ > > It should return non-zero on success, but somehow this caused the > process to exit, and modem stayed being a CD-ROM. Hi, Is this device changing its USB vendor and product ID ? We need this ID check, else all mass storage devices will receive the eject command! --HPS From owner-freebsd-current@FreeBSD.ORG Thu Jul 7 12:50:50 2011 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 AC53E106566B; Thu, 7 Jul 2011 12:50:50 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe07.c2i.net [212.247.154.194]) by mx1.freebsd.org (Postfix) with ESMTP id 09EC48FC1E; Thu, 7 Jul 2011 12:50:49 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=SJA03SmFjIOBaRUqQpAxZTuC3Mg0Qr8luS0qYjfHCY4= c=1 sm=1 a=SvYTsOw2Z4kA:10 a=8GCaWQNJa_IA:10 a=WQU8e4WWZSUA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=zO0weGsyaNLyVeU5gJ4A:9 a=wPNLvfGTeEIA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe07.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 149805704; Thu, 07 Jul 2011 14:50:48 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Thu, 7 Jul 2011 14:48:58 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: <1309237117.88943.YahooMailNeo@web39307.mail.mud.yahoo.com> <201107061719.38445.hselasky@c2i.net> In-Reply-To: X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq,NwSZ4V" =?iso-8859-1?q?=7CLR=2E+tj=7Dg5=0A=09=25V?=,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( =?iso-8859-1?q?=0A=09=3AAuzV9=3A=2EhESm-x4h240C=609=3Dw?= MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201107071448.58436.hselasky@c2i.net> Cc: PseudoCylon , "freebsd-wireless@freebsd.org" Subject: Re: [CFT] Sierra Wireless HSPA+ USB modem 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, 07 Jul 2011 12:50:50 -0000 On Thursday 07 July 2011 14:43:22 PseudoCylon wrote: > The compiler complained about uninitialized int > if_usie.c: 1484 > - uint8_t pad; > + uint8_t pad = 0; I changed it so that pad is set in both cases: pad = (hip->id & USIE_HIP_PAD) ? 1 : 0; if ((hip->id & USIE_HIP_MASK) == USIE_HIP_CNS2H) { cns = (struct usie_cns *)(((uint8_t *)(hip + 1)) + pad); --HPS From owner-freebsd-current@FreeBSD.ORG Thu Jul 7 15:14:41 2011 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 1645C106564A; Thu, 7 Jul 2011 15:14:41 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id E86CD8FC08; Thu, 7 Jul 2011 15:14:40 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.4/8.14.4) with ESMTP id p67FEe6Y075621; Thu, 7 Jul 2011 08:14:40 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.4/8.14.4/Submit) id p67FEepR075620; Thu, 7 Jul 2011 08:14:40 -0700 (PDT) (envelope-from sgk) Date: Thu, 7 Jul 2011 08:14:40 -0700 From: Steve Kargl To: Andriy Gapon Message-ID: <20110707151440.GA75537@troutmask.apl.washington.edu> References: <20110706170132.GA68775@troutmask.apl.washington.edu> <5080.1309971941@critter.freebsd.dk> <20110706180001.GA69157@troutmask.apl.washington.edu> <4E14A54A.4050106@freebsd.org> <4E155FF9.5090905@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E155FF9.5090905@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: FreeBSD Current , "Hartmann, O." , Nathan Whitehorn Subject: Re: Heavy I/O blocks FreeBSD box for several seconds 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, 07 Jul 2011 15:14:41 -0000 On Thu, Jul 07, 2011 at 10:27:53AM +0300, Andriy Gapon wrote: > on 06/07/2011 21:11 Nathan Whitehorn said the following: > > On 07/06/11 13:00, Steve Kargl wrote: > >> AFAICT, it is a cpu affinity issue. If I launch n+1 MPI images > >> on a system with n cpus/cores, then 2 (and sometimes 3) images > >> are stuck on a cpu and those 2 (or 3) images ping-pong on that > >> cpu. I recall trying to use renice(8) to force some load > >> balancing, but vaguely remember that it did not help. > > > > I've seen exactly this problem with multi-threaded math libraries, as well. > > Exactly the same? Let's see. > > > Using parallel GotoBLAS on FreeBSD gives terrible performance because the > > threads keep migrating between CPUs, causing frequent cache misses. > > So Steve reports that if he has Nthr > Ncpu, then some threads are "over-glued" > to a particular CPU, which results in sub-optimal scheduling for those threads. > I have to guess that Steve would want to see the threads being shuffled between > CPUs to produce more even CPU load. I'm using OpenMPI. These are N > Ncpu processes not threads, and without the loss of generality let N = Ncpu + 1. It is a classic master-slave situation where 1 process initializes all others. The n-1 slave processes are then independent of each other. After 20 minutes or so of number crunching, each slave sends a few 10s of KB of data to the master. The master collects all the data, writes it to disk, and then sends the slaves the next set of computations to do. The computations are nearly identical, so each slave finishes it task in the same amount of time. The problem appears to be that 2 slaves are bound to the same cpu and the remaining N - 3 slaves are bound to a specific cpu. The N - 3 slaves finish their task, send data to the master, and then spin (chewing up nearly 100% cpu) waiting for the 2 ping-ponging slaves to finishes. This causes a stall in the computation. When a complete computation takes days to complete, theses stall become problematic. So, yes, I want the processes to get a more uniform access to cpus via migration to other cpus. This is what 4BSD appears to do. > On the other hand, you report that your threads keep being shuffled between CPUs > (I presume for Nthr == Ncpu case, where Nthr is a count of the number-crunching > threads). And I guess that you want them to stay glued to particular CPUs. > > So how is this the same problem? In fact, it sounds like somewhat opposite. > The only thing in common is that you both don't like how ULE works. Well, it may be similar in that N - 2 threads are bound to N - 2 cpus, and the remaining 2 threads are ping ponging on the last remaining cpu. I suspect that GotoBLAS has a large amount communication between threads, and once again the computations stalls waiting of the 2 threads to either finish battling for the 1 cpu or perhaps the process uses pthread_yield() in some clever way to try to get load balancing. -- Steve From owner-freebsd-current@FreeBSD.ORG Thu Jul 7 15:50:00 2011 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 DBDD5106566B; Thu, 7 Jul 2011 15:50:00 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 6924F8FC12; Thu, 7 Jul 2011 15:50:00 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id p67Fnw1P090963; Thu, 7 Jul 2011 17:49:58 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id p67FnwDh090962; Thu, 7 Jul 2011 17:49:58 +0200 (CEST) (envelope-from marius) Date: Thu, 7 Jul 2011 17:49:58 +0200 From: Marius Strobl To: KOT MATPOCKuH Message-ID: <20110707154958.GK14797@alchemy.franken.de> References: <20110629134140.GF14797@alchemy.franken.de> <4E0B8F25.7090107@FreeBSD.org> <20110707100446.GJ14797@alchemy.franken.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: Doug Barton , FreeBSD Current Subject: Re: named crashes on assertion in rbtdb.c on sparc64/SMP 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, 07 Jul 2011 15:50:01 -0000 On Thu, Jul 07, 2011 at 03:44:32PM +0400, KOT MATPOCKuH wrote: > 2011/7/7 Marius Strobl : > > On Thu, Jul 07, 2011 at 01:46:23PM +0400, KOT MATPOCKuH wrote: > >> I updated system to r223824 and got named patched to 9.6.-ESV-R4-P3, > >> but problem is still exists: > >> 07-Jul-2011 13:24:22.765 general: > >> /usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns/rbtdb.c:1622: > >> REQUIRE(prev > 0) failed > >> 07-Jul-2011 13:24:22.781 general: exiting (due to assertion failure) > >> > >> How can I find root cause of the problem? > > From your description it's unclear whether you've built BIND with or > > without sparc64_isc_disable_atomic.diff. If it was built without that > > patch please give it a try. > As You can see, Doug is already included your patch in head: > http://svnweb.freebsd.org/base/head/contrib/bind9/lib/isc/sparc64/include/isc/atomic.h?r1=222395&r2=223811 > And, of course, bind builded with your patch... > That's not the patch I was referring to. I did a second one which just entirely disables the use of atomic operations on sparc64: http://people.freebsd.org/~marius/sparc64_isc_disable_atomic.diff Marius From owner-freebsd-current@FreeBSD.ORG Thu Jul 7 15:54:52 2011 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 B80D8106564A; Thu, 7 Jul 2011 15:54:52 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 47FDB8FC15; Thu, 7 Jul 2011 15:54:52 +0000 (UTC) Received: by qyk38 with SMTP id 38so728307qyk.13 for ; Thu, 07 Jul 2011 08:54:51 -0700 (PDT) Received: by 10.224.33.82 with SMTP id g18mr744333qad.105.1310052237133; Thu, 07 Jul 2011 08:23:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.90.195 with HTTP; Thu, 7 Jul 2011 08:23:17 -0700 (PDT) In-Reply-To: <20110707151440.GA75537@troutmask.apl.washington.edu> References: <20110706170132.GA68775@troutmask.apl.washington.edu> <5080.1309971941@critter.freebsd.dk> <20110706180001.GA69157@troutmask.apl.washington.edu> <4E14A54A.4050106@freebsd.org> <4E155FF9.5090905@FreeBSD.org> <20110707151440.GA75537@troutmask.apl.washington.edu> From: Vlad Galu Date: Thu, 7 Jul 2011 17:23:17 +0200 Message-ID: To: Steve Kargl Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Current , "Hartmann, O." , Nathan Whitehorn , Andriy Gapon Subject: Re: Heavy I/O blocks FreeBSD box for several seconds 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, 07 Jul 2011 15:54:52 -0000 On Thu, Jul 7, 2011 at 5:14 PM, Steve Kargl < sgk@troutmask.apl.washington.edu> wrote: > On Thu, Jul 07, 2011 at 10:27:53AM +0300, Andriy Gapon wrote: > > on 06/07/2011 21:11 Nathan Whitehorn said the following: > > > On 07/06/11 13:00, Steve Kargl wrote: > > >> AFAICT, it is a cpu affinity issue. If I launch n+1 MPI images > > >> on a system with n cpus/cores, then 2 (and sometimes 3) images > > >> are stuck on a cpu and those 2 (or 3) images ping-pong on that > > >> cpu. I recall trying to use renice(8) to force some load > > >> balancing, but vaguely remember that it did not help. > > > > > > I've seen exactly this problem with multi-threaded math libraries, as > well. > > > > Exactly the same? Let's see. > > > > > Using parallel GotoBLAS on FreeBSD gives terrible performance because > the > > > threads keep migrating between CPUs, causing frequent cache misses. > > > > So Steve reports that if he has Nthr > Ncpu, then some threads are > "over-glued" > > to a particular CPU, which results in sub-optimal scheduling for those > threads. > > I have to guess that Steve would want to see the threads being shuffled > between > > CPUs to produce more even CPU load. > > I'm using OpenMPI. These are N > Ncpu processes not threads, and without > the loss of generality let N = Ncpu + 1. It is a classic master-slave > situation where 1 process initializes all others. The n-1 slave processes > are then independent of each other. After 20 minutes or so of number > crunching, each slave sends a few 10s of KB of data to the master. The > master collects all the data, writes it to disk, and then sends the > slaves the next set of computations to do. The computations are nearly > identical, so each slave finishes it task in the same amount of time. The > problem appears to be that 2 slaves are bound to the same cpu and the > remaining N - 3 slaves are bound to a specific cpu. The N - 3 slaves > finish their task, send data to the master, and then spin (chewing up > nearly 100% cpu) waiting for the 2 ping-ponging slaves to finishes. > This causes a stall in the computation. When a complete computation > takes days to complete, theses stall become problematic. So, yes, I > want the processes to get a more uniform access to cpus via migration > to other cpus. This is what 4BSD appears to do. > > Spinning threads are a PITA for any scheduler, it's just that in your case 4BSD computes quantums differently. Is there any way to make the software sleep instead of spinning? > > On the other hand, you report that your threads keep being shuffled > between CPUs > > (I presume for Nthr == Ncpu case, where Nthr is a count of the > number-crunching > > threads). And I guess that you want them to stay glued to particular > CPUs. > > > > So how is this the same problem? In fact, it sounds like somewhat > opposite. > > The only thing in common is that you both don't like how ULE works. > > Well, it may be similar in that N - 2 threads are bound to N - 2 > cpus, and the remaining 2 threads are ping ponging on the last > remaining cpu. I suspect that GotoBLAS has a large amount > communication between threads, and once again the computations > stalls waiting of the 2 threads to either finish battling for the > 1 cpu or perhaps the process uses pthread_yield() in some clever > way to try to get load balancing. > > -- > Steve > _______________________________________________ > 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" > -- Good, fast & cheap. Pick any two. From owner-freebsd-current@FreeBSD.ORG Thu Jul 7 19:42:47 2011 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 C86801065673; Thu, 7 Jul 2011 19:42:47 +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 01FE58FC1B; Thu, 7 Jul 2011 19:42:46 +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 WAA28642; Thu, 07 Jul 2011 22:42:41 +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 1QeuTA-0009nz-Qf; Thu, 07 Jul 2011 22:42:40 +0300 Message-ID: <4E160C2F.8020001@FreeBSD.org> Date: Thu, 07 Jul 2011 22:42:39 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110706 Thunderbird/5.0 MIME-Version: 1.0 To: Steve Kargl References: <20110706170132.GA68775@troutmask.apl.washington.edu> <5080.1309971941@critter.freebsd.dk> <20110706180001.GA69157@troutmask.apl.washington.edu> <4E14A54A.4050106@freebsd.org> <4E155FF9.5090905@FreeBSD.org> <20110707151440.GA75537@troutmask.apl.washington.edu> In-Reply-To: <20110707151440.GA75537@troutmask.apl.washington.edu> X-Enigmail-Version: 1.2pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , "Hartmann, O." , Nathan Whitehorn Subject: Re: Heavy I/O blocks FreeBSD box for several seconds 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, 07 Jul 2011 19:42:48 -0000 on 07/07/2011 18:14 Steve Kargl said the following: > On Thu, Jul 07, 2011 at 10:27:53AM +0300, Andriy Gapon wrote: >> on 06/07/2011 21:11 Nathan Whitehorn said the following: >>> On 07/06/11 13:00, Steve Kargl wrote: >>>> AFAICT, it is a cpu affinity issue. If I launch n+1 MPI images >>>> on a system with n cpus/cores, then 2 (and sometimes 3) images >>>> are stuck on a cpu and those 2 (or 3) images ping-pong on that >>>> cpu. I recall trying to use renice(8) to force some load >>>> balancing, but vaguely remember that it did not help. >>> >>> I've seen exactly this problem with multi-threaded math libraries, as well. >> >> Exactly the same? Let's see. >> >>> Using parallel GotoBLAS on FreeBSD gives terrible performance because the >>> threads keep migrating between CPUs, causing frequent cache misses. [*]-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> So Steve reports that if he has Nthr > Ncpu, then some threads are "over-glued" >> to a particular CPU, which results in sub-optimal scheduling for those threads. >> I have to guess that Steve would want to see the threads being shuffled between >> CPUs to produce more even CPU load. > > I'm using OpenMPI. These are N > Ncpu processes not threads, I used 'thread' in a sense of a kernel thread. It shouldn't actually matter if it's a process or a thread in userland in this context. > and without > the loss of generality let N = Ncpu + 1. It is a classic master-slave > situation where 1 process initializes all others. The n-1 slave processes > are then independent of each other. After 20 minutes or so of number > crunching, each slave sends a few 10s of KB of data to the master. The > master collects all the data, writes it to disk, and then sends the > slaves the next set of computations to do. The computations are nearly > identical, so each slave finishes it task in the same amount of time. The > problem appears to be that 2 slaves are bound to the same cpu and the > remaining N - 3 slaves are bound to a specific cpu. The N - 3 slaves > finish their task, send data to the master, and then spin (chewing up > nearly 100% cpu) waiting for the 2 ping-ponging slaves to finishes. > This causes a stall in the computation. When a complete computation > takes days to complete, theses stall become problematic. So, yes, I > want the processes to get a more uniform access to cpus via migration > to other cpus. This is what 4BSD appears to do. I would imagine that periodic rebalancing would take care of this, but probably the ULE rebalancing algorithm is not perfect. There was a suggestion on performance@ to try to use a lower value for kern.sched.steal_thresh, a value of 1 was recommended: http://article.gmane.org/gmane.os.freebsd.performance/3459 >> On the other hand, you report that your threads keep being shuffled between CPUs >> (I presume for Nthr == Ncpu case, where Nthr is a count of the number-crunching >> threads). And I guess that you want them to stay glued to particular CPUs. >> >> So how is this the same problem? In fact, it sounds like somewhat opposite. >> The only thing in common is that you both don't like how ULE works. > > Well, it may be similar in that N - 2 threads are bound to N - 2 > cpus, and the remaining 2 threads are ping ponging on the last It could be, but Nathan has never said this [*] and I also have never seen this in my very limited experiments with GotoBLAS. > remaining cpu. I suspect that GotoBLAS has a large amount > communication between threads, and once again the computations > stalls waiting of the 2 threads to either finish battling for the > 1 cpu or perhaps the process uses pthread_yield() in some clever > way to try to get load balancing. > -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Jul 7 20:08:46 2011 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 1F479106566B; Thu, 7 Jul 2011 20:08:46 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id E94EF8FC08; Thu, 7 Jul 2011 20:08:45 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.4/8.14.4) with ESMTP id p67K8jVj077116; Thu, 7 Jul 2011 13:08:45 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.4/8.14.4/Submit) id p67K8j3F077115; Thu, 7 Jul 2011 13:08:45 -0700 (PDT) (envelope-from sgk) Date: Thu, 7 Jul 2011 13:08:45 -0700 From: Steve Kargl To: Andriy Gapon Message-ID: <20110707200845.GA77049@troutmask.apl.washington.edu> References: <20110706170132.GA68775@troutmask.apl.washington.edu> <5080.1309971941@critter.freebsd.dk> <20110706180001.GA69157@troutmask.apl.washington.edu> <4E14A54A.4050106@freebsd.org> <4E155FF9.5090905@FreeBSD.org> <20110707151440.GA75537@troutmask.apl.washington.edu> <4E160C2F.8020001@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E160C2F.8020001@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: FreeBSD Current , "Hartmann, O." , Nathan Whitehorn Subject: Re: Heavy I/O blocks FreeBSD box for several seconds 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, 07 Jul 2011 20:08:46 -0000 On Thu, Jul 07, 2011 at 10:42:39PM +0300, Andriy Gapon wrote: > on 07/07/2011 18:14 Steve Kargl said the following: >> >> I'm using OpenMPI. These are N > Ncpu processes not threads, > > I used 'thread' in a sense of a kernel thread. It shouldn't > actually matter if it's a process or a thread in userland > in this context. > > > and without > > the loss of generality let N = Ncpu + 1. It is a classic master-slave > > situation where 1 process initializes all others. The n-1 slave processes > > are then independent of each other. After 20 minutes or so of number > > crunching, each slave sends a few 10s of KB of data to the master. The > > master collects all the data, writes it to disk, and then sends the > > slaves the next set of computations to do. The computations are nearly > > identical, so each slave finishes it task in the same amount of time. The > > problem appears to be that 2 slaves are bound to the same cpu and the > > remaining N - 3 slaves are bound to a specific cpu. The N - 3 slaves > > finish their task, send data to the master, and then spin (chewing up > > nearly 100% cpu) waiting for the 2 ping-ponging slaves to finishes. > > This causes a stall in the computation. When a complete computation > > takes days to complete, theses stall become problematic. So, yes, I > > want the processes to get a more uniform access to cpus via migration > > to other cpus. This is what 4BSD appears to do. > > I would imagine that periodic rebalancing would take care of this, > but probably the ULE rebalancing algorithm is not perfect. :-) > There was a suggestion on performance@ to try to use a lower value for > kern.sched.steal_thresh, a value of 1 was recommended: > http://article.gmane.org/gmane.os.freebsd.performance/3459 node16:kargl[215] uname -a FreeBSD node16.cimu.org 9.0-CURRENT FreeBSD 9.0-CURRENT #2 r223824M: Thu Jul 7 11:12:15 PDT 2011 node16:kargl[216] sysctl -a | grep smp.cpu kern.smp.cpus: 4 4BSD kernel gives for N = Ncpu. 33 processes: 5 running, 28 sleeping PID USERNAME THR PRI NICE SIZE RES STATE C TIME CPU COMMAND 1387 kargl 1 67 0 370M 293M CPU1 1 1:31 98.34% sasmp 1384 kargl 1 67 0 370M 293M CPU2 2 1:31 98.34% sasmp 1386 kargl 1 67 0 370M 294M CPU3 3 1:30 98.34% sasmp 1385 kargl 1 67 0 370M 294M RUN 0 1:31 98.29% sasmp 4BSD kernel gives for N = Ncpu + 1. 34 processes: 6 running, 28 sleeping PID USERNAME THR PRI NICE SIZE RES STATE C TIME CPU COMMAND 1417 kargl 1 71 0 370M 294M RUN 0 1:30 79.39% sasmp 1416 kargl 1 71 0 370M 294M RUN 0 1:30 79.20% sasmp 1418 kargl 1 71 0 370M 294M CPU2 0 1:29 78.81% sasmp 1420 kargl 1 71 0 370M 294M CPU1 2 1:30 78.27% sasmp 1419 kargl 1 70 0 370M 294M CPU3 0 1:30 77.59% sasmp Recompiling the kernel to use ULE instead of 4BSD with the exact same hardware and kernel configuration. ULE kernel gives for N = Ncpu. 33 processes: 5 running, 28 sleeping PID USERNAME THR PRI NICE SIZE RES STATE C TIME CPU COMMAND 1294 kargl 1 103 0 370M 294M CPU3 3 1:30 100.00% sasmp 1292 kargl 1 103 0 370M 294M RUN 2 1:30 100.00% sasmp 1295 kargl 1 103 0 370M 293M CPU0 0 1:30 100.00% sasmp 1293 kargl 1 103 0 370M 294M CPU1 1 1:28 100.00% sasmp ULE kernel gives for N = Ncpu + 1. 34 processes: 6 running, 28 sleeping PID USERNAME THR PRI NICE SIZE RES STATE C TIME CPU COMMAND 1318 kargl 1 103 0 370M 294M CPU0 0 1:31 100.00% sasmp 1319 kargl 1 103 0 370M 294M RUN 1 1:29 100.00% sasmp 1322 kargl 1 99 0 370M 294M CPU2 2 1:03 87.26% sasmp 1320 kargl 1 91 0 370M 294M RUN 3 1:07 60.79% sasmp 1321 kargl 1 89 0 370M 294M CPU3 3 1:06 55.18% sasmp node16:root[165] sysctl -w kern.sched.steal_thresh=1 kern.sched.steal_thresh: 2 -> 1 34 processes: 6 running, 28 sleeping PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 1396 kargl 1 103 0 366M 291M CPU3 3 1:30 100.00% sasmp 1397 kargl 1 103 0 366M 291M CPU2 2 1:30 99.17% sasmp 1400 kargl 1 97 0 366M 291M CPU0 0 1:05 83.25% sasmp 1399 kargl 1 94 0 366M 291M RUN 1 1:04 73.97% sasmp 1398 kargl 1 98 0 366M 291M RUN 0 1:01 54.05% sasmp -- Steve From owner-freebsd-current@FreeBSD.ORG Thu Jul 7 21:26:54 2011 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 8347F106566B; Thu, 7 Jul 2011 21:26:54 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5C4A08FC13; Thu, 7 Jul 2011 21:26:54 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 123E646B42; Thu, 7 Jul 2011 17:26:54 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 8B53D8A027; Thu, 7 Jul 2011 17:26:53 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 7 Jul 2011 17:20:50 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <4E100086.7080105@FreeBSD.org> In-Reply-To: <4E100086.7080105@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201107071720.50203.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 07 Jul 2011 17:26:53 -0400 (EDT) Cc: Doug Barton Subject: Re: cardbus panic: end address is not aligned 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, 07 Jul 2011 21:26:54 -0000 On Sunday, July 03, 2011 1:39:18 am Doug Barton wrote: > I have 2 ath-based pc-card adapters. If I put either one of them in the > slot while the system is up, or if I try booting with them in the slot, > I get an instant panic. The cards previously worked in -current, and > continue to work in 8-stable and windows xp. I don't have any other > pc-cards to compare with. Full core.txt.0 file is in my home directory > on freefall. > > This problem persists on r223732 but happened to me for the first time a > week or 2 ago (haven't had time to report it previously, apologies). It > likely originated a while before though, I don't use these cards very > often. > > panic: end address is not aligned > > #1 0xffffffff80426a8a in kern_reboot (howto=260) > at /home/svn/head/sys/kern/kern_shutdown.c:430 > #2 0xffffffff80426521 in panic (fmt=Variable "fmt" is not available. > ) > at /home/svn/head/sys/kern/kern_shutdown.c:604 > #3 0xffffffff8032c648 in pcib_grow_window (sc=0xfffffe0002603400, > w=0xfffffe0002603498, type=3, start=0, end=4294967295, count=65536, > flags=Variable "flags" is not available. The line is here: KASSERT((w->limit & ((1ul << w->step) - 1)) == (1ul << w->step) - 1, ("end address is not aligned")); Can you run kgdb and do 'frame 3' and 'p/x *w'? Also, can you boot your machine, then do 'sysctl debug.bootverbose=1', insert the card and record the messages in dmesg when it does? (You can likely get those out of kgdb.) -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Jul 7 22:51:04 2011 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 4850C106564A; Thu, 7 Jul 2011 22:51:04 +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 EC6AB8FC14; Thu, 7 Jul 2011 22:51:03 +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 <1QexPS-0003Jx-Pk>; Fri, 08 Jul 2011 00:51:02 +0200 Received: from e178023242.adsl.alicedsl.de ([85.178.23.242] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1QexPS-0002J5-MI>; Fri, 08 Jul 2011 00:51:02 +0200 Message-ID: <4E163856.2050300@zedat.fu-berlin.de> Date: Fri, 08 Jul 2011 00:51:02 +0200 From: "Hartmann, O." User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110630 Thunderbird/5.0 MIME-Version: 1.0 To: Andriy Gapon References: <4E1421D9.7080808@zedat.fu-berlin.de> <4E147F54.40908@zedat.fu-berlin.de> <20110706162811.GA68436@troutmask.apl.washington.edu> <20110706193636.GA69550@troutmask.apl.washington.edu> <4E14CCE5.4050906@zedat.fu-berlin.de> <20110707015151.GB71966@troutmask.apl.washington.edu> <20110707031151.GA72452@troutmask.apl.washington.edu> <4E155A84.1010100@FreeBSD.org> In-Reply-To: <4E155A84.1010100@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.23.242 Cc: Adrian Chadd , Steve Kargl , arrowdodger <6yearold@gmail.com>, FreeBSD Current , Arnaud Lacombe , "freebsd-performance@freebsd.org" Subject: Re: Heavy I/O blocks FreeBSD box for several seconds 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, 07 Jul 2011 22:51:04 -0000 On 07/07/11 09:04, Andriy Gapon wrote: > on 07/07/2011 06:11 Steve Kargl said the following: >> Unfortunately, I have neither the brain capacity and time nor >> the money to fix the issue. To solve OP's problem in the >> short, the simplest solution may be to switch to 4BSD. Let's >> face, ULE is not a silver bullet. > I think that piling up different problems into a single discussion, even if they > involve a common component (to a certain degree), is not going to help anybody. > If I have read this thread correctly (and taking the subject line as a witness) > the OP had a problem with heavy I/O activity screwing up interactivity. I think > that it's not the same problem as sub-optimal performance of heavy CPU-bound > load, which is what you reported if I am not mistaken. > This is quibbling. On heavy loads on networ, disk et cetera, isn't there always and also a CPU bound load? Whenever this problem came up, it was brought down by force. Yes, I reported due to the obvious fact that this essential problem involves usability of several workstations. It get more obvious when FreeBSD is used with a GUI. But I also realized, as I reported(!), problems on a headless server, even with several tunings, performed slowly and with increasing numbers over time as recommended here (for instance, kern.sched.preempt_thresh=224 or up to kern.sched.preempt_thresh=512, with little effect). Where, if not here, should such problems be discussed? If we open for each dedicated micro-problem a separate thread, we would never gather that many problems which seem to be related to one single well known 'sweet spot'. From owner-freebsd-current@FreeBSD.ORG Thu Jul 7 23:13:43 2011 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 AD45E106566C; Thu, 7 Jul 2011 23:13:43 +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 646018FC0A; Thu, 7 Jul 2011 23:13:42 +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 <1QexlN-0005TK-Eg>; Fri, 08 Jul 2011 01:13:41 +0200 Received: from e178023242.adsl.alicedsl.de ([85.178.23.242] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1QexlN-0003Oa-B4>; Fri, 08 Jul 2011 01:13:41 +0200 Message-ID: <4E163DA4.6060505@zedat.fu-berlin.de> Date: Fri, 08 Jul 2011 01:13:40 +0200 From: "Hartmann, O." User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110630 Thunderbird/5.0 MIME-Version: 1.0 To: Andriy Gapon References: <20110706170132.GA68775@troutmask.apl.washington.edu> <5080.1309971941@critter.freebsd.dk> <20110706180001.GA69157@troutmask.apl.washington.edu> <4E14A54A.4050106@freebsd.org> <4E155FF9.5090905@FreeBSD.org> In-Reply-To: <4E155FF9.5090905@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.23.242 Cc: "freebsd-performance@freebsd.org" , FreeBSD Current , Nathan Whitehorn , Steve Kargl Subject: Re: Heavy I/O blocks FreeBSD box for several seconds 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, 07 Jul 2011 23:13:43 -0000 On 07/07/11 09:27, Andriy Gapon wrote: > on 06/07/2011 21:11 Nathan Whitehorn said the following: >> On 07/06/11 13:00, Steve Kargl wrote: >>> AFAICT, it is a cpu affinity issue. If I launch n+1 MPI images >>> on a system with n cpus/cores, then 2 (and sometimes 3) images >>> are stuck on a cpu and those 2 (or 3) images ping-pong on that >>> cpu. I recall trying to use renice(8) to force some load >>> balancing, but vaguely remember that it did not help. >> I've seen exactly this problem with multi-threaded math libraries, as well. > Exactly the same? Let's see. > >> Using parallel GotoBLAS on FreeBSD gives terrible performance because the >> threads keep migrating between CPUs, causing frequent cache misses. > So Steve reports that if he has Nthr> Ncpu, then some threads are "over-glued" > to a particular CPU, which results in sub-optimal scheduling for those threads. > I have to guess that Steve would want to see the threads being shuffled between > CPUs to produce more even CPU load. > > On the other hand, you report that your threads keep being shuffled between CPUs > (I presume for Nthr == Ncpu case, where Nthr is a count of the number-crunching > threads). And I guess that you want them to stay glued to particular CPUs. > > So how is this the same problem? In fact, it sounds like somewhat opposite. > The only thing in common is that you both don't like how ULE works. > > ULE has many knobs to tune its behavior. Unfortunately they are not very well > documented and there are too many of them. So, it's not easy to find which > combination would be the best for a particular work-load. In your particular > case you might want to try to increase value of kern.sched.affinity to increase > affinity of threads to their CPUs. Not all of those using FreeBSD are developer or experts, even experts of a very specific area of computer science and engineering or a particular subject of the FreeBSD kernel and its techniques of scheduling. I'm not capable of tuning my servers via a lot of undocumented knobs, I'm sorry. I'd like to do if there would be a kind of howto (handbook?). > > Also, please note that FreeBSD support in GotoBLAS is not equivalent to Linux > support as I have pointed out before. On Linux they bind their threads to CPUs > to avoid the situation that you describe. Apparently they didn't know how to do > CPU-binding on FreeBSD, so this is not implemented. You may have a motivation > to help them out with this. > From owner-freebsd-current@FreeBSD.ORG Thu Jul 7 23:17:57 2011 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 023BB106564A for ; Thu, 7 Jul 2011 23:17:57 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout029.mac.com (asmtpout029.mac.com [17.148.16.104]) by mx1.freebsd.org (Postfix) with ESMTP id D1F368FC0A for ; Thu, 7 Jul 2011 23:17:56 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from cswiger1.apple.com ([17.209.4.71]) by asmtp029.mac.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LNZ00M56KMIYE60@asmtp029.mac.com>; Thu, 07 Jul 2011 16:15:55 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813,1.0.211,0.0.0000 definitions=2011-07-07_10:2011-07-07, 2011-07-07, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1107070220 From: Chuck Swiger In-reply-to: <4E163856.2050300@zedat.fu-berlin.de> Date: Thu, 07 Jul 2011 16:15:54 -0700 Message-id: <5C3302CF-8EE7-489E-8D31-624DA1637B73@mac.com> References: <4E1421D9.7080808@zedat.fu-berlin.de> <4E147F54.40908@zedat.fu-berlin.de> <20110706162811.GA68436@troutmask.apl.washington.edu> <20110706193636.GA69550@troutmask.apl.washington.edu> <4E14CCE5.4050906@zedat.fu-berlin.de> <20110707015151.GB71966@troutmask.apl.washington.edu> <20110707031151.GA72452@troutmask.apl.washington.edu> <4E155A84.1010100@FreeBSD.org> <4E163856.2050300@zedat.fu-berlin.de> To: "Hartmann, O." X-Mailer: Apple Mail (2.1084) Cc: freebsd-performance@freebsd.org, FreeBSD current Subject: Re: Heavy I/O blocks FreeBSD box for several seconds 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, 07 Jul 2011 23:17:57 -0000 On Jul 7, 2011, at 3:51 PM, Hartmann, O. wrote: > This is quibbling. On heavy loads on networ, disk et cetera, isn't there always and also a CPU bound load? No. Properly written software blocks when waiting on network or disk I/O, and doesn't sit there spinning in a busy-wait consuming CPU until it actually gets more work to do. See select(2), kqueue(2), and friends. Regards, -- -Chuck From owner-freebsd-current@FreeBSD.ORG Thu Jul 7 23:45:51 2011 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 83E24106566B; Thu, 7 Jul 2011 23:45:51 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id E43B58FC13; Thu, 7 Jul 2011 23:45:50 +0000 (UTC) Received: by ywf7 with SMTP id 7so735936ywf.13 for ; Thu, 07 Jul 2011 16:45:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=jVjQUkH04ea3unW0HU8dW+DNAZkXaeu98Yg+m86GVrI=; b=j1RDX9t90XgTjVsVVQ64nI2JStye4SQFMyrUo/EodkJWGXqnJ0hF35fhiQx+v4UH0L my4azAtkXNFgKAK0+ymeoRL3osl+BcCKKukj1+mEorhM8rNY3Gd9mzw8GqkuL6Ul6twM X0sS3t6NsWLo1tqhtzi4bav3DQ1XBsezOnHFY= MIME-Version: 1.0 Received: by 10.151.50.15 with SMTP id c15mr1509604ybk.285.1310082350186; Thu, 07 Jul 2011 16:45:50 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.151.45.11 with HTTP; Thu, 7 Jul 2011 16:45:50 -0700 (PDT) In-Reply-To: References: <4E1421D9.7080808@zedat.fu-berlin.de> <4E147F54.40908@zedat.fu-berlin.de> <20110706162811.GA68436@troutmask.apl.washington.edu> <20110706193636.GA69550@troutmask.apl.washington.edu> <4E14CCE5.4050906@zedat.fu-berlin.de> <20110707015151.GB71966@troutmask.apl.washington.edu> Date: Fri, 8 Jul 2011 07:45:50 +0800 X-Google-Sender-Auth: QiFqO3AlDiZ1icJvGKpMKp-le5o Message-ID: From: Adrian Chadd To: Arnaud Lacombe Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Current , "Hartmann, O." , arrowdodger <6yearold@gmail.com>, Steve Kargl , freebsd-questions@freebsd.org Subject: Re: Heavy I/O blocks FreeBSD box for several seconds 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, 07 Jul 2011 23:45:51 -0000 (OT, yes, but I'd like to take a stab at explaining "why" these things fall to the wayside..) On 7 July 2011 12:08, Arnaud Lacombe wrote: > What would be the point to even start looking at an issue? You guys > (by "you", I mean "official" committers on public list) don't care When someone who has an active interest takes ownership of the problem. > about people providing patches, might it be for trivial, obvious, > fixes. I'm not even talking about complex patches ... When you > eventually ends up providing a patch, you ends up being slammed a door > at by maintainers asserting their code is perfect, until logic and > user complaints prove them wrong. > > That said, this comment is off-topic, but I will certainly re-state > this next month when I'll be ping'ing trivial patches. The problem is that someone doesn't own the problem. If I commit someone's fix to the tree without really understanding what's going on, I take ownership of that change and any issues/breakages/changes that it creates. The people responsible for these areas are likely very busy with other things. It's not that they don't want to help! It's much more likely that they don't have the time. Trivial patches aren't always so trivial. You can change the behaviour of something subtle which works great for you and not for others. This is very likely what's going on with IO/CPU scheduling. It's a tricky area. A simple fix isn't always as simple. So if there's a diagnosed problem, with reproducable test cases and some patches which fix it, I suggest doing something like the following: * create a webpage, even if it's a wiki somewhere (even wiki.freebsd.org if you ask someone nicely) * dump all the information you can in there. Having stuff in emails is great - but it's only really helpful for tracking the 'flow' of a discussion. Having a summarised analysis of all of that on a webpage is much more helpful. * Add the patches there. * Encourage people who aren't in your immediate community to try them too - to try and find if your changes mess up other configurations somehow. * Be persistent trying to get your changes in. If you've done the background research, done some wide-spread testing and show you've not caused any obvious regressions, you're much more likely to get your changes in. With all of that done, you can likely find a committer who will help you get your fixes into the tree. Please just try not to interpret a lack of response as a lack of interest. There's only so much time in the day and committers tend to be a busy bunch, with day jobs that may in no way reflect their FreeBSD interests. Finally, if people do enough of the above and begin to take ownership of parts of the tree, you'll find someone will likely sponsor you for a commit bit. HTH, Adrian From owner-freebsd-current@FreeBSD.ORG Fri Jul 8 01:38:49 2011 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 06FF7106564A for ; Fri, 8 Jul 2011 01:38:49 +0000 (UTC) (envelope-from moonlightakkiy@yahoo.ca) Received: from nm10.bullet.mail.sp2.yahoo.com (nm10.bullet.mail.sp2.yahoo.com [98.139.91.80]) by mx1.freebsd.org (Postfix) with SMTP id CB5288FC15 for ; Fri, 8 Jul 2011 01:38:48 +0000 (UTC) Received: from [98.139.91.64] by nm10.bullet.mail.sp2.yahoo.com with NNFMP; 08 Jul 2011 01:25:41 -0000 Received: from [98.136.185.41] by tm4.bullet.mail.sp2.yahoo.com with NNFMP; 08 Jul 2011 01:25:41 -0000 Received: from [127.0.0.1] by smtp102.mail.gq1.yahoo.com with NNFMP; 08 Jul 2011 01:25:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.ca; s=s1024; t=1310088341; bh=TNhuNKdgDCceSVVX8jXb0VQFOeVTmorFtDpYNBz4Oec=; h=X-Yahoo-Newman-Id:Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Received:MIME-Version:Received:Received:In-Reply-To:References:Date:Message-ID:Subject:From:To:Cc:Content-Type:Content-Transfer-Encoding; b=rwl1iyVfFnIaKzxMjpt9V7LfsN4iB62NrM1YyPjLuJv1D3mxmdfuY22NxsB5jQUr7s6qK148Cp26+OF6FYeIBEi5S5cMqwyHmVbAA7+qrrfGB0BBiipWAEG2bPLPtn6ZuVY/BqzCi2vgbXHg0Fy5+fzaF3FOICkIJ/3IqNZ4jC8= X-Yahoo-Newman-Id: 241197.82562.bm@smtp102.mail.gq1.yahoo.com Received: from mail-vx0-f182.google.com (moonlightakkiy@209.85.220.182 with plain) by smtp102.mail.gq1.yahoo.com with SMTP; 07 Jul 2011 18:25:40 -0700 PDT X-Yahoo-SMTP: Xr6qjFWswBAEmd20sAvB4Q3keqXvXsIH9TjJ X-YMail-OSG: uWPVWqwVM1nhy5ASmqxgKL4UTl_AUG0T8N097CjsxA7HWgy l.wzzwBv3eIZ1H00QWYuSj9lz3QH5rLHKOkM7KFRt8PaHfvANjQM8QtZVJ7d 72bUQTojH5jXiQK38vGH.lkf699OvizKRbl_pUrUyiUZCA8rU7LHm8egfC2P 56bjFLmiOk_gMJh3mKl_5vP4zUlgCBU4bs1QbgOoCTzVOYo2PDkFkxOORnIG TO6fZWpHMuREILp1cmJQSROOSO_W2kEKXqrPY5JLy0P4j0_aguQ9pyEEX.Gv tR6FhdSLHsqqu0YuqyrqG1uWmMMiwcdmbT3QRjtNFYjo43A7r4.U5ZIVnSo7 MhrrG.BFxGlZG26kiFnhB6WDSOlpWd5QtdMYYfLR35_R1MFMjI0UUWZVV3Lh 9yTzeolWOi2bZsPPTfG_xB0bhHbuTlN8bmE0U4yaTyqx.Cim6oig0dXRix31 jz09.hMF2HCgzSOhupmpevjZ2PYBHwkA4XwO9tUV4KGYdMD9UYpYozRiu1Zh 7RH3ARstJLJI2mxDg4t1Si2MlEK6xNwcMpfEsOShBqoBM8nyKzQ-- X-Yahoo-Newman-Property: ymail-3 Received: by vxg33 with SMTP id 33so1489179vxg.13 for ; Thu, 07 Jul 2011 18:25:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.179.131 with SMTP id dg3mr2144865vdc.9.1310088339378; Thu, 07 Jul 2011 18:25:39 -0700 (PDT) Received: by 10.52.108.229 with HTTP; Thu, 7 Jul 2011 18:25:39 -0700 (PDT) In-Reply-To: <201107071447.53041.hselasky@c2i.net> References: <1309237117.88943.YahooMailNeo@web39307.mail.mud.yahoo.com> <201107061719.38445.hselasky@c2i.net> <201107071447.53041.hselasky@c2i.net> Date: Thu, 7 Jul 2011 19:25:39 -0600 Message-ID: From: PseudoCylon To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, "freebsd-wireless@freebsd.org" Subject: Re: [CFT] Sierra Wireless HSPA+ USB modem 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, 08 Jul 2011 01:38:49 -0000 On Thu, Jul 7, 2011 at 6:47 AM, Hans Petter Selasky wrot= e: > On Thursday 07 July 2011 14:43:22 PseudoCylon wrote: >> On Wed, Jul 6, 2011 at 9:19 AM, Hans Petter Selasky > wrote: >> >> Hi, >> >> >> >> I'm going to review and import your driver. >> >> >> >> --HPS >> > >> > Hi, >> > >> > The intial patch had some bad code and didn't compile on 9-current. I'= ve >> > tried to clean it up. Please test and report back if I didn't break >> > anything. >> > >> > http://hselasky.homeunix.org:8192/usie_for_FreeBSD_9_current.patch >> > >> > --HPS >> >> Hello, >> >> Thanks for the patch. >> >> if_usie.c >> 241 =A0 if (usbd_lookup_id_by_uaa(usie_devs, sizeof(usie_devs), uaa) != =3D 0) >> 242 =A0 =A0 =A0 =A0 =A0 return; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* no de= vice match */ >> >> It should return non-zero on success, but somehow this caused the >> process to exit, and modem stayed being a CD-ROM. > > Hi, > > Is this device changing its USB vendor and product ID ? > Yes, it does. So I added the device id for cd-rom, SIERRA, TRUINSTALL (already in usbdevs). static const STRUCT_USB_HOST_ID usie_devs[] =3D { #define USIE_DEV(v, d) { \ USB_VP(USB_VENDOR_##v, USB_PRODUCT_##v##_##d) } USIE_DEV(SIERRA, MC8700), USIE_DEV(AIRPRIME, USB308), + USIE_DEV(SIERRA, TRUINSTALL), #undef USIE_DEV }; Now it works even if the modem is plugged in before loading the driver. The device id 0x0fff is for cd-rom, but sierra didn't specify the vendor id. So, there might be (AIRPRIME, TRUINSTALL). With your "uint8_t pad" fix, the driver works fine. Thanks AK Here is a patch. diff --git a/sys/dev/usb/net/if_usie.c b/sys/dev/usb/net/if_usie.c index 552765b..f6f6c60 100644 --- a/sys/dev/usb/net/if_usie.c +++ b/sys/dev/usb/net/if_usie.c @@ -88,6 +88,7 @@ static const STRUCT_USB_HOST_ID usie_devs[] =3D { USB_VP(USB_VENDOR_##v, USB_PRODUCT_##v##_##d) } USIE_DEV(SIERRA, MC8700), USIE_DEV(AIRPRIME, USB308), + USIE_DEV(SIERRA, TRUINSTALL), #undef USIE_DEV }; @@ -1522,8 +1523,9 @@ usie_hip_rsp(struct usie_softc *sc, uint8_t *rsp, uint32_t len) DPRINTF("hip: len=3D%d msgID=3D%02x, param=3D%02x\n", be16toh(hip->len), hip->id, hip->param); + pad =3D (hip->id & USIE_HIP_PAD) ? 1 : 0; + if ((hip->id & USIE_HIP_MASK) =3D=3D USIE_HIP_CNS2H) { - pad =3D (hip->id & USIE_HIP_PAD) ? 1 : 0; cns =3D (struct usie_cns *)(((uint8_t *)(hip + 1)) + pad); if (j < (sizeof(struct usie_cns) + From owner-freebsd-current@FreeBSD.ORG Fri Jul 8 05:28:24 2011 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 4AA46106564A for ; Fri, 8 Jul 2011 05:28:24 +0000 (UTC) (envelope-from freebsd@berczi.be) Received: from macsec.hu (cl-23.bud-01.hu.sixxs.net [IPv6:2a01:368:e000:16::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0FC1B8FC15 for ; Fri, 8 Jul 2011 05:28:23 +0000 (UTC) Received: from [10.11.0.1] by macsec.hu with esmtp (Exim 4.75 (FreeBSD)) (envelope-from ) id 1Qf3bw-000BP1-Ro; Fri, 08 Jul 2011 07:28:20 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Berczi Gabor In-Reply-To: <4E158846.4040807@gmail.com> Date: Fri, 8 Jul 2011 07:28:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <12DA9EAC-8677-49AD-BA6C-5A155D2A6122@berczi.be> <4E14C0D9.9040503@gmail.com> <2040FCF6-2CA2-4CF3-BB78-F5A3069297FF@berczi.be> <4E158846.4040807@gmail.com> To: Volodymyr Kostyrko X-Mailer: Apple Mail (2.1084) Cc: freebsd-current@freebsd.org Subject: Re: ZFS boot fails with two pools 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, 08 Jul 2011 05:28:24 -0000 On Jul 7, 2011, at 12:19 PM, Volodymyr Kostyrko wrote: >>> 2. Try to convince bios to boot from the disk of pool2. >>=20 >> There is no disk with a singular ZFS pool. >=20 > Any disk from bootable pool. Every disk contains two pools. And the BIOS sees only two (maybe three) = of them. >>> 3. You can possibly try deploying /boot/boot0 MBR selector code over = disks of data pool. Supplied boot0 code can be used to choose another = disk to jump to it during boot process and will remember the last = choice. >>=20 >> I'm not really sure how to do this with GPT. Should I use boot0 = instead of pmbr? >=20 > boot0cfg is your old friend Cool, how do we get acquinted? > Actuall I think that code on that stages just tries to boot from the = pool on the current disk. There are two pools on it... From owner-freebsd-current@FreeBSD.ORG Fri Jul 8 07:37:53 2011 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 09E97106566B; Fri, 8 Jul 2011 07:37:53 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe08.c2i.net [212.247.154.226]) by mx1.freebsd.org (Postfix) with ESMTP id 609508FC08; Fri, 8 Jul 2011 07:37:51 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=0STrgBBJ/IeSzGUncdVPgrlXwYQACyAaeTEJnWJdz8Q= c=1 sm=1 a=SvYTsOw2Z4kA:10 a=8GCaWQNJa_IA:10 a=WQU8e4WWZSUA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=8kQB0OdkAAAA:8 a=N3vH5299AAAA:8 a=j57HFelR7c5eax5xvCcA:9 a=mf3W9SHYvq4Z4mZeRX8A:7 a=wPNLvfGTeEIA:10 a=9aOQ2cSd83gA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe08.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 150414763; Fri, 08 Jul 2011 09:37:50 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Fri, 8 Jul 2011 09:35:58 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: <1309237117.88943.YahooMailNeo@web39307.mail.mud.yahoo.com> <201107071447.53041.hselasky@c2i.net> In-Reply-To: X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq,NwSZ4V" =?iso-8859-1?q?=7CLR=2E+tj=7Dg5=0A=09=25V?=,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( =?iso-8859-1?q?=0A=09=3AAuzV9=3A=2EhESm-x4h240C=609=3Dw?= MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201107080935.58680.hselasky@c2i.net> Cc: PseudoCylon , "freebsd-wireless@freebsd.org" Subject: Re: [CFT] Sierra Wireless HSPA+ USB modem 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, 08 Jul 2011 07:37:53 -0000 On Friday 08 July 2011 03:25:39 PseudoCylon wrote: > On Thu, Jul 7, 2011 at 6:47 AM, Hans Petter Selasky wrote: > > On Thursday 07 July 2011 14:43:22 PseudoCylon wrote: > >> On Wed, Jul 6, 2011 at 9:19 AM, Hans Petter Selasky > > > > wrote: > >> >> Hi, > >> >> > >> >> I'm going to review and import your driver. > >> >> > >> >> --HPS > >> > > >> > Hi, > >> > > >> > The intial patch had some bad code and didn't compile on 9-current. > >> > I've tried to clean it up. Please test and report back if I didn't > >> > break anything. > >> > > >> > http://hselasky.homeunix.org:8192/usie_for_FreeBSD_9_current.patch > >> > > >> > --HPS > >> > >> Hello, > >> Hi, Can I remove the mock DHCP client? It does not appear to be sending the DHCP frames anywhere, except BPF ? --HPS From owner-freebsd-current@FreeBSD.ORG Fri Jul 8 08:48:36 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 065F31065672; Fri, 8 Jul 2011 08:48:36 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-4.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id B8D2A14F30D; Fri, 8 Jul 2011 08:48:35 +0000 (UTC) Message-ID: <4E16C463.9020604@FreeBSD.org> Date: Fri, 08 Jul 2011 01:48:35 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110706 Thunderbird/5.0 MIME-Version: 1.0 To: John Baldwin References: <4E100086.7080105@FreeBSD.org> <201107071720.50203.jhb@freebsd.org> In-Reply-To: <201107071720.50203.jhb@freebsd.org> X-Enigmail-Version: 1.2pre OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: cardbus panic: end address is not aligned 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, 08 Jul 2011 08:48:36 -0000 On 07/07/2011 14:20, John Baldwin wrote: > On Sunday, July 03, 2011 1:39:18 am Doug Barton wrote: >> I have 2 ath-based pc-card adapters. If I put either one of them in the >> slot while the system is up, or if I try booting with them in the slot, >> I get an instant panic. The cards previously worked in -current, and >> continue to work in 8-stable and windows xp. I don't have any other >> pc-cards to compare with. Full core.txt.0 file is in my home directory >> on freefall. >> >> This problem persists on r223732 but happened to me for the first time a >> week or 2 ago (haven't had time to report it previously, apologies). It >> likely originated a while before though, I don't use these cards very >> often. >> >> panic: end address is not aligned >> >> #1 0xffffffff80426a8a in kern_reboot (howto=260) >> at /home/svn/head/sys/kern/kern_shutdown.c:430 >> #2 0xffffffff80426521 in panic (fmt=Variable "fmt" is not available. >> ) >> at /home/svn/head/sys/kern/kern_shutdown.c:604 >> #3 0xffffffff8032c648 in pcib_grow_window (sc=0xfffffe0002603400, >> w=0xfffffe0002603498, type=3, start=0, end=4294967295, count=65536, >> flags=Variable "flags" is not available. > > The line is here: > > KASSERT((w->limit & ((1ul << w->step) - 1)) == (1ul << w->step) - 1, > ("end address is not aligned")); > > Can you run kgdb and do 'frame 3' and 'p/x *w'? (kgdb) frame 3 #3 0xffffffff8032c648 in pcib_grow_window (sc=0xfffffe0002603400, w=0xfffffe0002603498, type=3, start=0, end=4294967295, count=65536, flags=Variable "flags" is not available. ) at /home/svn/head/sys/dev/pci/pci_pci.c:1018 1018 KASSERT((w->limit & ((1ul << w->step) - 1)) == (1ul << w->step) - 1, (kgdb) p/x *w $1 = {base = 0x80000000, limit = 0x8800ffff, rman = {rm_list = { tqh_first = 0xfffffe0002702a00, tqh_last = 0xfffffe0002702a98}, rm_mtx = 0xfffffe00024e20e0, rm_link = {tqe_next = 0xfffffe0002603520, tqe_prev = 0xfffffe0002603448}, rm_start = 0x0, rm_end = 0xffffffff, rm_type = 0x2, rm_descr = 0xfffffe0002608060}, res = 0xfffffe0002702b00, reg = 0x20, valid = 0x1, mask = 0x2, step = 0x14, name = 0xffffffff8071b77c} > Also, can you boot your machine, then do 'sysctl debug.bootverbose=1', insert > the card and record the messages in dmesg when it does? (You can likely get > those out of kgdb.) The system panics instantly when I insert the cards. Would a verbose dmesg entry from 8.2-stable work? I can do that on the same hardware. If not I can try it on -current and see if anything gets logged. Thanks for taking a look! Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Fri Jul 8 11:00:33 2011 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 7B505106566B; Fri, 8 Jul 2011 11:00:33 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe07.c2i.net [212.247.154.194]) by mx1.freebsd.org (Postfix) with ESMTP id CAADB8FC0A; Fri, 8 Jul 2011 11:00:32 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=SJA03SmFjIOBaRUqQpAxZTuC3Mg0Qr8luS0qYjfHCY4= c=1 sm=1 a=SvYTsOw2Z4kA:10 a=8GCaWQNJa_IA:10 a=WQU8e4WWZSUA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=6I5d2MoRAAAA:8 a=LaiKOz6ysApxJTeDc58A:9 a=wPNLvfGTeEIA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe07.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 150239985; Fri, 08 Jul 2011 13:00:30 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Fri, 8 Jul 2011 12:58:39 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: <1309237117.88943.YahooMailNeo@web39307.mail.mud.yahoo.com> <201107071447.53041.hselasky@c2i.net> In-Reply-To: X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq,NwSZ4V" =?iso-8859-1?q?=7CLR=2E+tj=7Dg5=0A=09=25V?=,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( =?iso-8859-1?q?=0A=09=3AAuzV9=3A=2EhESm-x4h240C=609=3Dw?= MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201107081258.39300.hselasky@c2i.net> Cc: PseudoCylon , "freebsd-wireless@freebsd.org" Subject: Re: [CFT] Sierra Wireless HSPA+ USB modem 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, 08 Jul 2011 11:00:33 -0000 Hi, I found some more bugs/issues before I committed the driver. Please verify: http://svn.freebsd.org/changeset/base/223864 --HPS From owner-freebsd-current@FreeBSD.ORG Fri Jul 8 11:47:09 2011 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 57FA2106566B; Fri, 8 Jul 2011 11:47:09 +0000 (UTC) (envelope-from matpockuh@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0A0738FC08; Fri, 8 Jul 2011 11:47:08 +0000 (UTC) Received: by pzk27 with SMTP id 27so1862568pzk.13 for ; Fri, 08 Jul 2011 04:47:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+fT/Y8FcEJNH8lg8q4bfLG50UBLgD5zhwHDrcC66bJc=; b=oVdvyZfJxSKLdHgydP32ne45JySqOUvvwHFKyXqU1oqHR0UqJ152huZrnHEVNg8glJ S0bBT3VeaEEgnj7M1kBW6hFssnRs+fL2rJ0yB8H1SjYEXj3bXsauOidpcJ1QkYAfCcRv 1U+bkHZs0iC+QyvQrx4YSbnpDv0Ha3Gql/RTY= MIME-Version: 1.0 Received: by 10.68.36.129 with SMTP id q1mr2746908pbj.374.1310125628421; Fri, 08 Jul 2011 04:47:08 -0700 (PDT) Received: by 10.68.62.97 with HTTP; Fri, 8 Jul 2011 04:47:08 -0700 (PDT) In-Reply-To: <20110707154958.GK14797@alchemy.franken.de> References: <20110629134140.GF14797@alchemy.franken.de> <4E0B8F25.7090107@FreeBSD.org> <20110707100446.GJ14797@alchemy.franken.de> <20110707154958.GK14797@alchemy.franken.de> Date: Fri, 8 Jul 2011 15:47:08 +0400 Message-ID: From: KOT MATPOCKuH To: Marius Strobl Content-Type: text/plain; charset=ISO-8859-1 Cc: Doug Barton , FreeBSD Current Subject: Re: named crashes on assertion in rbtdb.c on sparc64/SMP 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, 08 Jul 2011 11:47:09 -0000 2011/7/7 Marius Strobl : > That's not the patch I was referring to. I did a second one which just > entirely disables the use of atomic operations on sparc64: > http://people.freebsd.org/~marius/sparc64_isc_disable_atomic.diff Omg. I'm sorry. I applied this patch and restarted named, but named crashed immediatly after start: 08-Jul-2011 15:29:54.631 found 2 CPUs, using 2 worker threads 08-Jul-2011 15:29:54.633 using up to 4096 sockets Segmentation fault (core dumped) core's backtrace: #0 0x0000000040953ba8 in __sparc_utrap_install () from /lib/libc.so.7 (gdb) bt #0 0x0000000040953ba8 in __sparc_utrap_install () from /lib/libc.so.7 #1 0x0000000040953ccc in __sparc_utrap_install () from /lib/libc.so.7 #2 0x0000000040953f70 in __sparc_utrap_install () from /lib/libc.so.7 #3 0x00000000409537ac in __sparc_utrap_install () from /lib/libc.so.7 #4 0x00000000407c2d54 in pthread_mutex_lock () from /lib/libthr.so.3 #5 0x0000000000228dcc in ?? () Previous frame identical to this frame (corrupt stack?) Could this be a sign to a problem in libthr? PS. Also one month ago I got a problems with another multithreaded application from ports (www/oops). oops was crashed with stack's backtrace: #0 0x0000000040d8fc88 in __sparc_utrap_install () from /lib/libc.so.7 #1 0x0000000040d8fdac in __sparc_utrap_install () from /lib/libc.so.7 #2 0x0000000040d90050 in __sparc_utrap_install () from /lib/libc.so.7 #3 0x0000000040d8f88c in __sparc_utrap_install () from /lib/libc.so.7 #4 0x0000000040d64044 in _malloc_thread_cleanup () from /lib/libc.so.7 #5 0x0000000040c039b8 in fork () from /lib/libthr.so.3 #6 0x0000000040c03d38 in fork () from /lib/libthr.so.3 #7 0x0000000040c03f50 in pthread_exit () from /lib/libthr.so.3 #8 0x0000000040c04414 in pthread_detach () from /lib/libthr.so.3 #9 0x0000000040c04710 in pthread_create () from /lib/libthr.so.3 But on yesterday's world's build oops works properly. I think it may be related to r223228 (?) Or I incorrectly analyze stack for multithreaded applications? -- MATPOCKuH From owner-freebsd-current@FreeBSD.ORG Fri Jul 8 13:05:45 2011 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 61668106566B for ; Fri, 8 Jul 2011 13:05:45 +0000 (UTC) (envelope-from moonlightakkiy@yahoo.ca) Received: from nm12-vm0.bullet.mail.ne1.yahoo.com (nm12-vm0.bullet.mail.ne1.yahoo.com [98.138.91.51]) by mx1.freebsd.org (Postfix) with SMTP id 145238FC13 for ; Fri, 8 Jul 2011 13:05:44 +0000 (UTC) Received: from [98.138.90.51] by nm12.bullet.mail.ne1.yahoo.com with NNFMP; 08 Jul 2011 13:05:44 -0000 Received: from [98.138.84.37] by tm4.bullet.mail.ne1.yahoo.com with NNFMP; 08 Jul 2011 13:05:44 -0000 Received: from [127.0.0.1] by smtp105.mail.ne1.yahoo.com with NNFMP; 08 Jul 2011 13:05:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.ca; s=s1024; t=1310130344; bh=V5RQZntOgadmuSlTCtkhciID77DGV2sLc3mDm/dR4iA=; h=X-Yahoo-Newman-Id:Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Received:MIME-Version:Received:Received:In-Reply-To:References:Date:Message-ID:Subject:From:To:Cc:Content-Type; b=Q4JTPAAW/bYh8HlEWZ+rdZvWR1ckjMuAnPfCSdPWZMcLwOQlBzi8++nGiNvkrOHNAGZBOIa6XBxa3Buvs9Uq9MzA+deaUbJ8HaXADWgz+hKqvpXEaNdfYH4G/DxaV51g14+jskHszUTEoUhU3sHUiCdj4GhlTozvk4fWib8ZLXA= X-Yahoo-Newman-Id: 522401.51087.bm@smtp105.mail.ne1.yahoo.com Received: from mail-vw0-f54.google.com (moonlightakkiy@209.85.212.54 with plain) by smtp105.mail.ne1.yahoo.com with SMTP; 08 Jul 2011 06:05:43 -0700 PDT X-Yahoo-SMTP: Xr6qjFWswBAEmd20sAvB4Q3keqXvXsIH9TjJ X-YMail-OSG: yQpvkHwVM1nrWuntocx4RH0BY6ez.MDVTkIHXRl2lkCVExZ g6uQrFLBh93LBR_zDUAxNWjAPANCZrDrNr97LDmM2HEqgcDKWxNuY0gJg1SB eYg_MMhahAbACrpZHDW6Oe6Xd9GF93vnxQUl7Bxv13yDUILEHBoiOgi9046s vpLDtKueCkAyCu.XdCXx7JFBqVpuJJF0EvjComUUzyD54fj.FVtt0Nnz3MUn oELQjb6UgDYvxsNMRFx_UGDpccu9HcledkxNd6qx4kJW_P9.LJo7iZJeUlH7 a1dQcSavPQKTD9Y6IElFDTj.OWj1DXRumEq2lus7f.BjSzaCeZXFqGdD_V_1 OBaZI6hASnuTNnlG3zpd4JGbVZsUkLjfj8OYpHT_0bnAfTFHw3.bS6iNzovF Nai52_kwCLbynUuY_b5hBqD4TrCfmS28BBRhTdb5SvwetVEiGeLd4pjE7ppw hJqlizdMJnhdIEEkzS_Dd3ZxXilIcTW6ffNc_cLJD774- X-Yahoo-Newman-Property: ymail-3 Received: by vws18 with SMTP id 18so1888079vws.13 for ; Fri, 08 Jul 2011 06:05:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.179.131 with SMTP id dg3mr2879930vdc.9.1310128823094; Fri, 08 Jul 2011 05:40:23 -0700 (PDT) Received: by 10.52.108.229 with HTTP; Fri, 8 Jul 2011 05:40:23 -0700 (PDT) In-Reply-To: <201107080935.58680.hselasky@c2i.net> References: <1309237117.88943.YahooMailNeo@web39307.mail.mud.yahoo.com> <201107071447.53041.hselasky@c2i.net> <201107080935.58680.hselasky@c2i.net> Date: Fri, 8 Jul 2011 06:40:23 -0600 Message-ID: From: PseudoCylon To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org, "freebsd-wireless@freebsd.org" Subject: Re: [CFT] Sierra Wireless HSPA+ USB modem 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, 08 Jul 2011 13:05:45 -0000 On Fri, Jul 8, 2011 at 1:35 AM, Hans Petter Selasky wrote: > On Friday 08 July 2011 03:25:39 PseudoCylon wrote: >> On Thu, Jul 7, 2011 at 6:47 AM, Hans Petter Selasky > wrote: >> > On Thursday 07 July 2011 14:43:22 PseudoCylon wrote: >> >> On Wed, Jul 6, 2011 at 9:19 AM, Hans Petter Selasky >> > >> > wrote: >> >> >> Hi, >> >> >> >> >> >> I'm going to review and import your driver. >> >> >> >> >> >> --HPS >> >> > >> >> > Hi, >> >> > >> >> > The intial patch had some bad code and didn't compile on 9-current. >> >> > I've tried to clean it up. Please test and report back if I didn't >> >> > break anything. >> >> > >> >> > http://hselasky.homeunix.org:8192/usie_for_FreeBSD_9_current.patch >> >> > >> >> > --HPS >> >> >> >> Hello, >> >> > > Hi, > > Can I remove the mock DHCP client? > Yes, you can. I had a feeling of it won't go into the src tree. That's why it was in a separate file. The only drawback is now users have to manually set up the connection. Here is an updated how-to-use #ifconfig usie0 up IP and DNS addr will be printed on the console. Using those addr, #ifconfig usie0 inet N.N.N.N #ifconfig usie0 defaultif #echo "nameserver N.N.N.N" > /etc/resolv.conf One nemaserve is sufficient. #echo "nameserver N.N.N.N" >> /etc/resolv.conf And, I have tried the committed version of the driver, and it is working fine. Thanks for committing. AK From owner-freebsd-current@FreeBSD.ORG Fri Jul 8 13:20:00 2011 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 301E6106566B; Fri, 8 Jul 2011 13:20:00 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id E439A8FC1F; Fri, 8 Jul 2011 13:19:59 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 6765846B45; Fri, 8 Jul 2011 09:19:59 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id F062C8A02C; Fri, 8 Jul 2011 09:19:58 -0400 (EDT) From: John Baldwin To: Doug Barton Date: Fri, 8 Jul 2011 09:19:58 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <4E100086.7080105@FreeBSD.org> <201107071720.50203.jhb@freebsd.org> <4E16C463.9020604@FreeBSD.org> In-Reply-To: <4E16C463.9020604@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201107080919.58210.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 08 Jul 2011 09:19:59 -0400 (EDT) Cc: freebsd-current@freebsd.org Subject: Re: cardbus panic: end address is not aligned 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, 08 Jul 2011 13:20:00 -0000 On Friday, July 08, 2011 4:48:35 am Doug Barton wrote: > On 07/07/2011 14:20, John Baldwin wrote: > > On Sunday, July 03, 2011 1:39:18 am Doug Barton wrote: > >> I have 2 ath-based pc-card adapters. If I put either one of them in the > >> slot while the system is up, or if I try booting with them in the slot, > >> I get an instant panic. The cards previously worked in -current, and > >> continue to work in 8-stable and windows xp. I don't have any other > >> pc-cards to compare with. Full core.txt.0 file is in my home directory > >> on freefall. > >> > >> This problem persists on r223732 but happened to me for the first time a > >> week or 2 ago (haven't had time to report it previously, apologies). It > >> likely originated a while before though, I don't use these cards very > >> often. > >> > >> panic: end address is not aligned > >> > >> #1 0xffffffff80426a8a in kern_reboot (howto=260) > >> at /home/svn/head/sys/kern/kern_shutdown.c:430 > >> #2 0xffffffff80426521 in panic (fmt=Variable "fmt" is not available. > >> ) > >> at /home/svn/head/sys/kern/kern_shutdown.c:604 > >> #3 0xffffffff8032c648 in pcib_grow_window (sc=0xfffffe0002603400, > >> w=0xfffffe0002603498, type=3, start=0, end=4294967295, count=65536, > >> flags=Variable "flags" is not available. > > > > The line is here: > > > > KASSERT((w->limit & ((1ul << w->step) - 1)) == (1ul << w->step) - 1, > > ("end address is not aligned")); > > > > Can you run kgdb and do 'frame 3' and 'p/x *w'? > > (kgdb) frame 3 > #3 0xffffffff8032c648 in pcib_grow_window (sc=0xfffffe0002603400, > w=0xfffffe0002603498, type=3, start=0, end=4294967295, count=65536, > flags=Variable "flags" is not available. > ) > at /home/svn/head/sys/dev/pci/pci_pci.c:1018 > 1018 KASSERT((w->limit & ((1ul << w->step) - 1)) == (1ul << w->step) - 1, > (kgdb) p/x *w > $1 = {base = 0x80000000, limit = 0x8800ffff, rman = {rm_list = { > tqh_first = 0xfffffe0002702a00, tqh_last = 0xfffffe0002702a98}, > rm_mtx = 0xfffffe00024e20e0, rm_link = {tqe_next = 0xfffffe0002603520, > tqe_prev = 0xfffffe0002603448}, rm_start = 0x0, rm_end = 0xffffffff, > rm_type = 0x2, rm_descr = 0xfffffe0002608060}, res = > 0xfffffe0002702b00, > reg = 0x20, valid = 0x1, mask = 0x2, step = 0x14, name = > 0xffffffff8071b77c} Hmm, well that's odd. It didn't grow it enough it seems. > > Also, can you boot your machine, then do 'sysctl debug.bootverbose=1', insert > > the card and record the messages in dmesg when it does? (You can likely get > > those out of kgdb.) > > The system panics instantly when I insert the cards. Would a verbose > dmesg entry from 8.2-stable work? I can do that on the same hardware. > If not I can try it on -current and see if anything gets logged. Err, if you can get a crashdump, you can use 'printf "%s", msgbufp->msg_ptr' in kgdb to output all of dmseg. You can also use the 'dmesg' command against a crash dump directly, and if you have crashinfo enabled, the tail of the core.txt.N file in /var/crash will have the full dmesg in it as well. The real messages I will want to see are in the dmesg. Also, getting the output of 'devinfo -r' before you insert the card would also be helpful so I can see what it is growing from. Actually, forgo all that. Try this patch: Index: pci_pci.c =================================================================== --- pci_pci.c (revision 223847) +++ pci_pci.c (working copy) @@ -954,7 +954,7 @@ pcib_grow_window(struct pcib_softc *sc, struct pci if (bootverbose) printf("\tback candidate range: %#lx-%#lx\n", start_free, back); - back = roundup2(back + 1, w->step) - 1; + back = roundup2(back + 1, 1ul << w->step) - 1; back -= rman_get_end(w->res); } else back = 0; -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Jul 8 14:51:49 2011 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 2A7FD106564A for ; Fri, 8 Jul 2011 14:51:49 +0000 (UTC) (envelope-from jwd@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 19D2B8FC0C for ; Fri, 8 Jul 2011 14:51:49 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p68EpmCo021696 for ; Fri, 8 Jul 2011 14:51:48 GMT (envelope-from jwd@freefall.freebsd.org) Received: (from jwd@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p68EpmEI021695 for freebsd-current@freebsd.org; Fri, 8 Jul 2011 14:51:48 GMT (envelope-from jwd) Date: Fri, 8 Jul 2011 14:51:48 +0000 From: John To: freebsd-current@freebsd.org Message-ID: <20110708145148.GA12548@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Mailman-Approved-At: Fri, 08 Jul 2011 16:35:22 +0000 Subject: kenv values with ansi escapte sequences - ansi_caption 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, 08 Jul 2011 14:51:49 -0000 Hi Folks, It seems the new pre-boot options selection process has some values defined within the kernel environment that contain ansi control sequences. For instance: # kenv LINES="24" ansi_caption[1]="Boot [ENTER]" ansi_caption[2]="Escape to loader prompt" ansi_caption[4]="ACPI Support: Disabled" ansi_caption[5]="Boot Safe Mode: NO" ansi_caption[6]="Boot Single User: NO" ansi_caption[7]="Boot Verbose: NO" bootfile="kernel" Using less, od -c, or other utility, we have: # kenv | less LINES="24" ansi_caption[1]="ESC[1mBESC[37moot ESC[1m[ENTER]ESC[37m" ansi_caption[2]="ESC[1mEscESC[37mape to loader prompt" ansi_caption[4]="ESC[1mAESC[37mCPI Support: ESC[34;1mDisabledESC[37m" ansi_caption[5]="Boot Safe ESC[1mMESC[37mode: ESC[34;1mNOESC[37m" ansi_caption[6]="Boot ESC[1mSESC[37mingle User: ESC[34;1mNOESC[37m" ansi_caption[7]="Boot ESC[1mVESC[37merbose: ESC[34;1mNOESC[37m" bootfile="kernel" This caused a few issues with a script that parses the output of kenv. Simple enough to fix, but thought I'd see what others think. Thoughts? Opinions? Thanks, John From owner-freebsd-current@FreeBSD.ORG Fri Jul 8 16:47:23 2011 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 842C3106566B for ; Fri, 8 Jul 2011 16:47:23 +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 D8F678FC1C for ; Fri, 8 Jul 2011 16:47:22 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p68GlIu0002362 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Jul 2011 19:47:18 +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.4/8.14.4) with ESMTP id p68GlIZF058792; Fri, 8 Jul 2011 19:47:18 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p68GlILB058791; Fri, 8 Jul 2011 19:47:18 +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: Fri, 8 Jul 2011 19:47:18 +0300 From: Kostik Belousov To: John Message-ID: <20110708164718.GY48734@deviant.kiev.zoral.com.ua> References: <20110708145148.GA12548@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/kVOxs45Texhr2Rq" Content-Disposition: inline In-Reply-To: <20110708145148.GA12548@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=-3.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no 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: kenv values with ansi escapte sequences - ansi_caption 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, 08 Jul 2011 16:47:23 -0000 --/kVOxs45Texhr2Rq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 08, 2011 at 02:51:48PM +0000, John wrote: > Hi Folks, >=20 > It seems the new pre-boot options selection process has > some values defined within the kernel environment that contain > ansi control sequences. For instance: >=20 > # kenv > LINES=3D"24" > ansi_caption[1]=3D"Boot [ENTER]" > ansi_caption[2]=3D"Escape to loader prompt" > ansi_caption[4]=3D"ACPI Support: Disabled" > ansi_caption[5]=3D"Boot Safe Mode: NO" > ansi_caption[6]=3D"Boot Single User: NO" > ansi_caption[7]=3D"Boot Verbose: NO" > bootfile=3D"kernel" >=20 > Using less, od -c, or other utility, we have: >=20 > # kenv | less > LINES=3D"24" > ansi_caption[1]=3D"ESC[1mBESC[37moot ESC[1m[ENTER]ESC[37m" > ansi_caption[2]=3D"ESC[1mEscESC[37mape to loader prompt" > ansi_caption[4]=3D"ESC[1mAESC[37mCPI Support: ESC[34;1mDisabledESC[37m" > ansi_caption[5]=3D"Boot Safe ESC[1mMESC[37mode: ESC[34;1mNOESC[37m" > ansi_caption[6]=3D"Boot ESC[1mSESC[37mingle User: ESC[34;1mNOESC[37m" > ansi_caption[7]=3D"Boot ESC[1mVESC[37merbose: ESC[34;1mNOESC[37m" > bootfile=3D"kernel" >=20 > This caused a few issues with a script that parses the > output of kenv. Simple enough to fix, but thought I'd see > what others think. >=20 > Thoughts? Opinions? I think the right question there is why the variables are leaked into the kenv at all. They should be removed. --/kVOxs45Texhr2Rq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk4XNJUACgkQC3+MBN1Mb4hYCgCcCht/ZoX8+lnaLosx/BNb0MCz JnkAoLfOFr/7gXWDZ+SQCPKIIHfCe7Mg =CKDg -----END PGP SIGNATURE----- --/kVOxs45Texhr2Rq-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 8 18:11:04 2011 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 3B84B106566C; Fri, 8 Jul 2011 18:11:04 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id D5A4F8FC0A; Fri, 8 Jul 2011 18:11:03 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id p68IB2MZ097825; Fri, 8 Jul 2011 20:11:02 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id p68IB282097824; Fri, 8 Jul 2011 20:11:02 +0200 (CEST) (envelope-from marius) Date: Fri, 8 Jul 2011 20:11:02 +0200 From: Marius Strobl To: KOT MATPOCKuH Message-ID: <20110708181102.GA95673@alchemy.franken.de> References: <20110629134140.GF14797@alchemy.franken.de> <4E0B8F25.7090107@FreeBSD.org> <20110707100446.GJ14797@alchemy.franken.de> <20110707154958.GK14797@alchemy.franken.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: Doug Barton , FreeBSD Current Subject: Re: named crashes on assertion in rbtdb.c on sparc64/SMP 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, 08 Jul 2011 18:11:04 -0000 On Fri, Jul 08, 2011 at 03:47:08PM +0400, KOT MATPOCKuH wrote: > 2011/7/7 Marius Strobl : > > That's not the patch I was referring to. I did a second one which just > > entirely disables the use of atomic operations on sparc64: > > http://people.freebsd.org/~marius/sparc64_isc_disable_atomic.diff > Omg. I'm sorry. > I applied this patch and restarted named, but named crashed immediatly > after start: > 08-Jul-2011 15:29:54.631 found 2 CPUs, using 2 worker threads > 08-Jul-2011 15:29:54.633 using up to 4096 sockets > Segmentation fault (core dumped) > > core's backtrace: > #0 0x0000000040953ba8 in __sparc_utrap_install () from /lib/libc.so.7 > (gdb) bt > #0 0x0000000040953ba8 in __sparc_utrap_install () from /lib/libc.so.7 > #1 0x0000000040953ccc in __sparc_utrap_install () from /lib/libc.so.7 > #2 0x0000000040953f70 in __sparc_utrap_install () from /lib/libc.so.7 > #3 0x00000000409537ac in __sparc_utrap_install () from /lib/libc.so.7 > #4 0x00000000407c2d54 in pthread_mutex_lock () from /lib/libthr.so.3 > #5 0x0000000000228dcc in ?? () > Previous frame identical to this frame (corrupt stack?) > > Could this be a sign to a problem in libthr? Could be but IMO that's unlikely, if there'd be a bug affecting pthread_mutex_lock() there should be more fallout from that. I'm probably missing something how to properly disable the use of the ISC atomic implementation and to enable the alternative locking. Please try the following: a) Instead of the base BIND use the dns/bind96 port. The native build of the latter defaults to not using the ISC atomic implementation on sparc64 (and arm) and should properly enable the alternative. I can at least start named from bind96-9.6.3.1.ESV.R4.3 with the default configuration on -CURRENT without problems. b) Revert the above patch and try the base bind with the following (third) patch: http://people.freebsd.org/~marius/sparc64_isc_atomic.h.diff2 That one adds the memory barriers required for reference counting albeit in a sledgehammer-like fashion as the ISC atomic API doesn't allow to distinguish between acquire and release semantics. > > PS. > Also one month ago I got a problems with another multithreaded > application from ports (www/oops). oops was crashed with stack's > backtrace: > #0 0x0000000040d8fc88 in __sparc_utrap_install () from /lib/libc.so.7 > #1 0x0000000040d8fdac in __sparc_utrap_install () from /lib/libc.so.7 > #2 0x0000000040d90050 in __sparc_utrap_install () from /lib/libc.so.7 > #3 0x0000000040d8f88c in __sparc_utrap_install () from /lib/libc.so.7 > #4 0x0000000040d64044 in _malloc_thread_cleanup () from /lib/libc.so.7 > #5 0x0000000040c039b8 in fork () from /lib/libthr.so.3 > #6 0x0000000040c03d38 in fork () from /lib/libthr.so.3 > #7 0x0000000040c03f50 in pthread_exit () from /lib/libthr.so.3 > #8 0x0000000040c04414 in pthread_detach () from /lib/libthr.so.3 > #9 0x0000000040c04710 in pthread_create () from /lib/libthr.so.3 > > But on yesterday's world's build oops works properly. I think it may > be related to r223228 (?) Unlikely, the crash caused by the assertion in _malloc_thread_cleanup() was solved with r223369. Marius From owner-freebsd-current@FreeBSD.ORG Fri Jul 8 18:55:19 2011 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 E5E8F1065672 for ; Fri, 8 Jul 2011 18:55:19 +0000 (UTC) (envelope-from monthadar@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id A9F5A8FC0A for ; Fri, 8 Jul 2011 18:55:19 +0000 (UTC) Received: by gxk28 with SMTP id 28so1125598gxk.13 for ; Fri, 08 Jul 2011 11:55:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=5bQWDbNTRnOOKtB24gVZ6YO6pTGJMuE4GfKuJqHoeOQ=; b=CckCav7Y8YFXa4EiwUGi8d0/q/T8kZ/TDRxwbgAI4/zwd41oDZqGpcH7/r3kmIUaep M/FPgTukY6kyzDesUG6Yvyq7NYFQnZyH+8arnxWDnADbkVhG9NJuhw6Yx7f22F0AcEbf fT3vwUamHyLaU5rvtZCt3SWMxiv15nYG76QIA= MIME-Version: 1.0 Received: by 10.151.118.2 with SMTP id v2mr2336648ybm.99.1310149475251; Fri, 08 Jul 2011 11:24:35 -0700 (PDT) Received: by 10.151.49.6 with HTTP; Fri, 8 Jul 2011 11:24:35 -0700 (PDT) Date: Fri, 8 Jul 2011 20:24:35 +0200 Message-ID: From: Monthadar Al Jaberi To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Mbuf: m_prepend & M_PREPEND packet header length difference problem 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, 08 Jul 2011 18:55:20 -0000 Hi, The M_PREPEND macro updates m_pkthdr.len. But m_prepend does not update it. m_sanity function complains if I run m_prepend. Why doesnt m_prepend update m_pkthdr.len? br, -- //Monthadar Al Jaberi From owner-freebsd-current@FreeBSD.ORG Fri Jul 8 19:11:45 2011 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 333761065675; Fri, 8 Jul 2011 19:11:45 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id D163B8FC1C; Fri, 8 Jul 2011 19:11:44 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 6D93546B29; Fri, 8 Jul 2011 15:11:44 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 031488A02C; Fri, 8 Jul 2011 15:11:44 -0400 (EDT) From: John Baldwin To: current@freebsd.org Date: Fri, 8 Jul 2011 15:11:43 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201107081511.43417.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 08 Jul 2011 15:11:44 -0400 (EDT) Cc: edwin@freebsd.org Subject: [PATCH] Make top -P an interactive toggle 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, 08 Jul 2011 19:11:45 -0000 This patch lets you use 'P' while top is running to toggle between per-CPU and global CPU stats. Index: contrib/top/top.c =================================================================== --- contrib/top/top.c (revision 223873) +++ contrib/top/top.c (working copy) @@ -196,9 +196,9 @@ fd_set readfds; #ifdef ORDER - static char command_chars[] = "\f qh?en#sdkriIutHmSCajzo"; + static char command_chars[] = "\f qh?en#sdkriIutHmSCajzPo"; #else - static char command_chars[] = "\f qh?en#sdkriIutHmSCajz"; + static char command_chars[] = "\f qh?en#sdkriIutHmSCajzP"; #endif /* these defines enumerate the "strchr"s of the commands in command_chars */ #define CMD_redraw 0 @@ -225,8 +225,9 @@ #define CMD_showargs 20 #define CMD_jidtog 21 #define CMD_kidletog 22 +#define CMD_pcputog 23 #ifdef ORDER -#define CMD_order 23 +#define CMD_order 24 #endif /* set the buffer for stdout */ @@ -411,7 +412,7 @@ break; case 'P': - pcpu_stats = Yes; + pcpu_stats = !pcpu_stats; break; case 'z': @@ -1088,6 +1089,12 @@ ps.kidle ? "D" : "Not d"); putchar('\r'); break; + case CMD_pcputog: + pcpu_stats = !pcpu_stats; + toggle_pcpustats(&statics); + max_topn = display_updatecpus(&statics); + reset_display(); + break; default: new_message(MT_standout, " BAD CASE IN SWITCH!"); putchar('\r'); Index: contrib/top/display.c =================================================================== --- contrib/top/display.c (revision 223873) +++ contrib/top/display.c (working copy) @@ -151,16 +151,14 @@ return(smart_terminal ? lines : Largest); } -int display_init(statics) +int display_updatecpus(statics) struct statics *statics; { register int lines; - register char **pp; - register int *ip; register int i; - + /* call resize to do the dirty work */ lines = display_resize(); num_cpus = statics->ncpus; @@ -170,6 +168,21 @@ for (i = num_cpus; i > 9; i /= 10) cpustates_column++; + return(lines); +} + +int display_init(statics) + +struct statics *statics; + +{ + register int lines; + register char **pp; + register int *ip; + register int i; + + lines = display_updatecpus(statics); + /* only do the rest if we need to */ if (lines > -1) { Index: contrib/top/top.X =================================================================== --- contrib/top/top.X (revision 223873) +++ contrib/top/top.X (working copy) @@ -205,6 +205,7 @@ .BR \-H , .BR \-I , .BR \-j , +.BR \-P , .BR \-S , .BR \-t , .BR \-u , @@ -314,6 +315,9 @@ .IR jail (8) ID. .TP +.B P +Toggle the display of per-CPU statistics. +.TP .B t Toggle the display of the .I top Index: usr.bin/top/machine.c =================================================================== --- usr.bin/top/machine.c (revision 223873) +++ usr.bin/top/machine.c (working copy) @@ -239,19 +239,48 @@ static void getsysctl(const char *name, void *ptr, size_t len); static int swapmode(int *retavail, int *retfree); +void +toggle_pcpustats(struct statics *statics) +{ + + if (ncpus == 1) + return; + + /* Adjust display based on ncpus */ + if (pcpu_stats) { + y_mem += ncpus - 1; /* 3 */ + y_swap += ncpus - 1; /* 4 */ + y_idlecursor += ncpus - 1; /* 5 */ + y_message += ncpus - 1; /* 5 */ + y_header += ncpus - 1; /* 6 */ + y_procs += ncpus - 1; /* 7 */ + Header_lines += ncpus - 1; /* 7 */ + statics->ncpus = ncpus; + } else { + y_mem = 3; + y_swap = 4; + y_idlecursor = 5; + y_message = 5; + y_header = 6; + y_procs = 7; + Header_lines = 7; + statics->ncpus = 1; + } +} + int machine_init(struct statics *statics, char do_unames) { - int pagesize; - size_t modelen; + int i, j, empty, pagesize; + size_t size; struct passwd *pw; - modelen = sizeof(smpmode); - if ((sysctlbyname("machdep.smp_active", &smpmode, &modelen, + size = sizeof(smpmode); + if ((sysctlbyname("machdep.smp_active", &smpmode, &size, NULL, 0) != 0 && - sysctlbyname("kern.smp.active", &smpmode, &modelen, + sysctlbyname("kern.smp.active", &smpmode, &size, NULL, 0) != 0) || - modelen != sizeof(smpmode)) + size != sizeof(smpmode)) smpmode = 0; if (do_unames) { @@ -299,52 +328,38 @@ statics->order_names = ordernames; #endif - /* Adjust display based on ncpus */ - if (pcpu_stats) { - int i, j, empty; - size_t size; - - cpumask = 0; - ncpus = 0; - GETSYSCTL("kern.smp.maxcpus", maxcpu); - size = sizeof(long) * maxcpu * CPUSTATES; - times = malloc(size); - if (times == NULL) - err(1, "malloc %zd bytes", size); - if (sysctlbyname("kern.cp_times", times, &size, NULL, 0) == -1) - err(1, "sysctlbyname kern.cp_times"); - pcpu_cp_time = calloc(1, size); - maxid = (size / CPUSTATES / sizeof(long)) - 1; - for (i = 0; i <= maxid; i++) { - empty = 1; - for (j = 0; empty && j < CPUSTATES; j++) { - if (times[i * CPUSTATES + j] != 0) - empty = 0; - } - if (!empty) { - cpumask |= (1ul << i); - ncpus++; - } + /* Allocate state for per-CPU stats. */ + cpumask = 0; + ncpus = 0; + GETSYSCTL("kern.smp.maxcpus", maxcpu); + size = sizeof(long) * maxcpu * CPUSTATES; + times = malloc(size); + if (times == NULL) + err(1, "malloc %zd bytes", size); + if (sysctlbyname("kern.cp_times", times, &size, NULL, 0) == -1) + err(1, "sysctlbyname kern.cp_times"); + pcpu_cp_time = calloc(1, size); + maxid = (size / CPUSTATES / sizeof(long)) - 1; + for (i = 0; i <= maxid; i++) { + empty = 1; + for (j = 0; empty && j < CPUSTATES; j++) { + if (times[i * CPUSTATES + j] != 0) + empty = 0; } - - if (ncpus > 1) { - y_mem += ncpus - 1; /* 3 */ - y_swap += ncpus - 1; /* 4 */ - y_idlecursor += ncpus - 1; /* 5 */ - y_message += ncpus - 1; /* 5 */ - y_header += ncpus - 1; /* 6 */ - y_procs += ncpus - 1; /* 7 */ - Header_lines += ncpus - 1; /* 7 */ + if (!empty) { + cpumask |= (1ul << i); + ncpus++; } - size = sizeof(long) * ncpus * CPUSTATES; - pcpu_cp_old = calloc(1, size); - pcpu_cp_diff = calloc(1, size); - pcpu_cpu_states = calloc(1, size); - statics->ncpus = ncpus; - } else { - statics->ncpus = 1; } + size = sizeof(long) * ncpus * CPUSTATES; + pcpu_cp_old = calloc(1, size); + pcpu_cp_diff = calloc(1, size); + pcpu_cpu_states = calloc(1, size); + statics->ncpus = 1; + if (pcpu_stats) + toggle_pcpustats(statics); + /* all done! */ return (0); } @@ -398,14 +413,11 @@ int i, j; size_t size; - /* get the cp_time array */ - if (pcpu_stats) { - size = (maxid + 1) * CPUSTATES * sizeof(long); - if (sysctlbyname("kern.cp_times", pcpu_cp_time, &size, NULL, 0) == -1) - err(1, "sysctlbyname kern.cp_times"); - } else { - GETSYSCTL("kern.cp_time", cp_time); - } + /* get the CPU stats */ + size = (maxid + 1) * CPUSTATES * sizeof(long); + if (sysctlbyname("kern.cp_times", pcpu_cp_time, &size, NULL, 0) == -1) + err(1, "sysctlbyname kern.cp_times"); + GETSYSCTL("kern.cp_time", cp_time); GETSYSCTL("vm.loadavg", sysload); GETSYSCTL("kern.lastpid", lastpid); @@ -413,21 +425,17 @@ for (i = 0; i < 3; i++) si->load_avg[i] = (double)sysload.ldavg[i] / sysload.fscale; - if (pcpu_stats) { - for (i = j = 0; i <= maxid; i++) { - if ((cpumask & (1ul << i)) == 0) - continue; - /* convert cp_time counts to percentages */ - percentages(CPUSTATES, &pcpu_cpu_states[j * CPUSTATES], - &pcpu_cp_time[j * CPUSTATES], - &pcpu_cp_old[j * CPUSTATES], - &pcpu_cp_diff[j * CPUSTATES]); - j++; - } - } else { - /* convert cp_time counts to percentages */ - percentages(CPUSTATES, cpu_states, cp_time, cp_old, cp_diff); + /* convert cp_time counts to percentages */ + for (i = j = 0; i <= maxid; i++) { + if ((cpumask & (1ul << i)) == 0) + continue; + percentages(CPUSTATES, &pcpu_cpu_states[j * CPUSTATES], + &pcpu_cp_time[j * CPUSTATES], + &pcpu_cp_old[j * CPUSTATES], + &pcpu_cp_diff[j * CPUSTATES]); + j++; } + percentages(CPUSTATES, cpu_states, cp_time, cp_old, cp_diff); /* sum memory & swap statistics */ { -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Jul 8 19:17:21 2011 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 5019F106566C; Fri, 8 Jul 2011 19:17:21 +0000 (UTC) (envelope-from matpockuh@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1BB638FC08; Fri, 8 Jul 2011 19:17:20 +0000 (UTC) Received: by pvg11 with SMTP id 11so1765507pvg.13 for ; Fri, 08 Jul 2011 12:17:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=WJ8CVFcRnzIQFy0Kb2HlVtdmczfy8P8+nchWGgsywas=; b=shyhP5+UlhDrqqyRGLNRnBjA7od9yL09nkP+5V6Rkx07c/HIoO6JcDUL2VtmP0Ejr6 Xng/X9zxh+uuFHr2chcD+ymUpixpbq3QOExNHIxG9yy0CGwqFxxf07Vm7eE5MZdSMBd/ JX47hQ5V7lHpq2swxMMcXEK3/m0ZseFWqbiUM= MIME-Version: 1.0 Received: by 10.68.41.167 with SMTP id g7mr3284561pbl.173.1310152640279; Fri, 08 Jul 2011 12:17:20 -0700 (PDT) Received: by 10.68.62.97 with HTTP; Fri, 8 Jul 2011 12:17:20 -0700 (PDT) In-Reply-To: <20110708181102.GA95673@alchemy.franken.de> References: <20110629134140.GF14797@alchemy.franken.de> <4E0B8F25.7090107@FreeBSD.org> <20110707100446.GJ14797@alchemy.franken.de> <20110707154958.GK14797@alchemy.franken.de> <20110708181102.GA95673@alchemy.franken.de> Date: Fri, 8 Jul 2011 23:17:20 +0400 Message-ID: From: KOT MATPOCKuH To: Marius Strobl Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Doug Barton , FreeBSD Current Subject: Re: named crashes on assertion in rbtdb.c on sparc64/SMP 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, 08 Jul 2011 19:17:21 -0000 2011/7/8 Marius Strobl : > Please try the following: > a) Instead of the base BIND use the dns/bind96 port. The native build > =A0 of the latter defaults to not using the ISC atomic implementation > =A0 on sparc64 (and arm) and should properly enable the alternative. I > =A0 can at least start named from bind96-9.6.3.1.ESV.R4.3 with the defaul= t > =A0 configuration on -CURRENT without problems. dns/bind96? Why not bind98? As I see dns/bind98 configures without atomic swap operations. I will try to use dns/bind98 at first :) > b) Revert the above patch and try the base bind with the following > =A0 (third) patch: > =A0 http://people.freebsd.org/~marius/sparc64_isc_atomic.h.diff2 > =A0 That one adds the memory barriers required for reference counting > =A0 albeit in a sledgehammer-like fashion as the ISC atomic API doesn't > =A0 allow to distinguish between acquire and release semantics. Hmmm... With this patch build fails: root@sunrise:/usr/src/lib/bind/dns# make cc -O2 -pipe -DVERSION=3D'"9.6.-ESV-R4-P3"' -DHAVE_CONFIG_H -D_REENTRANT -D_THREAD_SAFE -DLIBINTERFACE=3D59 -DLIBREVISION=3D5 -DLIBAGE=3D1 -DOPENSSL -DUSE_MD5 -DWORDS_BIGENDIAN -DNS_LOCALSTATEDIR=3D'"/var"' -DNS_SYSCONFDIR=3D'"/etc/namedb"' -DNAMED_CONFFILE=3D'"/etc/namedb/named.conf"' -DRNDC_CONFFILE=3D'"/etc/namedb/rndc.conf"' -DRNDC_KEYFILE=3D'"/etc/namedb/rndc.key"' -I/usr/src/lib/bind/dns/.. -I/usr/src/lib/bind/dns/../../../contrib/bind9/lib/bind9/include -I/usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns/include/dst -I/usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns/include -I/usr/src/lib/bind/dns/../dns -I/usr/src/lib/bind/dns/../../../contrib/bind9/lib/isccc/include -I/usr/src/lib/bind/dns/../../../contrib/bind9/lib/isccfg/include -I/usr/src/lib/bind/dns/../../../contrib/bind9/lib/isc/unix/include -I/usr/src/lib/bind/dns/../../../contrib/bind9/lib/isc/pthreads/include -I/usr/src/lib/bind/dns/../../../contrib/bind9/lib/isc/include -I/usr/src/lib/bind/dns/../isc -I/usr/src/lib/bind/dns/../../../contrib/bind9/lib/lwres/unix/include -I/usr/src/lib/bind/dns/../../../contrib/bind9/lib/lwres/include -I/usr/src/lib/bind/dns/../lwres -I/usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns/include/dst -I/usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns/include -I/usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns -I/usr/src/lib/bind/dns -I/usr/src/lib/bind/dns/../../../contrib/bind9/lib/isc/sparc64/include -std=3Dgnu99 -c /usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns/acach= e.c {standard input}: Assembler messages: {standard input}:13: Error: Illegal operands: invalid membar mask name {standard input}:2180: Error: Illegal operands: invalid membar mask name *** Error code 1 > Unlikely, the crash caused by the assertion in _malloc_thread_cleanup() > was solved with r223369. Thanks you anyway! --=20 MATPOCKuH From owner-freebsd-current@FreeBSD.ORG Fri Jul 8 19:32:39 2011 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 DDA80106566C; Fri, 8 Jul 2011 19:32:39 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 536068FC0C; Fri, 8 Jul 2011 19:32:37 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id p68JWaZR098053; Fri, 8 Jul 2011 21:32:36 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id p68JWar1098052; Fri, 8 Jul 2011 21:32:36 +0200 (CEST) (envelope-from marius) Date: Fri, 8 Jul 2011 21:32:36 +0200 From: Marius Strobl To: KOT MATPOCKuH Message-ID: <20110708193236.GB95673@alchemy.franken.de> References: <20110629134140.GF14797@alchemy.franken.de> <4E0B8F25.7090107@FreeBSD.org> <20110707100446.GJ14797@alchemy.franken.de> <20110707154958.GK14797@alchemy.franken.de> <20110708181102.GA95673@alchemy.franken.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: Doug Barton , FreeBSD Current Subject: Re: named crashes on assertion in rbtdb.c on sparc64/SMP 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, 08 Jul 2011 19:32:39 -0000 On Fri, Jul 08, 2011 at 11:17:20PM +0400, KOT MATPOCKuH wrote: > 2011/7/8 Marius Strobl : > > > Please try the following: > > a) Instead of the base BIND use the dns/bind96 port. The native build > > ? of the latter defaults to not using the ISC atomic implementation > > ? on sparc64 (and arm) and should properly enable the alternative. I > > ? can at least start named from bind96-9.6.3.1.ESV.R4.3 with the default > > ? configuration on -CURRENT without problems. > dns/bind96? Why not bind98? In order to have a result which can be compared with the base BIND. Whether bind98 works or works without the ISC atomic operations says nothing about the bind96 port or the base version. > As I see dns/bind98 configures without atomic swap operations. > I will try to use dns/bind98 at first :) > > > b) Revert the above patch and try the base bind with the following > > ? (third) patch: > > ? http://people.freebsd.org/~marius/sparc64_isc_atomic.h.diff2 > > ? That one adds the memory barriers required for reference counting > > ? albeit in a sledgehammer-like fashion as the ISC atomic API doesn't > > ? allow to distinguish between acquire and release semantics. > > Hmmm... With this patch build fails: Oops, sorry, I forgot to revert the previous patch when test-compiling. Please re-fetch sparc64_isc_atomic.h.diff2 and try again. Marius From owner-freebsd-current@FreeBSD.ORG Fri Jul 8 21:50:51 2011 Return-Path: Delivered-To: current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 46B7A106566C; Fri, 8 Jul 2011 21:50:51 +0000 (UTC) Date: Fri, 8 Jul 2011 21:50:51 +0000 From: Alexander Best To: John Baldwin Message-ID: <20110708215051.GA14098@freebsd.org> References: <201107081511.43417.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201107081511.43417.jhb@freebsd.org> Cc: current@freebsd.org, edwin@freebsd.org Subject: Re: [PATCH] Make top -P an interactive toggle 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, 08 Jul 2011 21:50:51 -0000 On Fri Jul 8 11, John Baldwin wrote: > This patch lets you use 'P' while top is running to toggle between per-CPU and > global CPU stats. very cool. i always thought that being able to interactivly enable/disable per-cpu stats in top would be a useful feature. great to see this being implemented. top is nearing perfection. ;) > > Index: contrib/top/top.c > =================================================================== > --- contrib/top/top.c (revision 223873) > +++ contrib/top/top.c (working copy) > @@ -196,9 +196,9 @@ > fd_set readfds; > > #ifdef ORDER > - static char command_chars[] = "\f qh?en#sdkriIutHmSCajzo"; > + static char command_chars[] = "\f qh?en#sdkriIutHmSCajzPo"; > #else > - static char command_chars[] = "\f qh?en#sdkriIutHmSCajz"; > + static char command_chars[] = "\f qh?en#sdkriIutHmSCajzP"; > #endif > /* these defines enumerate the "strchr"s of the commands in command_chars */ > #define CMD_redraw 0 > @@ -225,8 +225,9 @@ > #define CMD_showargs 20 > #define CMD_jidtog 21 > #define CMD_kidletog 22 > +#define CMD_pcputog 23 > #ifdef ORDER > -#define CMD_order 23 > +#define CMD_order 24 > #endif > > /* set the buffer for stdout */ > @@ -411,7 +412,7 @@ > break; > > case 'P': > - pcpu_stats = Yes; > + pcpu_stats = !pcpu_stats; > break; > > case 'z': > @@ -1088,6 +1089,12 @@ > ps.kidle ? "D" : "Not d"); > putchar('\r'); > break; > + case CMD_pcputog: > + pcpu_stats = !pcpu_stats; > + toggle_pcpustats(&statics); > + max_topn = display_updatecpus(&statics); > + reset_display(); > + break; > default: > new_message(MT_standout, " BAD CASE IN SWITCH!"); > putchar('\r'); > Index: contrib/top/display.c > =================================================================== > --- contrib/top/display.c (revision 223873) > +++ contrib/top/display.c (working copy) > @@ -151,16 +151,14 @@ > return(smart_terminal ? lines : Largest); > } > > -int display_init(statics) > +int display_updatecpus(statics) > > struct statics *statics; > > { > register int lines; > - register char **pp; > - register int *ip; > register int i; > - > + > /* call resize to do the dirty work */ > lines = display_resize(); > num_cpus = statics->ncpus; > @@ -170,6 +168,21 @@ > for (i = num_cpus; i > 9; i /= 10) > cpustates_column++; > > + return(lines); > +} > + > +int display_init(statics) > + > +struct statics *statics; > + > +{ > + register int lines; > + register char **pp; > + register int *ip; > + register int i; > + > + lines = display_updatecpus(statics); > + > /* only do the rest if we need to */ > if (lines > -1) > { > Index: contrib/top/top.X > =================================================================== > --- contrib/top/top.X (revision 223873) > +++ contrib/top/top.X (working copy) > @@ -205,6 +205,7 @@ > .BR \-H , > .BR \-I , > .BR \-j , > +.BR \-P , > .BR \-S , > .BR \-t , > .BR \-u , > @@ -314,6 +315,9 @@ > .IR jail (8) > ID. > .TP > +.B P > +Toggle the display of per-CPU statistics. > +.TP > .B t > Toggle the display of the > .I top > Index: usr.bin/top/machine.c > =================================================================== > --- usr.bin/top/machine.c (revision 223873) > +++ usr.bin/top/machine.c (working copy) > @@ -239,19 +239,48 @@ > static void getsysctl(const char *name, void *ptr, size_t len); > static int swapmode(int *retavail, int *retfree); > > +void > +toggle_pcpustats(struct statics *statics) > +{ > + > + if (ncpus == 1) > + return; > + > + /* Adjust display based on ncpus */ > + if (pcpu_stats) { > + y_mem += ncpus - 1; /* 3 */ > + y_swap += ncpus - 1; /* 4 */ > + y_idlecursor += ncpus - 1; /* 5 */ > + y_message += ncpus - 1; /* 5 */ > + y_header += ncpus - 1; /* 6 */ > + y_procs += ncpus - 1; /* 7 */ > + Header_lines += ncpus - 1; /* 7 */ > + statics->ncpus = ncpus; > + } else { > + y_mem = 3; > + y_swap = 4; > + y_idlecursor = 5; > + y_message = 5; > + y_header = 6; > + y_procs = 7; > + Header_lines = 7; > + statics->ncpus = 1; > + } > +} > + > int > machine_init(struct statics *statics, char do_unames) > { > - int pagesize; > - size_t modelen; > + int i, j, empty, pagesize; > + size_t size; > struct passwd *pw; > > - modelen = sizeof(smpmode); > - if ((sysctlbyname("machdep.smp_active", &smpmode, &modelen, > + size = sizeof(smpmode); > + if ((sysctlbyname("machdep.smp_active", &smpmode, &size, > NULL, 0) != 0 && > - sysctlbyname("kern.smp.active", &smpmode, &modelen, > + sysctlbyname("kern.smp.active", &smpmode, &size, > NULL, 0) != 0) || > - modelen != sizeof(smpmode)) > + size != sizeof(smpmode)) > smpmode = 0; > > if (do_unames) { > @@ -299,52 +328,38 @@ > statics->order_names = ordernames; > #endif > > - /* Adjust display based on ncpus */ > - if (pcpu_stats) { > - int i, j, empty; > - size_t size; > - > - cpumask = 0; > - ncpus = 0; > - GETSYSCTL("kern.smp.maxcpus", maxcpu); > - size = sizeof(long) * maxcpu * CPUSTATES; > - times = malloc(size); > - if (times == NULL) > - err(1, "malloc %zd bytes", size); > - if (sysctlbyname("kern.cp_times", times, &size, NULL, 0) == -1) > - err(1, "sysctlbyname kern.cp_times"); > - pcpu_cp_time = calloc(1, size); > - maxid = (size / CPUSTATES / sizeof(long)) - 1; > - for (i = 0; i <= maxid; i++) { > - empty = 1; > - for (j = 0; empty && j < CPUSTATES; j++) { > - if (times[i * CPUSTATES + j] != 0) > - empty = 0; > - } > - if (!empty) { > - cpumask |= (1ul << i); > - ncpus++; > - } > + /* Allocate state for per-CPU stats. */ > + cpumask = 0; > + ncpus = 0; > + GETSYSCTL("kern.smp.maxcpus", maxcpu); > + size = sizeof(long) * maxcpu * CPUSTATES; > + times = malloc(size); > + if (times == NULL) > + err(1, "malloc %zd bytes", size); > + if (sysctlbyname("kern.cp_times", times, &size, NULL, 0) == -1) > + err(1, "sysctlbyname kern.cp_times"); > + pcpu_cp_time = calloc(1, size); > + maxid = (size / CPUSTATES / sizeof(long)) - 1; > + for (i = 0; i <= maxid; i++) { > + empty = 1; > + for (j = 0; empty && j < CPUSTATES; j++) { > + if (times[i * CPUSTATES + j] != 0) > + empty = 0; > } > - > - if (ncpus > 1) { > - y_mem += ncpus - 1; /* 3 */ > - y_swap += ncpus - 1; /* 4 */ > - y_idlecursor += ncpus - 1; /* 5 */ > - y_message += ncpus - 1; /* 5 */ > - y_header += ncpus - 1; /* 6 */ > - y_procs += ncpus - 1; /* 7 */ > - Header_lines += ncpus - 1; /* 7 */ > + if (!empty) { > + cpumask |= (1ul << i); > + ncpus++; > } > - size = sizeof(long) * ncpus * CPUSTATES; > - pcpu_cp_old = calloc(1, size); > - pcpu_cp_diff = calloc(1, size); > - pcpu_cpu_states = calloc(1, size); > - statics->ncpus = ncpus; > - } else { > - statics->ncpus = 1; > } > + size = sizeof(long) * ncpus * CPUSTATES; > + pcpu_cp_old = calloc(1, size); > + pcpu_cp_diff = calloc(1, size); > + pcpu_cpu_states = calloc(1, size); > + statics->ncpus = 1; > > + if (pcpu_stats) > + toggle_pcpustats(statics); > + > /* all done! */ > return (0); > } > @@ -398,14 +413,11 @@ > int i, j; > size_t size; > > - /* get the cp_time array */ > - if (pcpu_stats) { > - size = (maxid + 1) * CPUSTATES * sizeof(long); > - if (sysctlbyname("kern.cp_times", pcpu_cp_time, &size, NULL, 0) == -1) > - err(1, "sysctlbyname kern.cp_times"); > - } else { > - GETSYSCTL("kern.cp_time", cp_time); > - } > + /* get the CPU stats */ > + size = (maxid + 1) * CPUSTATES * sizeof(long); > + if (sysctlbyname("kern.cp_times", pcpu_cp_time, &size, NULL, 0) == -1) > + err(1, "sysctlbyname kern.cp_times"); > + GETSYSCTL("kern.cp_time", cp_time); > GETSYSCTL("vm.loadavg", sysload); > GETSYSCTL("kern.lastpid", lastpid); > > @@ -413,21 +425,17 @@ > for (i = 0; i < 3; i++) > si->load_avg[i] = (double)sysload.ldavg[i] / sysload.fscale; > > - if (pcpu_stats) { > - for (i = j = 0; i <= maxid; i++) { > - if ((cpumask & (1ul << i)) == 0) > - continue; > - /* convert cp_time counts to percentages */ > - percentages(CPUSTATES, &pcpu_cpu_states[j * CPUSTATES], > - &pcpu_cp_time[j * CPUSTATES], > - &pcpu_cp_old[j * CPUSTATES], > - &pcpu_cp_diff[j * CPUSTATES]); > - j++; > - } > - } else { > - /* convert cp_time counts to percentages */ > - percentages(CPUSTATES, cpu_states, cp_time, cp_old, cp_diff); > + /* convert cp_time counts to percentages */ > + for (i = j = 0; i <= maxid; i++) { > + if ((cpumask & (1ul << i)) == 0) > + continue; > + percentages(CPUSTATES, &pcpu_cpu_states[j * CPUSTATES], > + &pcpu_cp_time[j * CPUSTATES], > + &pcpu_cp_old[j * CPUSTATES], > + &pcpu_cp_diff[j * CPUSTATES]); > + j++; > } > + percentages(CPUSTATES, cpu_states, cp_time, cp_old, cp_diff); > > /* sum memory & swap statistics */ > { > > -- > John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Jul 8 23:22:13 2011 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 58EE21065672; Fri, 8 Jul 2011 23:22:13 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4BB4A8FC08; Fri, 8 Jul 2011 23:22:12 +0000 (UTC) Received: by wyg24 with SMTP id 24so2220008wyg.13 for ; Fri, 08 Jul 2011 16:22:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kDr20xs3SNskjGCgZGirqb3C/YKgbuf+IxXb6SJAvEc=; b=rjWwLQpeOK7ApVB+NDVeH6ROJO8TFtI9G5nDWLfAlYleGR3FBTNpC4gVS3CLQrMwxx 1fClVlmpGjDu6RQFDzNCG9NrqUNaBWDPJpJ9dXBC2TxD/tCGwQnV92XbPx/Y2v99Lngi S2FIAPyvxN1fV/zmPjO4LuaQdIxVlrdSzSXbc= MIME-Version: 1.0 Received: by 10.227.177.193 with SMTP id bj1mr2317960wbb.30.1310165886465; Fri, 08 Jul 2011 15:58:06 -0700 (PDT) Received: by 10.227.209.209 with HTTP; Fri, 8 Jul 2011 15:58:06 -0700 (PDT) In-Reply-To: <20110708215051.GA14098@freebsd.org> References: <201107081511.43417.jhb@freebsd.org> <20110708215051.GA14098@freebsd.org> Date: Sat, 9 Jul 2011 00:58:06 +0200 Message-ID: From: Oliver Pinter To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: Alexander Best , current@freebsd.org, edwin@freebsd.org Subject: Re: [PATCH] Make top -P an interactive toggle 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, 08 Jul 2011 23:22:13 -0000 On 7/8/11, Alexander Best wrote: > On Fri Jul 8 11, John Baldwin wrote: >> This patch lets you use 'P' while top is running to toggle between per-CPU >> and >> global CPU stats. > > very cool. i always thought that being able to interactivly enable/disable > per-cpu stats in top would be a useful feature. great to see this being > implemented. > > top is nearing perfection. ;) > >> >> Index: contrib/top/top.c >> =================================================================== >> --- contrib/top/top.c (revision 223873) >> +++ contrib/top/top.c (working copy) >> @@ -196,9 +196,9 @@ >> fd_set readfds; >> >> #ifdef ORDER >> - static char command_chars[] = "\f qh?en#sdkriIutHmSCajzo"; >> + static char command_chars[] = "\f qh?en#sdkriIutHmSCajzPo"; >> #else >> - static char command_chars[] = "\f qh?en#sdkriIutHmSCajz"; >> + static char command_chars[] = "\f qh?en#sdkriIutHmSCajzP"; >> #endif >> /* these defines enumerate the "strchr"s of the commands in command_chars >> */ >> #define CMD_redraw 0 >> @@ -225,8 +225,9 @@ >> #define CMD_showargs 20 >> #define CMD_jidtog 21 >> #define CMD_kidletog 22 >> +#define CMD_pcputog 23 >> #ifdef ORDER >> -#define CMD_order 23 >> +#define CMD_order 24 >> #endif >> >> /* set the buffer for stdout */ >> @@ -411,7 +412,7 @@ >> break; >> >> case 'P': >> - pcpu_stats = Yes; >> + pcpu_stats = !pcpu_stats; >> break; >> >> case 'z': >> @@ -1088,6 +1089,12 @@ >> ps.kidle ? "D" : "Not d"); >> putchar('\r'); >> break; >> + case CMD_pcputog: >> + pcpu_stats = !pcpu_stats; >> + toggle_pcpustats(&statics); >> + max_topn = display_updatecpus(&statics); >> + reset_display(); >> + break; >> default: >> new_message(MT_standout, " BAD CASE IN SWITCH!"); >> putchar('\r'); >> Index: contrib/top/display.c >> =================================================================== >> --- contrib/top/display.c (revision 223873) >> +++ contrib/top/display.c (working copy) >> @@ -151,16 +151,14 @@ >> return(smart_terminal ? lines : Largest); >> } >> >> -int display_init(statics) >> +int display_updatecpus(statics) >> >> struct statics *statics; >> >> { >> register int lines; >> - register char **pp; >> - register int *ip; >> register int i; >> - >> + >> /* call resize to do the dirty work */ >> lines = display_resize(); >> num_cpus = statics->ncpus; >> @@ -170,6 +168,21 @@ >> for (i = num_cpus; i > 9; i /= 10) >> cpustates_column++; >> >> + return(lines); >> +} >> + >> +int display_init(statics) >> + >> +struct statics *statics; >> + >> +{ >> + register int lines; >> + register char **pp; >> + register int *ip; >> + register int i; >> + >> + lines = display_updatecpus(statics); >> + >> /* only do the rest if we need to */ >> if (lines > -1) >> { >> Index: contrib/top/top.X >> =================================================================== >> --- contrib/top/top.X (revision 223873) >> +++ contrib/top/top.X (working copy) >> @@ -205,6 +205,7 @@ >> .BR \-H , >> .BR \-I , >> .BR \-j , >> +.BR \-P , >> .BR \-S , >> .BR \-t , >> .BR \-u , >> @@ -314,6 +315,9 @@ >> .IR jail (8) >> ID. >> .TP >> +.B P >> +Toggle the display of per-CPU statistics. >> +.TP >> .B t >> Toggle the display of the >> .I top >> Index: usr.bin/top/machine.c >> =================================================================== >> --- usr.bin/top/machine.c (revision 223873) >> +++ usr.bin/top/machine.c (working copy) >> @@ -239,19 +239,48 @@ >> static void getsysctl(const char *name, void *ptr, size_t len); >> static int swapmode(int *retavail, int *retfree); >> >> +void >> +toggle_pcpustats(struct statics *statics) >> +{ >> + >> + if (ncpus == 1) >> + return; >> + >> + /* Adjust display based on ncpus */ >> + if (pcpu_stats) { >> + y_mem += ncpus - 1; /* 3 */ >> + y_swap += ncpus - 1; /* 4 */ >> + y_idlecursor += ncpus - 1; /* 5 */ >> + y_message += ncpus - 1; /* 5 */ >> + y_header += ncpus - 1; /* 6 */ >> + y_procs += ncpus - 1; /* 7 */ >> + Header_lines += ncpus - 1; /* 7 */ >> + statics->ncpus = ncpus; >> + } else { >> + y_mem = 3; >> + y_swap = 4; >> + y_idlecursor = 5; >> + y_message = 5; >> + y_header = 6; >> + y_procs = 7; >> + Header_lines = 7; >> + statics->ncpus = 1; >> + } >> +} >> + >> int >> machine_init(struct statics *statics, char do_unames) >> { >> - int pagesize; >> - size_t modelen; >> + int i, j, empty, pagesize; >> + size_t size; >> struct passwd *pw; >> >> - modelen = sizeof(smpmode); >> - if ((sysctlbyname("machdep.smp_active", &smpmode, &modelen, >> + size = sizeof(smpmode); >> + if ((sysctlbyname("machdep.smp_active", &smpmode, &size, >> NULL, 0) != 0 && >> - sysctlbyname("kern.smp.active", &smpmode, &modelen, >> + sysctlbyname("kern.smp.active", &smpmode, &size, >> NULL, 0) != 0) || >> - modelen != sizeof(smpmode)) >> + size != sizeof(smpmode)) >> smpmode = 0; >> >> if (do_unames) { >> @@ -299,52 +328,38 @@ >> statics->order_names = ordernames; >> #endif >> >> - /* Adjust display based on ncpus */ >> - if (pcpu_stats) { >> - int i, j, empty; >> - size_t size; >> - >> - cpumask = 0; >> - ncpus = 0; >> - GETSYSCTL("kern.smp.maxcpus", maxcpu); >> - size = sizeof(long) * maxcpu * CPUSTATES; >> - times = malloc(size); >> - if (times == NULL) >> - err(1, "malloc %zd bytes", size); >> - if (sysctlbyname("kern.cp_times", times, &size, NULL, 0) == -1) >> - err(1, "sysctlbyname kern.cp_times"); >> - pcpu_cp_time = calloc(1, size); >> - maxid = (size / CPUSTATES / sizeof(long)) - 1; >> - for (i = 0; i <= maxid; i++) { >> - empty = 1; >> - for (j = 0; empty && j < CPUSTATES; j++) { >> - if (times[i * CPUSTATES + j] != 0) >> - empty = 0; >> - } >> - if (!empty) { >> - cpumask |= (1ul << i); >> - ncpus++; >> - } >> + /* Allocate state for per-CPU stats. */ >> + cpumask = 0; >> + ncpus = 0; >> + GETSYSCTL("kern.smp.maxcpus", maxcpu); >> + size = sizeof(long) * maxcpu * CPUSTATES; >> + times = malloc(size); >> + if (times == NULL) >> + err(1, "malloc %zd bytes", size); >> + if (sysctlbyname("kern.cp_times", times, &size, NULL, 0) == -1) >> + err(1, "sysctlbyname kern.cp_times"); >> + pcpu_cp_time = calloc(1, size); >> + maxid = (size / CPUSTATES / sizeof(long)) - 1; >> + for (i = 0; i <= maxid; i++) { >> + empty = 1; >> + for (j = 0; empty && j < CPUSTATES; j++) { >> + if (times[i * CPUSTATES + j] != 0) >> + empty = 0; >> } >> - >> - if (ncpus > 1) { >> - y_mem += ncpus - 1; /* 3 */ >> - y_swap += ncpus - 1; /* 4 */ >> - y_idlecursor += ncpus - 1; /* 5 */ >> - y_message += ncpus - 1; /* 5 */ >> - y_header += ncpus - 1; /* 6 */ >> - y_procs += ncpus - 1; /* 7 */ >> - Header_lines += ncpus - 1; /* 7 */ >> + if (!empty) { >> + cpumask |= (1ul << i); >> + ncpus++; >> } >> - size = sizeof(long) * ncpus * CPUSTATES; >> - pcpu_cp_old = calloc(1, size); >> - pcpu_cp_diff = calloc(1, size); >> - pcpu_cpu_states = calloc(1, size); >> - statics->ncpus = ncpus; >> - } else { >> - statics->ncpus = 1; >> } >> + size = sizeof(long) * ncpus * CPUSTATES; >> + pcpu_cp_old = calloc(1, size); >> + pcpu_cp_diff = calloc(1, size); >> + pcpu_cpu_states = calloc(1, size); >> + statics->ncpus = 1; >> >> + if (pcpu_stats) >> + toggle_pcpustats(statics); >> + >> /* all done! */ >> return (0); >> } >> @@ -398,14 +413,11 @@ >> int i, j; >> size_t size; >> >> - /* get the cp_time array */ >> - if (pcpu_stats) { >> - size = (maxid + 1) * CPUSTATES * sizeof(long); >> - if (sysctlbyname("kern.cp_times", pcpu_cp_time, &size, NULL, 0) == -1) >> - err(1, "sysctlbyname kern.cp_times"); >> - } else { >> - GETSYSCTL("kern.cp_time", cp_time); >> - } >> + /* get the CPU stats */ >> + size = (maxid + 1) * CPUSTATES * sizeof(long); >> + if (sysctlbyname("kern.cp_times", pcpu_cp_time, &size, NULL, 0) == -1) >> + err(1, "sysctlbyname kern.cp_times"); >> + GETSYSCTL("kern.cp_time", cp_time); >> GETSYSCTL("vm.loadavg", sysload); >> GETSYSCTL("kern.lastpid", lastpid); >> >> @@ -413,21 +425,17 @@ >> for (i = 0; i < 3; i++) >> si->load_avg[i] = (double)sysload.ldavg[i] / sysload.fscale; >> >> - if (pcpu_stats) { >> - for (i = j = 0; i <= maxid; i++) { >> - if ((cpumask & (1ul << i)) == 0) >> - continue; >> - /* convert cp_time counts to percentages */ >> - percentages(CPUSTATES, &pcpu_cpu_states[j * CPUSTATES], >> - &pcpu_cp_time[j * CPUSTATES], >> - &pcpu_cp_old[j * CPUSTATES], >> - &pcpu_cp_diff[j * CPUSTATES]); >> - j++; >> - } >> - } else { >> - /* convert cp_time counts to percentages */ >> - percentages(CPUSTATES, cpu_states, cp_time, cp_old, cp_diff); >> + /* convert cp_time counts to percentages */ >> + for (i = j = 0; i <= maxid; i++) { >> + if ((cpumask & (1ul << i)) == 0) >> + continue; >> + percentages(CPUSTATES, &pcpu_cpu_states[j * CPUSTATES], >> + &pcpu_cp_time[j * CPUSTATES], >> + &pcpu_cp_old[j * CPUSTATES], >> + &pcpu_cp_diff[j * CPUSTATES]); >> + j++; >> } >> + percentages(CPUSTATES, cpu_states, cp_time, cp_old, cp_diff); >> >> /* sum memory & swap statistics */ >> { >> >> -- >> John Baldwin > _______________________________________________ > 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" > Is there any chance to MFC back this commit to 7-STABLE? From owner-freebsd-current@FreeBSD.ORG Sat Jul 9 08:30:47 2011 Return-Path: Delivered-To: current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id D0B9A1065670; Sat, 9 Jul 2011 08:30:47 +0000 (UTC) Date: Sat, 9 Jul 2011 08:30:47 +0000 From: Alexander Best To: John Baldwin Message-ID: <20110709083047.GA86927@freebsd.org> References: <201107081511.43417.jhb@freebsd.org> <20110708215051.GA14098@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110708215051.GA14098@freebsd.org> Cc: current@freebsd.org, edwin@freebsd.org Subject: Re: [PATCH] Make top -P an interactive toggle 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, 09 Jul 2011 08:30:47 -0000 On Fri Jul 8 11, Alexander Best wrote: > On Fri Jul 8 11, John Baldwin wrote: > > This patch lets you use 'P' while top is running to toggle between per-CPU and > > global CPU stats. > > very cool. i always thought that being able to interactivly enable/disable > per-cpu stats in top would be a useful feature. great to see this being > implemented. oh...and of course i tested your patch. ;) works great without any issues. > > top is nearing perfection. ;) > > > > > Index: contrib/top/top.c > > =================================================================== > > --- contrib/top/top.c (revision 223873) > > +++ contrib/top/top.c (working copy) > > @@ -196,9 +196,9 @@ > > fd_set readfds; > > > > #ifdef ORDER > > - static char command_chars[] = "\f qh?en#sdkriIutHmSCajzo"; > > + static char command_chars[] = "\f qh?en#sdkriIutHmSCajzPo"; > > #else > > - static char command_chars[] = "\f qh?en#sdkriIutHmSCajz"; > > + static char command_chars[] = "\f qh?en#sdkriIutHmSCajzP"; > > #endif > > /* these defines enumerate the "strchr"s of the commands in command_chars */ > > #define CMD_redraw 0 > > @@ -225,8 +225,9 @@ > > #define CMD_showargs 20 > > #define CMD_jidtog 21 > > #define CMD_kidletog 22 > > +#define CMD_pcputog 23 > > #ifdef ORDER > > -#define CMD_order 23 > > +#define CMD_order 24 > > #endif > > > > /* set the buffer for stdout */ > > @@ -411,7 +412,7 @@ > > break; > > > > case 'P': > > - pcpu_stats = Yes; > > + pcpu_stats = !pcpu_stats; > > break; > > > > case 'z': > > @@ -1088,6 +1089,12 @@ > > ps.kidle ? "D" : "Not d"); > > putchar('\r'); > > break; > > + case CMD_pcputog: > > + pcpu_stats = !pcpu_stats; > > + toggle_pcpustats(&statics); > > + max_topn = display_updatecpus(&statics); > > + reset_display(); > > + break; > > default: > > new_message(MT_standout, " BAD CASE IN SWITCH!"); > > putchar('\r'); > > Index: contrib/top/display.c > > =================================================================== > > --- contrib/top/display.c (revision 223873) > > +++ contrib/top/display.c (working copy) > > @@ -151,16 +151,14 @@ > > return(smart_terminal ? lines : Largest); > > } > > > > -int display_init(statics) > > +int display_updatecpus(statics) > > > > struct statics *statics; > > > > { > > register int lines; > > - register char **pp; > > - register int *ip; > > register int i; > > - > > + > > /* call resize to do the dirty work */ > > lines = display_resize(); > > num_cpus = statics->ncpus; > > @@ -170,6 +168,21 @@ > > for (i = num_cpus; i > 9; i /= 10) > > cpustates_column++; > > > > + return(lines); > > +} > > + > > +int display_init(statics) > > + > > +struct statics *statics; > > + > > +{ > > + register int lines; > > + register char **pp; > > + register int *ip; > > + register int i; > > + > > + lines = display_updatecpus(statics); > > + > > /* only do the rest if we need to */ > > if (lines > -1) > > { > > Index: contrib/top/top.X > > =================================================================== > > --- contrib/top/top.X (revision 223873) > > +++ contrib/top/top.X (working copy) > > @@ -205,6 +205,7 @@ > > .BR \-H , > > .BR \-I , > > .BR \-j , > > +.BR \-P , > > .BR \-S , > > .BR \-t , > > .BR \-u , > > @@ -314,6 +315,9 @@ > > .IR jail (8) > > ID. > > .TP > > +.B P > > +Toggle the display of per-CPU statistics. > > +.TP > > .B t > > Toggle the display of the > > .I top > > Index: usr.bin/top/machine.c > > =================================================================== > > --- usr.bin/top/machine.c (revision 223873) > > +++ usr.bin/top/machine.c (working copy) > > @@ -239,19 +239,48 @@ > > static void getsysctl(const char *name, void *ptr, size_t len); > > static int swapmode(int *retavail, int *retfree); > > > > +void > > +toggle_pcpustats(struct statics *statics) > > +{ > > + > > + if (ncpus == 1) > > + return; > > + > > + /* Adjust display based on ncpus */ > > + if (pcpu_stats) { > > + y_mem += ncpus - 1; /* 3 */ > > + y_swap += ncpus - 1; /* 4 */ > > + y_idlecursor += ncpus - 1; /* 5 */ > > + y_message += ncpus - 1; /* 5 */ > > + y_header += ncpus - 1; /* 6 */ > > + y_procs += ncpus - 1; /* 7 */ > > + Header_lines += ncpus - 1; /* 7 */ > > + statics->ncpus = ncpus; > > + } else { > > + y_mem = 3; > > + y_swap = 4; > > + y_idlecursor = 5; > > + y_message = 5; > > + y_header = 6; > > + y_procs = 7; > > + Header_lines = 7; > > + statics->ncpus = 1; > > + } > > +} > > + > > int > > machine_init(struct statics *statics, char do_unames) > > { > > - int pagesize; > > - size_t modelen; > > + int i, j, empty, pagesize; > > + size_t size; > > struct passwd *pw; > > > > - modelen = sizeof(smpmode); > > - if ((sysctlbyname("machdep.smp_active", &smpmode, &modelen, > > + size = sizeof(smpmode); > > + if ((sysctlbyname("machdep.smp_active", &smpmode, &size, > > NULL, 0) != 0 && > > - sysctlbyname("kern.smp.active", &smpmode, &modelen, > > + sysctlbyname("kern.smp.active", &smpmode, &size, > > NULL, 0) != 0) || > > - modelen != sizeof(smpmode)) > > + size != sizeof(smpmode)) > > smpmode = 0; > > > > if (do_unames) { > > @@ -299,52 +328,38 @@ > > statics->order_names = ordernames; > > #endif > > > > - /* Adjust display based on ncpus */ > > - if (pcpu_stats) { > > - int i, j, empty; > > - size_t size; > > - > > - cpumask = 0; > > - ncpus = 0; > > - GETSYSCTL("kern.smp.maxcpus", maxcpu); > > - size = sizeof(long) * maxcpu * CPUSTATES; > > - times = malloc(size); > > - if (times == NULL) > > - err(1, "malloc %zd bytes", size); > > - if (sysctlbyname("kern.cp_times", times, &size, NULL, 0) == -1) > > - err(1, "sysctlbyname kern.cp_times"); > > - pcpu_cp_time = calloc(1, size); > > - maxid = (size / CPUSTATES / sizeof(long)) - 1; > > - for (i = 0; i <= maxid; i++) { > > - empty = 1; > > - for (j = 0; empty && j < CPUSTATES; j++) { > > - if (times[i * CPUSTATES + j] != 0) > > - empty = 0; > > - } > > - if (!empty) { > > - cpumask |= (1ul << i); > > - ncpus++; > > - } > > + /* Allocate state for per-CPU stats. */ > > + cpumask = 0; > > + ncpus = 0; > > + GETSYSCTL("kern.smp.maxcpus", maxcpu); > > + size = sizeof(long) * maxcpu * CPUSTATES; > > + times = malloc(size); > > + if (times == NULL) > > + err(1, "malloc %zd bytes", size); > > + if (sysctlbyname("kern.cp_times", times, &size, NULL, 0) == -1) > > + err(1, "sysctlbyname kern.cp_times"); > > + pcpu_cp_time = calloc(1, size); > > + maxid = (size / CPUSTATES / sizeof(long)) - 1; > > + for (i = 0; i <= maxid; i++) { > > + empty = 1; > > + for (j = 0; empty && j < CPUSTATES; j++) { > > + if (times[i * CPUSTATES + j] != 0) > > + empty = 0; > > } > > - > > - if (ncpus > 1) { > > - y_mem += ncpus - 1; /* 3 */ > > - y_swap += ncpus - 1; /* 4 */ > > - y_idlecursor += ncpus - 1; /* 5 */ > > - y_message += ncpus - 1; /* 5 */ > > - y_header += ncpus - 1; /* 6 */ > > - y_procs += ncpus - 1; /* 7 */ > > - Header_lines += ncpus - 1; /* 7 */ > > + if (!empty) { > > + cpumask |= (1ul << i); > > + ncpus++; > > } > > - size = sizeof(long) * ncpus * CPUSTATES; > > - pcpu_cp_old = calloc(1, size); > > - pcpu_cp_diff = calloc(1, size); > > - pcpu_cpu_states = calloc(1, size); > > - statics->ncpus = ncpus; > > - } else { > > - statics->ncpus = 1; > > } > > + size = sizeof(long) * ncpus * CPUSTATES; > > + pcpu_cp_old = calloc(1, size); > > + pcpu_cp_diff = calloc(1, size); > > + pcpu_cpu_states = calloc(1, size); > > + statics->ncpus = 1; > > > > + if (pcpu_stats) > > + toggle_pcpustats(statics); > > + > > /* all done! */ > > return (0); > > } > > @@ -398,14 +413,11 @@ > > int i, j; > > size_t size; > > > > - /* get the cp_time array */ > > - if (pcpu_stats) { > > - size = (maxid + 1) * CPUSTATES * sizeof(long); > > - if (sysctlbyname("kern.cp_times", pcpu_cp_time, &size, NULL, 0) == -1) > > - err(1, "sysctlbyname kern.cp_times"); > > - } else { > > - GETSYSCTL("kern.cp_time", cp_time); > > - } > > + /* get the CPU stats */ > > + size = (maxid + 1) * CPUSTATES * sizeof(long); > > + if (sysctlbyname("kern.cp_times", pcpu_cp_time, &size, NULL, 0) == -1) > > + err(1, "sysctlbyname kern.cp_times"); > > + GETSYSCTL("kern.cp_time", cp_time); > > GETSYSCTL("vm.loadavg", sysload); > > GETSYSCTL("kern.lastpid", lastpid); > > > > @@ -413,21 +425,17 @@ > > for (i = 0; i < 3; i++) > > si->load_avg[i] = (double)sysload.ldavg[i] / sysload.fscale; > > > > - if (pcpu_stats) { > > - for (i = j = 0; i <= maxid; i++) { > > - if ((cpumask & (1ul << i)) == 0) > > - continue; > > - /* convert cp_time counts to percentages */ > > - percentages(CPUSTATES, &pcpu_cpu_states[j * CPUSTATES], > > - &pcpu_cp_time[j * CPUSTATES], > > - &pcpu_cp_old[j * CPUSTATES], > > - &pcpu_cp_diff[j * CPUSTATES]); > > - j++; > > - } > > - } else { > > - /* convert cp_time counts to percentages */ > > - percentages(CPUSTATES, cpu_states, cp_time, cp_old, cp_diff); > > + /* convert cp_time counts to percentages */ > > + for (i = j = 0; i <= maxid; i++) { > > + if ((cpumask & (1ul << i)) == 0) > > + continue; > > + percentages(CPUSTATES, &pcpu_cpu_states[j * CPUSTATES], > > + &pcpu_cp_time[j * CPUSTATES], > > + &pcpu_cp_old[j * CPUSTATES], > > + &pcpu_cp_diff[j * CPUSTATES]); > > + j++; > > } > > + percentages(CPUSTATES, cpu_states, cp_time, cp_old, cp_diff); > > > > /* sum memory & swap statistics */ > > { > > > > -- > > John Baldwin From owner-freebsd-current@FreeBSD.ORG Sat Jul 9 09:44:16 2011 Return-Path: Delivered-To: current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 6DC3F1065672; Sat, 9 Jul 2011 09:44:16 +0000 (UTC) Date: Sat, 9 Jul 2011 09:44:16 +0000 From: Alexander Best To: John Baldwin Message-ID: <20110709094416.GA95093@freebsd.org> References: <201107081511.43417.jhb@freebsd.org> <20110708215051.GA14098@freebsd.org> <20110709083047.GA86927@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110709083047.GA86927@freebsd.org> Cc: current@freebsd.org, edwin@freebsd.org Subject: Re: [PATCH] Make top -P an interactive toggle 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, 09 Jul 2011 09:44:16 -0000 On Sat Jul 9 11, Alexander Best wrote: > On Fri Jul 8 11, Alexander Best wrote: > > On Fri Jul 8 11, John Baldwin wrote: > > > This patch lets you use 'P' while top is running to toggle between per-CPU and > > > global CPU stats. > > > > very cool. i always thought that being able to interactivly enable/disable > > per-cpu stats in top would be a useful feature. great to see this being > > implemented. > > oh...and of course i tested your patch. ;) works great without any issues. would it be possible to display a note when using 'P'? E.g. when pressing 'z' top informs the user with one of these messages: "Displaying system idle process." or "Not displaying system idle process." would be nice to have something similar when pressing the 'P' key. Maybe: "Display per-cpu CPU usage statistics." and "Not display per-cpu CPU usage statistics." cheers. alex > > > > > top is nearing perfection. ;) > > > > > > > > Index: contrib/top/top.c > > > =================================================================== > > > --- contrib/top/top.c (revision 223873) > > > +++ contrib/top/top.c (working copy) > > > @@ -196,9 +196,9 @@ > > > fd_set readfds; > > > > > > #ifdef ORDER > > > - static char command_chars[] = "\f qh?en#sdkriIutHmSCajzo"; > > > + static char command_chars[] = "\f qh?en#sdkriIutHmSCajzPo"; > > > #else > > > - static char command_chars[] = "\f qh?en#sdkriIutHmSCajz"; > > > + static char command_chars[] = "\f qh?en#sdkriIutHmSCajzP"; > > > #endif > > > /* these defines enumerate the "strchr"s of the commands in command_chars */ > > > #define CMD_redraw 0 > > > @@ -225,8 +225,9 @@ > > > #define CMD_showargs 20 > > > #define CMD_jidtog 21 > > > #define CMD_kidletog 22 > > > +#define CMD_pcputog 23 > > > #ifdef ORDER > > > -#define CMD_order 23 > > > +#define CMD_order 24 > > > #endif > > > > > > /* set the buffer for stdout */ > > > @@ -411,7 +412,7 @@ > > > break; > > > > > > case 'P': > > > - pcpu_stats = Yes; > > > + pcpu_stats = !pcpu_stats; > > > break; > > > > > > case 'z': > > > @@ -1088,6 +1089,12 @@ > > > ps.kidle ? "D" : "Not d"); > > > putchar('\r'); > > > break; > > > + case CMD_pcputog: > > > + pcpu_stats = !pcpu_stats; > > > + toggle_pcpustats(&statics); > > > + max_topn = display_updatecpus(&statics); > > > + reset_display(); > > > + break; > > > default: > > > new_message(MT_standout, " BAD CASE IN SWITCH!"); > > > putchar('\r'); > > > Index: contrib/top/display.c > > > =================================================================== > > > --- contrib/top/display.c (revision 223873) > > > +++ contrib/top/display.c (working copy) > > > @@ -151,16 +151,14 @@ > > > return(smart_terminal ? lines : Largest); > > > } > > > > > > -int display_init(statics) > > > +int display_updatecpus(statics) > > > > > > struct statics *statics; > > > > > > { > > > register int lines; > > > - register char **pp; > > > - register int *ip; > > > register int i; > > > - > > > + > > > /* call resize to do the dirty work */ > > > lines = display_resize(); > > > num_cpus = statics->ncpus; > > > @@ -170,6 +168,21 @@ > > > for (i = num_cpus; i > 9; i /= 10) > > > cpustates_column++; > > > > > > + return(lines); > > > +} > > > + > > > +int display_init(statics) > > > + > > > +struct statics *statics; > > > + > > > +{ > > > + register int lines; > > > + register char **pp; > > > + register int *ip; > > > + register int i; > > > + > > > + lines = display_updatecpus(statics); > > > + > > > /* only do the rest if we need to */ > > > if (lines > -1) > > > { > > > Index: contrib/top/top.X > > > =================================================================== > > > --- contrib/top/top.X (revision 223873) > > > +++ contrib/top/top.X (working copy) > > > @@ -205,6 +205,7 @@ > > > .BR \-H , > > > .BR \-I , > > > .BR \-j , > > > +.BR \-P , > > > .BR \-S , > > > .BR \-t , > > > .BR \-u , > > > @@ -314,6 +315,9 @@ > > > .IR jail (8) > > > ID. > > > .TP > > > +.B P > > > +Toggle the display of per-CPU statistics. > > > +.TP > > > .B t > > > Toggle the display of the > > > .I top > > > Index: usr.bin/top/machine.c > > > =================================================================== > > > --- usr.bin/top/machine.c (revision 223873) > > > +++ usr.bin/top/machine.c (working copy) > > > @@ -239,19 +239,48 @@ > > > static void getsysctl(const char *name, void *ptr, size_t len); > > > static int swapmode(int *retavail, int *retfree); > > > > > > +void > > > +toggle_pcpustats(struct statics *statics) > > > +{ > > > + > > > + if (ncpus == 1) > > > + return; > > > + > > > + /* Adjust display based on ncpus */ > > > + if (pcpu_stats) { > > > + y_mem += ncpus - 1; /* 3 */ > > > + y_swap += ncpus - 1; /* 4 */ > > > + y_idlecursor += ncpus - 1; /* 5 */ > > > + y_message += ncpus - 1; /* 5 */ > > > + y_header += ncpus - 1; /* 6 */ > > > + y_procs += ncpus - 1; /* 7 */ > > > + Header_lines += ncpus - 1; /* 7 */ > > > + statics->ncpus = ncpus; > > > + } else { > > > + y_mem = 3; > > > + y_swap = 4; > > > + y_idlecursor = 5; > > > + y_message = 5; > > > + y_header = 6; > > > + y_procs = 7; > > > + Header_lines = 7; > > > + statics->ncpus = 1; > > > + } > > > +} > > > + > > > int > > > machine_init(struct statics *statics, char do_unames) > > > { > > > - int pagesize; > > > - size_t modelen; > > > + int i, j, empty, pagesize; > > > + size_t size; > > > struct passwd *pw; > > > > > > - modelen = sizeof(smpmode); > > > - if ((sysctlbyname("machdep.smp_active", &smpmode, &modelen, > > > + size = sizeof(smpmode); > > > + if ((sysctlbyname("machdep.smp_active", &smpmode, &size, > > > NULL, 0) != 0 && > > > - sysctlbyname("kern.smp.active", &smpmode, &modelen, > > > + sysctlbyname("kern.smp.active", &smpmode, &size, > > > NULL, 0) != 0) || > > > - modelen != sizeof(smpmode)) > > > + size != sizeof(smpmode)) > > > smpmode = 0; > > > > > > if (do_unames) { > > > @@ -299,52 +328,38 @@ > > > statics->order_names = ordernames; > > > #endif > > > > > > - /* Adjust display based on ncpus */ > > > - if (pcpu_stats) { > > > - int i, j, empty; > > > - size_t size; > > > - > > > - cpumask = 0; > > > - ncpus = 0; > > > - GETSYSCTL("kern.smp.maxcpus", maxcpu); > > > - size = sizeof(long) * maxcpu * CPUSTATES; > > > - times = malloc(size); > > > - if (times == NULL) > > > - err(1, "malloc %zd bytes", size); > > > - if (sysctlbyname("kern.cp_times", times, &size, NULL, 0) == -1) > > > - err(1, "sysctlbyname kern.cp_times"); > > > - pcpu_cp_time = calloc(1, size); > > > - maxid = (size / CPUSTATES / sizeof(long)) - 1; > > > - for (i = 0; i <= maxid; i++) { > > > - empty = 1; > > > - for (j = 0; empty && j < CPUSTATES; j++) { > > > - if (times[i * CPUSTATES + j] != 0) > > > - empty = 0; > > > - } > > > - if (!empty) { > > > - cpumask |= (1ul << i); > > > - ncpus++; > > > - } > > > + /* Allocate state for per-CPU stats. */ > > > + cpumask = 0; > > > + ncpus = 0; > > > + GETSYSCTL("kern.smp.maxcpus", maxcpu); > > > + size = sizeof(long) * maxcpu * CPUSTATES; > > > + times = malloc(size); > > > + if (times == NULL) > > > + err(1, "malloc %zd bytes", size); > > > + if (sysctlbyname("kern.cp_times", times, &size, NULL, 0) == -1) > > > + err(1, "sysctlbyname kern.cp_times"); > > > + pcpu_cp_time = calloc(1, size); > > > + maxid = (size / CPUSTATES / sizeof(long)) - 1; > > > + for (i = 0; i <= maxid; i++) { > > > + empty = 1; > > > + for (j = 0; empty && j < CPUSTATES; j++) { > > > + if (times[i * CPUSTATES + j] != 0) > > > + empty = 0; > > > } > > > - > > > - if (ncpus > 1) { > > > - y_mem += ncpus - 1; /* 3 */ > > > - y_swap += ncpus - 1; /* 4 */ > > > - y_idlecursor += ncpus - 1; /* 5 */ > > > - y_message += ncpus - 1; /* 5 */ > > > - y_header += ncpus - 1; /* 6 */ > > > - y_procs += ncpus - 1; /* 7 */ > > > - Header_lines += ncpus - 1; /* 7 */ > > > + if (!empty) { > > > + cpumask |= (1ul << i); > > > + ncpus++; > > > } > > > - size = sizeof(long) * ncpus * CPUSTATES; > > > - pcpu_cp_old = calloc(1, size); > > > - pcpu_cp_diff = calloc(1, size); > > > - pcpu_cpu_states = calloc(1, size); > > > - statics->ncpus = ncpus; > > > - } else { > > > - statics->ncpus = 1; > > > } > > > + size = sizeof(long) * ncpus * CPUSTATES; > > > + pcpu_cp_old = calloc(1, size); > > > + pcpu_cp_diff = calloc(1, size); > > > + pcpu_cpu_states = calloc(1, size); > > > + statics->ncpus = 1; > > > > > > + if (pcpu_stats) > > > + toggle_pcpustats(statics); > > > + > > > /* all done! */ > > > return (0); > > > } > > > @@ -398,14 +413,11 @@ > > > int i, j; > > > size_t size; > > > > > > - /* get the cp_time array */ > > > - if (pcpu_stats) { > > > - size = (maxid + 1) * CPUSTATES * sizeof(long); > > > - if (sysctlbyname("kern.cp_times", pcpu_cp_time, &size, NULL, 0) == -1) > > > - err(1, "sysctlbyname kern.cp_times"); > > > - } else { > > > - GETSYSCTL("kern.cp_time", cp_time); > > > - } > > > + /* get the CPU stats */ > > > + size = (maxid + 1) * CPUSTATES * sizeof(long); > > > + if (sysctlbyname("kern.cp_times", pcpu_cp_time, &size, NULL, 0) == -1) > > > + err(1, "sysctlbyname kern.cp_times"); > > > + GETSYSCTL("kern.cp_time", cp_time); > > > GETSYSCTL("vm.loadavg", sysload); > > > GETSYSCTL("kern.lastpid", lastpid); > > > > > > @@ -413,21 +425,17 @@ > > > for (i = 0; i < 3; i++) > > > si->load_avg[i] = (double)sysload.ldavg[i] / sysload.fscale; > > > > > > - if (pcpu_stats) { > > > - for (i = j = 0; i <= maxid; i++) { > > > - if ((cpumask & (1ul << i)) == 0) > > > - continue; > > > - /* convert cp_time counts to percentages */ > > > - percentages(CPUSTATES, &pcpu_cpu_states[j * CPUSTATES], > > > - &pcpu_cp_time[j * CPUSTATES], > > > - &pcpu_cp_old[j * CPUSTATES], > > > - &pcpu_cp_diff[j * CPUSTATES]); > > > - j++; > > > - } > > > - } else { > > > - /* convert cp_time counts to percentages */ > > > - percentages(CPUSTATES, cpu_states, cp_time, cp_old, cp_diff); > > > + /* convert cp_time counts to percentages */ > > > + for (i = j = 0; i <= maxid; i++) { > > > + if ((cpumask & (1ul << i)) == 0) > > > + continue; > > > + percentages(CPUSTATES, &pcpu_cpu_states[j * CPUSTATES], > > > + &pcpu_cp_time[j * CPUSTATES], > > > + &pcpu_cp_old[j * CPUSTATES], > > > + &pcpu_cp_diff[j * CPUSTATES]); > > > + j++; > > > } > > > + percentages(CPUSTATES, cpu_states, cp_time, cp_old, cp_diff); > > > > > > /* sum memory & swap statistics */ > > > { > > > > > > -- > > > John Baldwin From owner-freebsd-current@FreeBSD.ORG Sat Jul 9 10:20:14 2011 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 06C3D1065675 for ; Sat, 9 Jul 2011 10:20:14 +0000 (UTC) (envelope-from eirnym@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id C88198FC15 for ; Sat, 9 Jul 2011 10:20:13 +0000 (UTC) Received: by iwr19 with SMTP id 19so3131209iwr.13 for ; Sat, 09 Jul 2011 03:20:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ZLk8ONwFuQeIgINSj9BOHIgd6VQZfr/spNXc050oRgE=; b=szVwpFYEdvs/SQOC2VwN1NWdVDlDmcxBEmK+7CfWZqwk0qrHKNod8EuB9SWM/vTwys zH9ESr5MHLe61e/NKRDTEnD9KkO6QkH2XCRCfA2o9wIKGyL2xVRevANIo5aS0JQcaKJe c/lZvlePYPPf8whRqzJzMitx83CIcGd7KGO9Y= Received: by 10.231.116.215 with SMTP id n23mr11399ibq.143.1310206813147; Sat, 09 Jul 2011 03:20:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.38.5 with HTTP; Sat, 9 Jul 2011 03:19:53 -0700 (PDT) In-Reply-To: References: <12DA9EAC-8677-49AD-BA6C-5A155D2A6122@berczi.be> <4E14C0D9.9040503@gmail.com> <2040FCF6-2CA2-4CF3-BB78-F5A3069297FF@berczi.be> <4E158846.4040807@gmail.com> From: Eir Nym Date: Sat, 9 Jul 2011 14:19:53 +0400 Message-ID: To: Berczi Gabor Content-Type: text/plain; charset=UTF-8 Cc: Volodymyr Kostyrko , freebsd-current@freebsd.org Subject: Re: ZFS boot fails with two pools 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, 09 Jul 2011 10:20:14 -0000 On 8 July 2011 09:28, Berczi Gabor wrote: > > On Jul 7, 2011, at 12:19 PM, Volodymyr Kostyrko wrote: > >>>> 2. Try to convince bios to boot from the disk of pool2. >>> >>> There is no disk with a singular ZFS pool. >> >> Any disk from bootable pool. > > Every disk contains two pools. And the BIOS sees only two (maybe three) of them. > >>>> 3. You can possibly try deploying /boot/boot0 MBR selector code over disks of data pool. Supplied boot0 code can be used to choose another disk to jump to it during boot process and will remember the last choice. >>> >>> I'm not really sure how to do this with GPT. Should I use boot0 instead of pmbr? >> >> boot0cfg is your old friend > > Cool, how do we get acquinted? > >> Actuall I think that code on that stages just tries to boot from the pool on the current disk. > > There are two pools on it... > gpart(8) can set 'bootme' flag for GPT partition, so there no problem to specify from which partition to boot. -- Eir Nym > _______________________________________________ > 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 Sat Jul 9 13:00:25 2011 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 139CB106566B for ; Sat, 9 Jul 2011 13:00:25 +0000 (UTC) (envelope-from inyaoo@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 92C778FC0A for ; Sat, 9 Jul 2011 13:00:24 +0000 (UTC) Received: by wwe6 with SMTP id 6so2584046wwe.31 for ; Sat, 09 Jul 2011 06:00:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=STfdCrswmR3Bd+gwsk9Xg7sNkZT4pUriZp0ox5ECwEc=; b=Mqt+r8t2+Z6N/qlqr9iAJE4K9jvEiyxb6q1xQGt2h+Ft3oTxSXvR6MXVodGxb6yz+d u5dzxRxiI2l699BWiuzuMmdwXiM6yg2bXnzRfrl0FnN1GB0480b6iNL9XHveaLtmfnXo 83KcX8wQXpMsV/L/BEfjUeOMBpVg6S2qfI0XU= Received: by 10.227.138.16 with SMTP id y16mr2721079wbt.67.1310216423405; Sat, 09 Jul 2011 06:00:23 -0700 (PDT) Received: from localhost (rockhall.torservers.net [77.247.181.163]) by mx.google.com with ESMTPS id fp5sm7239116wbb.49.2011.07.09.06.00.11 (version=SSLv3 cipher=OTHER); Sat, 09 Jul 2011 06:00:21 -0700 (PDT) From: Pan Tsu To: Eir Nym References: <12DA9EAC-8677-49AD-BA6C-5A155D2A6122@berczi.be> <4E14C0D9.9040503@gmail.com> <2040FCF6-2CA2-4CF3-BB78-F5A3069297FF@berczi.be> <4E158846.4040807@gmail.com> Date: Sat, 09 Jul 2011 16:59:34 +0400 In-Reply-To: (Eir Nym's message of "Sat, 9 Jul 2011 14:19:53 +0400") Message-ID: <86r55zboeh.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain Cc: Berczi Gabor , freebsd-current@freebsd.org, Volodymyr Kostyrko Subject: Re: ZFS boot fails with two pools 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, 09 Jul 2011 13:00:25 -0000 Eir Nym writes: > On 8 July 2011 09:28, Berczi Gabor wrote: >> >> On Jul 7, 2011, at 12:19 PM, Volodymyr Kostyrko wrote: >> >>>>> 2. Try to convince bios to boot from the disk of pool2. >>>> >>>> There is no disk with a singular ZFS pool. >>> >>> Any disk from bootable pool. >> >> Every disk contains two pools. And the BIOS sees only two (maybe three) of them. >> >>>>> 3. You can possibly try deploying /boot/boot0 MBR selector code >>>>> over disks of data pool. Supplied boot0 code can be used to >>>>> choose another disk to jump to it during boot process and will >>>>> remember the last choice. >>>> >>>> I'm not really sure how to do this with GPT. Should I use boot0 instead of pmbr? >>> >>> boot0cfg is your old friend >> >> Cool, how do we get acquinted? >> >>> Actuall I think that code on that stages just tries to boot from the pool on the current disk. >> >> There are two pools on it... >> > > gpart(8) can set 'bootme' flag for GPT partition, so there no problem > to specify from which partition to boot. Doesn't gptzfsboot probe all `freebsd-zfs' partitions irrespective of their boot* attributes? A quick search shows why $ fgrep -ir bootme sys/boot sys/cddl/boot $ grep -wr 'gpt.*(' sys/boot sys/cddl/boot From owner-freebsd-current@FreeBSD.ORG Sat Jul 9 21:22:55 2011 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 2C390106566C; Sat, 9 Jul 2011 21:22: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 C909F8FC16; Sat, 9 Jul 2011 21:22:54 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p69LMrYo058506; Sat, 9 Jul 2011 17:22:53 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p69LMr9K058121; Sat, 9 Jul 2011 21:22:53 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 9 Jul 2011 21:22:53 GMT Message-Id: <201107092122.p69LMr9K058121@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, 09 Jul 2011 21:22:55 -0000 TB --- 2011-07-09 20:24:05 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-07-09 20:24:05 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2011-07-09 20:24:05 - cleaning the object tree TB --- 2011-07-09 20:24:27 - cvsupping the source tree TB --- 2011-07-09 20:24:27 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2011-07-09 20:24:41 - building world TB --- 2011-07-09 20:24:41 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-09 20:24:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-09 20:24:41 - TARGET=powerpc TB --- 2011-07-09 20:24:41 - TARGET_ARCH=powerpc64 TB --- 2011-07-09 20:24:41 - TZ=UTC TB --- 2011-07-09 20:24:41 - __MAKE_CONF=/dev/null TB --- 2011-07-09 20:24:41 - cd /src TB --- 2011-07-09 20:24:41 - /usr/bin/make -B buildworld >>> World build started on Sat Jul 9 20:24:42 UTC 2011 >>> 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 [...] gzip -cn /src/share/man/man9/vm_map_madvise.9 > vm_map_madvise.9.gz gzip -cn /src/share/man/man9/vm_map_max.9 > vm_map_max.9.gz gzip -cn /src/share/man/man9/vm_map_protect.9 > vm_map_protect.9.gz gzip -cn /src/share/man/man9/vm_map_remove.9 > vm_map_remove.9.gz gzip -cn /src/share/man/man9/vm_map_simplify_entry.9 > vm_map_simplify_entry.9.gz gzip -cn /src/share/man/man9/vm_map_stack.9 > vm_map_stack.9.gz gzip -cn /src/share/man/man9/vm_map_submap.9 > vm_map_submap.9.gz make: don't know how to make vm_map_sync.9. Stop *** Error code 2 Stop in /src/share/man. *** 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 --- 2011-07-09 21:22:53 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-07-09 21:22:53 - ERROR: failed to build world TB --- 2011-07-09 21:22:53 - 2667.36 user 632.05 system 3527.95 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sat Jul 9 21:22:55 2011 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 73D471065673; Sat, 9 Jul 2011 21:22: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 1CC228FC19; Sat, 9 Jul 2011 21:22:54 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p69LMseN058824; Sat, 9 Jul 2011 17:22:54 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p69LMski058819; Sat, 9 Jul 2011 21:22:54 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 9 Jul 2011 21:22:54 GMT Message-Id: <201107092122.p69LMski058819@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, 09 Jul 2011 21:22:55 -0000 TB --- 2011-07-09 20:28:46 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-07-09 20:28:46 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2011-07-09 20:28:46 - cleaning the object tree TB --- 2011-07-09 20:29:03 - cvsupping the source tree TB --- 2011-07-09 20:29:03 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2011-07-09 20:29:16 - building world TB --- 2011-07-09 20:29:16 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-09 20:29:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-09 20:29:16 - TARGET=sparc64 TB --- 2011-07-09 20:29:16 - TARGET_ARCH=sparc64 TB --- 2011-07-09 20:29:16 - TZ=UTC TB --- 2011-07-09 20:29:16 - __MAKE_CONF=/dev/null TB --- 2011-07-09 20:29:16 - cd /src TB --- 2011-07-09 20:29:16 - /usr/bin/make -B buildworld >>> World build started on Sat Jul 9 20:29:17 UTC 2011 >>> 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 [...] gzip -cn /src/share/man/man9/vm_map_madvise.9 > vm_map_madvise.9.gz gzip -cn /src/share/man/man9/vm_map_max.9 > vm_map_max.9.gz gzip -cn /src/share/man/man9/vm_map_protect.9 > vm_map_protect.9.gz gzip -cn /src/share/man/man9/vm_map_remove.9 > vm_map_remove.9.gz gzip -cn /src/share/man/man9/vm_map_simplify_entry.9 > vm_map_simplify_entry.9.gz gzip -cn /src/share/man/man9/vm_map_stack.9 > vm_map_stack.9.gz gzip -cn /src/share/man/man9/vm_map_submap.9 > vm_map_submap.9.gz make: don't know how to make vm_map_sync.9. Stop *** Error code 2 Stop in /src/share/man. *** 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 --- 2011-07-09 21:22:54 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-07-09 21:22:54 - ERROR: failed to build world TB --- 2011-07-09 21:22:54 - 2440.01 user 600.23 system 3247.55 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sat Jul 9 21:42:34 2011 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 C127F106566B; Sat, 9 Jul 2011 21:42:34 +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 67A1C8FC0C; Sat, 9 Jul 2011 21:42:34 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p69LgX5j090758; Sat, 9 Jul 2011 17:42:33 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p69LgXO1090757; Sat, 9 Jul 2011 21:42:33 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 9 Jul 2011 21:42:33 GMT Message-Id: <201107092142.p69LgXO1090757@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, 09 Jul 2011 21:42:34 -0000 TB --- 2011-07-09 20:06:18 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-07-09 20:06:18 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2011-07-09 20:06:18 - cleaning the object tree TB --- 2011-07-09 20:06:41 - cvsupping the source tree TB --- 2011-07-09 20:06:41 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2011-07-09 20:07:11 - building world TB --- 2011-07-09 20:07:11 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-09 20:07:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-09 20:07:11 - TARGET=powerpc TB --- 2011-07-09 20:07:11 - TARGET_ARCH=powerpc TB --- 2011-07-09 20:07:11 - TZ=UTC TB --- 2011-07-09 20:07:11 - __MAKE_CONF=/dev/null TB --- 2011-07-09 20:07:11 - cd /src TB --- 2011-07-09 20:07:11 - /usr/bin/make -B buildworld >>> World build started on Sat Jul 9 20:07:12 UTC 2011 >>> 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 [...] gzip -cn /src/share/man/man9/vm_map_madvise.9 > vm_map_madvise.9.gz gzip -cn /src/share/man/man9/vm_map_max.9 > vm_map_max.9.gz gzip -cn /src/share/man/man9/vm_map_protect.9 > vm_map_protect.9.gz gzip -cn /src/share/man/man9/vm_map_remove.9 > vm_map_remove.9.gz gzip -cn /src/share/man/man9/vm_map_simplify_entry.9 > vm_map_simplify_entry.9.gz gzip -cn /src/share/man/man9/vm_map_stack.9 > vm_map_stack.9.gz gzip -cn /src/share/man/man9/vm_map_submap.9 > vm_map_submap.9.gz make: don't know how to make vm_map_sync.9. Stop *** Error code 2 Stop in /src/share/man. *** 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 --- 2011-07-09 21:42:33 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-07-09 21:42:33 - ERROR: failed to build world TB --- 2011-07-09 21:42:33 - 4717.41 user 833.18 system 5774.66 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sat Jul 9 23:58:08 2011 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 D1F41106566B; Sat, 9 Jul 2011 23:58:08 +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 8E95E8FC12; Sat, 9 Jul 2011 23:58:08 +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 p69Nr2r8010527 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sat, 9 Jul 2011 17:53:03 -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: <1427345072.163222.1309540223239.JavaMail.root@mail-01.cse.ucsc.edu> Date: Sat, 9 Jul 2011 17:53:02 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1427345072.163222.1309540223239.JavaMail.root@mail-01.cse.ucsc.edu> To: Tim Gustafson 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, 09 Jul 2011 17:53:06 -0600 (MDT) Cc: Artem Belevich , freebsd-current@FreeBSD.org, Hendrik Hasenbein Subject: Re: FreeBSD 9 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, 09 Jul 2011 23:58:08 -0000 The latest FreeNAS images also have mps and zpool 28. Warner On Jul 1, 2011, at 11:10 AM, Tim Gustafson wrote: >> More specifically, it's in 8.2-STABLE. mps driver was MFC'ed on >> Feb 18th, 2011. It didn't make it into 8.2-RELEASE. >>=20 >> Try mfsBSD image from http://mfsbsd.vx.sk/ -- it may work better. >=20 > That's what I used. I used the zpool 15 versions though; maybe the = zpool 28 version had the new driver on it? >=20 > At any rate, 9 is working for now, except for the net-snmp compilation = problem which I got around by using the binary package. >=20 > = -=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= - > Tim Gustafson = tjg@soe.ucsc.edu > Baskin School of Engineering = 831-459-5354 > UC Santa Cruz Baskin = Engineering 317B > = -=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= - > _______________________________________________ > 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 >=20