From owner-freebsd-current@FreeBSD.ORG Sun Feb 20 03:24: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 30BE11065674; Sun, 20 Feb 2011 03:24:20 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 8CCEA8FC1D; Sun, 20 Feb 2011 03:24:19 +0000 (UTC) Received: from ur.dons.net.au (ppp203-122-198-244.lns6.adl6.internode.on.net [203.122.198.244]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id p1K2ivsW091043 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 20 Feb 2011 13:14:58 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Daniel O'Connor" In-Reply-To: Date: Sun, 20 Feb 2011 13:14:57 +1030 Content-Transfer-Encoding: quoted-printable Message-Id: <1F3921E9-5314-43CA-9515-EDAADFCD47B1@gsoft.com.au> References: To: grarpamp X-Mailer: Apple Mail (2.1082) X-Spam-Score: 0.163 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: freebsd-current Current , freebsd-sysinstall@freebsd.org Subject: Re: FreeBSD Installer Roadmap 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, 20 Feb 2011 03:24:20 -0000 On 19/02/2011, at 20:04, grarpamp wrote: > 1 - I used install.cfg's on floppies to clone systems, a lot. Hands > on the box were needed with that. Operators skills were in question, > so having them use the dialog menus properly was a pain and often > resulted in non-zeroed disk or half built systems. And though all > else was cloned, it needed a separate .cfg for each box due > to: >=20 > fqdn, gateway, ip/mask > interface - sometimes changed > root disk - sometimes changed >=20 > Would have killed for a simple console shell script to ask those > questions of the operator, per machine. Not to get into the whole "wishlist for sysinstall Mk II" (aka second = system syndrome in full effect).. You can do this with sysinstall already (although it isn't very clean). Also, you don't need floppies, you can do the whole install off a FAT32 = USB stick with the aforementioned install.cfg file and a script run from = that. I do this at work to do a partition & minimal install, then untar a = pre-populated FS generated from a chroot. It also asks various questions = afterward for final tuning. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-current@FreeBSD.ORG Sun Feb 20 08:54: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 468E9106566B; Sun, 20 Feb 2011 08:54:16 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by mx1.freebsd.org (Postfix) with ESMTP id CCF8C8FC0A; Sun, 20 Feb 2011 08:54:15 +0000 (UTC) Received: from localhost (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by acme.spoerlein.net (8.14.4/8.14.4) with ESMTP id p1K8sE4s074482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 20 Feb 2011 09:54:14 +0100 (CET) (envelope-from uqs@spoerlein.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=spoerlein.net; s=dkim200908; t=1298192054; bh=ROG7eRBuUkyrd0HZBdQke7v4eSAmuBQrZIKa7t/WrB0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Transfer-Encoding:In-Reply-To; b=c2cttfRmbGQvw6LhXW9+bfevAZYIhxLBC/W/LGofaZiz7IuojW5fiDSCHZ7Ur7L4V REunLt0t/juKQz/kn8+C8Be+oZmHDN4gZwdBr1OSgSUM0SsKlufLV65QPDdPACclhl SB6FP1rYTBkN3zVnAzZF03ztOUst4mVpZ/kxIAwY= Date: Sun, 20 Feb 2011 09:54:14 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Alexander Best Message-ID: <20110220085414.GS65811@acme.spoerlein.net> Mail-Followup-To: Alexander Best , freebsd-current@freebsd.org References: <20110215211029.GA74471@freebsd.org> <20110218131603.GO65811@acme.spoerlein.net> <20110218163613.GA21409@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20110218163613.GA21409@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org Subject: Re: $PATH and buildworld not getting along 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, 20 Feb 2011 08:54:16 -0000 On Fri, 18.02.2011 at 16:36:13 +0000, Alexander Best wrote: > On Fri Feb 18 11, Ulrich Spörlein wrote: > > On Tue, 15.02.2011 at 21:10:29 +0000, Alexander Best wrote: > > > hi there, > > > > > > i've run into an issue where $PATH doesn't get discarded during buildworld. is > > > this behavior to be expected? to reproduce do: > > > > > > 1) be sure /usr/local/bin comes *before* /usr/bin in your $PATH > > > 2) ln -s /bin/cat /usr/local/bin/cc (some sh script would be better) > > > 3) cd /usr/src ; make SRCCONF=/dev/null __MAKE_CONF=/dev/null buildworld > > > 4) see how buildworld fails, because cat(1) gets invoked instead of cc(1). > > > > > > ... buildkernel on the other hand seems to be immune to such an issue. > > > > The bootstrap stage needs *some* compiler on the host system to build > > the (cross)compiler that is then used during the rest of buildworld (and > > all of buildkernel). If you remove cc or c++ or libstdc++.so then you're > > screwed. > > sure, but cc resides in in /usr/bin. so there's no need to invoke anything > from /usr/local/bin at all. > > > > > As to whether the user's PATH should be honored for building the > > bootstrap/cross/build-tools, I'd say yes. > > i'd say no. imo nothing from /usr/local/* should ever be invoked when compiling > a target in /usr/src. everything that's needed is in /usr/* (excluding local). You're assuming a build of FreeBSD on FreeBSD. But people might want to build FreeBSD on NetBSD and use the initial bootstrap cc from /usr/pkg/bin (or whatever). FreeBSD should be about tools, not policy. If you shoot yourself in the foot by messing with PATH + cc(1), that's your problem. hth Uli From owner-freebsd-current@FreeBSD.ORG Sun Feb 20 14:33: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 3F902106566B for ; Sun, 20 Feb 2011 14:33:56 +0000 (UTC) (envelope-from samspeed@mail.ru) Received: from f30.mail.ru (f30.mail.ru [217.69.129.95]) by mx1.freebsd.org (Postfix) with ESMTP id B1DFB8FC1B for ; Sun, 20 Feb 2011 14:33:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail; h=Message-Id:Content-Transfer-Encoding:Content-Type:Reply-To:In-Reply-To:References:Date:Mime-Version:Subject:Cc:To:From; bh=JYRv0706SDXNDaZRS4VWpfw+lLaq90q4okSZtHN/MPg=; b=poJdZyvznbvHUVtcKP6MwBjdNbvvTDeWRk0n4mbY4zd5Q1prMVsTdOLr04TU+arkJq0I8Dw/NuEzRZ320G4pP7w+sdHe2g0jRxvK2YDEADlu5CO3xH+J1QxX7ySlmnJ5; Received: from mail by f30.mail.ru with local id 1PrAM9-0001fN-00; Sun, 20 Feb 2011 17:33:49 +0300 Received: from [91.202.27.126] by e.mail.ru with HTTP; Sun, 20 Feb 2011 17:33:49 +0300 From: Andrey Smagin To: Andrew Boyer Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: 172.17.1.151 via proxy [91.202.27.126] Date: Sun, 20 Feb 2011 17:33:49 +0300 References: <4D4A38FD.7000607@rdtc.ru> <4D3011DB.9050900@frasunek.com> <4FD1B1C3-08A7-4F48-A30A-DE5A8F3D3834@averesystems.com> In-Reply-To: <4FD1B1C3-08A7-4F48-A30A-DE5A8F3D3834@averesystems.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Message-Id: X-Spam: Not detected X-Mras: Ok Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, Eugene Grosbein , Mike Tancsa Subject: Re[2]: About "panic: bufwrite: buffer is not busy???" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andrey Smagin List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Feb 2011 14:33:56 -0000 On week -current I have same problem, my box paniced every 2-15 min. I resolve problem by next steps - unplug network connectors from 2 intel em (82574L) cards. I think last time that mpd5 related panic, but mpd5 work with another re interface interated on MB. I think it may be em related panic, or em+mpd5. Wed, 16 Feb 2011 12:08:30 -0500 письмо от Andrew Boyer : > Moving this to -current and -stable and following up... > > Something is broken with coredumps on stable/8 amd64. I tried a vanilla > 8.2-RC3 and yesterday's csup of stable/8; neither can dump a core with 'sysctl > debug.kdb.panic=1'. > > For the 8.2-RC3 / amd64 / GENERIC install, I used the memstick image, > installed on ad7 (a 250GB SATA drive), used the default partition map, and set > dumpdev to AUTO. > > I added enough tracing to show that the second panic is due to the syncer > process flushing buffers to the other filesystems in parallel with the dump. > I've seen this panic and a similar one 'buffer not locked' coming from > ffs_write(). One time out of about 30 the core ran to completion, but slowly > (~1MB/sec). Other times the dump just locks up completely with no other > output. > > Does anyone know what might have changed to expose this problem? > > I don't ever see it under 7.1. > > Thanks, > Andrew > > On Feb 3, 2011, at 12:11 AM, Eugene Grosbein wrote: > > > On 02.02.2011 00:50, Gleb Smirnoff wrote: > > > >> E> Uptime: 8h3m51s > >> E> Dumping 4087 MB (3 chunks) > >> E> chunk 0: 1MB (150 pages) ... ok > >> E> chunk 1: 3575MB (915088 pages) 3559 3543panic: bufwrite: buffer is not > busy??? > >> E> cpuid = 3 > >> E> Uptime: 8h3m52s > >> E> Automatic reboot in 15 seconds - press a key on the console to abort > >> Can you add KDB_TRACE option to kernel? Your boxes for some reason can't > >> dump core, but with this option we will have at least trace. > > > > I see Mike Tancsa's box has "bufwrite: buffer is not busy???" problem too. > > Has anyone a thought how to fix generation of crashdumps? > > > > Eugene Grosbein > > > > > > _______________________________________________ > > 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" > > -------------------------------------------------- > Andrew Boyer aboyer@averesystems.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 Feb 20 15:31: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 09AC6106564A; Sun, 20 Feb 2011 15:31:00 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 836408FC1A; Sun, 20 Feb 2011 15:30:59 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:68ff:b8ee:849:710f] ([IPv6:2607:f3e0:0:4:68ff:b8ee:849:710f]) by smarthost1.sentex.ca (8.14.4/8.14.4) with ESMTP id p1KFUqXc050028 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 20 Feb 2011 10:30:53 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <4D6133AC.6070507@sentex.net> Date: Sun, 20 Feb 2011 10:30:52 -0500 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Andrey Smagin References: <4D4A38FD.7000607@rdtc.ru> <4D3011DB.9050900@frasunek.com> <4FD1B1C3-08A7-4F48-A30A-DE5A8F3D3834@averesystems.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.67 on IPv6:2607:f3e0:0:1::12 Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, Eugene Grosbein , Andrew Boyer Subject: Re: About "panic: bufwrite: buffer is not busy???" 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, 20 Feb 2011 15:31:00 -0000 On 2/20/2011 9:33 AM, Andrey Smagin wrote: > On week -current I have same problem, my box paniced every 2-15 min. I resolve problem by next steps - unplug network connectors from 2 intel em (82574L) cards. I think last time that mpd5 related panic, but mpd5 work with another re interface interated on MB. I think it may be em related panic, or em+mpd5. The latest panic I saw didnt have anything to do with em. Are you sure your crashes are because of the nic drive ? The latest I saw was on Friday. # kgdb /usr/obj/usr/src/sys/router/kernel.debug vmcore.11 (kgdb) bt #0 doadump () at pcpu.h:231 #1 0xc04a51f9 in db_fncall (dummy1=1, dummy2=0, dummy3=-1063333856, dummy4=0xc6b9696c "") at /usr/src/sys/ddb/db_command.c:548 #2 0xc04a55f1 in db_command (last_cmdp=0xc096f73c, cmd_table=0x0, dopager=1) at /usr/src/sys/ddb/db_command.c:445 #3 0xc04a574a in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 #4 0xc04a764d in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_main.c:229 #5 0xc068ba7e in kdb_trap (type=12, code=0, tf=0xc6b96b94) at /usr/src/sys/kern/subr_kdb.c:546 #6 0xc088056f in trap_fatal (frame=0xc6b96b94, eva=52) at /usr/src/sys/i386/i386/trap.c:937 #7 0xc0880830 in trap_pfault (frame=0xc6b96b94, usermode=0, eva=52) at /usr/src/sys/i386/i386/trap.c:859 #8 0xc0880d4a in trap (frame=0xc6b96b94) at /usr/src/sys/i386/i386/trap.c:532 #9 0xc086716c in calltrap () at /usr/src/sys/i386/i386/exception.s:166 #10 0xc0657a16 in uihold (uip=0x0) at /usr/src/sys/kern/kern_resource.c:1248 #11 0xc0654ec9 in crcopy (dest=0xce3ee800, src=0xce3ee600) at /usr/src/sys/kern/kern_prot.c:1873 #12 0xc0654fd1 in crcopysafe (p=0xc90cc810, cr=0xce3ee800) at /usr/src/sys/kern/kern_prot.c:1950 #13 0xc0656d7f in seteuid (td=0xc9196b80, uap=0xc6b96cec) at /usr/src/sys/kern/kern_prot.c:615 #14 0xc06985ff in syscallenter (td=0xc9196b80, sa=0xc6b96ce4) at /usr/src/sys/kern/subr_trap.c:315 #15 0xc0880884 in syscall (frame=0xc6b96d28) at /usr/src/sys/i386/i386/trap.c:1061 #16 0xc08671d1 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:264 #17 0x00000033 in ?? () (kgdb) frame 10 #10 0xc0657a16 in uihold (uip=0x0) at /usr/src/sys/kern/kern_resource.c:1248 1248 { (kgdb) list 1243 * Place another refcount on a uidinfo struct. 1244 */ 1245 void 1246 uihold(uip) 1247 struct uidinfo *uip; 1248 { 1249 1250 refcount_acquire(&uip->ui_ref); 1251 } 1252 (kgdb) p *uip Cannot access memory at address 0x0 (kgdb) p uip $1 = (struct uidinfo *) 0x0 (kgdb) > > > Wed, 16 Feb 2011 12:08:30 -0500 письмо от Andrew Boyer : > >> Moving this to -current and -stable and following up... >> >> Something is broken with coredumps on stable/8 amd64. I tried a vanilla >> 8.2-RC3 and yesterday's csup of stable/8; neither can dump a core with 'sysctl >> debug.kdb.panic=1'. >> >> For the 8.2-RC3 / amd64 / GENERIC install, I used the memstick image, >> installed on ad7 (a 250GB SATA drive), used the default partition map, and set >> dumpdev to AUTO. >> >> I added enough tracing to show that the second panic is due to the syncer >> process flushing buffers to the other filesystems in parallel with the dump. >> I've seen this panic and a similar one 'buffer not locked' coming from >> ffs_write(). One time out of about 30 the core ran to completion, but slowly >> (~1MB/sec). Other times the dump just locks up completely with no other >> output. >> >> Does anyone know what might have changed to expose this problem? >> >> I don't ever see it under 7.1. >> >> Thanks, >> Andrew >> >> On Feb 3, 2011, at 12:11 AM, Eugene Grosbein wrote: >> >>> On 02.02.2011 00:50, Gleb Smirnoff wrote: >>> >>>> E> Uptime: 8h3m51s >>>> E> Dumping 4087 MB (3 chunks) >>>> E> chunk 0: 1MB (150 pages) ... ok >>>> E> chunk 1: 3575MB (915088 pages) 3559 3543panic: bufwrite: buffer is not >> busy??? >>>> E> cpuid = 3 >>>> E> Uptime: 8h3m52s >>>> E> Automatic reboot in 15 seconds - press a key on the console to abort >>>> Can you add KDB_TRACE option to kernel? Your boxes for some reason can't >>>> dump core, but with this option we will have at least trace. >>> >>> I see Mike Tancsa's box has "bufwrite: buffer is not busy???" problem too. >>> Has anyone a thought how to fix generation of crashdumps? >>> >>> Eugene Grosbein >>> >>> >>> _______________________________________________ >>> 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" >> >> -------------------------------------------------- >> Andrew Boyer aboyer@averesystems.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" > > -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-current@FreeBSD.ORG Sun Feb 20 15:37: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 8E81A106566C for ; Sun, 20 Feb 2011 15:37:56 +0000 (UTC) (envelope-from jeremie@le-hen.org) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by mx1.freebsd.org (Postfix) with ESMTP id 0E6D18FC16 for ; Sun, 20 Feb 2011 15:37:54 +0000 (UTC) Received: from endor.tataz.chchile.org (unknown [82.233.239.98]) by smtp5-g21.free.fr (Postfix) with ESMTP id 8A4D3D48174; Sun, 20 Feb 2011 16:37:48 +0100 (CET) Received: from felucia.tataz.chchile.org (felucia.tataz.chchile.org [192.168.1.9]) by endor.tataz.chchile.org (Postfix) with ESMTP id B209B33CF9; Sun, 20 Feb 2011 15:37:46 +0000 (UTC) Received: by felucia.tataz.chchile.org (Postfix, from userid 1000) id 9330CA14C7; Sun, 20 Feb 2011 15:37:46 +0000 (UTC) Date: Sun, 20 Feb 2011 16:37:46 +0100 From: Jeremie Le Hen To: "Matthew D. Fuller" Message-ID: <20110220153746.GB6573@felucia.tataz.chchile.org> References: <20110219185043.GA6573@felucia.tataz.chchile.org> <20110219203729.GE27891@over-yonder.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110219203729.GE27891@over-yonder.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@FreeBSD.org, Jeremie Le Hen Subject: Re: [RFC] Force stdio output streams to line-buffered mode 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, 20 Feb 2011 15:37:56 -0000 On Sat, Feb 19, 2011 at 02:37:29PM -0600, Matthew D. Fuller wrote: > On Sat, Feb 19, 2011 at 07:50:43PM +0100 I heard the voice of > Jeremie Le Hen, and lo! it spake thus: > > > > I've attached a small patch for stdio, so if the environment variable > > STDIO_IOLBF is set, the output streams will be line-oriented by default. > > iostat -x 1 | env STDIO_IOLBF=1 grep -v ad10 | cat -n > > I've no real comment on anything else (sounds like an interesting > hack, whatever else), but just for this particular case, you know that > grep has a --line-buffered arg, right? Yes indeed, my example wasn't especially smart :). Actually, I often stumble on this problem with an awk script I use to columize output. -- Jeremie Le Hen Humans are born free and equal. But some are more equal than others. Coluche From owner-freebsd-current@FreeBSD.ORG Sun Feb 20 15:55: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 566A2106564A; Sun, 20 Feb 2011 15:55:38 +0000 (UTC) (envelope-from aboyer@averesystems.com) Received: from zimbra.averesystems.com (75-149-8-245-Pennsylvania.hfc.comcastbusiness.net [75.149.8.245]) by mx1.freebsd.org (Postfix) with ESMTP id 0CD768FC0A; Sun, 20 Feb 2011 15:55:37 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zimbra.averesystems.com (Postfix) with ESMTP id 2232C44A005; Sun, 20 Feb 2011 10:54:44 -0500 (EST) X-Virus-Scanned: amavisd-new at averesystems.com Received: from zimbra.averesystems.com ([127.0.0.1]) by localhost (zimbra.averesystems.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2TsV5VszDrj; Sun, 20 Feb 2011 10:54:41 -0500 (EST) Received: from [192.168.4.6] (c-24-131-84-46.hsd1.pa.comcast.net [24.131.84.46]) by zimbra.averesystems.com (Postfix) with ESMTPSA id 8CE5844A004; Sun, 20 Feb 2011 10:54:41 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1082) From: Andrew Boyer In-Reply-To: <20110220154651.GA17661@icarus.home.lan> Date: Sun, 20 Feb 2011 10:55:34 -0500 Message-Id: References: <4D4A38FD.7000607@rdtc.ru> <4D3011DB.9050900@frasunek.com> <4FD1B1C3-08A7-4F48-A30A-DE5A8F3D3834@averesystems.com> <4D6133AC.6070507@sentex.net> <20110220154651.GA17661@icarus.home.lan> To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Andrey Smagin , Eugene Grosbein , Jeremy Chadwick , Mike Tancsa Subject: Re: About "panic: bufwrite: buffer is not busy???" 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, 20 Feb 2011 15:55:38 -0000 On Feb 20, 2011, at 10:46 AM, Jeremy Chadwick wrote: > On Sun, Feb 20, 2011 at 10:30:52AM -0500, Mike Tancsa wrote: >> On 2/20/2011 9:33 AM, Andrey Smagin wrote: >>> On week -current I have same problem, my box paniced every 2-15 min. = I resolve problem by next steps - unplug network connectors from 2 intel = em (82574L) cards. I think last time that mpd5 related panic, but mpd5 = work with another re interface interated on MB. I think it may be em = related panic, or em+mpd5. >>=20 >> The latest panic I saw didnt have anything to do with em. Are you = sure >> your crashes are because of the nic drive ? >=20 > Not to mention, the error string the OP provided (see Subject) is only > contained in one file: sys/ufs/ffs/ffs_vfsops.c, function > ffs_bufwrite(). So, that would be some kind of weird = filesystem-related > issue, not NIC-specific. I have no idea how to debug said problem. >=20 The issue is the file system activity occurring in parallel with the = coredump, which is strange. It seems like everything else should be = halted before the dump begins but I couldn't find a place in the code = that actually tries to stop the other CPUs. My question isn't about the initial panic (I was using the sysctl to = provoke one), but about the secondary panic. This is on 8-core systems. -Andrew -------------------------------------------------- Andrew Boyer aboyer@averesystems.com From owner-freebsd-current@FreeBSD.ORG Sun Feb 20 15:47: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 2FCC41065673 for ; Sun, 20 Feb 2011 15:47:01 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by mx1.freebsd.org (Postfix) with ESMTP id 0E35B8FC1C for ; Sun, 20 Feb 2011 15:47:00 +0000 (UTC) Received: from omta18.emeryville.ca.mail.comcast.net ([76.96.30.74]) by qmta06.emeryville.ca.mail.comcast.net with comcast id AFiJ1g0011bwxycA6Fn0fS; Sun, 20 Feb 2011 15:47:00 +0000 Received: from koitsu.dyndns.org ([98.248.33.18]) by omta18.emeryville.ca.mail.comcast.net with comcast id AFmr1g01h0PUQVN8eFmvB1; Sun, 20 Feb 2011 15:46:58 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 3B7109B422; Sun, 20 Feb 2011 07:46:51 -0800 (PST) Date: Sun, 20 Feb 2011 07:46:51 -0800 From: Jeremy Chadwick To: Mike Tancsa Message-ID: <20110220154651.GA17661@icarus.home.lan> References: <4D4A38FD.7000607@rdtc.ru> <4D3011DB.9050900@frasunek.com> <4FD1B1C3-08A7-4F48-A30A-DE5A8F3D3834@averesystems.com> <4D6133AC.6070507@sentex.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D6133AC.6070507@sentex.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Sun, 20 Feb 2011 16:21:13 +0000 Cc: freebsd-stable@freebsd.org, freebsd-current@freebsd.org, Andrey Smagin , Eugene Grosbein , Andrew Boyer Subject: Re: About "panic: bufwrite: buffer is not busy???" 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, 20 Feb 2011 15:47:01 -0000 On Sun, Feb 20, 2011 at 10:30:52AM -0500, Mike Tancsa wrote: > On 2/20/2011 9:33 AM, Andrey Smagin wrote: > > On week -current I have same problem, my box paniced every 2-15 min. I resolve problem by next steps - unplug network connectors from 2 intel em (82574L) cards. I think last time that mpd5 related panic, but mpd5 work with another re interface interated on MB. I think it may be em related panic, or em+mpd5. > > The latest panic I saw didnt have anything to do with em. Are you sure > your crashes are because of the nic drive ? Not to mention, the error string the OP provided (see Subject) is only contained in one file: sys/ufs/ffs/ffs_vfsops.c, function ffs_bufwrite(). So, that would be some kind of weird filesystem-related issue, not NIC-specific. I have no idea how to debug said problem. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-current@FreeBSD.ORG Sun Feb 20 16:55: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 0E781106566B; Sun, 20 Feb 2011 16:55:02 +0000 (UTC) (envelope-from samspeed@mail.ru) Received: from f23.mail.ru (f23.mail.ru [217.69.129.89]) by mx1.freebsd.org (Postfix) with ESMTP id 62A588FC12; Sun, 20 Feb 2011 16:55:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail; h=Message-Id:Content-Transfer-Encoding:Content-Type:Reply-To:In-Reply-To:References:Date:Mime-Version:Subject:Cc:To:From; bh=njS6zTgB+d+oIxVZdnLEmASts36n8/3n61TcPIt9HGs=; b=Xpkcb5di7uIwourD/ATC8qAsaNGIi1Ctai7gK3AF4Dlr+00/LnzdG2uy6hBvttvVsutuedW24WoDOixFR2kCykyHOdCd96HV+z3aO0/GdmSNnp2G+7I+zlWnAQXxDyb1; Received: from mail by f23.mail.ru with local id 1PrCYb-0002wI-00; Sun, 20 Feb 2011 19:54:49 +0300 Received: from [91.202.27.126] by e.mail.ru with HTTP; Sun, 20 Feb 2011 19:54:49 +0300 From: Andrey Smagin To: Mike Tancsa Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: 172.17.1.151 via proxy [91.202.27.126] Date: Sun, 20 Feb 2011 19:54:49 +0300 References: <4D4A38FD.7000607@rdtc.ru> <4D6133AC.6070507@sentex.net> In-Reply-To: <4D6133AC.6070507@sentex.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Message-Id: X-Spam: Not detected X-Mras: Ok Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, Eugene Grosbein , Andrew Boyer Subject: Re[2]: About "panic: bufwrite: buffer is not busy???" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andrey Smagin List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Feb 2011 16:55:02 -0000 Sun, 20 Feb 2011 10:30:52 -0500 письмо от Mike Tancsa : > On 2/20/2011 9:33 AM, Andrey Smagin wrote: > > On week -current I have same problem, my box paniced every 2-15 min. I > resolve problem by next steps - unplug network connectors from 2 intel em > (82574L) cards. I think last time that mpd5 related panic, but mpd5 work with > another re interface interated on MB. I think it may be em related panic, or > em+mpd5. > > The latest panic I saw didnt have anything to do with em. Are you sure > your crashes are because of the nic drive ? I not shure crash because nic driver, I say only because my box after unplug 2 em nic's have uptime from moment of unplug to right now moment. About all last week I tried understand source of panic. My box : Phenom x4 12GB 2 re nic 2 em nic through re0 em1 em2 work mpd5 re0 pptp client em0 pppoe client em1 l2tp client > The latest I saw was on Friday. > > # kgdb /usr/obj/usr/src/sys/router/kernel.debug vmcore.11 > (kgdb) bt > #0 doadump () at pcpu.h:231 > #1 0xc04a51f9 in db_fncall (dummy1=1, dummy2=0, dummy3=-1063333856, > dummy4=0xc6b9696c "") at /usr/src/sys/ddb/db_command.c:548 > #2 0xc04a55f1 in db_command (last_cmdp=0xc096f73c, cmd_table=0x0, > dopager=1) at /usr/src/sys/ddb/db_command.c:445 > #3 0xc04a574a in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 > #4 0xc04a764d in db_trap (type=12, code=0) at > /usr/src/sys/ddb/db_main.c:229 > #5 0xc068ba7e in kdb_trap (type=12, code=0, tf=0xc6b96b94) at > /usr/src/sys/kern/subr_kdb.c:546 > #6 0xc088056f in trap_fatal (frame=0xc6b96b94, eva=52) at > /usr/src/sys/i386/i386/trap.c:937 > #7 0xc0880830 in trap_pfault (frame=0xc6b96b94, usermode=0, eva=52) at > /usr/src/sys/i386/i386/trap.c:859 > #8 0xc0880d4a in trap (frame=0xc6b96b94) at > /usr/src/sys/i386/i386/trap.c:532 > #9 0xc086716c in calltrap () at /usr/src/sys/i386/i386/exception.s:166 > #10 0xc0657a16 in uihold (uip=0x0) at /usr/src/sys/kern/kern_resource.c:1248 > #11 0xc0654ec9 in crcopy (dest=0xce3ee800, src=0xce3ee600) at > /usr/src/sys/kern/kern_prot.c:1873 > #12 0xc0654fd1 in crcopysafe (p=0xc90cc810, cr=0xce3ee800) at > /usr/src/sys/kern/kern_prot.c:1950 > #13 0xc0656d7f in seteuid (td=0xc9196b80, uap=0xc6b96cec) at > /usr/src/sys/kern/kern_prot.c:615 > #14 0xc06985ff in syscallenter (td=0xc9196b80, sa=0xc6b96ce4) at > /usr/src/sys/kern/subr_trap.c:315 > #15 0xc0880884 in syscall (frame=0xc6b96d28) at > /usr/src/sys/i386/i386/trap.c:1061 > #16 0xc08671d1 in Xint0x80_syscall () at > /usr/src/sys/i386/i386/exception.s:264 > #17 0x00000033 in ?? () > > (kgdb) frame 10 > #10 0xc0657a16 in uihold (uip=0x0) at /usr/src/sys/kern/kern_resource.c:1248 > 1248 { > (kgdb) list > 1243 * Place another refcount on a uidinfo struct. > 1244 */ > 1245 void > 1246 uihold(uip) > 1247 struct uidinfo *uip; > 1248 { > 1249 > 1250 refcount_acquire(&uip->ui_ref); > 1251 } > 1252 > (kgdb) p *uip > Cannot access memory at address 0x0 > (kgdb) p uip > $1 = (struct uidinfo *) 0x0 > (kgdb) > > > > > > > Wed, 16 Feb 2011 12:08:30 -0500 письмо от Andrew Boyer > : > > > >> Moving this to -current and -stable and following up... > >> > >> Something is broken with coredumps on stable/8 amd64. I tried a vanilla > >> 8.2-RC3 and yesterday's csup of stable/8; neither can dump a core with > 'sysctl > >> debug.kdb.panic=1'. > >> > >> For the 8.2-RC3 / amd64 / GENERIC install, I used the memstick image, > >> installed on ad7 (a 250GB SATA drive), used the default partition map, and > set > >> dumpdev to AUTO. > >> > >> I added enough tracing to show that the second panic is due to the syncer > >> process flushing buffers to the other filesystems in parallel with the > dump. > >> I've seen this panic and a similar one 'buffer not locked' coming from > >> ffs_write(). One time out of about 30 the core ran to completion, but > slowly > >> (~1MB/sec). Other times the dump just locks up completely with no other > >> output. > >> > >> Does anyone know what might have changed to expose this problem? > >> > >> I don't ever see it under 7.1. > >> > >> Thanks, > >> Andrew > >> > >> On Feb 3, 2011, at 12:11 AM, Eugene Grosbein wrote: > >> > >>> On 02.02.2011 00:50, Gleb Smirnoff wrote: > >>> > >>>> E> Uptime: 8h3m51s > >>>> E> Dumping 4087 MB (3 chunks) > >>>> E> chunk 0: 1MB (150 pages) ... ok > >>>> E> chunk 1: 3575MB (915088 pages) 3559 3543panic: bufwrite: buffer is > not > >> busy??? > >>>> E> cpuid = 3 > >>>> E> Uptime: 8h3m52s > >>>> E> Automatic reboot in 15 seconds - press a key on the console to abort > >>>> Can you add KDB_TRACE option to kernel? Your boxes for some reason can't > >>>> dump core, but with this option we will have at least trace. > >>> > >>> I see Mike Tancsa's box has "bufwrite: buffer is not busy???" problem too. > >>> Has anyone a thought how to fix generation of crashdumps? > >>> > >>> Eugene Grosbein > >>> > >>> > >>> _______________________________________________ > >>> 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" > >> > >> -------------------------------------------------- > >> Andrew Boyer aboyer@averesystems.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" > > > > > > > -- > ------------------- > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications, mike@sentex.net > Providing Internet services since 1994 www.sentex.net > Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-current@FreeBSD.ORG Sun Feb 20 18:25:10 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 5CBAC1065693; Sun, 20 Feb 2011 18:25:10 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id 8849B8FC13; Sun, 20 Feb 2011 18:25:09 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id DF96441C7CC; Sun, 20 Feb 2011 19:25:08 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id 4N0FTCM1UUiR; Sun, 20 Feb 2011 19:25:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 8133C41C7C9; Sun, 20 Feb 2011 19:25:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 00B5C4448F3; Sun, 20 Feb 2011 18:21:18 +0000 (UTC) Date: Sun, 20 Feb 2011 18:21:18 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Hajimu UMEMOTO In-Reply-To: Message-ID: <20110220181713.C13400@maildrop.int.zabbadoz.net> References: X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org, FreeBSD current mailing list Subject: Re: CFR: importing openresolv 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, 20 Feb 2011 18:25:10 -0000 On Thu, 19 Aug 2010, Hajimu UMEMOTO wrote: Hi, > I wish to import openresolv 3.3.5 into our base tree. It makes > merging the DNS server addresses informed from DHCP, DHCPv6, PPP, ... > into /etc/resolv.conf easier. > > http://roy.marples.name/projects/openresolv > > My patch against 9-CURRENT can be obtained from: > > http://www.imasy.or.jp/~ume/FreeBSD/openresolv-20100818.diff.gz Do you have an updated patch for 3.4.1 or 3.3.6? I'd like to help to you get it in for 9.0-R. I wouldn't even mind if some ports would conflict with it for a while not making the situation any worse than it is these days. /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. From owner-freebsd-current@FreeBSD.ORG Sun Feb 20 19:36: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 62F71106564A for ; Sun, 20 Feb 2011 19:36:44 +0000 (UTC) (envelope-from eirnym@gmail.com) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by mx1.freebsd.org (Postfix) with ESMTP id EA5808FC1D for ; Sun, 20 Feb 2011 19:36:43 +0000 (UTC) Received: by bwz13 with SMTP id 13so1739849bwz.17 for ; Sun, 20 Feb 2011 11:36:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:from:date:message-id:subject:to :content-type; bh=ukfDaS71wVNlTDm1oJxQNYZ/y7U70ozNkwYwq88mNJg=; b=IZepBW2T3ui9OQzFdDO5/5F5yLZmoaFM2tW/eLcEh3UwIEL9NZ8joOdRM0gIHsl62M L4DPWR0vkMTZdmSNQSpH0kiEOOYDlQk/tkt9KapBloQr6UoDyBNFprfp1V0x14TWwZak A2senWSzypxED9hXnpAmigc+yUf3wR/qahTv0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=FKpXYxESKB01L27HVepHhdQJojtNbJ62ciidDBgzVdLQY+YN6SQ2BnnmJ8g9nkiITG ecDM0vqPVADOYtRbiL5KqzNyVyeGN2HBnXnpzE7dAI/biwvTbWRt2qtr2JoeZeSik18a PZWt5z2qI5rCq9mKOdh2DRKelSL/yRO2YMEgs= Received: by 10.204.14.202 with SMTP id h10mr533740bka.182.1298228934277; Sun, 20 Feb 2011 11:08:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.14.141 with HTTP; Sun, 20 Feb 2011 11:08:33 -0800 (PST) From: Eir Nym Date: Sun, 20 Feb 2011 22:08:33 +0300 Message-ID: To: FreeBSD Mail Lists Content-Type: text/plain; charset=UTF-8 Subject: Sade(8) compile 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: Sun, 20 Feb 2011 19:36:44 -0000 Hello guys, I have amd64 FreeBSD-Current box (r214751) and want to build fresh system to install, but compile fails every time . Configuration files are same. The failure is in sade(8), where compiller try to find dialog h in /usr/src/usr.sbin/../../gnu/lib/libdialog/dialog.h , not in libadialog directory. First appearance of this failure is about month ago (I have autobuild system) make.conf is /dev/null src.conf contains following keys turned on: WITHOUT_ATM WITHOUT_AMD WITH_BSD_GREP WITHOUT_CTM WITHOUT_FLOPPY WITHOUT_FREEBSD_UPDATE WITHOUT_IPFILTER WITHOUT_IPFW WITHOUT_IPX WITHOUT_NIS WITHOUT_NLS_CATALOGS WITHOUT_RCMDS WITHOUT_TCSH WITH_BIND_LARGE_FILE WITH_BIND_SIGCHASE WITH_GPIO From owner-freebsd-current@FreeBSD.ORG Sun Feb 20 22:23: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 4E581106564A for ; Sun, 20 Feb 2011 22:23:32 +0000 (UTC) (envelope-from yanegomi@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 D4F5D8FC16 for ; Sun, 20 Feb 2011 22:23:31 +0000 (UTC) Received: by wyb32 with SMTP id 32so1268574wyb.13 for ; Sun, 20 Feb 2011 14:23:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=nZQktCJJf7S55uqF6+ZhFAJ6g+/O8mo7/vcKa5uwONE=; b=swTSxiDejrUB3nEY9UMKlF0hm3RwjmumwzOXIuChFtwfIGQSdYWHI/XlDdS1tEvVJV 9WJD3rGwgEW4SdX9HPJSBCwS5meTNpLt2sv2g3cOV6Rxl8iWr7QzuEAYqQh26f1+xLs2 nLvTABabiJLdX3aFnaDItnEDU5ebmkXt+UpME= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=oMx5LEm9RDGH9qCxFmZwCQIms/pxxALbUc8TG3SaPHqDs4odYo0KS9BHtms7rf/7XS GmGcA+KTL443kG1yelMGThBtf/KlPsPKj5DLn5YqZX2fv73rowZua4DD4r0fs5tSE3pQ GcDYw1YwYdEQPJtqGMCHi+zCFZ+rtakMhyk4g= MIME-Version: 1.0 Received: by 10.216.154.8 with SMTP id g8mr1498892wek.12.1298240610673; Sun, 20 Feb 2011 14:23:30 -0800 (PST) Sender: yanegomi@gmail.com Received: by 10.216.71.200 with HTTP; Sun, 20 Feb 2011 14:23:30 -0800 (PST) In-Reply-To: References: Date: Sun, 20 Feb 2011 14:23:30 -0800 X-Google-Sender-Auth: 3rA6sqCD2MaPFLWsgki3Ti_CXcM Message-ID: From: Garrett Cooper To: Eir Nym Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Mail Lists Subject: Re: Sade(8) compile 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: Sun, 20 Feb 2011 22:23:32 -0000 On Sun, Feb 20, 2011 at 11:08 AM, Eir Nym wrote: > Hello guys, > > I have amd64 FreeBSD-Current box (r214751) and want to build fresh > system to install, but compile fails every time . Configuration files > are same. > > The failure is in sade(8), where compiller try to find dialog h in > /usr/src/usr.sbin/../../gnu/lib/libdialog/dialog.h , not in libadialog > directory. First appearance of this failure =A0is about month ago (I > have autobuild system) Works for me: FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r218082M: Sun Jan 30 00:20:08 PST 2011 gcooper@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 Make sure to update the Makefile to point at libodialog instead of libdialog. See this commit for more details: http://svn.freebsd.org/viewvc/base?view=3Drevision&revision=3D217309 . HTH, -Garrett From owner-freebsd-current@FreeBSD.ORG Mon Feb 21 01:44:36 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 C999A106564A; Mon, 21 Feb 2011 01:44:36 +0000 (UTC) (envelope-from dhorn2000@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5B2C38FC1B; Mon, 21 Feb 2011 01:44:36 +0000 (UTC) Received: by qwj9 with SMTP id 9so4506914qwj.13 for ; Sun, 20 Feb 2011 17:44:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=GdUtYTrYqmE96ngqCdCQRmM5cq0ALdXG1Cob/j3trvw=; b=RwE1quuyb5m/rCMujtiXuLBjYJRyOHlSyD0IwTTgtZAQshMmS94pSsmRM/gMNV3Ujg mHUHj3b77ya5zfrJ7WL4/EI+7MgDqelZHFNYkBBEwyOwbbc4wsRC+Q6SobKAUnWNAxSp MaffzUUtlrBI/EYXkn0wjXg0I/kHmW4VmUVpI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=IVSTrZ1EsHZJXjWL1PhpfaT0gfVQDcMpMn3p7znhx5PpWOK88u5HYWE4SbefdJ6QMV A7A7aLa5laqhgW3k3dcYog8D+OJFpHdbc9CpCRYWyBs0XLxSE5725WO0/+En0rmsnzQE 8sC3uP35tZR0tEc/GMNBn38Sa3yrMs8nPVRcc= MIME-Version: 1.0 Received: by 10.229.85.82 with SMTP id n18mr544664qcl.292.1298251326813; Sun, 20 Feb 2011 17:22:06 -0800 (PST) Received: by 10.229.215.138 with HTTP; Sun, 20 Feb 2011 17:22:06 -0800 (PST) In-Reply-To: References: Date: Sun, 20 Feb 2011 20:22:06 -0500 Message-ID: From: David Horn To: Hajimu UMEMOTO Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: arch@freebsd.org, current@freebsd.org Subject: Re: CFR: importing openresolv 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, 21 Feb 2011 01:44:37 -0000 On Wed, Aug 18, 2010 at 11:27 AM, Hajimu UMEMOTO wrote: > Hi, > > I wish to import openresolv 3.3.5 into our base tree. =A0It makes > merging the DNS server addresses informed from DHCP, DHCPv6, PPP, ... > into /etc/resolv.conf easier. > > =A0 =A0 =A0 =A0http://roy.marples.name/projects/openresolv > > My patch against 9-CURRENT can be obtained from: > > =A0 =A0 =A0 =A0http://www.imasy.or.jp/~ume/FreeBSD/openresolv-20100818.di= ff.gz > > Sincerely, > > -- > Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan > ume@mahoroba.org =A0ume@{,jp.}FreeBSD.org > http://www.imasy.org/~ume/ Sounds like a fine plan. I will help test as time allows. I had a test patch incorporating openresolv quite some time ago, and it was straight forward, and worked well in my limited testing with dual stack multiple DNS providers. (DHCPv6/RFC5006-RDNSS/DHCPv4/Avahi) >From talking to Roy Marples in the past, this code has already been imported into netbsd at some level, and I believe that he was recommending the use of the latest code from the repository due to some bug fixes, but it is worthy of another conversation since quite some time has elapsed since my last query. Good Luck. _Dave From owner-freebsd-current@FreeBSD.ORG Mon Feb 21 05:56: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 5E25F1065670 for ; Mon, 21 Feb 2011 05:56:22 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 3A46A8FC17 for ; Mon, 21 Feb 2011 05:56:22 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id CF4C346B0D; Mon, 21 Feb 2011 00:56:21 -0500 (EST) Date: Mon, 21 Feb 2011 05:56:21 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Shawn Webb In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD-current Subject: Re: DTrace 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: Mon, 21 Feb 2011 05:56:22 -0000 On Fri, 18 Feb 2011, Shawn Webb wrote: > Hey fellow current users, > > Looks like dtrace is broken in current: > > # dtrace -l -f acl dtrace: invalid probe specifier acl: > "/usr/lib/dtrace/psinfo.d", line 37: syntax error near "uid_t" Error messages along these lines almost always mean that the kernel was built without WITH_CTF (causing dtrace to be unable to find the type information it requires). Robert > > Line 37 shows: > uid_t pr_uid; /* real user id */ > > Looks good to me, but why is dtrace complaining? > > Thanks, > > Shawn Webb > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Mon Feb 21 07:25: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 B8E65106573C for ; Mon, 21 Feb 2011 07:25:34 +0000 (UTC) (envelope-from rmgls@free.fr) Received: from smtpfb1-g21.free.fr (smtpfb1-g21.free.fr [212.27.42.9]) by mx1.freebsd.org (Postfix) with ESMTP id 7258D8FC0C for ; Mon, 21 Feb 2011 07:25:32 +0000 (UTC) Received: from smtp3-g21.free.fr (smtp3-g21.free.fr [212.27.42.3]) by smtpfb1-g21.free.fr (Postfix) with ESMTP id 03AC12DD4B for ; Mon, 21 Feb 2011 08:06:35 +0100 (CET) Received: from free.fr (unknown [88.172.40.194]) by smtp3-g21.free.fr (Postfix) with ESMTP id 125E6A624E for ; Mon, 21 Feb 2011 08:06:29 +0100 (CET) from: rmgls@free.fr To: freebsd-current@freebsd.org Date: Mon, 21 Feb 2011 08:06:33 +0100 Sender: rmgls@free.fr Message-Id: <20110221070630.125E6A624E@smtp3-g21.free.fr> Subject: Dell 370 bluetooth minicard 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, 21 Feb 2011 07:25:34 -0000 Hello all, On a Dell E6400 the bluetooth wireless minicard (Dell 370 => BCM2046B1 if i am right) does not attach to any driver. Is this ship supported by the btbcmfw driver? Any comment would be helpfull. Thanks. rmgls rmgls@free.fr From owner-freebsd-current@FreeBSD.ORG Mon Feb 21 10:26: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 B8BDE1065673 for ; Mon, 21 Feb 2011 10:26:02 +0000 (UTC) (envelope-from samspeed@mail.ru) Received: from f18.mail.ru (f18.mail.ru [217.69.129.85]) by mx1.freebsd.org (Postfix) with ESMTP id 405FF8FC13 for ; Mon, 21 Feb 2011 10:26:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail; h=Message-Id:Content-Type:Reply-To:Date:Mime-Version:Subject:To:From; bh=adQu24J0V1ZBBY9FoD8oCL/nV3miT0d2pS9t+4lZA+E=; b=S/j4S2Ue6C++ous7yxSST5/A/OSmDQPv1v7T3Fv4UmaHr5P32qEULGPM7eo6zOBHS0Z2O6nS3F3w7ocvpzenQS61q/maMJC23ZE261mB6IoCNgR5Taz4Zv5av/Qb4oAz; Received: from mail by f18.mail.ru with local id 1PrSxs-0008Pu-00 for freebsd-current@freebsd.org; Mon, 21 Feb 2011 13:26:00 +0300 Received: from [91.202.27.126] by e.mail.ru with HTTP; Mon, 21 Feb 2011 13:26:00 +0300 From: Andrey Smagin To: freebsd-current@freebsd.org Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: 172.17.1.60 via proxy [91.202.27.126] Date: Mon, 21 Feb 2011 13:26:00 +0300 Message-Id: X-Spam: Not detected X-Mras: Ok Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: current repeateble crash in 2 places X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andrey Smagin List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 10:26:02 -0000 today current crash with loaded mpd5 1st place: ipwf_chk ipfw_check_hook pfil_run_hooks ip_output tcp_output repeated tcp_mtudisc ~20 times tcp_ctlinput icmp_input ip_input swi_net intr_event_execute_handlers 2nd place flowtable_lookup flowteble_lookup_mbuf ip_output tcp_output ~ repeated tcp_mtudisc 20 times tcp_ctlinput icmp_input ip_input netisr_dispatch_src ng_iface_rcvdata ng_apply_item repeated ng_snd_item 3 ng_pppoe_rcvdata_ether times ng_apply_item ng_snd_item ether_demux ether_input em_rxeof em_msix_rx inthr_event_execute_handlers ithread_loop From owner-freebsd-current@FreeBSD.ORG Mon Feb 21 10:33:42 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 B6DDA1065670 for ; Mon, 21 Feb 2011 10:33:42 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 817298FC17 for ; Mon, 21 Feb 2011 10:33:42 +0000 (UTC) Received: by iyj12 with SMTP id 12so703284iyj.13 for ; Mon, 21 Feb 2011 02:33:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.43.65.136 with SMTP id xm8mr1702824icb.313.1298284421899; Mon, 21 Feb 2011 02:33:41 -0800 (PST) Received: by 10.231.149.79 with HTTP; Mon, 21 Feb 2011 02:33:41 -0800 (PST) Date: Mon, 21 Feb 2011 11:33:41 +0100 Message-ID: From: Olivier Smedts To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Can't buildworld since Clang update 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, 21 Feb 2011 10:33:42 -0000 Hello, I can't buildworld with Clang since the last update. %uname -a FreeBSD zozo.afpicl.lan 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r218908M: Mon Feb 21 09:56:35 CET 2011 root@zozo.afpicl.lan:/usr/obj/usr/src/sys/CORE amd64 %clang -v FreeBSD clang version 2.9 (trunk 126079) 20110220 Target: x86_64-undermydesk-freebsd9.0 Thread model: posix %cat /etc/src.conf .if !defined(CC) || ${CC} =3D=3D "cc" CC=3Dclang .endif .if !defined(CXX) || ${CXX} =3D=3D "c++" CXX=3Dclang++ .endif # Don't die on warnings NO_WERROR=3D WERROR=3D %head /etc/make.conf CPUTYPE?=3Dcore2 KERNCONF=3DCORE CFLAGS=3D-O2 -pipe -march=3Dnative NO_CPU_CFLAGS=3Dyes COPTFLAGS=3D-O2 -pipe -march=3Dnative NO_CPU_COPTFLAGS=3Dyes BOOTWAIT=3D0 WITHOUT_PROFILE=3Dyes # make buildworld [...] =3D=3D=3D> lib/libz (obj,depend,all,install) [...] clang -O2 -pipe -march=3Dnative -DHAS_snprintf -DHAS_vsnprintf -I/usr/src/lib/libz -DASMV -DNO_UNDERLINE -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wa,--noexecstack -c /usr/src/lib/libz/contrib/gcc_gvmat64/gvmat64.S /tmp/cc-VUyvc6.s:6:1: warning: ignoring directive for now .intel_syntax noprefix ^ /tmp/cc-VUyvc6.s:12:9: error: unknown use of instruction mnemonic without a size suffix mov [(rsp + 40 - 96)],rbx ^ /tmp/cc-VUyvc6.s:13:9: error: unknown use of instruction mnemonic without a size suffix mov [(rsp + 48 - 96)],rbp ^ /tmp/cc-VUyvc6.s:16:9: error: unknown use of instruction mnemonic without a size suffix mov rcx,rdi ^ /tmp/cc-VUyvc6.s:18:9: error: unknown use of instruction mnemonic without a size suffix mov r8d,esi ^ /tmp/cc-VUyvc6.s:21:9: error: unknown use of instruction mnemonic without a size suffix mov [(rsp + 56 - 96)],r12 ^ /tmp/cc-VUyvc6.s:22:9: error: unknown use of instruction mnemonic without a size suffix mov [(rsp + 64 - 96)],r13 ^ /tmp/cc-VUyvc6.s:23:9: error: unknown use of instruction mnemonic without a size suffix mov [(rsp + 72 - 96)],r14 ^ /tmp/cc-VUyvc6.s:24:9: error: unknown use of instruction mnemonic without a size suffix mov [(rsp + 80 - 96)],r15 ^ /tmp/cc-VUyvc6.s:26:9: error: unknown use of instruction mnemonic without a size suffix mov edi, [ rcx + 168] ^ /tmp/cc-VUyvc6.s:27:9: error: unknown use of instruction mnemonic without a size suffix mov esi, [ rcx + 188] ^ /tmp/cc-VUyvc6.s:28:9: error: unknown use of instruction mnemonic without a size suffix mov eax, [ rcx + 76] ^ /tmp/cc-VUyvc6.s:29:9: error: unknown use of instruction mnemonic without a size suffix mov ebx, [ rcx + 172] ^ /tmp/cc-VUyvc6.s:30:9: error: unknown use of instruction mnemonic without a size suffix cmp edi, esi ^ /tmp/cc-VUyvc6.s:32:9: error: unknown use of instruction mnemonic without a size suffix shr ebx, 2 ^ /tmp/cc-VUyvc6.s:40:9: error: ambiguous instructions require an explicit suffix (could be 'decb', 'decw', 'decl', or 'decq') dec ebx ^ /tmp/cc-VUyvc6.s:41:9: error: unknown use of instruction mnemonic without a size suffix shl ebx, 16 ^ /tmp/cc-VUyvc6.s:42:9: error: unknown use of instruction mnemonic without a size suffix or ebx, eax ^ /tmp/cc-VUyvc6.s:49:9: error: unknown use of instruction mnemonic without a size suffix mov eax, [ rcx + 192] ^ /tmp/cc-VUyvc6.s:50:9: error: unknown use of instruction mnemonic without a size suffix mov [(rsp + 8 - 96)], ebx ^ /tmp/cc-VUyvc6.s:51:9: error: unknown use of instruction mnemonic without a size suffix mov r10d, [ rcx + 164] ^ /tmp/cc-VUyvc6.s:52:9: error: unknown use of instruction mnemonic without a size suffix cmp r10d, eax ^ /tmp/cc-VUyvc6.s:53:9: error: unknown use of instruction mnemonic without a size suffix cmovnl r10d, eax ^ /tmp/cc-VUyvc6.s:54:9: error: unknown use of instruction mnemonic without a size suffix mov [(rsp + 16 - 96)],r10d ^ /tmp/cc-VUyvc6.s:59:9: error: unknown use of instruction mnemonic without a size suffix mov r10, [ rcx + 80] ^ /tmp/cc-VUyvc6.s:60:9: error: unknown use of instruction mnemonic without a size suffix mov ebp, [ rcx + 156] ^ /tmp/cc-VUyvc6.s:61:9: error: unknown use of instruction mnemonic without a size suffix lea r13, [r10 + rbp] ^ /tmp/cc-VUyvc6.s:66:10: error: unknown use of instruction mnemonic without a size suffix mov r9,r13 ^ /tmp/cc-VUyvc6.s:67:10: error: ambiguous instructions require an explicit suffix (could be 'negb', 'negw', 'negl', or 'negq') neg r13 ^ /tmp/cc-VUyvc6.s:68:10: error: unknown use of instruction mnemonic without a size suffix and r13,3 ^ /tmp/cc-VUyvc6.s:74:9: error: unknown use of instruction mnemonic without a size suffix mov eax, [ rcx + 68] ^ /tmp/cc-VUyvc6.s:75:9: error: unknown use of instruction mnemonic without a size suffix sub eax, (258 +3 +1) ^ /tmp/cc-VUyvc6.s:78:9: error: unknown use of instruction mnemonic without a size suffix xor edi,edi ^ /tmp/cc-VUyvc6.s:79:9: error: unknown use of instruction mnemonic without a size suffix sub ebp, eax ^ /tmp/cc-VUyvc6.s:81:9: error: unknown use of instruction mnemonic without a size suffix mov r11d, [ rcx + 168] ^ /tmp/cc-VUyvc6.s:83:9: error: unknown use of instruction mnemonic without a size suffix cmovng ebp,edi ^ /tmp/cc-VUyvc6.s:90:8: error: unknown use of instruction mnemonic without a size suffix lea rsi,[r10+r11] ^ /tmp/cc-VUyvc6.s:96:25: error: unexpected token in argument list movzx r12d,word ptr [r9] ^ /tmp/cc-VUyvc6.s:97:25: error: unexpected token in argument list movzx ebx, word ptr [r9 + r11 - 1] ^ /tmp/cc-VUyvc6.s:99:9: error: unknown use of instruction mnemonic without a size suffix mov rdi, [ rcx + 96] ^ /tmp/cc-VUyvc6.s:103:9: error: unknown use of instruction mnemonic without a size suffix mov edx, [(rsp + 8 - 96)] ^ /tmp/cc-VUyvc6.s:105:21: error: unexpected token in argument list cmp bx,word ptr [rsi + r8 - 1] ^ /tmp/cc-VUyvc6.s:111:9: error: unknown use of instruction mnemonic without a size suffix and r8d, edx ^ /tmp/cc-VUyvc6.s:113:25: error: unexpected token in argument list movzx r8d, word ptr [rdi + r8*2] ^ /tmp/cc-VUyvc6.s:114:9: error: unknown use of instruction mnemonic without a size suffix cmp r8d, ebp ^ /tmp/cc-VUyvc6.s:119:9: error: unknown use of instruction mnemonic without a size suffix sub edx, 0x00010000 ^ /tmp/cc-VUyvc6.s:120:3: warning: ignoring directive for now .att_syntax ^ /tmp/cc-VUyvc6.s:122:3: warning: ignoring directive for now .intel_syntax noprefix ^ /tmp/cc-VUyvc6.s:125:21: error: unexpected token in argument list cmp bx,word ptr [rsi + r8 - 1] ^ /tmp/cc-VUyvc6.s:126:3: warning: ignoring directive for now .att_syntax ^ /tmp/cc-VUyvc6.s:128:3: warning: ignoring directive for now .intel_syntax noprefix ^ /tmp/cc-VUyvc6.s:131:9: error: unknown use of instruction mnemonic without a size suffix and r8d, edx ^ /tmp/cc-VUyvc6.s:133:25: error: unexpected token in argument list movzx r8d, word ptr [rdi + r8*2] ^ /tmp/cc-VUyvc6.s:134:9: error: unknown use of instruction mnemonic without a size suffix cmp r8d, ebp ^ /tmp/cc-VUyvc6.s:135:3: warning: ignoring directive for now .att_syntax ^ /tmp/cc-VUyvc6.s:137:3: warning: ignoring directive for now .intel_syntax noprefix ^ /tmp/cc-VUyvc6.s:138:9: error: unknown use of instruction mnemonic without a size suffix sub edx, 0x00010000 ^ /tmp/cc-VUyvc6.s:139:3: warning: ignoring directive for now .att_syntax ^ /tmp/cc-VUyvc6.s:141:3: warning: ignoring directive for now .intel_syntax noprefix ^ /tmp/cc-VUyvc6.s:144:21: error: unexpected token in argument list cmp bx,word ptr [rsi + r8 - 1] ^ /tmp/cc-VUyvc6.s:145:3: warning: ignoring directive for now .att_syntax ^ /tmp/cc-VUyvc6.s:147:3: warning: ignoring directive for now .intel_syntax noprefix ^ /tmp/cc-VUyvc6.s:150:9: error: unknown use of instruction mnemonic without a size suffix and r8d, edx ^ /tmp/cc-VUyvc6.s:152:25: error: unexpected token in argument list movzx r8d, word ptr [rdi + r8*2] ^ /tmp/cc-VUyvc6.s:153:9: error: unknown use of instruction mnemonic without a size suffix cmp r8d, ebp ^ /tmp/cc-VUyvc6.s:154:3: warning: ignoring directive for now .att_syntax ^ /tmp/cc-VUyvc6.s:156:3: warning: ignoring directive for now .intel_syntax noprefix ^ /tmp/cc-VUyvc6.s:157:9: error: unknown use of instruction mnemonic without a size suffix sub edx, 0x00010000 ^ /tmp/cc-VUyvc6.s:158:3: warning: ignoring directive for now .att_syntax ^ /tmp/cc-VUyvc6.s:160:3: warning: ignoring directive for now .intel_syntax noprefix ^ /tmp/cc-VUyvc6.s:164:21: error: unexpected token in argument list cmp bx,word ptr [rsi + r8 - 1] ^ /tmp/cc-VUyvc6.s:165:3: warning: ignoring directive for now .att_syntax ^ /tmp/cc-VUyvc6.s:168:3: warning: ignoring directive for now .intel_syntax noprefix ^ /tmp/cc-VUyvc6.s:172:9: error: unknown use of instruction mnemonic without a size suffix and r8d, edx ^ /tmp/cc-VUyvc6.s:174:25: error: unexpected token in argument list movzx r8d, word ptr [rdi + r8*2] ^ /tmp/cc-VUyvc6.s:175:9: error: unknown use of instruction mnemonic without a size suffix cmp r8d, ebp ^ /tmp/cc-VUyvc6.s:176:3: warning: ignoring directive for now .att_syntax ^ /tmp/cc-VUyvc6.s:178:3: warning: ignoring directive for now .intel_syntax noprefix ^ /tmp/cc-VUyvc6.s:179:9: error: unknown use of instruction mnemonic without a size suffix sub edx, 0x00010000 ^ /tmp/cc-VUyvc6.s:180:3: warning: ignoring directive for now .att_syntax ^ /tmp/cc-VUyvc6.s:182:3: warning: ignoring directive for now .intel_syntax noprefix ^ /tmp/cc-VUyvc6.s:186:21: error: unexpected token in argument list cmp bx,word ptr [rsi + r8 - 1] ^ /tmp/cc-VUyvc6.s:187:3: warning: ignoring directive for now .att_syntax ^ /tmp/cc-VUyvc6.s:189:3: warning: ignoring directive for now .intel_syntax noprefix ^ /tmp/cc-VUyvc6.s:191:24: error: unexpected token in argument list cmp r12w, word ptr [r10 + r8] ^ /tmp/cc-VUyvc6.s:192:3: warning: ignoring directive for now .att_syntax ^ /tmp/cc-VUyvc6.s:194:3: warning: ignoring directive for now .intel_syntax noprefix ^ /tmp/cc-VUyvc6.s:198:9: error: unknown use of instruction mnemonic without a size suffix mov [(rsp + 8 - 96)], edx ^ /tmp/cc-VUyvc6.s:205:9: error: unknown use of instruction mnemonic without a size suffix lea rsi,[r8+r10] ^ /tmp/cc-VUyvc6.s:206:9: error: unknown use of instruction mnemonic without a size suffix mov rdx, 0xfffffffffffffef8 ^ /tmp/cc-VUyvc6.s:207:9: error: unknown use of instruction mnemonic without a size suffix lea rsi, [rsi + r13 + 0x0108] ^ /tmp/cc-VUyvc6.s:208:9: error: unknown use of instruction mnemonic without a size suffix lea rdi, [r9 + r13 + 0x0108] ^ /tmp/cc-VUyvc6.s:214:9: error: unknown use of instruction mnemonic without a size suffix mov rax, [rsi + rdx] ^ /tmp/cc-VUyvc6.s:215:9: error: unknown use of instruction mnemonic without a size suffix xor rax, [rdi + rdx] ^ /tmp/cc-VUyvc6.s:218:9: error: unknown use of instruction mnemonic without a size suffix mov rax, [rsi + rdx + 8] ^ /tmp/cc-VUyvc6.s:219:9: error: unknown use of instruction mnemonic without a size suffix xor rax, [rdi + rdx + 8] ^ /tmp/cc-VUyvc6.s:223:9: error: unknown use of instruction mnemonic without a size suffix mov rax, [rsi + rdx + 8+8] ^ /tmp/cc-VUyvc6.s:224:9: error: unknown use of instruction mnemonic without a size suffix xor rax, [rdi + rdx + 8+8] ^ /tmp/cc-VUyvc6.s:227:9: error: unknown use of instruction mnemonic without a size suffix add rdx,8+8+8 ^ /tmp/cc-VUyvc6.s:229:3: warning: ignoring directive for now .att_syntax ^ /tmp/cc-VUyvc6.s:232:3: warning: ignoring directive for now .intel_syntax noprefix ^ /tmp/cc-VUyvc6.s:234:18: error: unknown use of instruction mnemonic without a size suffix LeaveLoopCmps16: add rdx,8 ^ /tmp/cc-VUyvc6.s:235:17: error: unknown use of instruction mnemonic without a size suffix LeaveLoopCmps8: add rdx,8 ^ /tmp/cc-VUyvc6.s:238:9: error: unknown use of instruction mnemonic without a size suffix test eax, 0x0000FFFF ^ /tmp/cc-VUyvc6.s:241:9: error: unknown use of instruction mnemonic without a size suffix test eax,0xffffffff ^ /tmp/cc-VUyvc6.s:245:9: error: unknown use of instruction mnemonic without a size suffix add rdx,4 ^ /tmp/cc-VUyvc6.s:246:9: error: unknown use of instruction mnemonic without a size suffix shr rax,32 ^ /tmp/cc-VUyvc6.s:247:9: error: unknown use of instruction mnemonic without a size suffix or ax,ax ^ /tmp/cc-VUyvc6.s:248:3: warning: ignoring directive for now .att_syntax ^ /tmp/cc-VUyvc6.s:250:3: warning: ignoring directive for now .intel_syntax noprefix ^ /tmp/cc-VUyvc6.s:253:9: error: unknown use of instruction mnemonic without a size suffix shr eax,16 ^ /tmp/cc-VUyvc6.s:254:9: error: unknown use of instruction mnemonic without a size suffix add rdx,2 ^ /tmp/cc-VUyvc6.s:257:9: error: unknown use of instruction mnemonic without a size suffix sub al, 1 ^ /tmp/cc-VUyvc6.s:258:9: error: unknown use of instruction mnemonic without a size suffix adc rdx, 0 ^ /tmp/cc-VUyvc6.s:262:9: error: unknown use of instruction mnemonic without a size suffix lea rax, [rdi + rdx] ^ /tmp/cc-VUyvc6.s:263:9: error: unknown use of instruction mnemonic without a size suffix sub rax, r9 ^ /tmp/cc-VUyvc6.s:264:9: error: unknown use of instruction mnemonic without a size suffix cmp eax, 258 ^ /tmp/cc-VUyvc6.s:265:3: warning: ignoring directive for now .att_syntax ^ /tmp/cc-VUyvc6.s:267:3: warning: ignoring directive for now .intel_syntax noprefix ^ /tmp/cc-VUyvc6.s:273:9: error: unknown use of instruction mnemonic without a size suffix cmp eax, r11d ^ /tmp/cc-VUyvc6.s:276:9: error: unknown use of instruction mnemonic without a size suffix lea rsi,[r10+r11] ^ /tmp/cc-VUyvc6.s:278:9: error: unknown use of instruction mnemonic without a size suffix mov rdi, [ rcx + 96] ^ /tmp/cc-VUyvc6.s:279:9: error: unknown use of instruction mnemonic without a size suffix mov edx, [(rsp + 8 - 96)] ^ /tmp/cc-VUyvc6.s:280:3: warning: ignoring directive for now .att_syntax ^ /tmp/cc-VUyvc6.s:282:3: warning: ignoring directive for now .intel_syntax noprefix ^ /tmp/cc-VUyvc6.s:290:9: error: unknown use of instruction mnemonic without a size suffix mov r11d, eax ^ /tmp/cc-VUyvc6.s:291:9: error: unknown use of instruction mnemonic without a size suffix mov [ rcx + 160], r8d ^ /tmp/cc-VUyvc6.s:292:9: error: unknown use of instruction mnemonic without a size suffix cmp eax, [(rsp + 16 - 96)] ^ /tmp/cc-VUyvc6.s:293:3: warning: ignoring directive for now .att_syntax ^ /tmp/cc-VUyvc6.s:295:3: warning: ignoring directive for now .intel_syntax noprefix ^ /tmp/cc-VUyvc6.s:297:9: error: unknown use of instruction mnemonic without a size suffix lea rsi,[r10+rax] ^ /tmp/cc-VUyvc6.s:299:25: error: unexpected token in argument list movzx ebx, word ptr [r9 + rax - 1] ^ /tmp/cc-VUyvc6.s:300:9: error: unknown use of instruction mnemonic without a size suffix mov rdi, [ rcx + 96] ^ /tmp/cc-VUyvc6.s:301:9: error: unknown use of instruction mnemonic without a size suffix mov edx, [(rsp + 8 - 96)] ^ /tmp/cc-VUyvc6.s:302:3: warning: ignoring directive for now .att_syntax ^ /tmp/cc-VUyvc6.s:304:3: warning: ignoring directive for now .intel_syntax noprefix ^ /tmp/cc-VUyvc6.s:309:9: error: unknown use of instruction mnemonic without a size suffix mov r11d,258 ^ /tmp/cc-VUyvc6.s:310:9: error: unknown use of instruction mnemonic without a size suffix mov [ rcx + 160], r8d ^ /tmp/cc-VUyvc6.s:316:9: error: unknown use of instruction mnemonic without a size suffix mov eax, [ rcx + 164] ^ /tmp/cc-VUyvc6.s:317:9: error: unknown use of instruction mnemonic without a size suffix cmp r11d, eax ^ /tmp/cc-VUyvc6.s:318:9: error: unknown use of instruction mnemonic without a size suffix cmovng eax, r11d ^ /tmp/cc-VUyvc6.s:320:9: error: unknown use of instruction mnemonic without a size suffix mov rbx,[(rsp + 40 - 96)] ^ /tmp/cc-VUyvc6.s:321:9: error: unknown use of instruction mnemonic without a size suffix mov rbp,[(rsp + 48 - 96)] ^ /tmp/cc-VUyvc6.s:322:9: error: unknown use of instruction mnemonic without a size suffix mov r12,[(rsp + 56 - 96)] ^ /tmp/cc-VUyvc6.s:323:9: error: unknown use of instruction mnemonic without a size suffix mov r13,[(rsp + 64 - 96)] ^ /tmp/cc-VUyvc6.s:324:9: error: unknown use of instruction mnemonic without a size suffix mov r14,[(rsp + 72 - 96)] ^ /tmp/cc-VUyvc6.s:325:9: error: unknown use of instruction mnemonic without a size suffix mov r15,[(rsp + 80 - 96)] ^ /tmp/cc-VUyvc6.s:328:9: error: unknown use of instruction mnemonic without a size suffix ret 0 ^ /tmp/cc-VUyvc6.s:336:3: error: unknown use of instruction mnemonic without a size suffix ret 0 ^ *** Error code 1 Stop in /usr/src/lib/libz. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. --=20 Olivier Smedts=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 _ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 ASCII ribbon campaign ( ) e-mail: olivier@gid0.org=A0 =A0 =A0 =A0 - against HTML email & vCards=A0 X www: http://www.gid0.org=A0 =A0 - against proprietary attachments / \ =A0 "Il y a seulement 10 sortes de gens dans le monde : =A0 ceux qui comprennent le binaire, =A0 et ceux qui ne le comprennent pas." From owner-freebsd-current@FreeBSD.ORG Mon Feb 21 15:07: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 7CFD11065674 for ; Mon, 21 Feb 2011 15:07:39 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3DD418FC12 for ; Mon, 21 Feb 2011 15:07:39 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:c8b2:9bc2:a26a:95be] (unknown [IPv6:2001:7b8:3a7:0:c8b2:9bc2:a26a:95be]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 488695C59; Mon, 21 Feb 2011 16:07:38 +0100 (CET) Message-ID: <4D627FBE.1070700@FreeBSD.org> Date: Mon, 21 Feb 2011 16:07:42 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.15pre) Gecko/20110219 Lanikai/3.1.9pre MIME-Version: 1.0 To: Olivier Smedts References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Can't buildworld since Clang update 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, 21 Feb 2011 15:07:39 -0000 On 2011-02-21 11:33, Olivier Smedts wrote: > I can't buildworld with Clang since the last update. ... > %cat /etc/src.conf > .if !defined(CC) || ${CC} == "cc" > CC=clang > .endif > .if !defined(CXX) || ${CXX} == "c++" > CXX=clang++ > .endif > # Don't die on warnings > NO_WERROR= > WERROR= Try putting these lines in /etc/make.conf instead. Unfortunately, due to the way src.conf is read, it isn't usable for the few cases we need to disable clang's integrated assembler, using the '-no-integrated-as' option. > /tmp/cc-VUyvc6.s:6:1: warning: ignoring directive for now > .intel_syntax noprefix > ^ In this case, you hit the one and only instance of the '.intel_syntax' directive in the tree; this directive is not yet supported by clang's integrated assembler. From owner-freebsd-current@FreeBSD.ORG Mon Feb 21 16:04: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 99C64106566B for ; Mon, 21 Feb 2011 16:04:36 +0000 (UTC) (envelope-from rbgarga@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 2EA318FC12 for ; Mon, 21 Feb 2011 16:04:35 +0000 (UTC) Received: by wyb32 with SMTP id 32so1948079wyb.13 for ; Mon, 21 Feb 2011 08:04:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type:content-transfer-encoding; bh=hHPF/qS/RA+Y0pMUzCgTENryi99853VsG1MVXCdl2pM=; b=QwqvJ2GcWOqbAGygh5DSI83RlxgwaoPsCO0DcNnIjWspXsmOslGBQ5Lj3kp3rBkAhV 6n2nJJPvK3vLY37dKp/aWc+qrPJzxETqmdwhW9ofxEU9dQ5iV4I4v6/jRNyCNEAJQqR1 pDbA4hMxpNt7D2hn6GJumwpHm5LAYzg45z9FA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; b=kJUv+eMpzdqzQ2uNFc/FHwfVBtMsNT0r0yvD1Ayr2BtcuOwjDexcPAk6d1AkwbqJPS 9A7Li6xiBGM76nqdgOYS2L/FxQwAoHBlPVQOlHErPikgXnOADXSYiKh/ej15wSJxqMmu 1UWQmDJQHlp+u9CSWbKcYPUg7xnfIHlgpI1K4= Received: by 10.216.171.68 with SMTP id q46mr2193649wel.98.1298304179106; Mon, 21 Feb 2011 08:02:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.11.69 with HTTP; Mon, 21 Feb 2011 08:02:39 -0800 (PST) In-Reply-To: References: From: Renato Botelho Date: Mon, 21 Feb 2011 13:02:39 -0300 Message-ID: To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: Error building world after last clang update 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, 21 Feb 2011 16:04:36 -0000 On Mon, Feb 21, 2011 at 12:34 PM, Renato Botelho wrote: > I was trying to upgrade my 9.0-CURRENT amd64 after clang > was updated, but i got following error: > > =3D=3D=3D> sys/boot/i386/cdboot (all) > =3D=3D=3D> sys/boot/i386/gptboot (all) > =3D=3D=3D> sys/boot/i386/kgzldr (all) > =3D=3D=3D> sys/boot/i386/libi386 (all) > clang -O2 -pipe =A0-DLOADER_NFS_SUPPORT -DCOMPORT=3D0x3f8 -DCOMSPEED=3D96= 00 > -DSMBIOS_SERIAL_NUMBERS -DLOADER_GPT_SUPPORT -DTERM_EMU > -Dalloca=3D__builtin_alloca > -I/usr/src/sys/boot/i386/libi386/../../common > -I/usr/src/sys/boot/i386/libi386/../btx/lib > -I/usr/src/sys/boot/i386/libi386/../../../contrib/dev/acpica/include > -I/usr/src/sys/boot/i386/libi386/../../.. -I. > -I/usr/src/sys/boot/i386/libi386/../../../../lib/libstand/ > -ffreestanding -mpreferred-stack-boundary=3D2 =A0-mno-mmx -mno-3dnow > -mno-sse -mno-sse2 -mno-sse3 -msoft-float -m32 -march=3Di386 -std=3Dgnu99 > =A0-c /usr/src/sys/boot/i386/libi386/amd64_tramp.S > clang: warning: argument unused during compilation: > '-mpreferred-stack-boundary=3D2' > /tmp/cc-ohEeiE.s:35:9: error: .code32 not supported yet > =A0.code32 > =A0 =A0 =A0 =A0^ > /tmp/cc-ohEeiE.s:69:9: error: .code64 not supported yet > =A0.code64 > =A0 =A0 =A0 =A0^ > *** Error code 1 > 1 error > *** Error code 2 > 1 error > *** Error code 2 > 1 error > *** Error code 2 > 1 error > *** Error code 2 > 1 error > *** Error code 2 > 1 error > *** Error code 2 > 1 error > [1] =A0 =A094534 exit 2 =A0 =A0 nice -n 15 make -j1 buildworld buildkerne= l > > My /etc/src.conf has: > > .if !defined(CC) || ${CC} =3D=3D "cc" > CC=3Dclang > .endif > .if !defined(CXX) || ${CXX} =3D=3D "c++" > CXX=3Dclang++ > .endif > # Don't die on warnings > NO_WERROR=3D > WERROR=3D > > Any hints? I read the answer for a problem like this and followed the suggestion of add clang config lines on /etc/make.conf. It worked fine, it's building again now. --=20 Renato Botelho From owner-freebsd-current@FreeBSD.ORG Mon Feb 21 16:05: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 8827A106566B for ; Mon, 21 Feb 2011 16:05:22 +0000 (UTC) (envelope-from rbgarga@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 210858FC1F for ; Mon, 21 Feb 2011 16:05:21 +0000 (UTC) Received: by wyb32 with SMTP id 32so1948720wyb.13 for ; Mon, 21 Feb 2011 08:05:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:from:date:message-id:subject:to :content-type; bh=fzeiGtSYMIAY18xwzvTI87D4BmlfEbFQACG3aEuIwbY=; b=uZRz2NW4DjvhNRfqVGr02mO8q+U+8VZQRYoez1pe6P7twlhN+HPEkh96D6BuVztFJE tgaWk6SubX5K0LftaNb53UoTdNjsNo+pzKCekJWJkSPEDaz87yn5YhIb75tVUr4xlNLV eHhVjaFN9tV8yMXTA4kcniW7OvX1mP/Agnbdk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=ERKobLCZ5ntb9aTxlMyGq/fN2LskpwUsfygbWM9STYVDPE1vpIyPs1KiMWSc3O6jeG c/zixm63RIF58LSIk9cZZkRsuuBHy0PFE11/iRoCM/YJNTJC4soXKoTQQB/7/KXhnwRS iu2QdhB4xE3X/IBJf1dSF0gs3uyucOt1E80i4= Received: by 10.216.150.129 with SMTP id z1mr1250137wej.113.1298302516297; Mon, 21 Feb 2011 07:35:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.11.69 with HTTP; Mon, 21 Feb 2011 07:34:56 -0800 (PST) From: Renato Botelho Date: Mon, 21 Feb 2011 12:34:56 -0300 Message-ID: To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 Subject: Error building world after last clang update 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, 21 Feb 2011 16:05:22 -0000 I was trying to upgrade my 9.0-CURRENT amd64 after clang was updated, but i got following error: ===> sys/boot/i386/cdboot (all) ===> sys/boot/i386/gptboot (all) ===> sys/boot/i386/kgzldr (all) ===> sys/boot/i386/libi386 (all) clang -O2 -pipe -DLOADER_NFS_SUPPORT -DCOMPORT=0x3f8 -DCOMSPEED=9600 -DSMBIOS_SERIAL_NUMBERS -DLOADER_GPT_SUPPORT -DTERM_EMU -Dalloca=__builtin_alloca -I/usr/src/sys/boot/i386/libi386/../../common -I/usr/src/sys/boot/i386/libi386/../btx/lib -I/usr/src/sys/boot/i386/libi386/../../../contrib/dev/acpica/include -I/usr/src/sys/boot/i386/libi386/../../.. -I. -I/usr/src/sys/boot/i386/libi386/../../../../lib/libstand/ -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -m32 -march=i386 -std=gnu99 -c /usr/src/sys/boot/i386/libi386/amd64_tramp.S clang: warning: argument unused during compilation: '-mpreferred-stack-boundary=2' /tmp/cc-ohEeiE.s:35:9: error: .code32 not supported yet .code32 ^ /tmp/cc-ohEeiE.s:69:9: error: .code64 not supported yet .code64 ^ *** Error code 1 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error [1] 94534 exit 2 nice -n 15 make -j1 buildworld buildkernel My /etc/src.conf has: .if !defined(CC) || ${CC} == "cc" CC=clang .endif .if !defined(CXX) || ${CXX} == "c++" CXX=clang++ .endif # Don't die on warnings NO_WERROR= WERROR= Any hints? -- Renato Botelho From owner-freebsd-current@FreeBSD.ORG Mon Feb 21 16:43:29 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 9C34E1065672 for ; Mon, 21 Feb 2011 16:43:29 +0000 (UTC) (envelope-from jerome.flesch@netasq.com) Received: from work.netasq.com (mars.netasq.com [91.212.116.3]) by mx1.freebsd.org (Postfix) with ESMTP id 0BD208FC14 for ; Mon, 21 Feb 2011 16:43:28 +0000 (UTC) Received: from pc_jf.netasq.com (unknown [10.2.200.254]) by work.netasq.com (Postfix) with ESMTPSA id 427AC740001; Mon, 21 Feb 2011 17:26:17 +0100 (CET) Message-ID: <4D6291A5.4050206@netasq.com> Date: Mon, 21 Feb 2011 17:24:05 +0100 From: Jerome Flesch User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.16) Gecko/20110106 Thunderbird/3.0.11 MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090401030701030108000803" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Process timing issue 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, 21 Feb 2011 16:43:29 -0000 This is a cryptographically signed message in MIME format. --------------ms090401030701030108000803 Content-Type: multipart/mixed; boundary="------------070706020906040708070509" This is a multi-part message in MIME format. --------------070706020906040708070509 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hello, While investigating a timing issue with one of our program, we found out = something weird: We've written a small test program that just calls=20 clock_gettime() a lot of times and checks that the time difference=20 between calls makes sense. In the end, it seems it doesn't always do. Calling twice in a row clock_gettime() takes usually less than 1ms. But=20 with an average load, about 1 time in 200000, more than 10ms are spent=20 between both calls for no apparent reason. According to our tests, when=20 it happens, the time between both calls can go from few milliseconds to=20 many seconds (our best score so far is 10 seconds :). Same goes for=20 gettimeofday(). To reproduce this issue, we use the small test program joined to this=20 mail and openssl speed test commands (usually 'openssl speed -elapsed=20 dsa2048'). It only appears if one of these openssl speed test run on the = same core than our test progam, so we have to start as many openssl=20 instances as there are cores on the test computer. For instance: - FreeBSD 7.3 + Core 2 duo - FreeBSD 7.4/STABLE + Core 2 duo - FreeBSD 8.1 + Core 2 duo - FreeBSD 8.2-RC3 + Core 2 duo (clean setup) - FreeBSD 9.0/CURRENT + Core 2 duo (clean setup, checked out last Friday)= On all these setups, with 2 instances of openssl speed tests, on=20 average, for 2000000*2 calls to clock_gettime(), we got about 10 pauses=20 of between 100 and 300ms - FreeBSD 8.2-RC1 + Xeon W3680 (6 cores): With 12 instances of openssl speed tests, for 10000000*2 calls to=20 clock_gettime(), we got pauses of between 300ms and 10s. - FreeBSD 6.3 + VIA C3: With 1 instance of openssl, we got pauses of between 70ms and 300ms= - FreeBSD 7.3 + VIA C7: With 1 instance of openssl, we got pauses of between 150ms and 1s=20 (Note: this computer may be slightly more loaded then the previous one) For comparison purpose, we also tried on 2 Linux systems: - Linux 2.6.32.15 (Via nano, with a bunch of services running on it): - 1 openssl speed tests + 2000000 iterations: max 10ms - 10 openssl speed tests + 2000000 iterations: max 44ms - Linux 2.6 (Core i7): - 10 openssl speed tests + 2000000: max 1ms We tried setting the test program to the highest priority possible=20 (rtprio(REALTIME, RTP_PRIO_MAX)) and it doesn't seem to change a thing. Does anyone know if there is a reason for this behavior ? Is there=20 something that can be done to improve things ? --------------070706020906040708070509 Content-Type: text/plain; name="timecheck.c" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="timecheck.c" #include #include #include #include #include #include #include #include int main(int argc, char *argv[]) { struct timespec pre, cur; useconds_t d, dmin, dmax, dsum; int dweird =3D 0; int i, loop; if (argc !=3D 2) { fprintf(stderr, "timecheck \n"); return EXIT_FAILURE; } loop =3D atoi(argv[1]); dmax =3D dsum =3D 0; dmin =3D UINT_MAX; fprintf(stdout, "looping %d times...\n", loop); for (i =3D 0; i < loop; i++) { if (clock_gettime(CLOCK_MONOTONIC, &pre) < 0) err(EX_OSERR, NULL); if (clock_gettime(CLOCK_MONOTONIC, &cur) < 0) err(EX_OSERR, NULL); d =3D (cur.tv_sec - pre.tv_sec) * 1000000; d =3D d + (cur.tv_nsec / 1000) - (pre.tv_nsec / 1000); dsum +=3D d; if (d < dmin) dmin =3D d; if (d > dmax) dmax =3D d; if (d > 10*1000) /* 10 ms */ dweird++; cur =3D pre; } fprintf(stdout, "dmin =3D %dus\ndmax =3D %dus\ndmean =3D %dus\ndweird = =3D %d\n", dmin, dmax, dsum / loop, dweird); return 0; } --------------070706020906040708070509-- --------------ms090401030701030108000803-- From owner-freebsd-current@FreeBSD.ORG Mon Feb 21 16:50:29 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 0E3D7106566B; Mon, 21 Feb 2011 16:50:29 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from mail.mahoroba.org (ent.mahoroba.org [IPv6:2001:2f0:104:8010::1]) by mx1.freebsd.org (Postfix) with ESMTP id AC0888FC1A; Mon, 21 Feb 2011 16:50:28 +0000 (UTC) Received: from yuga.mahoroba.org (ume@yuga.mahoroba.org [IPv6:2001:2f0:104:8010:21b:d3ff:fe38:5381]) (user=ume mech=DIGEST-MD5 bits=0) by mail.mahoroba.org (8.14.4/8.14.4) with ESMTP/inet6 id p1LGoHO6034342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Feb 2011 01:50:21 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Tue, 22 Feb 2011 01:50:17 +0900 Message-ID: From: Hajimu UMEMOTO To: "Bjoern A. Zeeb" In-Reply-To: <20110220181713.C13400@maildrop.int.zabbadoz.net> References: <20110220181713.C13400@maildrop.int.zabbadoz.net> User-Agent: xcite1.60> Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-2022-JP-2?B?R29qGyQoRCtXGyhC?=) APEL/10.8 Emacs/23.2 (i386-portbld-freebsd8.1) MULE/6.0 (HANACHIRUSATO) X-Operating-System: FreeBSD 8.2-PRERELEASE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Tue, 22 Feb 2011 01:50:22 +0900 (JST) X-Virus-Scanned: clamav-milter 0.97 at asuka.mahoroba.org X-Virus-Status: Clean X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, T_RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on asuka.mahoroba.org Cc: arch@FreeBSD.org, FreeBSD current mailing list Subject: Re: CFR: importing openresolv 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, 21 Feb 2011 16:50:29 -0000 Hi, >>>>> On Sun, 20 Feb 2011 18:21:18 +0000 (UTC) >>>>> "Bjoern A. Zeeb" said: bz> Do you have an updated patch for 3.4.1 or 3.3.6? I'd like to help to bz> you get it in for 9.0-R. I wouldn't even mind if some ports would bz> conflict with it for a while not making the situation any worse than bz> it is these days. I didn't notice that openresolv was updated. I'll soon make a new diff for 3.4.1. hrs@ noticed that ppp(8) and uhsoctl(8) in our base tree touch /etc/resolv.conf. We need to change them to use resovlconf(8). Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-current@FreeBSD.ORG Mon Feb 21 17:51:16 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 60CDA106564A; Mon, 21 Feb 2011 17:51:16 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from mail.mahoroba.org (ent.mahoroba.org [IPv6:2001:2f0:104:8010::1]) by mx1.freebsd.org (Postfix) with ESMTP id 63EC48FC14; Mon, 21 Feb 2011 17:51:15 +0000 (UTC) Received: from yuga.mahoroba.org (ume@yuga.mahoroba.org [IPv6:2001:2f0:104:8010:21b:d3ff:fe38:5381]) (user=ume mech=DIGEST-MD5 bits=0) by mail.mahoroba.org (8.14.4/8.14.4) with ESMTP/inet6 id p1LHp7ir031949 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Feb 2011 02:51:07 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Tue, 22 Feb 2011 02:51:06 +0900 Message-ID: From: Hajimu UMEMOTO To: "Bjoern A. Zeeb" In-Reply-To: References: <20110220181713.C13400@maildrop.int.zabbadoz.net> User-Agent: xcite1.60> Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-2022-JP-2?B?R29qGyQoRCtXGyhC?=) APEL/10.8 Emacs/23.2 (i386-portbld-freebsd8.1) MULE/6.0 (HANACHIRUSATO) X-Operating-System: FreeBSD 8.2-PRERELEASE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Tue, 22 Feb 2011 02:51:07 +0900 (JST) X-Virus-Scanned: clamav-milter 0.97 at asuka.mahoroba.org X-Virus-Status: Clean X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, T_RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on asuka.mahoroba.org Cc: arch@FreeBSD.org, FreeBSD current mailing list Subject: Re: CFR: importing openresolv 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, 21 Feb 2011 17:51:16 -0000 Hi, >>>>> On Tue, 22 Feb 2011 01:50:17 +0900 >>>>> Hajimu UMEMOTO said: bz> Do you have an updated patch for 3.4.1 or 3.3.6? I'd like to help to bz> you get it in for 9.0-R. I wouldn't even mind if some ports would bz> conflict with it for a while not making the situation any worse than bz> it is these days. ume> I didn't notice that openresolv was updated. I'll soon make a new ume> diff for 3.4.1. ume> hrs@ noticed that ppp(8) and uhsoctl(8) in our base tree touch ume> /etc/resolv.conf. We need to change them to use resovlconf(8). I've updated a patch for 3.4.1: http://www.imasy.or.jp/~ume/FreeBSD/openresolv-20110222.diff.gz If you have the previous patch applied, make sure to remove src/contrib/openresolv and src/sbin/resolvconf before applying new one. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-current@FreeBSD.ORG Mon Feb 21 17:55:12 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 70B461065674 for ; Mon, 21 Feb 2011 17:55:12 +0000 (UTC) (envelope-from rbgarga@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 DBF748FC17 for ; Mon, 21 Feb 2011 17:55:09 +0000 (UTC) Received: by wyb32 with SMTP id 32so2054830wyb.13 for ; Mon, 21 Feb 2011 09:55:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=MANr6XOaCqqnHxwTmZHZChlMlbJXMirASLU+4qnGIyA=; b=TpH51436rxFgyH2hv/8QDMgTayoRIsEGf3MTiZAFTW9+RoDhSgM5Wnyd5SVYIG25lq byCXV/+z8Ng13JYmzZJkQWq+5f3Z/vrcQLNASnEvXNjMszy8dIpb+1qN3DqJ+jNTKXZT ICgxjbWBhhu1OwSF3RFjPzgXTvlsRcbgwDzyQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=jYxfCJBAvP2kV5hFTTkIaxTJE1aGyn0ZV0Ec7E6qtLTSdTaKJJsOz8wTsgf21u3+D1 wZfQhHejyywTn/P7Kq+RWDLOhgbeY8a0PuTIJm33QccMoYQ/H+nF8FH0oufFxmIxmljG FdOcj38/A/gj9zdZHIneiKM8TMXYpSyhdawm4= Received: by 10.216.13.194 with SMTP id b44mr1414512web.68.1298309387128; Mon, 21 Feb 2011 09:29:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.11.69 with HTTP; Mon, 21 Feb 2011 09:29:27 -0800 (PST) In-Reply-To: References: <20101103134417.GB81149@hoeg.nl> <20101103144449.GD81149@hoeg.nl> From: Renato Botelho Date: Mon, 21 Feb 2011 14:29:27 -0300 Message-ID: To: Ed Schouten Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Current Subject: Re: Openoffice doesn't work with kernel+world built with Clang 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, 21 Feb 2011 17:55:12 -0000 On Wed, Nov 3, 2010 at 1:05 PM, Renato Botelho wrote: > On Wed, Nov 3, 2010 at 12:44 PM, Ed Schouten wrote: >> * Renato Botelho , 20101103 15:36: >>> On Wed, Nov 3, 2010 at 11:44 AM, Ed Schouten wrote: >>> > Garga! >>> > >>> > * Renato Botelho , 20101103 13:36: >>> >> For now i solve my problem adding this to /etc/src.conf >>> >> >>> >> .if ${.CURDIR} == "/usr/src/gnu/lib/libgcc" >>> >> CC=cc >>> >> CXX=c++ >>> >> .endif >>> >> >>> >> This way libgcc_s.so is built using gcc instead of clang and the problem >>> >> is gone. I just wonder other problems we can find since simething on >>> >> libgcc_s.so is broken when built with clang. >>> > >>> > Would it be hard to figure out which exact object file causes this? >>> >>> Hi Ed, >>> >>> I've submitted a ktrace result of openoffice execution [1], i just >>> saw it got a SIGBUS at some point, but debug openoffice doesn't >>> seem to be a trivial task. >>> >>> I don't know if we can build OO with debug symbols to make it >>> easier to debug. If you know what i can do to help debugging, >>> just let me know and i can provide any information. >> >> Well, I mean, can you build some of libgcc's object files with Clang and >> others with GCC? Hint: Just build everything with GCC. Afterwards, go >> into the object directory, rm some of the .o files and make CC=clang. >> >> Since OOo is a C++ application, I suspect the unwind-related object >> files to be the culprit. > > Bingo! When I build everything but unwind-dw2.o with clang it works. > This is the object that is causing the problem. FYI, after upgrade it today to r218915, and remove the hack to build libgcc with gcc instead of clang, the problem is gone. Now my world + kernel are both 100% built with clang and i can start openoffice as well. -- Renato Botelho From owner-freebsd-current@FreeBSD.ORG Mon Feb 21 18:21: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 DE3A11065670 for ; Mon, 21 Feb 2011 18:21:08 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout027.mac.com (asmtpout027.mac.com [17.148.16.102]) by mx1.freebsd.org (Postfix) with ESMTP id C548F8FC08 for ; Mon, 21 Feb 2011 18:21:08 +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 asmtp027.mac.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) with ESMTPSA id <0LGZ00AESCAUFQ00@asmtp027.mac.com> for freebsd-current@freebsd.org; Mon, 21 Feb 2011 10:20:56 -0800 (PST) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2011-02-21_05:2011-02-21, 2011-02-21, 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-1102210083 From: Chuck Swiger In-reply-to: <4D6291A5.4050206@netasq.com> Date: Mon, 21 Feb 2011 10:20:54 -0800 Message-id: <8C8FE4A5-F031-466A-9CB8-46D79EEA280D@mac.com> References: <4D6291A5.4050206@netasq.com> To: Jerome Flesch X-Mailer: Apple Mail (2.1082) Cc: freebsd-current@freebsd.org Subject: Re: Process timing issue 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, 21 Feb 2011 18:21:08 -0000 On Feb 21, 2011, at 8:24 AM, Jerome Flesch wrote: > While investigating a timing issue with one of our program, we found out something weird: We've written a small test program that just calls clock_gettime() a lot of times and checks that the time difference between calls makes sense. In the end, it seems it doesn't always do. > > Calling twice in a row clock_gettime() takes usually less than 1ms. But with an average load, about 1 time in 200000, more than 10ms are spent between both calls for no apparent reason. According to our tests, when it happens, the time between both calls can go from few milliseconds to many seconds (our best score so far is 10 seconds :). Same goes for gettimeofday(). A scheduler quantum of 10ms (or HZ=100) is a common granularity; probably some other process got the CPU and your timer process didn't run until the next or some later scheduler tick. If you are maxing out the available CPU by running many "openssl speed" tasks, then this behavior is more-or-less expected. > We tried setting the test program to the highest priority possible (rtprio(REALTIME, RTP_PRIO_MAX)) and it doesn't seem to change a thing. > > Does anyone know if there is a reason for this behavior ? Is there something that can be done to improve things ? FreeBSD doesn't offer hard realtime guarantees, and it values maximizing throughput for all tasks more than it does providing absolute minimum latency even for something wanting RT. There has been some discussion in the past about making RT tasks with very high priority less pre-emptible by lower priority tasks by removing or reducing the priority lowering that occurs when a task gets allocated CPU time. What problem are you trying to solve where continuous CPU load and minimum latency realtime are both required? Regards, -- -Chuck From owner-freebsd-current@FreeBSD.ORG Mon Feb 21 21:10:31 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 243E3106566B; Mon, 21 Feb 2011 21:10:31 +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 9622F8FC15; Mon, 21 Feb 2011 21:10:29 +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 p1LLAPAP001849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Feb 2011 23:10:25 +0200 (EET) (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 p1LLAOBP044748; Mon, 21 Feb 2011 23:10:24 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p1LLAOAK044747; Mon, 21 Feb 2011 23:10:24 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 21 Feb 2011 23:10:24 +0200 From: Kostik Belousov To: Mike Tancsa Message-ID: <20110221211024.GV78089@deviant.kiev.zoral.com.ua> References: <4D4A38FD.7000607@rdtc.ru> <4D3011DB.9050900@frasunek.com> <4FD1B1C3-08A7-4F48-A30A-DE5A8F3D3834@averesystems.com> <4D6133AC.6070507@sentex.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uIetXajv+QHHV+2h" Content-Disposition: inline In-Reply-To: <4D6133AC.6070507@sentex.net> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-3.4 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, freebsd-stable@freebsd.org Subject: Re: About "panic: bufwrite: buffer is not busy???" 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, 21 Feb 2011 21:10:31 -0000 --uIetXajv+QHHV+2h Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 20, 2011 at 10:30:52AM -0500, Mike Tancsa wrote: > On 2/20/2011 9:33 AM, Andrey Smagin wrote: > > On week -current I have same problem, my box paniced every 2-15 min. I = resolve problem by next steps - unplug network connectors from 2 intel em (= 82574L) cards. I think last time that mpd5 related panic, but mpd5 work wit= h another re interface interated on MB. I think it may be em related panic,= or em+mpd5. >=20 > The latest panic I saw didnt have anything to do with em. Are you sure > your crashes are because of the nic drive ? >=20 > The latest I saw was on Friday. >=20 > # kgdb /usr/obj/usr/src/sys/router/kernel.debug vmcore.11 > (kgdb) bt > #0 doadump () at pcpu.h:231 > #1 0xc04a51f9 in db_fncall (dummy1=3D1, dummy2=3D0, dummy3=3D-1063333856, > dummy4=3D0xc6b9696c "") at /usr/src/sys/ddb/db_command.c:548 > #2 0xc04a55f1 in db_command (last_cmdp=3D0xc096f73c, cmd_table=3D0x0, > dopager=3D1) at /usr/src/sys/ddb/db_command.c:445 > #3 0xc04a574a in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 > #4 0xc04a764d in db_trap (type=3D12, code=3D0) at > /usr/src/sys/ddb/db_main.c:229 > #5 0xc068ba7e in kdb_trap (type=3D12, code=3D0, tf=3D0xc6b96b94) at > /usr/src/sys/kern/subr_kdb.c:546 > #6 0xc088056f in trap_fatal (frame=3D0xc6b96b94, eva=3D52) at > /usr/src/sys/i386/i386/trap.c:937 > #7 0xc0880830 in trap_pfault (frame=3D0xc6b96b94, usermode=3D0, eva=3D52= ) at > /usr/src/sys/i386/i386/trap.c:859 > #8 0xc0880d4a in trap (frame=3D0xc6b96b94) at > /usr/src/sys/i386/i386/trap.c:532 > #9 0xc086716c in calltrap () at /usr/src/sys/i386/i386/exception.s:166 > #10 0xc0657a16 in uihold (uip=3D0x0) at /usr/src/sys/kern/kern_resource.c= :1248 > #11 0xc0654ec9 in crcopy (dest=3D0xce3ee800, src=3D0xce3ee600) at > /usr/src/sys/kern/kern_prot.c:1873 > #12 0xc0654fd1 in crcopysafe (p=3D0xc90cc810, cr=3D0xce3ee800) at > /usr/src/sys/kern/kern_prot.c:1950 > #13 0xc0656d7f in seteuid (td=3D0xc9196b80, uap=3D0xc6b96cec) at > /usr/src/sys/kern/kern_prot.c:615 > #14 0xc06985ff in syscallenter (td=3D0xc9196b80, sa=3D0xc6b96ce4) at > /usr/src/sys/kern/subr_trap.c:315 > #15 0xc0880884 in syscall (frame=3D0xc6b96d28) at > /usr/src/sys/i386/i386/trap.c:1061 > #16 0xc08671d1 in Xint0x80_syscall () at > /usr/src/sys/i386/i386/exception.s:264 > #17 0x00000033 in ?? () >=20 > (kgdb) frame 10 > #10 0xc0657a16 in uihold (uip=3D0x0) at /usr/src/sys/kern/kern_resource.c= :1248 > 1248 { > (kgdb) list > 1243 * Place another refcount on a uidinfo struct. > 1244 */ > 1245 void > 1246 uihold(uip) > 1247 struct uidinfo *uip; > 1248 { > 1249 > 1250 refcount_acquire(&uip->ui_ref); > 1251 } > 1252 > (kgdb) p *uip > Cannot access memory at address 0x0 > (kgdb) p uip > $1 =3D (struct uidinfo *) 0x0 > (kgdb) Is this reproducable ? What system version is it ? Could you, please, go to frame 12 and show the output of "p *p", "p *(p->p_ucred)" ? --uIetXajv+QHHV+2h Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk1i1L8ACgkQC3+MBN1Mb4iWjQCdGtiGPTrEYq5J8OXDcGCZUHyz F54AoIP0E6k99wX7IjPdqwydwakY/85D =lR70 -----END PGP SIGNATURE----- --uIetXajv+QHHV+2h-- From owner-freebsd-current@FreeBSD.ORG Mon Feb 21 21:15: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 7B9AE106564A for ; Mon, 21 Feb 2011 21:15:54 +0000 (UTC) (envelope-from maksim.yevmenkin@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 439168FC08 for ; Mon, 21 Feb 2011 21:15:53 +0000 (UTC) Received: by iwn33 with SMTP id 33so1011374iwn.13 for ; Mon, 21 Feb 2011 13:15:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=3aq0G8LsAXRZUYaq2+KRQgUdnNpYr7IOUfRYgyVpgF4=; b=w/aHTmDOhOJlV+dvUGncEb/pkEUYABtd9aNituyLzF99CSqDLGGTNFe3mxoIg+Fm1J MzUQY8kuuzMr9YvLLZeKYnH1RwUwHWu9LlZybvzO+ym0FnEfjPGGBcD3L5RKOzdtafG2 t5nQQyUbQ5p1tsF1bPeL3Mgo5vOERM6ynLduM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Ea8dqKPa+BaMfC6e05GlHmw3Sf53wGalqyf7GHrob/WJ0llvb4pBEADD0Z5CFytKlW 4VE5aUOzk9CCfHXm8fpTHQdYfrf3KvSUrkTi+za2sHlA7Jwqi9H/kyzxHgDf9DFiTvn7 cNu/xUjYsEtAVKzzkqq1Phv7sVAygoAGPxUps= MIME-Version: 1.0 Received: by 10.231.32.129 with SMTP id c1mr1456410ibd.145.1298321487995; Mon, 21 Feb 2011 12:51:27 -0800 (PST) Received: by 10.231.208.19 with HTTP; Mon, 21 Feb 2011 12:51:27 -0800 (PST) In-Reply-To: <20110221070630.125E6A624E@smtp3-g21.free.fr> References: <20110221070630.125E6A624E@smtp3-g21.free.fr> Date: Mon, 21 Feb 2011 12:51:27 -0800 Message-ID: From: Maksim Yevmenkin To: rmgls@free.fr Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: Dell 370 bluetooth minicard 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, 21 Feb 2011 21:15:54 -0000 Hello, > On a Dell E6400 the bluetooth wireless minicard (Dell 370 => BCM2046B1 > if i am right) does not attach to any driver. > Is this ship supported by the btbcmfw driver? > Any comment would be helpfull. did you try to load ng_ubt(4) driver? also freebsd-bluetooth@ is probably more appropriate for those type of questions. thanks max From owner-freebsd-current@FreeBSD.ORG Mon Feb 21 21:27: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 10BE41065675; Mon, 21 Feb 2011 21:27:35 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 87A748FC15; Mon, 21 Feb 2011 21:27:34 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:68ff:b8ee:849:710f] ([IPv6:2607:f3e0:0:4:68ff:b8ee:849:710f]) by smarthost1.sentex.ca (8.14.4/8.14.4) with ESMTP id p1LLRWVg052586 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 21 Feb 2011 16:27:32 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <4D62D8C1.1090408@sentex.net> Date: Mon, 21 Feb 2011 16:27:29 -0500 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Kostik Belousov References: <4D4A38FD.7000607@rdtc.ru> <4D3011DB.9050900@frasunek.com> <4FD1B1C3-08A7-4F48-A30A-DE5A8F3D3834@averesystems.com> <4D6133AC.6070507@sentex.net> <20110221211024.GV78089@deviant.kiev.zoral.com.ua> In-Reply-To: <20110221211024.GV78089@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on IPv6:2607:f3e0:0:1::12 Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: About "panic: bufwrite: buffer is not busy???" 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, 21 Feb 2011 21:27:35 -0000 On 2/21/2011 4:10 PM, Kostik Belousov wrote: > Is this reproducable ? The box seems to have a number of bugs it has been triggering. gleb@freebsd.org's netgraph patch, seems to have fixed one of them. Max seems to have fixed two others. This one, I am not sure. I can re-enable memguard to randomly sample again, which is what seemed to have caught / triggered it. > What system version is it ? 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #11: Thu Feb 17 i386, 4G of RAM > > Could you, please, go to frame 12 and show the output of "p *p", > "p *(p->p_ucred)" ? (kgdb) frame 12 #12 0xc0654fd1 in crcopysafe (p=0xc90cc810, cr=0xce3ee800) at /usr/src/sys/kern/kern_prot.c:1950 1950 crcopy(cr, oldcred); (kgdb) list 1945 PROC_UNLOCK(p); 1946 crextend(cr, groups); 1947 PROC_LOCK(p); 1948 oldcred = p->p_ucred; 1949 } 1950 crcopy(cr, oldcred); 1951 1952 return (oldcred); 1953 } 1954 (kgdb) p *(p->p_ucred) $1 = {cr_ref = 3373030400, cr_uid = 3460374784, cr_ruid = 3231313392, cr_svuid = 7196, cr_ngroups = 0, cr_rgid = 503415038, cr_svgid = 0, cr_uidinfo = 0x0, cr_ruidinfo = 0x0, cr_prison = 0x0, cr_pspare = 0xffffffff, cr_flags = 4294967295, cr_pspare2 = {0x0, 0x0}, cr_label = 0xffffffff, cr_audit = {ai_auid = 0, ai_mask = {am_success = 0, am_failure = 1298034100}, ai_termid = {at_port = 3, at_type = 1, at_addr = {0, 64, 0, 0}}, ai_asid = 0, ai_flags = 0}, cr_groups = 0xc9e37900, cr_agroups = 16} (kgdb) p *p $2 = {p_list = {le_next = 0xc93ed560, le_prev = 0xc9187ac0}, p_threads = {tqh_first = 0xc9196b80, tqh_last = 0xc9196b88}, p_slock = {lock_object = { lo_name = 0xc08efca2 "process slock", lo_flags = 720896, lo_data = 0, lo_witness = 0x0}, mtx_lock = 4}, p_ucred = 0xce3ee600, p_fd = 0xc9559100, p_fdtol = 0x0, p_stats = 0xc90cd600, p_limit = 0xc912d600, p_limco = {c_links = {sle = {sle_next = 0x0}, tqe = {tqe_next = 0x0, tqe_prev = 0x0}}, c_time = 0, c_arg = 0x0, c_func = 0, c_lock = 0xc90cc898, c_flags = 0, c_cpu = 0}, p_sigacts = 0xc911f000, p_flag = 268435713, p_state = PRS_NORMAL, p_pid = 565, p_hash = {le_next = 0x0, le_prev = 0xc8d148d4}, p_pglist = {le_next = 0x0, le_prev = 0xc90c85c8}, p_pptr = 0xc8d2b000, p_sibling = {le_next = 0xc93ed560, le_prev = 0xc9187b3c}, p_children = {lh_first = 0x0}, p_mtx = { lock_object = {lo_name = 0xc08efc95 "process lock", lo_flags = 21168128, lo_data = 0, lo_witness = 0x0}, mtx_lock = 3373886336}, p_ksi = 0xc908f9b0, p_sigqueue = { sq_signals = {__bits = {0, 0, 0, 0}}, sq_kill = {__bits = {0, 0, 0, 0}}, sq_list = {tqh_first = 0x0, tqh_last = 0xc90cc8d0}, sq_proc = 0xc90cc810, sq_flags = 1}, p_oppid = 0, p_vmspace = 0xc93f0e80, p_swtick = 6600, p_realtimer = {it_interval = {tv_sec = 0, tv_usec = 0}, it_value = {tv_sec = 0, tv_usec = 0}}, p_ru = {ru_utime = { tv_sec = 0, tv_usec = 0}, ru_stime = {tv_sec = 0, tv_usec = 0}, ru_maxrss = 0, ru_ixrss = 0, ru_idrss = 0, ru_isrss = 0, ru_minflt = 0, ru_majflt = 0, ru_nswap = 0, ru_inblock = 0, ru_oublock = 0, ru_msgsnd = 0, ru_msgrcv = 0, ru_nsignals = 0, ru_nvcsw = 0, ru_nivcsw = 0}, p_rux = {rux_runtime = 109046064880, rux_uticks = 1368, rux_sticks = 5393, rux_iticks = 0, rux_uu = 10366008, rux_su = 40860399, rux_tu = 51225136}, p_crux = {rux_runtime = 0, rux_uticks = 0, rux_sticks = 0, rux_iticks = 0, rux_uu = 0, rux_su = 0, rux_tu = 0}, p_profthreads = 0, p_exitthreads = 0, p_traceflag = 0, p_tracevp = 0x0, p_tracecred = 0x0, p_textvp = 0xc95bf96c, p_lock = 0, p_sigiolst = {slh_first = 0x0}, p_sigparent = 20, p_sig = 0, p_code = 0, p_stops = 0, p_stype = 0, p_step = 0 '\0', p_pfsflags = 0 '\0', p_nlminfo = 0x0, p_aioinfo = 0x0, p_singlethread = 0x0, p_suspcount = 0, p_xthread = 0x0, p_boundary_count = 0, p_pendingcnt = 0, p_itimers = 0x0, p_magic = 3203398350, p_osrel = 802500, p_comm = "zebra", '\0' , p_pgrp = 0xc90c85c0, p_sysent = 0xc095c800, p_args = 0xc90c8440, p_cpulimit = 9223372036854775807, p_nice = 0 '\0', p_fibnum = 0, p_xstat = 0, p_klist = {kl_list = {slh_first = 0x0}, kl_lock = 0xc062a990 , kl_unlock = 0xc062a940 , kl_assert_locked = 0xc06275f0 , kl_assert_unlocked = 0xc0627600 , kl_lockarg = 0xc90cc898}, p_numthreads = 1, p_md = { md_ldt = 0x0}, p_itcallout = {c_links = {sle = {sle_next = 0x0}, tqe = {tqe_next = 0x0, tqe_prev = 0x0}}, c_time = 0, c_arg = 0x0, c_func = 0, c_lock = 0x0, c_flags = 16, c_cpu = 0}, p_acflag = 1, p_peers = 0x0, p_leader = 0xc90cc810, p_emuldata = 0x0, p_label = 0x0, p_sched = 0xc90ccac0, p_ktr = {stqh_first = 0x0, stqh_last = 0xc90ccaa0}, p_mqnotifier = {lh_first = 0x0}, p_dtrace = 0x0, p_pwait = {cv_description = 0xc08f00ef "ppwait", cv_waiters = 0}, p_dbgwait = {cv_description = 0xc08f00f6 "dbgwait", cv_waiters = 0}} (kgdb) -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-current@FreeBSD.ORG Mon Feb 21 22:31: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 087FD1065672; Mon, 21 Feb 2011 22:31:25 +0000 (UTC) (envelope-from josh@tcbug.org) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id BA91D8FC19; Mon, 21 Feb 2011 22:31:24 +0000 (UTC) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.messagingengine.com (Postfix) with ESMTP id 2292A20526; Mon, 21 Feb 2011 17:12:53 -0500 (EST) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Mon, 21 Feb 2011 17:12:53 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=from:to:subject:date:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:message-id; s=smtpout; bh=GAI2tCTUeQo7F+owe3BD8COWyN4=; b=GWc+AQm039RnN9neBTYr8eRsVXjPl+NcpLGaPCUVziCu0uL7lRS5D/4JODeKnp9E9WroWp2N6su4eFH4SNM+qjrnoexkcZhS4UZFayzmhQLbQj6HlHGbVau4nelOm8REYE2qTNvVrEkaf+UmnIB/xZ/PkPFFijUtmu7dBrQOILc= X-Sasl-enc: 9cPRiNuzrEYKMYCpYghgIOiSBCn4md3A1aw54i0Svzh4 1298326372 Received: from tcbug.ixsystems.com (74-34-19-98.dr01.rsmt.mn.frontiernet.net [74.34.19.98]) by mail.messagingengine.com (Postfix) with ESMTPSA id B2B094094EA; Mon, 21 Feb 2011 17:12:52 -0500 (EST) From: Josh Paetzel To: freebsd-arch@freebsd.org Date: Mon, 21 Feb 2011 16:12:41 -0600 User-Agent: KMail/1.13.5 (FreeBSD/8.1-RELEASE; KDE/4.4.5; amd64; ; ) References: <4D35CFFB.3010302@freebsd.org> <61079648-D76C-4699-AC4D-F6EBE64ABFFC@vicor.com> <201102190844.43267.bruce@cran.org.uk> In-Reply-To: <201102190844.43267.bruce@cran.org.uk> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3047959.TjBYZPoihf"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201102211612.51233.josh@tcbug.org> Cc: Bruce Cran , freebsd-current@freebsd.org, Devin Teske , freebsd-sysinstall@freebsd.org, Nathan Whitehorn Subject: Re: FreeBSD Installer Roadmap 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, 21 Feb 2011 22:31:25 -0000 --nextPart3047959.TjBYZPoihf Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Saturday, February 19, 2011 02:44:42 am Bruce Cran wrote: > On Saturday 19 February 2011 03:04:39 Devin Teske wrote: > > There are many reasons for this, and none of them are selfish (although > > it remains possible to drum-up some selfish reason, all of the reasons > > behind our motivation are in-fact unselfish). Truth-be-told, I welcome > > the replacement of sysinstall but am very wary that ANY replacement will > > be able to exactly replicate the hardware compatibility that sysinstall > > currently enjoys. I do indeed envision a great celebration as FreeBSD-9 > > bucks sysinstall but also at the same time have nightmares of receiving > > waves of calls from people having trouble (for example) "installing > > FreeBSD-9 on their AMD K6 based system, circa long-long-ago in a > > universe far-far-away." (yes, we do have data centers running that very > > equipment with uptime in the 1,000's of days). >=20 > I think bsdinstall as it currently is is simple enough that there shouldn= 't > be any compatibility issues: it uses gpart for partitioning, runs tools > like tzsetup to configure settings etc. so there's far less to go wrong > than sysinstall's custom code which for example could crash on the > "probing devices" screen. pc-sysinstall has been used as the PC-BSD installer for quite a while now, = and=20 has done a lot of installs on a lot of different hardware platforms. I'll= =20 wager that the compatibility of the shell command gpart is a better bet tha= n=20 the "stick your thumbs in you ears and yell nananana while you scribble 1's= =20 and 0's to a disk and voila, there's a disklabel" approach that sysinstall= =20 uses. That being said, sysinstall holds FreeBSD back in a lot of ways, using GPT= =20 labeling, installing to ZFS, or gmirror, using geli, all require you to boo= t=20 to a shell and do an install by hand. I'm sure more people can chime in to= =20 limitations in sysinstall than I can think of off the top of my head. So my question is: Given that everyone involved is very conscious of lockin= g=20 out FreeBSD from hardware platforms due to installer compatibility, wouldn'= t a=20 better use of your time be investing in the future and ensuring that it wor= ks=20 on legacy platforms as opposed to putting sysinstall on life support when i= t=20 already has some fairly serious missing functionality, that is only likely = to=20 become more of an issue in the future? =2D-=20 Thanks, Josh Paetzel --nextPart3047959.TjBYZPoihf Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iQEcBAABAgAGBQJNYuNhAAoJEKFq1/n1feG2ys8H/2ftBaqnaq9mZcXsY0iWQ8J9 tz35avx7w4633MOdWCdjMUIFfQXStRCR1L18fBSXPfhzhd6hgzkUDRHZmpk/OZfo 6PBzHU/bGBb2qSYpPblUiCLeh+y8rNVSezSKazay5B8Cr2teb5sVFBm1n45H4sx1 ZO6q+7zBhFSfmGxF62H9zktk0m81lmI0DU5Uu9WYUdZlUO9FUOD2cWAFYwIux1OG tMzZTfqEmPllgzb3nneWtxZt9l8ZEki7RryHtE0JyhwPk3w0U0ytameZ5dReK+S4 A1Nua+1Y5HEzpfWFCxYDiT8cxwru67g2bq03iBZrgAfVnobffS04XB2HuTfjbzA= =3JpJ -----END PGP SIGNATURE----- --nextPart3047959.TjBYZPoihf-- From owner-freebsd-current@FreeBSD.ORG Mon Feb 21 22:33: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 36EE71065741 for ; Mon, 21 Feb 2011 22:33:04 +0000 (UTC) (envelope-from erob@gthcfoundation.org) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by mx1.freebsd.org (Postfix) with ESMTP id 125F98FC19 for ; Mon, 21 Feb 2011 22:33:04 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=ISO-8859-1; format=flowed Received: from marina.localdomain ([184.162.50.38]) by VL-MR-MRZ20.ip.videotron.ca (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTP id <0LGZ00CA8L6PHB30@VL-MR-MRZ20.ip.videotron.ca> for freebsd-current@freebsd.org; Mon, 21 Feb 2011 16:32:49 -0500 (EST) Message-id: <4D62DA07.7070308@gthcfoundation.org> Date: Mon, 21 Feb 2011 16:32:55 -0500 From: Etienne Robillard User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.16) Gecko/20110113 Thunderbird/3.0.11 To: freebsd-current@freebsd.org Subject: Stack overflow before kernel load.. 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, 21 Feb 2011 22:33:04 -0000 Hi, Any ideas why the bootloader prints a 'error: stack overflow' message and request user confirmation to load the kernel manually? $ uname -a FreeBSD marina.localdomain 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #1: Wed Feb 16 03:38:23 EST 2011 root@:/usr/local/freebsd8/src/sys/amd64/compile/GENERIC.ndebug amd64 Thanks, Etienne From owner-freebsd-current@FreeBSD.ORG Mon Feb 21 23:24: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 4094F106566B; Mon, 21 Feb 2011 23:24:53 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (unknown [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id C1A448FC13; Mon, 21 Feb 2011 23:24:52 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 18214E61BB; Mon, 21 Feb 2011 23:24:49 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=subject :from:to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; s=mail; bh=xC6B+zWdVyXf +pmAt7mpxOCReM0=; b=fWLHhR1s8lsyiEzSmK3y9sF71JKWIqZtsz//ImJBim1/ YHGq5WbrcwlQrPDei/AtMSvnFB7hin2FZgTKO+EMIXqRygowC2fdeKSyLkspjzjD zFdZesI8FCoXCGPymWz02SD98wIHL9HnQwRIXQfiXmUtp5VYRwh7tZFQH4P/j9Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s=mail; b=OOgFP1 WjbDHEVhD7uVhwt4kuQP5IMZ3fp0UQNKv2chNbVD5Jqzw8cERdwBuTf4/st4S2If 7Lgu37t/ZNKEbeccjKQNm6pZ/8TmQLdBXuaGUYth3keXW3G0FShtG/FLiT11sUcQ HJsB10ZuUOBfb31oDir1oCtDMKzA/NFUZU3Ao= Received: from [192.168.0.11] (client-86-31-177-138.oxfd.adsl.virginmedia.com [86.31.177.138]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id 9D18BE61BA; Mon, 21 Feb 2011 23:24:48 +0000 (GMT) From: Bruce Cran To: Josh Paetzel In-Reply-To: <201102211612.51233.josh@tcbug.org> References: <4D35CFFB.3010302@freebsd.org> <61079648-D76C-4699-AC4D-F6EBE64ABFFC@vicor.com> <201102190844.43267.bruce@cran.org.uk> <201102211612.51233.josh@tcbug.org> Content-Type: text/plain; charset="UTF-8" Date: Mon, 21 Feb 2011 23:23:05 +0000 Message-ID: <1298330585.4940.56.camel@debian.nessbank> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: Nathan, Devin Teske , freebsd-current@freebsd.org, Whitehorn , freebsd-arch@freebsd.org, freebsd-sysinstall@freebsd.org Subject: Re: FreeBSD Installer Roadmap 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, 21 Feb 2011 23:24:53 -0000 On Mon, 2011-02-21 at 16:12 -0600, Josh Paetzel wrote: > pc-sysinstall has been used as the PC-BSD installer for quite a while now, and > has done a lot of installs on a lot of different hardware platforms. I'll > wager that the compatibility of the shell command gpart is a better bet than > the "stick your thumbs in you ears and yell nananana while you scribble 1's > and 0's to a disk and voila, there's a disklabel" approach that sysinstall > uses. I wish that was true: unfortunately I tried and failed to create a ZFS installation with pc-sysinstall, and I get a few worrying error messages even with UFS while it repartitions the disk - people have been reporting it creating unbootable systems. gpart might be more compatible, but I don't think parsing the output of tools like as fdisk, diskinfo and dmesg is. The concerns about GPT, ZFS, gmirror etc. in sysinstall could all be resolved in a couple of days by ripping out the existing partitioning code and replacing it with ae@'s new version of sade from /user/ae/usr.sbin/sade . However since the future is pc-sysinstall I've now shifted my work to improving the Qt front-end. -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Mon Feb 21 23:24: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 429831065675; Mon, 21 Feb 2011 23:24:53 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (unknown [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id C1AFF8FC14; Mon, 21 Feb 2011 23:24:52 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id AA40AE61BC; Mon, 21 Feb 2011 23:24:50 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=subject :from:to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; s=mail; bh=xC6B+zWdVyXf +pmAt7mpxOCReM0=; b=I1jv6HKCAp8g6XunlErsjJy5qQfe5DdXYg5HdypDkukm 8mojj9HZOscu3HpxeJYY7AvXQwUehN+cB0LHkxQRwamX8xco8KLesxOQnAn2B5RA 93uZUaMmoNILdW4SJInsRi1SlbAL6TWvDHf5oOe1hENZ9IlXv+M6QdZiEfF4Db0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s=mail; b=LBp56o V9oFgVRvZGBj3unl79FQ7hww56SNzwNcS/ix3Ff1MNo88Bw8hJ7zLn63ObKPuSDY iYq6dih3nO+h7384gUWTg/4906WnAlCJDe92q0qeUb3JlFJjBbPw55qufvEJZn54 RGGKtPsY+sPWQdZXd/CXtOHDDwP3ZrH5CuUsE= Received: from [192.168.0.11] (client-86-31-177-138.oxfd.adsl.virginmedia.com [86.31.177.138]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id 3995DE61BA; Mon, 21 Feb 2011 23:24:50 +0000 (GMT) From: Bruce Cran To: Josh Paetzel In-Reply-To: <201102211612.51233.josh@tcbug.org> References: <4D35CFFB.3010302@freebsd.org> <61079648-D76C-4699-AC4D-F6EBE64ABFFC@vicor.com> <201102190844.43267.bruce@cran.org.uk> <201102211612.51233.josh@tcbug.org> Content-Type: text/plain; charset="UTF-8" Date: Mon, 21 Feb 2011 23:24:47 +0000 Message-ID: <1298330687.4940.57.camel@debian.nessbank> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: Nathan, Devin Teske , freebsd-current@freebsd.org, Whitehorn , freebsd-arch@freebsd.org, freebsd-sysinstall@freebsd.org Subject: Re: FreeBSD Installer Roadmap 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, 21 Feb 2011 23:24:53 -0000 On Mon, 2011-02-21 at 16:12 -0600, Josh Paetzel wrote: > pc-sysinstall has been used as the PC-BSD installer for quite a while now, and > has done a lot of installs on a lot of different hardware platforms. I'll > wager that the compatibility of the shell command gpart is a better bet than > the "stick your thumbs in you ears and yell nananana while you scribble 1's > and 0's to a disk and voila, there's a disklabel" approach that sysinstall > uses. I wish that was true: unfortunately I tried and failed to create a ZFS installation with pc-sysinstall, and I get a few worrying error messages even with UFS while it repartitions the disk - people have been reporting it creating unbootable systems. gpart might be more compatible, but I don't think parsing the output of tools like as fdisk, diskinfo and dmesg is. The concerns about GPT, ZFS, gmirror etc. in sysinstall could all be resolved in a couple of days by ripping out the existing partitioning code and replacing it with ae@'s new version of sade from /user/ae/usr.sbin/sade . However since the future is pc-sysinstall I've now shifted my work to improving the Qt front-end. -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Tue Feb 22 02:38: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 1AF42106566B; Tue, 22 Feb 2011 02:38:12 +0000 (UTC) (envelope-from dteske@vicor.com) Received: from postoffice.vicor.com (postoffice.vicor.com [69.26.56.53]) by mx1.freebsd.org (Postfix) with ESMTP id ECE2A8FC12; Tue, 22 Feb 2011 02:38:11 +0000 (UTC) Received: from [210.177.209.182] (port=13437 helo=[192.168.1.151]) by postoffice.vicor.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71) (envelope-from ) id 1Pri8c-0002wb-AH; Mon, 21 Feb 2011 18:38:10 -0800 Mime-Version: 1.0 (Apple Message framework v1081) From: Devin Teske In-Reply-To: <201102211612.51233.josh@tcbug.org> Date: Mon, 21 Feb 2011 18:38:03 -0800 Message-Id: References: <4D35CFFB.3010302@freebsd.org> <61079648-D76C-4699-AC4D-F6EBE64ABFFC@vicor.com> <201102190844.43267.bruce@cran.org.uk> <201102211612.51233.josh@tcbug.org> To: Josh Paetzel X-Mailer: Apple Mail (2.1081) X-Scan-Signature: 50a71de0cae8f0fceb03b5a800567216 X-Scan-Host: postoffice.vicor.com X-Mailman-Approved-At: Tue, 22 Feb 2011 03:08:47 +0000 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Bruce Cran , Devin Teske , freebsd-current@freebsd.org, Nathan Whitehorn , freebsd-arch@freebsd.org, freebsd-sysinstall@freebsd.org Subject: Re: FreeBSD Installer Roadmap 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, 22 Feb 2011 02:38:12 -0000 On Feb 21, 2011, at 2:12 PM, Josh Paetzel wrote: > On Saturday, February 19, 2011 02:44:42 am Bruce Cran wrote: >> On Saturday 19 February 2011 03:04:39 Devin Teske wrote: >>> There are many reasons for this, and none of them are selfish = (although >>> it remains possible to drum-up some selfish reason, all of the = reasons >>> behind our motivation are in-fact unselfish). Truth-be-told, I = welcome >>> the replacement of sysinstall but am very wary that ANY replacement = will >>> be able to exactly replicate the hardware compatibility that = sysinstall >>> currently enjoys. I do indeed envision a great celebration as = FreeBSD-9 >>> bucks sysinstall but also at the same time have nightmares of = receiving >>> waves of calls from people having trouble (for example) "installing >>> FreeBSD-9 on their AMD K6 based system, circa long-long-ago in a >>> universe far-far-away." (yes, we do have data centers running that = very >>> equipment with uptime in the 1,000's of days). >>=20 >> I think bsdinstall as it currently is is simple enough that there = shouldn't >> be any compatibility issues: it uses gpart for partitioning, runs = tools >> like tzsetup to configure settings etc. so there's far less to go = wrong >> than sysinstall's custom code which for example could crash on the >> "probing devices" screen. >=20 > pc-sysinstall has been used as the PC-BSD installer for quite a while = now, and=20 > has done a lot of installs on a lot of different hardware platforms. = I'll=20 > wager that the compatibility of the shell command gpart is a better = bet than=20 > the "stick your thumbs in you ears and yell nananana while you = scribble 1's=20 > and 0's to a disk and voila, there's a disklabel" approach that = sysinstall=20 > uses. This is a common affront that can be assuaged simply by perusing = sysinstall's code. Unfortunately, I may be truly-alone in my opinion = that sysinstall is elegantly simple (but then again, I also have an = innate understanding of why each/every line of code exists; bourne = in-truth from a decadal melange of knowledge when it comes to ancient = architectures -- that and I routinely read the 15+ years of commit logs = "for fun"). In reality, the _only_ thing, in my honest opinion, that sysinstall = fails-at is its embracement of new technologies such as GPT, ZFS, and = geli (just to name a few; all of which you mention below). However, this = is not the position that I am (or we are, as a business collective) = coming from. =46rom the position at which we stand, sysinstall is not = [yet] deficient and despite your claims, neither does it resort to = black-magic "scribbl[ing] 1's and 0's to a disk and voila, there's a = disklabel" (by comparison standards, might one be able to say -- if = taking the same naive tone -- that gpart "scribble[s] 1's and 0's and = voila, there's a [partition table]"; the only distinction being perhaps = your own bias of MBR versus GPT which if you conversely understood the = limitations of MBR then you might not have such qualms against = disklabels). Just as it was stated by another in this thread that a system with = 1,000+ days uptime may not be a good candidate for upgrade (entirely on = the basis that such a system in its current state has proved its = meddle), we make an argument along the same lines for the install = process -- because sysinstall has served us *so exquisitely well* over = the years (its meddle being proven) we are reluctant to blindly accept = the "new kid on the block" without rigorous recension (note: in = comparison by age, any technology is young when compared to sysinstall). >=20 > That being said, sysinstall holds FreeBSD back in a lot of ways, using = GPT=20 > labeling, installing to ZFS, or gmirror, using geli, all require you = to boot=20 > to a shell and do an install by hand. I'm sure more people can chime = in to=20 > limitations in sysinstall than I can think of off the top of my head. You are absolutely correct in highlighting the most prominent = short-comings of sysinstall, but alas if you don't need those features = then completely swapping out your installer for a new one begins to make = less sense than sticking with what has served (and will continue to = serve) you well. The long and the short of this is, we don't use GPT, we don't (and = wouldn't) use ZFS as a root partition scheme, and have no use for geli = on the root disk (though may venture into using geli as a PCI solution = -- pcisecuritystandards.org -- on secondary media mounted at boot-time). Philosophically, innovation is bourne of necessity -- and we don't need = any of the things that bsdinstall brings us ... so the only thing that = bsdinstall represents is more work for me in migrating thousands upon = thousands of lines of code to the new installer, vetting every aspect of = the new installer in the process (note that we utilize sysinstall in = ways that others could only dream of -- something you'll be able to see = for yourself when I get back from Hong Kong to The States and start = publishing our/my work). That being said, if we _did_ need the features that are provided by = bsdinstall versus what is available today with sysinstall, I assure you = that there would be a concerted effort to start using bsdinstall ... our = hand would simply be forced. However, since we don't need those features = it seems silly to waste any man-hours on migration (by comparison, I can = put sysinstall on life-support with no trouble at all because I = envisaged this day coming and made preparations in the final ahn many = years ago). >=20 > So my question is: Given that everyone involved is very conscious of = locking=20 > out FreeBSD from hardware platforms due to installer compatibility, = wouldn't a=20 > better use of your time be investing in the future and ensuring that = it works=20 > on legacy platforms as opposed to putting sysinstall on life support = when it=20 > already has some fairly serious missing functionality, that is only = likely to=20 > become more of an issue in the future? On the contrary, it takes no effort whatsoever to put sysinstall on = life-support. Rather, it's going to take a very long time to prove that = bsdinstall can do what sysinstall can do. If asked to quantize what = percentage of features we use in sysinstall, I'd have to say 30%, = however the 30% that we do utilize is the underrepresented portion (the = portions that nobody talks about). Also, worth mentioning is that we've = patched sysinstall by 811 lines (by last count) to add even more = features (features that likely won't exist in bsdinstall that will need = to be ported). To make things worse, we're going to also have to completely rewrite all = the programs that generate the scripts that are then fed into = sysinstall's scripting abilities. Those programs weigh in at 3089+ lines = of code (including a mixture of Asm, C, FICL, and sh). It may come to pass that bsdinstall is not up to the task at-hand and = will require patching (just as sysinstall was originally not up to the = task at hand, and so we patched it ... ... _heavily_. Really, the crux of the issue is that our organization is **just now** = migrating off of FreeBSD-4 (yes, it's true... there are over 1,000 = FreeBSD-4.11 machines running in production at this very moment spanning = the entire United States, parts of India, and parts of the Indo-pacific = rim). Worse? We just added yet-another 200+ to those ranks in the past 2 = months. My hat is off to you sir... as I envy your position that you can be so = free-moving. We are encumbered by entrenched methods and do not have the = luxury of trying new things for the sake of change (case in-point, since = bsdinstall brings nothing new to the table that we rely upon, it truly = would be change for the sake of change in our organization). Fin de dialectics. >=20 > --=20 > Thanks, >=20 > Josh Paetzel -- Cheers, Devin Teske -> CONTACT INFORMATION <- Business Solutions Consultant II FIS - fisglobal.com 510-735-5650 Mobile 510-621-2038 Office 510-621-2020 Office Fax 909-477-4578 Home/Fax devin.teske@fisglobal.com -> LEGAL DISCLAIMER <- This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy. -> END TRANSMISSION <- From owner-freebsd-current@FreeBSD.ORG Tue Feb 22 06:36:47 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 644C3106564A; Tue, 22 Feb 2011 06:36:47 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 0CFCC8FC0A; Tue, 22 Feb 2011 06:36:46 +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 p1M6ajts080911; Tue, 22 Feb 2011 01:36:45 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p1M6ajrT080898; Tue, 22 Feb 2011 06:36:45 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 22 Feb 2011 06:36:45 GMT Message-Id: <201102220636.p1M6ajrT080898@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: Tue, 22 Feb 2011 06:36:47 -0000 TB --- 2011-02-22 05:21:04 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2011-02-22 05:21:04 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2011-02-22 05:21:04 - cleaning the object tree TB --- 2011-02-22 05:21:20 - cvsupping the source tree TB --- 2011-02-22 05:21:20 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2011-02-22 05:21:54 - building world TB --- 2011-02-22 05:21:54 - MAKEOBJDIRPREFIX=/obj TB --- 2011-02-22 05:21:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-02-22 05:21:54 - TARGET=powerpc TB --- 2011-02-22 05:21:54 - TARGET_ARCH=powerpc64 TB --- 2011-02-22 05:21:54 - TZ=UTC TB --- 2011-02-22 05:21:54 - __MAKE_CONF=/dev/null TB --- 2011-02-22 05:21:54 - cd /src TB --- 2011-02-22 05:21:54 - /usr/bin/make -B buildworld >>> World build started on Tue Feb 22 05:21: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 [...] {standard input}:58: Error: unsupported relocation against r1 {standard input}:59: Error: unsupported relocation against f1 {standard input}:59: Error: unsupported relocation against r1 {standard input}:60: Error: unsupported relocation against r1 {standard input}:60: Error: unsupported relocation against r1 {standard input}:61: Error: unsupported relocation against r2 {standard input}:61: Error: unsupported relocation against r1 {standard input}:62: Error: unsupported relocation against r2 *** Error code 1 Stop in /src/lib/clang/libllvmpowerpccodegen. *** Error code 1 Stop in /src/lib/clang. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-02-22 06:36:45 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-02-22 06:36:45 - ERROR: failed to build world TB --- 2011-02-22 06:36:45 - 3753.97 user 545.79 system 4541.04 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Tue Feb 22 07:03: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 92EF4106564A; Tue, 22 Feb 2011 07:03:23 +0000 (UTC) (envelope-from josh@tcbug.org) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 5A5248FC15; Tue, 22 Feb 2011 07:03:23 +0000 (UTC) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id 95EC920947; Tue, 22 Feb 2011 02:03:22 -0500 (EST) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Tue, 22 Feb 2011 02:03:22 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=from:to:subject:date:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:message-id; s=smtpout; bh=PZsflNLY9INovIWw/J0WNZQ1/z0=; b=RaVUg2UjFt1vaJ7CPIERGARpILYFHehpGcyhwipg11S1sJUVx7EMiTBaLKsQ9na9X1uE/VSpPSVfCIYiwLI14y/8PsxJva87myAAzsjcPe0uZ9PdVduOWFwU9BWhbx/kjE93vn45CebXRif3VaIcnOY6Rvm0F9GArNDFsX/+yko= X-Sasl-enc: zIzC3TaLCdg5WNm0wG01GDEVTPK0Gz1dRkCKWwacEUk6 1298358202 Received: from tcbug.ixsystems.com (74-34-19-98.dr01.rsmt.mn.frontiernet.net [74.34.19.98]) by mail.messagingengine.com (Postfix) with ESMTPSA id 2783C401AC0; Tue, 22 Feb 2011 02:03:22 -0500 (EST) From: Josh Paetzel To: freebsd-arch@freebsd.org Date: Tue, 22 Feb 2011 01:03:07 -0600 User-Agent: KMail/1.13.5 (FreeBSD/8.1-RELEASE; KDE/4.4.5; amd64; ; ) References: <4D35CFFB.3010302@freebsd.org> <201102211612.51233.josh@tcbug.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1403105.siBJnKaS6S"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201102220103.20158.josh@tcbug.org> Cc: Bruce Cran , freebsd-current@freebsd.org, Devin Teske , Nathan Whitehorn , freebsd-sysinstall@freebsd.org Subject: Re: FreeBSD Installer Roadmap 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, 22 Feb 2011 07:03:23 -0000 --nextPart1403105.siBJnKaS6S Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Monday, February 21, 2011 08:38:03 pm Devin Teske wrote: >=20 > Really, the crux of the issue is that our organization is **just now** > migrating off of FreeBSD-4 (yes, it's true... there are over 1,000 > FreeBSD-4.11 machines running in production at this very moment spanning > the entire United States, parts of India, and parts of the Indo-pacific > rim). Worse? We just added yet-another 200+ to those ranks in the past 2 > months. >=20 > My hat is off to you sir... as I envy your position that you can be so > free-moving. We are encumbered by entrenched methods and do not have the > luxury of trying new things for the sake of change (case in-point, since > bsdinstall brings nothing new to the table that we rely upon, it truly > would be change for the sake of change in our organization). >=20 > Fin de dialectics. >=20 >=20 >=20 >=20 > -- > Cheers, > Devin Teske Maintaining sysinstall for 4.x is indeed a NOOP, since features aren't bein= g=20 added to it, and the featureset that sysinstall supports is pretty much in= =20 line with the featureset in 4...no ZFS, no geom_*, etc etc etc. On the other hand, maintaining sysinstall for the next N years of new FreeB= SD=20 releases seems hard, when it's already missing features compared to what=20 =46reeBSD supports, and that's likely to continue to grow. I totally agree that for internal use, migrating thousands of lines of code= =20 makes no sense whatsoever, especially if sysinstall meets your needs and yo= u=20 don't care about the functionality it doesn't have. Exporting that to the= =20 community seems to be a questionable use of resources. I'm no stranger to large deployments. With my ${WORK} hat on we can instal= l a=20 thousand FreeBSD systems in a week. In my 16+ years of involvement with=20 =46reeBSD I've written three automated installers...quite frankly, ditching= =20 sysinstall for that happened really fast. I do admit to being a tad curious where you find systems that can run FreeB= SD=20 4 at this point. A single socket intel shows up as 8 or 12 CPUs these days= ,=20 more than enough to tie 4.x into knots. Add in disk controllers, NICs, ACP= I=20 (modern systems use that for nearly everything it seems) and suddenly an=20 installer seems the least of the concerns. I suppose my last question is along the lines of, "If adding geom_mirror=20 support to sysinstall was easy, why has it been 6+ years since gmirror made= =20 it's appearance in FreeBSD and you still can't create or install to a gmirr= or=20 with sysinstall?" =20 =2D-=20 Thanks, Josh Paetzel --nextPart1403105.siBJnKaS6S Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iQEcBAABAgAGBQJNY1+3AAoJEKFq1/n1feG2WSYIAJ980gk0UpqyK+KcevHJQoxQ 1hxgj+UP4/cbpdyNn3tjOck9W3Hxtnz9zhdoZOEQOz/MtoCJzhE03n4ysnzC7lhs vwNduIyoV1hViFbsW681y56MmPn30LptTvyzhkYbMHuJQa5GuQr+ptXgQPHIBQC/ Cg9xcEDhUrWUhHqK1b2jZ3puWZNyeSOCI/ixWgdx4zCfRO4NiL2nNW5KAZaTf/rE I2R9+B2c6cU/ikMdcZaIo5hCmsNxKsBO3wgAel6EvX1RV4vCettHOTSaeC4fSoD6 fl3Vso/eR5aWe8PWgHBXBi5BtJRQ+ZYyiHNFJJYpLclL27Qp4uVJ7jFeljcKL7o= =Bzo2 -----END PGP SIGNATURE----- --nextPart1403105.siBJnKaS6S-- From owner-freebsd-current@FreeBSD.ORG Tue Feb 22 08:15: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 BC7021065672; Tue, 22 Feb 2011 08:15:55 +0000 (UTC) (envelope-from yanegomi@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 2D52C8FC21; Tue, 22 Feb 2011 08:15:54 +0000 (UTC) Received: by wwf26 with SMTP id 26so6785863wwf.31 for ; Tue, 22 Feb 2011 00:15:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=lbkRBcdC2fQmvuJhiHq48SEu9pzrdTGyiqRNjHXlAZQ=; b=vutoG+9Of+eS9LZz870ZL1Y320pSQe7XvOcIMC/B2htDAj2HxeUnYeZvWjMwbjLwWQ 2ky20BsinubhQNYN9xm34eTJPf23sWEtOXz94OONhB/vVRLg+HfpBv4IzjIQPD4KyzUn 8IrXZilx7jdPKF/vll0hY/KifsIqTtCVLIYOM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=jEjFCbLzwM6GUPXecbkm1ey37O8d+qnNr2trz9Lq7n4PAaI/ywkQl7cTFWcu2S/ZE9 MjliswNJzPSgXNxmMTH3CK/VF1jT5bdZ5OieQE4PGN5N0EhBzGcSTN8en6dnSYESqfGp rvBNy86pXHdWfsATyxmBHwTxJVdMGv8w+nJXY= MIME-Version: 1.0 Received: by 10.216.183.145 with SMTP id q17mr2102343wem.5.1298362554106; Tue, 22 Feb 2011 00:15:54 -0800 (PST) Received: by 10.216.15.74 with HTTP; Tue, 22 Feb 2011 00:15:54 -0800 (PST) Date: Tue, 22 Feb 2011 00:15:54 -0800 Message-ID: From: Garrett Cooper To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Current Subject: Wow... (<-- blown away at performance) 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, 22 Feb 2011 08:15:55 -0000 I don't know what to say, but r218938 screams with flash videos (native Linux speed). Not sure if it's the new binutils or if it's the new linuxulator patches, but I can run multiple instances of youtube in parallel (5 total with other miscellaneous flash animation) without it totally lagging out Firefox/X11, and it appears to close the instances of firefox properly now. Hopefully this version fares better than r218113 did (I think I hit a kernel bug after 2 weeks uptime, where my system just hardlocked for no apparent reason). Anyhow, hope others have similar results. Cheers! -Garrett $ uname -a FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r218938M: Mon Feb 21 23:10:51 PST 2011 gcooper@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 From owner-freebsd-current@FreeBSD.ORG Tue Feb 22 09:20: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 714941065672; Tue, 22 Feb 2011 09:20:53 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (unknown [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id 22C368FC0A; Tue, 22 Feb 2011 09:20:53 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 4ED0FE61BF; Tue, 22 Feb 2011 09:20:52 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=subject :from:to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; s=mail; bh=9yqtpASMzKVx MDF7eCjvuisjEiE=; b=YBbpRUky33c61IzCtrDvTor+VrB89H1Yyk2tT9VVSe5e jII3S7m8tVKUCgmVvGvv2emfvH7lMbFpLQAf/8HoSBprC4nWBE/S7mSIEGte5DBN by5UZrJ/Zzo71mQpSmMeA4uLY1OoKvGs+JncjBanuwEqCpYTRxQvGXDvsCbFX7c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s=mail; b=KdTLKw 8Tm3/UH/4Af3x7HMvYtUt5/qyJ9oge5WgCzpRNePpPEbhaI82yuvQw3NcAq9ODas QygbMPw1yiBGqAYEeo/qnCiTQdQ5OIbOJrDy9AF02nVlEhlIne2zXaEdJvhDdZ42 jIUmOV83B4NeSvS0ODn8PIl/Oj42J0XO2wZNM= Received: from [192.168.0.11] (client-86-31-177-138.oxfd.adsl.virginmedia.com [86.31.177.138]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id E1769E61BE; Tue, 22 Feb 2011 09:20:51 +0000 (GMT) From: Bruce Cran To: Josh Paetzel In-Reply-To: <201102220103.20158.josh@tcbug.org> References: <4D35CFFB.3010302@freebsd.org> <201102211612.51233.josh@tcbug.org> <201102220103.20158.josh@tcbug.org> Content-Type: text/plain; charset="UTF-8" Date: Tue, 22 Feb 2011 09:20:50 +0000 Message-ID: <1298366450.4940.69.camel@debian.nessbank> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: freebsd-sysinstall@freebsd.org, freebsd-current@freebsd.org, Devin Teske , Nathan Whitehorn , freebsd-arch@freebsd.org Subject: Re: FreeBSD Installer Roadmap 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, 22 Feb 2011 09:20:53 -0000 On Tue, 2011-02-22 at 01:03 -0600, Josh Paetzel wrote: > I suppose my last question is along the lines of, "If adding geom_mirror > support to sysinstall was easy, why has it been 6+ years since gmirror made > it's appearance in FreeBSD and you still can't create or install to a gmirror > with sysinstall?" It's not been added because everyone thinks sysinstall code is horrible and won't touch it. -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Tue Feb 22 09:25: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 5856F1065673 for ; Tue, 22 Feb 2011 09:25:57 +0000 (UTC) (envelope-from jerome.flesch@netasq.com) Received: from work.netasq.com (mars.netasq.com [91.212.116.3]) by mx1.freebsd.org (Postfix) with ESMTP id E8AB18FC08 for ; Tue, 22 Feb 2011 09:25:56 +0000 (UTC) Received: from pc_jf.netasq.com (unknown [10.2.200.254]) by work.netasq.com (Postfix) with ESMTPSA id 9E410740015; Tue, 22 Feb 2011 10:24:35 +0100 (CET) Message-ID: <4D638050.2010906@netasq.com> Date: Tue, 22 Feb 2011 10:22:24 +0100 From: Jerome Flesch User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.16) Gecko/20110106 Thunderbird/3.0.11 MIME-Version: 1.0 To: Chuck Swiger References: <4D6291A5.4050206@netasq.com> <8C8FE4A5-F031-466A-9CB8-46D79EEA280D@mac.com> In-Reply-To: <8C8FE4A5-F031-466A-9CB8-46D79EEA280D@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Process timing issue 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, 22 Feb 2011 09:25:57 -0000 > On Feb 21, 2011, at 8:24 AM, Jerome Flesch wrote: >> While investigating a timing issue with one of our program, we found out something weird: We've written a small test program that just calls clock_gettime() a lot of times and checks that the time difference between calls makes sense. In the end, it seems it doesn't always do. >> >> Calling twice in a row clock_gettime() takes usually less than 1ms. But with an average load, about 1 time in 200000, more than 10ms are spent between both calls for no apparent reason. According to our tests, when it happens, the time between both calls can go from few milliseconds to many seconds (our best score so far is 10 seconds :). Same goes for gettimeofday(). > > A scheduler quantum of 10ms (or HZ=100) is a common granularity; probably some other process got the CPU and your timer process didn't run until the next or some later scheduler tick. If you are maxing out the available CPU by running many "openssl speed" tasks, then this behavior is more-or-less expected. > We did most of our tests with kern.hz=1000 (the default FreeBSD value as far as I know) and we also tried with kern.hz=2000 and kern.hz=10000. It didn't change a thing. Also, we are talking about a process not being scheduled for more than 100ms with only 1 instance of openssl on the same CPU core. Even with a scheduler quantum of 10ms, I find that worrying :/ We expected both processes (the test program and openssl) to have each half the CPU time and being scheduled quite often (at least once each 10ms). According to the output of our test program, it works fine for most of the calls to clock_gettime(), but from time to time (about 1 loop in 200000 on my computer), we have a latency pike (>= 100ms). Thing is, these pikes wouldn't worry us much if they wouldn't last longer than 1s, but they do on some occasions. >> We tried setting the test program to the highest priority possible (rtprio(REALTIME, RTP_PRIO_MAX)) and it doesn't seem to change a thing. >> > >> Does anyone know if there is a reason for this behavior ? Is there something that can be done to improve things ? > > FreeBSD doesn't offer hard realtime guarantees, and it values maximizing throughput for all tasks more than it does providing absolute minimum latency even for something wanting RT. There has been some discussion in the past about making RT tasks with very high priority less pre-emptible by lower priority tasks by removing or reducing the priority lowering that occurs when a task gets allocated CPU time. > > What problem are you trying to solve where continuous CPU load and minimum latency realtime are both required? > We are not looking for hard realtime guarantees. Most of our tests were done in normal priority. Using real time priority on our test program was just a try to see it improves things. From what I can tell, it doesn't :/ > Regards, From owner-freebsd-current@FreeBSD.ORG Tue Feb 22 10:10: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 04DD71065674 for ; Tue, 22 Feb 2011 10:10:39 +0000 (UTC) (envelope-from eirnym@gmail.com) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by mx1.freebsd.org (Postfix) with ESMTP id 5A3DA8FC1D for ; Tue, 22 Feb 2011 10:10:37 +0000 (UTC) Received: by bwz13 with SMTP id 13so3264173bwz.17 for ; Tue, 22 Feb 2011 02:10:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=bJdxLfPnS31kjIhhXLphpYRGO8keGSBVpIkVmdAu03Q=; b=jLtfXKvDbDvL+QXWVU6YzWYKCN0Y87iPQLeg03KaBRftc7x9khMFL2FRb7SpOlDH/O 84Gf+uXqnUGAkgk7meD/YYgHJIyc2B1T4/aG1D+P9sPYos63BEEkO1hsaCDI7fgvtyUs dn5tmKdRKhKV7Mrh8QS4V8qXG8eueY6Qu/dM0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=pNZ69yA/Sy6USzW+K2pABm5+ybZJWgGKC8RrDhyH94pJfptV2+uHgeR6IXjaW8mbtH JpJ+lQjCZM/UNqnLgWHHuGEp6pdUdvYqcuCdjGMi2tEXtLxLJXtqlahyu3TZS3tbwNjo Q5WkBLm5FY1KlxU/gCkNyza2UHFfEgJB6inPs= Received: by 10.204.14.202 with SMTP id h10mr2321115bka.182.1298369437182; Tue, 22 Feb 2011 02:10:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.14.141 with HTTP; Tue, 22 Feb 2011 02:10:17 -0800 (PST) In-Reply-To: References: From: Eir Nym Date: Tue, 22 Feb 2011 13:10:17 +0300 Message-ID: To: Garrett Cooper Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current , Dimitry Andric Subject: Re: Wow... (<-- blown away at performance) 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, 22 Feb 2011 10:10:39 -0000 On 22 February 2011 11:15, Garrett Cooper wrote: > =C2=A0 =C2=A0I don't know what to say, but r218938 screams with flash vid= eos > (native Linux speed). Not sure if it's the new binutils or if it's the > new linuxulator patches, but I can run multiple instances of youtube > in parallel (5 total with other miscellaneous flash animation) without > it totally lagging out Firefox/X11, and it appears to close the > instances of firefox properly now. Hopefully this version fares better > than r218113 did (I think I hit a kernel bug after 2 weeks uptime, > where my system just hardlocked for no apparent reason). > =C2=A0 =C2=A0Anyhow, hope others have similar results. > Cheers! > -Garrett > > $ uname -a > FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r218938M: > Mon Feb 21 23:10:51 PST 2011 > gcooper@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA =C2=A0amd64 > _______________________________________________ > 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= " > Which FlashPlayer version do you test? Adobe has made significant performance changes in 10.2 (from 10.1). You can search for StageVideo performance to learn more about. Youtube already use them since 10.2 beta From owner-freebsd-current@FreeBSD.ORG Tue Feb 22 10:51: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 9FB08106566B; Tue, 22 Feb 2011 10:51:09 +0000 (UTC) (envelope-from dteske@vicor.com) Received: from postoffice.vicor.com (postoffice.vicor.com [69.26.56.53]) by mx1.freebsd.org (Postfix) with ESMTP id 7F1F48FC19; Tue, 22 Feb 2011 10:51:09 +0000 (UTC) Received: from [210.177.209.182] (port=13139 helo=[192.168.1.151]) by postoffice.vicor.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71) (envelope-from ) id 1PrppZ-0004JS-V4; Tue, 22 Feb 2011 02:51:08 -0800 Mime-Version: 1.0 (Apple Message framework v1081) From: Devin Teske In-Reply-To: <201102220103.20158.josh@tcbug.org> Date: Tue, 22 Feb 2011 02:50:54 -0800 Message-Id: References: <4D35CFFB.3010302@freebsd.org> <201102211612.51233.josh@tcbug.org> <201102220103.20158.josh@tcbug.org> To: Josh Paetzel X-Mailer: Apple Mail (2.1081) X-Scan-Signature: 0d916604628b474728ef7f444882548c X-Scan-Host: postoffice.vicor.com X-Mailman-Approved-At: Tue, 22 Feb 2011 12:42:52 +0000 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Bruce Cran , freebsd-sysinstall@freebsd.org, freebsd-current@freebsd.org, Nathan Whitehorn , freebsd-arch@freebsd.org Subject: Re: FreeBSD Installer Roadmap 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, 22 Feb 2011 10:51:09 -0000 On Feb 21, 2011, at 11:03 PM, Josh Paetzel wrote: > On Monday, February 21, 2011 08:38:03 pm Devin Teske wrote: >=20 >>=20 >> Really, the crux of the issue is that our organization is **just = now** >> migrating off of FreeBSD-4 (yes, it's true... there are over 1,000 >> FreeBSD-4.11 machines running in production at this very moment = spanning >> the entire United States, parts of India, and parts of the = Indo-pacific >> rim). Worse? We just added yet-another 200+ to those ranks in the = past 2 >> months. >>=20 >> My hat is off to you sir... as I envy your position that you can be = so >> free-moving. We are encumbered by entrenched methods and do not have = the >> luxury of trying new things for the sake of change (case in-point, = since >> bsdinstall brings nothing new to the table that we rely upon, it = truly >> would be change for the sake of change in our organization). >>=20 >> Fin de dialectics. >>=20 >>=20 >>=20 >>=20 >> -- >> Cheers, >> Devin Teske >=20 > Maintaining sysinstall for 4.x is indeed a NOOP, since features aren't = being=20 > added to it, and the featureset that sysinstall supports is pretty = much in=20 > line with the featureset in 4...no ZFS, no geom_*, etc etc etc. >=20 > On the other hand, maintaining sysinstall for the next N years of new = FreeBSD=20 > releases seems hard Actually, it's trivial to anyone that has mastered release engineering = (see release(7) and the handbook). > , when it's already missing features compared to what=20 > FreeBSD supports, That's the operative word here ("supports"). Lord help us when that = changes to "requires" (that is to say, if/when the FreeBSD kernel = becomes legacy-free with respect to supporting fdisk/disklabel = partitioned disks). > and that's likely to continue to grow. We've yet to see a "must have" technology that would require us to shun = sysinstall (as explained earlier, we have no desire whatsoever to boot = from ZFS, gmirror, geli, GPT, or anything else missing from sysinstall). One such possible motivation would be if we needed to create a boot = partition that exceeds 4TB (the limits of MBR partitioning versus GPT). = I just don't see that happening (workstations, servers, pedestals... why = would we ever need >8GB for the operating system? all production data is = being stored on enterprise class devices such as the NEC-D210, and being = backed up with tapes such as LTO; In our organization every machine is = expendable and we have disaster recovery procedures for any/all = failures). >=20 > I totally agree that for internal use, migrating thousands of lines of = code=20 > makes no sense whatsoever, especially if sysinstall meets your needs = and you=20 > don't care about the functionality it doesn't have. Exporting that to = the=20 > community seems to be a questionable use of resources. >=20 > I'm no stranger to large deployments. With my ${WORK} hat on we can = install a=20 > thousand FreeBSD systems in a week. In my 16+ years of involvement = with=20 > FreeBSD I've written three automated installers...quite frankly, = ditching=20 > sysinstall for that happened really fast. Good work. However, it's a shame that you found the need to ditch sysinstall. We = found no such need and have created an automated network installation = process literally on the assembly line in a factory the size of a = football stadium -- responsible for churning out thousands of machines = per year with FreeBSD-4.11 pre-installed before they arrive on-site (all = using sysinstall). The hardware gets assembled to-spec, slides down an = assembly-line, a technician jacks power, network, video and keyboard to = the box, netboots it by pressing F12, waits 5 minutes for the screen to = finish installation, powers it off, and slides it down the line. > I do admit to being a tad curious where you find systems that can run = FreeBSD=20 > 4 at this point. We're installing FreeBSD-4.11 onto modern systems, including: Intel Server Chassis SC5299 Intel Server Chassis SR2500 just to name a couple. Albeit, we've back-ported many drivers, such as mfi(3) from RELENG_6 to = support the LSI MegaSAS controller. We're no stranger to putting even the Operating System on Life Support = for as long as it takes for our customers to bolster their budgets for = an integrated upgrade strategy. We have a very small yet largely talented group of individuals = (including myself) within our organization that quickly and efficiently = remediate lost functionality required to maintain hardware compatibility = simply because our customers cannot stomach upgrading the OS every = 18-months (or whatever the life-cycle may be). We can't be forcing our = customers to upgrade their entire organization everytime the OS can't = boot from some new controller -- not when adding the lost functionality = into the OS is only a matter of a couple weeks work (at most). So in earnest, I should have clarified that despite running FreeBSD-4.11 = on thousands of machines... it's actually a highly customized kernel = _and_ install process that allows us to run on modern hardware. > A single socket intel shows up as 8 or 12 CPUs these days,=20 > more than enough to tie 4.x into knots. Add in disk controllers, = NICs, ACPI=20 > (modern systems use that for nearly everything it seems) and suddenly = an=20 > installer seems the least of the concerns. You are absolutely right. Everything about FreeBSD-4.11 is on = life-support in our enterprise. The kernel/installer has pieces from = RELENG_6, RELENG_7, and even RELENG_8. Life-support is our specialty as = our clients demand it. When suppliers decide to EOL certain hardware, we = simply back-port the necessary changes to support the new hardware. When = FreeBSD EOL'd 4.11, that by no means gave us a right to go mandate that = our customers immediately upgrade (which would cost potentially millions = of dollars). >=20 > I suppose my last question is along the lines of, "If adding = geom_mirror=20 > support to sysinstall was easy, why has it been 6+ years since gmirror = made=20 > it's appearance in FreeBSD and you still can't create or install to a = gmirror=20 > with sysinstall?" In enterprise business we rely on hardware RAID. If software RAID such as gmirror was an acceptable solution in our = Enterprise, I'd have personally added it to sysinstall years ago. >=20 >=20 > --=20 > Thanks, >=20 > Josh Paetzel -- Cheers, Devin Teske -> CONTACT INFORMATION <- Business Solutions Consultant II FIS - fisglobal.com 510-735-5650 Mobile 510-621-2038 Office 510-621-2020 Office Fax 909-477-4578 Home/Fax devin.teske@fisglobal.com -> LEGAL DISCLAIMER <- This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy. -> FUN STUFF <- -----BEGIN GEEK CODE BLOCK----- Version 3.12 GAT/CS/B/CC/E/IT/MC/M/MU/P/S/TW d+(++) s: a- C+++@$ UB++++$ P++++@$ = L++++$ E- W+++ N? o? K? w@ O M++$ V- PS+>++ PE@ Y+ PGP-> t(+) 5? X(+) R(-) tv+ = b+>++ DI+ D+(++) G++ e>++++ h r+++ z+++ ------END GEEK CODE BLOCK------ http://www.geekcode.com/ -> END TRANSMISSION <- From owner-freebsd-current@FreeBSD.ORG Tue Feb 22 11:40: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 19488106564A; Tue, 22 Feb 2011 11:40:25 +0000 (UTC) (envelope-from alexandre.martins@netasq.com) Received: from work.netasq.com (mars.netasq.com [91.212.116.3]) by mx1.freebsd.org (Postfix) with ESMTP id 99F0C8FC08; Tue, 22 Feb 2011 11:40:24 +0000 (UTC) Received: from pc-alex.netasq.com (unknown [10.2.200.254]) by work.netasq.com (Postfix) with ESMTP id 4F3DE30CB711; Tue, 22 Feb 2011 12:39:00 +0100 (CET) From: Alexandre Martins Organization: Netasq To: freebsd-current@freebsd.org Date: Tue, 22 Feb 2011 12:40:30 +0100 User-Agent: KMail/1.13.5 (FreeBSD/7.3-RELEASE-p4; KDE/4.5.5; i386; ; ) References: <201102140935.22490.alexandre.martins@netasq.com> <86fwrqpqd9.fsf@gmail.com> <201102141718.35023.alexandre.martins@netasq.com> In-Reply-To: <201102141718.35023.alexandre.martins@netasq.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1673807.28dQXujLLt"; protocol="application/pgp-signature"; micalg=pgp-sha256 Content-Transfer-Encoding: 7bit Message-Id: <201102221240.34271.alexandre.martins@netasq.com> X-Mailman-Approved-At: Tue, 22 Feb 2011 12:43:12 +0000 Cc: Anonymous , Dimitry Andric Subject: Re: OpenSSL 1.0.0d for Freebsd 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: Tue, 22 Feb 2011 11:40:25 -0000 --nextPart1673807.28dQXujLLt Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Dears, After several research, i have removed the problematic part. You can find the new version here: http://people.freebsd.org/~fabient/patch-head20110222-openssl1.0.0d Regards, =2D-=20 Alexandre Martins Research engineer NETASQ On Monday 14 February 2011 17:18:24 Alexandre Martins wrote: > Dear, >=20 > Thank you for your feed-back. >=20 > I'll look for this issu, and i hope deliver a better patch quickly. >=20 > Regards, >=20 > > Alexandre Martins writes: > > > For those interested in testing, you can find a patch that add OpenSSL > > > 1.0d to head. > >=20 > > [...] > >=20 > > Hmm, doesn't build with ld(1) from /projects/binutils-2.17. > >=20 > > $ make -dl all > > as -o rc4-amd64.o /usr/src/secure/lib/libcrypto/amd64/rc4-amd64.s > > [ -z "ctfconvert" -o -n "1" ] || (echo ctfconvert -L VERSION > > rc4-amd64.o > >=20 > > && ctfconvert -L VERSION rc4-amd64.o) echo building static crypto > > library > >=20 > > building static crypto library > > rm -f libcrypto.a > > ar cq libcrypto.a `lorder ...` > > ranlib libcrypto.a > > as -o rc4-amd64.po /usr/src/secure/lib/libcrypto/amd64/rc4-amd64.s > > [ -z "ctfconvert" -o -n "1" ] || (echo ctfconvert -L VERSION > >=20 > > rc4-amd64.po && ctfconvert -L VERSION rc4-amd64.po) echo building > > profiled crypto library > >=20 > > building profiled crypto library > > rm -f libcrypto_p.a > > ar cq libcrypto_p.a `lorder ...` > > ranlib libcrypto_p.a > > as -o rc4-amd64.So /usr/src/secure/lib/libcrypto/amd64/rc4-amd64.s > > [ -z "ctfconvert" -o -n "1" ] || (echo ctfconvert -L VERSION > >=20 > > rc4-amd64.So && ctfconvert -L VERSION rc4-amd64.So) echo building shar= ed > > library libcrypto.so.7 > >=20 > > building shared library libcrypto.so.7 > > rm -f libcrypto.so.7 libcrypto.so > > ln -fs libcrypto.so.7 libcrypto.so > > cc -fstack-protector -shared -Wl,-x -o libcrypto.so.7 > >=20 > > -Wl,-soname,libcrypto.so.7 `lorder ...` /usr/bin/ld: rc4-amd64.So: > > relocation R_X86_64_PC32 against `OPENSSL_ia32cap_P' can not be used wh= en > > making a shared object; recompile with -fPIC /usr/bin/ld: final link > > failed: Bad value > >=20 > > *** Error code 1 > >=20 > > Reverting back to binutils-2.15 makes build fail with another error. > > libcrypto builds fine but linking against it always fails > >=20 > > $ cc foo.c -lcrypto > > /usr/lib/libcrypto.so: undefined reference to > > `_x86_64_Camellia_decrypt' /usr/lib/libcrypto.so: undefined reference > > to `.Ldloop' > >=20 > > Indeed, some parts are missing > >=20 > > %% diff against output from cmll-x86_64.pl > > --- secure/lib/libcrypto/amd64/cmll_amd64.s > > +++ crypto/openssl/crypto/camellia/asm/cmll-x86_64.pl.out > >=20 > > @@ -312,6 +312,170 @@ Camellia_DecryptBlock_Rounds: > > call _x86_64_Camellia_decrypt > >=20 --nextPart1673807.28dQXujLLt Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iF4EABEIAAYFAk1joLIACgkQVHYVC4W8mzgcOAEAuXG7AbuvuHqoWZkXpzTe48gT hT69s4GE/AODH76doJYA/AknC2JzjTb8HDhhQ4DlFaSYK8JDp79SfYUfwT8bl45Y =yalr -----END PGP SIGNATURE----- --nextPart1673807.28dQXujLLt-- From owner-freebsd-current@FreeBSD.ORG Tue Feb 22 15:02: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 0D75D1065670; Tue, 22 Feb 2011 15:02:02 +0000 (UTC) (envelope-from datastream.freecity@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 A17A18FC1B; Tue, 22 Feb 2011 15:02:01 +0000 (UTC) Received: by gyh4 with SMTP id 4so1569845gyh.13 for ; Tue, 22 Feb 2011 07:02:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=rsM3zmdTNHfqcIndQNIDntAi4jhVrOnJs7EgzOURiSM=; b=Weva+i0RhJ+9sOcTXqwdf9Yzbxy/gDYHI0RSu76jKUv69E1Q3QSWjnPp158aJAbWZg bIELHlRtJbBtjpPtuc11PTk/ik29fbbm5qmU90USrLl7J3OJGDpvkf8Wag/273W5Tyv/ ZucB/UDJ6brAom4ChzNnfV+TnDHoBo7jiUyfY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=UdhXOqJbqeCKrOdZSIyhUjFXHwlAiCKAWEF8Ct+5Ef7PtR3jhA3cJWHoKFDA2oTdPt KpoxhYqIRgaQzX4GxC8dTQnaGHWTXMRZx/n4fYgOtojslIAmOa9D+Ysc8kHtBaX8rxAk An1LewWLt8n/6AhIRAyJZrMPVsA8xWV8lsSig= MIME-Version: 1.0 Received: by 10.151.40.5 with SMTP id s5mr3454224ybj.63.1298385477681; Tue, 22 Feb 2011 06:37:57 -0800 (PST) Received: by 10.151.47.7 with HTTP; Tue, 22 Feb 2011 06:37:57 -0800 (PST) In-Reply-To: <4D627FBE.1070700@FreeBSD.org> References: <4D627FBE.1070700@FreeBSD.org> Date: Tue, 22 Feb 2011 22:37:57 +0800 Message-ID: From: "datastream datastream.freecity" To: Dimitry Andric Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Olivier Smedts , freebsd-current@freebsd.org Subject: Re: Can't buildworld since Clang update 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, 22 Feb 2011 15:02:02 -0000 I add '-no-integrated-as' in /etc/make.conf,but I still failed. #clang -v FreeBSD clang version 2.8 (tags/RELEASE_28 115870) 20101007 Target: x86_64-undermydesk-freebsd9.0 Thread model: posix #make buildworld ...... ===> cddl/usr.bin/zinject (all) clang -O2 -pipe -fno-omit-frame-pointer -no-integrated-as -I/usr/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/usr/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/usr/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/usr/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/usr/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/usr/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/usr/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/usr/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/usr/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/usr/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/usr/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector -Wno-pointer-sign -Wno-unknown-pragmas -c /usr/src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/zinject.c clang -O2 -pipe -fno-omit-frame-pointer -no-integrated-as -I/usr/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/usr/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/usr/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/usr/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/usr/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/usr/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/usr/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/usr/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/usr/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/usr/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/usr/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector -Wno-pointer-sign -Wno-unknown-pragmas -c /usr/src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c /usr/src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c:209:10: warning: 10 enumeration values not handled in switch: 'TYPE_MOS', 'TYPE_MOSDIR', 'TYPE_METASLAB'... [-Wswitch-enum] switch (type) { ^ /usr/src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c:323:11: warning: 5 enumeration values not handled in switch: 'TYPE_DATA', 'TYPE_DNODE', 'TYPE_LABEL_UBERBLOCK'... [-Wswitch-enum] switch (type) { ^ /usr/src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c:449:10: warning: 10 enumeration values not handled in switch: 'TYPE_DATA', 'TYPE_DNODE', 'TYPE_MOS'... [-Wswitch-enum] switch (label_type) { ^ 3 warnings generated. clang -O2 -pipe -fno-omit-frame-pointer -no-integrated-as -I/usr/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/usr/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/usr/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/usr/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/usr/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/usr/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/usr/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/usr/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/usr/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/usr/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/usr/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector -Wno-pointer-sign -Wno-unknown-pragmas -o zinject zinject.o translate.o -lavl -lgeom -lm -lnvpair -lumem -luutil -lzfs -lzpool clang: warning: argument unused during compilation: '-std=gnu89' /usr/obj/usr/src/tmp/lib/libthr.so.3: undefined reference to `_rtld_get_stack_prot' clang: error: linker command failed with exit code 1 (use -v to see invocation) *** Error code 1 Stop in /usr/src/cddl/usr.bin/zinject. *** Error code 1 Stop in /usr/src/cddl/usr.bin. *** Error code 1 Stop in /usr/src/cddl. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. On Mon, Feb 21, 2011 at 11:07 PM, Dimitry Andric wrote: > On 2011-02-21 11:33, Olivier Smedts wrote: > >> I can't buildworld with Clang since the last update. >> > ... > > %cat /etc/src.conf >> .if !defined(CC) || ${CC} == "cc" >> CC=clang >> .endif >> .if !defined(CXX) || ${CXX} == "c++" >> CXX=clang++ >> .endif >> # Don't die on warnings >> NO_WERROR= >> WERROR= >> > > Try putting these lines in /etc/make.conf instead. Unfortunately, due > to the way src.conf is read, it isn't usable for the few cases we need > to disable clang's integrated assembler, using the '-no-integrated-as' > option. > > > > /tmp/cc-VUyvc6.s:6:1: warning: ignoring directive for now >> .intel_syntax noprefix >> ^ >> > > In this case, you hit the one and only instance of the '.intel_syntax' > directive in the tree; this directive is not yet supported by clang's > integrated assembler. > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Tue Feb 22 15:13:10 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 8FA66106564A for ; Tue, 22 Feb 2011 15:13:10 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4E2128FC14 for ; Tue, 22 Feb 2011 15:13:10 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:794d:2247:36f9:4086] (unknown [IPv6:2001:7b8:3a7:0:794d:2247:36f9:4086]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 81AF35C59; Tue, 22 Feb 2011 16:13:09 +0100 (CET) Message-ID: <4D63D28B.4080900@FreeBSD.org> Date: Tue, 22 Feb 2011 16:13:15 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.15pre) Gecko/20110221 Lanikai/3.1.9pre MIME-Version: 1.0 To: "datastream datastream.freecity" References: <4D627FBE.1070700@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Olivier Smedts , freebsd-current@freebsd.org Subject: Re: Can't buildworld since Clang update 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, 22 Feb 2011 15:13:10 -0000 On 2011-02-22 15:37, datastream datastream.freecity wrote: > I add '-no-integrated-as' in /etc/make.conf,but I still failed. Don't do that. The few instances where the integrated assembler needs to be disabled are already covered. ... > /usr/obj/usr/src/tmp/lib/libthr.so.3: undefined reference to > `_rtld_get_stack_prot' Something seems to be seriously wrong in your tree. Can you try to blow away /usr/obj entirely, remove the -no-integrated-as flag from make.conf, and try again? From owner-freebsd-current@FreeBSD.ORG Tue Feb 22 15:39: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 D74BC1065674; Tue, 22 Feb 2011 15:39:17 +0000 (UTC) (envelope-from null@pozo.com) Received: from pozo.com (pozo.com [216.101.162.50]) by mx1.freebsd.org (Postfix) with ESMTP id 46FC18FC0C; Tue, 22 Feb 2011 15:39:15 +0000 (UTC) Received: from T61p.pozo.com (t61p.pozo.com [192.168.0.4]) (authenticated bits=0) by pozo.com (8.14.4/8.14.4) with ESMTP id p1MFH419086921 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 22 Feb 2011 07:17:05 -0800 (PST) (envelope-from null@pozo.com) Message-Id: <201102221517.p1MFH419086921@pozo.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 22 Feb 2011 07:16:58 -0800 To: Dimitry Andric , Olivier Smedts From: Manfred Antar In-Reply-To: <4D627FBE.1070700@FreeBSD.org> References: <4D627FBE.1070700@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, score=-100.9 required=5.0 tests=ALL_TRUSTED,MISSING_MID, USER_IN_WHITELIST autolearn=no version=3.3.1, No X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pozo.com X-pozocom-MailScanner-Information: Please contact the ISP for more information X-pozocom-MailScanner-ID: p1MFH419086921 X-pozocom-MailScanner: Found to be clean X-pozocom-MailScanner-From: null@pozo.com Cc: freebsd-current@freebsd.org Subject: Re: Can't buildworld since Clang update 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, 22 Feb 2011 15:39:17 -0000 At 07:07 AM 2/21/2011, Dimitry Andric wrote: >On 2011-02-21 11:33, Olivier Smedts wrote: >>I can't buildworld with Clang since the last update. >... >>%cat /etc/src.conf >>.if !defined(CC) || ${CC} == "cc" >>CC=clang >>.endif >>.if !defined(CXX) || ${CXX} == "c++" >>CXX=clang++ >>.endif >># Don't die on warnings >>NO_WERROR= >>WERROR= > >Try putting these lines in /etc/make.conf instead. Unfortunately, due >to the way src.conf is read, it isn't usable for the few cases we need >to disable clang's integrated assembler, using the '-no-integrated-as' >option. > > >>/tmp/cc-VUyvc6.s:6:1: warning: ignoring directive for now >>.intel_syntax noprefix >>^ > >I too am having trouble with buildworld >I switched back to standard /usr/bin/cc, but make buildworld stops here: > >c++ -O2 -pipe -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/include -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support -I. -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DLLVM_HOSTTRIPLE=\"i386-undermydesk-freebsd9.0\" -I/usr/obj/usr/src/tmp/legacy/usr/include -fno-exceptions -c /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/system_error.cpp >building static llvmsupport library >ranlib libllvmsupport.a >===> lib/clang/libllvmsystem (obj,depend,all,install) >cd: can't cd to /usr/src/lib/clang/libllvmsystem >*** Error code 2 > >Stop in /usr/src. >*** Error code 1 > >Stop in /usr/src. >*** Error code 1 > >Stop in /usr/src. > >Last night i deleted /usr/src and did a fresh cvsup >Still same problem > >================================== >|| null@pozo.com || >|| Ph. (415) 681-6235 || >================================== -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From owner-freebsd-current@FreeBSD.ORG Tue Feb 22 15:42:26 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 9203F106566C for ; Tue, 22 Feb 2011 15:42:26 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 517748FC15 for ; Tue, 22 Feb 2011 15:42:26 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:794d:2247:36f9:4086] (unknown [IPv6:2001:7b8:3a7:0:794d:2247:36f9:4086]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 5C2455C59; Tue, 22 Feb 2011 16:42:25 +0100 (CET) Message-ID: <4D63D967.5040500@FreeBSD.org> Date: Tue, 22 Feb 2011 16:42:31 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.15pre) Gecko/20110221 Lanikai/3.1.9pre MIME-Version: 1.0 To: Manfred Antar References: <4D627FBE.1070700@FreeBSD.org> <201102221517.p1MFH419086921@pozo.com> In-Reply-To: <201102221517.p1MFH419086921@pozo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Olivier Smedts , freebsd-current@freebsd.org Subject: Re: Can't buildworld since Clang update 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, 22 Feb 2011 15:42:26 -0000 On 2011-02-22 16:16, Manfred Antar wrote: >> I too am having trouble with buildworld >> I switched back to standard /usr/bin/cc, but make buildworld stops here: >> >> c++ -O2 -pipe -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/include -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support -I. -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DLLVM_HOSTTRIPLE=\"i386-undermydesk-freebsd9.0\" -I/usr/obj/usr/src/tmp/legacy/usr/include -fno-exceptions -c /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/system_error.cpp >> building static llvmsupport library >> ranlib libllvmsupport.a >> ===> lib/clang/libllvmsystem (obj,depend,all,install) >> cd: can't cd to /usr/src/lib/clang/libllvmsystem libllvmsystem does not exist anymore, and has been eliminated from lib/clang/Makefile. Your tree is out of date, or inconsistently updated. Try using another cvsup mirror. From owner-freebsd-current@FreeBSD.ORG Tue Feb 22 15: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 6D8AC106566C; Tue, 22 Feb 2011 15:44:32 +0000 (UTC) (envelope-from null@pozo.com) Received: from pozo.com (pozo.com [216.101.162.50]) by mx1.freebsd.org (Postfix) with ESMTP id CC2538FC08; Tue, 22 Feb 2011 15:44:31 +0000 (UTC) Received: from T61p.pozo.com (t61p.pozo.com [192.168.0.4]) (authenticated bits=0) by pozo.com (8.14.4/8.14.4) with ESMTP id p1MFiDwv005627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 22 Feb 2011 07:44:13 -0800 (PST) (envelope-from null@pozo.com) Message-Id: <201102221544.p1MFiDwv005627@pozo.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 22 Feb 2011 07:44:07 -0800 To: Dimitry Andric , Olivier Smedts From: Manfred Antar Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, score=-100.9 required=5.0 tests=ALL_TRUSTED,MISSING_MID, USER_IN_WHITELIST autolearn=no version=3.3.1, No X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pozo.com X-pozocom-MailScanner-Information: Please contact the ISP for more information X-pozocom-MailScanner-ID: p1MFiDwv005627 X-pozocom-MailScanner: Found to be clean X-pozocom-MailScanner-From: null@pozo.com Cc: freebsd-current@freebsd.org Subject: Re: Can't buildworld since Clang update 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, 22 Feb 2011 15:44:32 -0000 At 07:07 AM 2/21/2011, Dimitry Andric wrote: >On 2011-02-21 11:33, Olivier Smedts wrote: >>I can't buildworld with Clang since the last update. >... >>%cat /etc/src.conf >>.if !defined(CC) || ${CC} == "cc" >>CC=clang >>.endif >>.if !defined(CXX) || ${CXX} == "c++" >>CXX=clang++ >>.endif >># Don't die on warnings >>NO_WERROR= >>WERROR= > >Try putting these lines in /etc/make.conf instead. Unfortunately, due >to the way src.conf is read, it isn't usable for the few cases we need >to disable clang's integrated assembler, using the '-no-integrated-as' >option. > > >>/tmp/cc-VUyvc6.s:6:1: warning: ignoring directive for now >>.intel_syntax noprefix >>^ > >I too am having trouble with buildworld >I switched back to standard /usr/bin/cc, but make buildworld stops here: > >c++ -O2 -pipe -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/include -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support -I. -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DLLVM_HOSTTRIPLE=\"i386-undermydesk-freebsd9.0\" -I/usr/obj/usr/src/tmp/legacy/usr/include -fno-exceptions -c /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/system_error.cpp >building static llvmsupport library >ranlib libllvmsupport.a >===> lib/clang/libllvmsystem (obj,depend,all,install) >cd: can't cd to /usr/src/lib/clang/libllvmsystem >*** Error code 2 > >Stop in /usr/src. >*** Error code 1 > >Stop in /usr/src. >*** Error code 1 > >Stop in /usr/src. > >Last night i deleted /usr/src and did a fresh cvsup >Still same problem Turns out that cvsup10.us.freebsd.org which i was using is not up to date. I'm using cvsup.us.freebsd.org now and am getting many new updates. >================================== >|| null@pozo.com || >|| Ph. (415) 681-6235 || >================================== -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From owner-freebsd-current@FreeBSD.ORG Tue Feb 22 16:19: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 B935B106566C; Tue, 22 Feb 2011 16:19:56 +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 8C1508FC12; Tue, 22 Feb 2011 16:19:56 +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 279AA46B03; Tue, 22 Feb 2011 11:19:56 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.10]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 552718A009; Tue, 22 Feb 2011 11:19:55 -0500 (EST) From: John Baldwin To: freebsd-arch@freebsd.org Date: Tue, 22 Feb 2011 07:45:45 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.4-CBSD-20110107; KDE/4.4.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201102220745.45695.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 22 Feb 2011 11:19:55 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=2.1 required=4.2 tests=BAYES_00,DATE_IN_PAST_03_06, MAY_BE_FORGED,RDNS_DYNAMIC autolearn=no version=3.3.1 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: freebsd-current@freebsd.org, grarpamp , freebsd-sysinstall@freebsd.org Subject: Re: FreeBSD Installer Roadmap 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, 22 Feb 2011 16:19:56 -0000 On Saturday, February 19, 2011 4:34:11 am grarpamp wrote: > Sysinstall is fine, as I'm sure any replacement will be. So I'll > just note a few things I'd like to see in any such replacement... > > 1 - I used install.cfg's on floppies to clone systems, a lot. Hands > on the box were needed with that. Operators skills were in question, > so having them use the dialog menus properly was a pain and often > resulted in non-zeroed disk or half built systems. And though all > else was cloned, it needed a separate .cfg for each box due > to: > > fqdn, gateway, ip/mask > interface - sometimes changed > root disk - sometimes changed > > Would have killed for a simple console shell script to ask those > questions of the operator, per machine. Actually, you can do that if you are a bit creative (add a few more tools to the mfsroot, and use the 'system' command in install.cfg to invoke a shell script that then generates a foo.cfg you later include via loadConfig, but I've covered that at multiple conferences by now). That said, I'm hopeful that the new installer will be more flexible in less hackish ways while letting you do things like PXE boot to a shell where you can use mfiutil to create a RAID-5 volume and then invoke the installer on that, etc. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Feb 22 16:20:00 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 7B079106564A for ; Tue, 22 Feb 2011 16: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 2DFD18FC12 for ; Tue, 22 Feb 2011 16:20:00 +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 B320946B03; Tue, 22 Feb 2011 11:19:59 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.10]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id BFA7C8A009; Tue, 22 Feb 2011 11:19:58 -0500 (EST) From: John Baldwin To: Ulrich =?iso-8859-1?q?Sp=F6rlein?= Date: Tue, 22 Feb 2011 09:44:22 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.4-CBSD-20110107; KDE/4.4.5; amd64; ; ) References: <201102151618.21934.jhb@freebsd.org> <20110218131731.GP65811@acme.spoerlein.net> In-Reply-To: <20110218131731.GP65811@acme.spoerlein.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201102220944.22511.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 22 Feb 2011 11:19:58 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=0.5 required=4.2 tests=BAYES_00,MAY_BE_FORGED, RDNS_DYNAMIC autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: FreeBSD current mailing list Subject: Re: Use meaningful directory prefixes in lib32 build 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, 22 Feb 2011 16:20:00 -0000 On Friday, February 18, 2011 8:17:31 am Ulrich Sp=F6rlein wrote: > On Tue, 15.02.2011 at 16:18:21 -0500, John Baldwin wrote: > > This patch adjusts the various lib32 targets to use a suitable DIRPRFX = so that=20 > > when lib32 builds certain areas of the tree the full path to those area= s shows=20 > > up in the make output: > >=20 > > Index: Makefile.inc1 > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > --- Makefile.inc1 (revision 218554) > > +++ Makefile.inc1 (working copy) > > @@ -457,36 +457,38 @@ build32: > > .for _t in obj depend all > > cd ${.CURDIR}/kerberos5/tools; \ > > MAKEOBJDIRPREFIX=3D${OBJTREE}/lib32 ${MAKE} SSP_CFLAGS=3D DESTDIR= =3D \ > > - ${_t} > > + DIRPRFX=3Dkerberos5/tools/ ${_t} > > .endfor > > .endif > > .for _t in obj includes > > - cd ${.CURDIR}/include; ${LIB32WMAKE} ${_t} > > - cd ${.CURDIR}/lib; ${LIB32WMAKE} ${_t} > > + cd ${.CURDIR}/include; ${LIB32WMAKE} DIRPRFX=3Dinclude/ ${_t} > > + cd ${.CURDIR}/lib; ${LIB32WMAKE} DIRPRFX=3Dlib/ ${_t} > > .if ${MK_CDDL} !=3D "no" > > - cd ${.CURDIR}/cddl/lib; ${LIB32WMAKE} ${_t} > > + cd ${.CURDIR}/cddl/lib; ${LIB32WMAKE} DIRPRFX=3Dcddl/lib/ ${_t} > > .endif > > - cd ${.CURDIR}/gnu/lib; ${LIB32WMAKE} ${_t} > > + cd ${.CURDIR}/gnu/lib; ${LIB32WMAKE} DIRPRFX=3Dgnu/lib/ ${_t} > > .if ${MK_CRYPT} !=3D "no" > > - cd ${.CURDIR}/secure/lib; ${LIB32WMAKE} ${_t} > > + cd ${.CURDIR}/secure/lib; ${LIB32WMAKE} DIRPRFX=3Dsecure/lib/ ${_t} > > .endif > > .if ${MK_KERBEROS} !=3D "no" > > - cd ${.CURDIR}/kerberos5/lib; ${LIB32WMAKE} ${_t} > > + cd ${.CURDIR}/kerberos5/lib; ${LIB32WMAKE} DIRPRFX=3Dkerberos5/lib ${= _t} > > .endif > > .endfor > > .for _dir in usr.bin/lex/lib > > - cd ${.CURDIR}/${_dir}; ${LIB32WMAKE} obj > > + cd ${.CURDIR}/${_dir}; ${LIB32WMAKE} DIRPRFX=3D${_dir}/ obj > > .endfor > > .for _dir in lib/ncurses/ncurses lib/ncurses/ncursesw lib/libmagic > > cd ${.CURDIR}/${_dir}; \ > > MAKEOBJDIRPREFIX=3D${OBJTREE}/lib32 ${MAKE} SSP_CFLAGS=3D DESTDIR= =3D \ > > - build-tools > > + DIRPRFX=3D${_dir}/ build-tools > > .endfor > > cd ${.CURDIR}; \ > > ${LIB32WMAKE} -f Makefile.inc1 libraries > > .for _t in obj depend all > > - cd ${.CURDIR}/libexec/rtld-elf; PROG=3Dld-elf32.so.1 ${LIB32WMAKE} ${= _t} > > - cd ${.CURDIR}/usr.bin/ldd; PROG=3Dldd32 ${LIB32WMAKE} ${_t} > > + cd ${.CURDIR}/libexec/rtld-elf; PROG=3Dld-elf32.so.1 ${LIB32WMAKE} \ > > + DIRPRFX=3Dlibexec/rtld-elf/ ${_t} > > + cd ${.CURDIR}/usr.bin/ldd; PROG=3Dldd32 ${LIB32WMAKE} \ > > + DIRPRFX=3Dusr.bin/ldd ${_t} > > .endfor > > =20 > > distribute32 install32: >=20 > I have no idea what DIRPRFX actually does, but will it also move the > actual OBJDIR location to something more sensible, or is only make's > (terminal) output affected? It just affects terminal output: bsd.subdir.mk: ${ECHODIR} "=3D=3D=3D> ${DIRPRFX}$${entry}.= ${MACHINE_ARCH} (${.TARGET:realinstall=3Dinstall})"; \ bsd.subdir.mk: ${ECHODIR} "=3D=3D=3D> ${DIRPRFX}$$entry ($= {.TARGET:realinstall=3Dinstall})"; \ bsd.subdir.mk: DIRPRFX=3D${DIRPRFX}$$edir/; \ =2D-=20 John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Feb 22 16:20: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 B06B8106566C for ; Tue, 22 Feb 2011 16:20:01 +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 7B9588FC1B for ; Tue, 22 Feb 2011 16:20:01 +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 272B746B32; Tue, 22 Feb 2011 11:20:01 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.10]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E00678A02A; Tue, 22 Feb 2011 11:19:59 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 22 Feb 2011 09:49:22 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.4-CBSD-20110107; KDE/4.4.5; amd64; ; ) References: <20110219185043.GA6573@felucia.tataz.chchile.org> In-Reply-To: <20110219185043.GA6573@felucia.tataz.chchile.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201102220949.22736.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 22 Feb 2011 11:20:00 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=0.5 required=4.2 tests=BAYES_00,MAY_BE_FORGED, RDNS_DYNAMIC autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Jeremie Le Hen Subject: Re: [RFC] Force stdio output streams to line-buffered mode 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, 22 Feb 2011 16:20:01 -0000 On Saturday, February 19, 2011 1:50:43 pm Jeremie Le Hen wrote: > Hi, > > I've been annoyed multiple time when running a command such like > iostat -x 1 | grep -v ad10 | cat -n > > The problem stems from two factors: > - grep's stdio sees that its stdout is not a terminal, so stdout is > full buffered and not line-buffered; > - iostat produces output too slowly so the aforementioned buffer takes > numerous seconds to be filled and flushed to the last command. > > This problems is not specific to FreeBSD, it is actually a consequence > of POSIX specification. I've checked this on Solaris and Linux. > > I've attached a small patch for stdio, so if the environment variable > STDIO_IOLBF is set, the output streams will be line-oriented by default. > iostat -x 1 | env STDIO_IOLBF=1 grep -v ad10 | cat -n > > Before send it as a PR, I would like to hear your comments about this, > especially: > - the variable name (no bikeshed please, I just ask this if there is a > naming convention I'm not aware of); > - the documentation: I've put a hint in stdio(3) manpage and put the > full explanation in setvbuf(3). Many people would find this useful I think. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Feb 22 16:26: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 D42DB1065672; Tue, 22 Feb 2011 16:26:34 +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 5DFE08FC0A; Tue, 22 Feb 2011 16:26:34 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.icecube.wisc.edu (Postfix) with ESMTP id C0AFB582CD; Tue, 22 Feb 2011 10:26:33 -0600 (CST) 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 NyKcAvK-9aEW; Tue, 22 Feb 2011 10:26:33 -0600 (CST) Received: from wanderer.tachypleus.net (i3-dhcp-172-16-223-170.icecube.wisc.edu [172.16.223.170]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 89C57582C3; Tue, 22 Feb 2011 10:26:33 -0600 (CST) Message-ID: <4D63E3B9.8030308@freebsd.org> Date: Tue, 22 Feb 2011 10:26:33 -0600 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20110103 Thunderbird/3.1.7 MIME-Version: 1.0 To: John Baldwin References: <201102220745.45695.jhb@freebsd.org> In-Reply-To: <201102220745.45695.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-sysinstall@freebsd.org, freebsd-current@freebsd.org, grarpamp , freebsd-arch@freebsd.org Subject: Re: FreeBSD Installer Roadmap 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, 22 Feb 2011 16:26:34 -0000 On 02/22/11 06:45, John Baldwin wrote: > On Saturday, February 19, 2011 4:34:11 am grarpamp wrote: >> Sysinstall is fine, as I'm sure any replacement will be. So I'll >> just note a few things I'd like to see in any such replacement... >> >> 1 - I used install.cfg's on floppies to clone systems, a lot. Hands >> on the box were needed with that. Operators skills were in question, >> so having them use the dialog menus properly was a pain and often >> resulted in non-zeroed disk or half built systems. And though all >> else was cloned, it needed a separate.cfg for each box due >> to: >> >> fqdn, gateway, ip/mask >> interface - sometimes changed >> root disk - sometimes changed >> >> Would have killed for a simple console shell script to ask those >> questions of the operator, per machine. > > Actually, you can do that if you are a bit creative (add a few more tools to > the mfsroot, and use the 'system' command in install.cfg to invoke a shell > script that then generates a foo.cfg you later include via loadConfig, but > I've covered that at multiple conferences by now). That said, I'm hopeful > that the new installer will be more flexible in less hackish ways while > letting you do things like PXE boot to a shell where you can use mfiutil to > create a RAID-5 volume and then invoke the installer on that, etc. This is something that I very explicitly built in to the design of bsdinstall. When the installer starts (as well as at several other points), you are offered an option to bring up a shell specifically to do things like this. Scripted installs are just shell scripts instead of a configuration file, so it is trivial to interleave complicated things like this. -Nathan From owner-freebsd-current@FreeBSD.ORG Tue Feb 22 16:30: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 3A996106566B; Tue, 22 Feb 2011 16:30:18 +0000 (UTC) (envelope-from yanegomi@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 9BFF58FC1D; Tue, 22 Feb 2011 16:30:17 +0000 (UTC) Received: by wwf26 with SMTP id 26so7239493wwf.31 for ; Tue, 22 Feb 2011 08:30:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=P5IgdAVharQoLPynXJhta2QzJDtC251IGl1pILSzP94=; b=mlTK/A0/DgdKafsWZvW4NTjehW1Wypc3ueA+wqbCTny5pc+3eGXnYmY53klY+0rVtm 0oJG3/xr1IrOw0OhBmd/2n0g4cdwG7dTCTt/fiUbrbugWUsJDQfVS2L0e/EU91KZjH08 Qm0DPFvGYhKxSUhIFlArvfSsvIJaOqdizZrTM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=a1DLws9uitgrrVS8Ln7EWfhu996EtEm2V2jlpI9zk3rrDrSorqYJLQMmwZ28XoIshp RMweJ15XXalFOgN+FpSYLs3LEpK2fY2G0wqBJKcju0kBln02RUQ9JRHCnyTC8MSNuEQB vLI7XN1eA79uTEkwfchDKXq5kRXBKtq3Incp4= MIME-Version: 1.0 Received: by 10.216.1.145 with SMTP id 17mr2673089wed.50.1298392175680; Tue, 22 Feb 2011 08:29:35 -0800 (PST) Received: by 10.216.15.74 with HTTP; Tue, 22 Feb 2011 08:29:35 -0800 (PST) In-Reply-To: References: Date: Tue, 22 Feb 2011 08:29:35 -0800 Message-ID: From: Garrett Cooper To: Eir Nym Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current , Dimitry Andric Subject: Re: Wow... (<-- blown away at performance) 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, 22 Feb 2011 16:30:18 -0000 On Tue, Feb 22, 2011 at 2:10 AM, Eir Nym wrote: > On 22 February 2011 11:15, Garrett Cooper wrote: >> =A0 =A0I don't know what to say, but r218938 screams with flash videos >> (native Linux speed). Not sure if it's the new binutils or if it's the >> new linuxulator patches, but I can run multiple instances of youtube >> in parallel (5 total with other miscellaneous flash animation) without >> it totally lagging out Firefox/X11, and it appears to close the >> instances of firefox properly now. Hopefully this version fares better >> than r218113 did (I think I hit a kernel bug after 2 weeks uptime, >> where my system just hardlocked for no apparent reason). >> =A0 =A0Anyhow, hope others have similar results. >> Cheers! >> -Garrett >> >> $ uname -a >> FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r218938M: >> Mon Feb 21 23:10:51 PST 2011 >> gcooper@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA =A0amd64 > > Which FlashPlayer version do you test? Adobe has made significant > performance changes in 10.2 (from 10.1). You can search for StageVideo > performance to learn more about. Youtube already use them since 10.2 > beta linux-f10-flashplugin-10.1r102.65 . The performance increases are claimed to be "up to 85%" on the Stage Video site, but I'm seeing a more than 200% increase (now it actually scales between multiple instances, instead of croaks with one instance, tiling up and down the screen when moving the window slider for instance or switching tabs). Besides, it seems like it needs external support from the video driver, and I'm not sure that that bridge exists in the linuxulator. Also, it looks like npviewer.bin still hangs to resources on until Firefox closes (or I kill it :)..), so something still needs to be resolved there, but that isn't a regression (it's acted that way for ages), and shouldn't be too hard to do. Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Tue Feb 22 17:15: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 5806E106566B; Tue, 22 Feb 2011 17:15:04 +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 232638FC16; Tue, 22 Feb 2011 17:15:04 +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 D315246B0C; Tue, 22 Feb 2011 12:15:03 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.10]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 45E0E8A009; Tue, 22 Feb 2011 12:15:03 -0500 (EST) From: John Baldwin To: Nathan Whitehorn Date: Tue, 22 Feb 2011 12:14:57 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.4-CBSD-20110107; KDE/4.4.5; amd64; ; ) References: <201102220745.45695.jhb@freebsd.org> <4D63E3B9.8030308@freebsd.org> In-Reply-To: <4D63E3B9.8030308@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201102221214.58073.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 22 Feb 2011 12:15:03 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=0.5 required=4.2 tests=BAYES_00,MAY_BE_FORGED, RDNS_DYNAMIC autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: freebsd-sysinstall@freebsd.org, freebsd-current@freebsd.org, grarpamp , freebsd-arch@freebsd.org Subject: Re: FreeBSD Installer Roadmap 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, 22 Feb 2011 17:15:04 -0000 On Tuesday, February 22, 2011 11:26:33 am Nathan Whitehorn wrote: > On 02/22/11 06:45, John Baldwin wrote: > > On Saturday, February 19, 2011 4:34:11 am grarpamp wrote: > >> Sysinstall is fine, as I'm sure any replacement will be. So I'll > >> just note a few things I'd like to see in any such replacement... > >> > >> 1 - I used install.cfg's on floppies to clone systems, a lot. Hands > >> on the box were needed with that. Operators skills were in question, > >> so having them use the dialog menus properly was a pain and often > >> resulted in non-zeroed disk or half built systems. And though all > >> else was cloned, it needed a separate.cfg for each box due > >> to: > >> > >> fqdn, gateway, ip/mask > >> interface - sometimes changed > >> root disk - sometimes changed > >> > >> Would have killed for a simple console shell script to ask those > >> questions of the operator, per machine. > > > > Actually, you can do that if you are a bit creative (add a few more tools to > > the mfsroot, and use the 'system' command in install.cfg to invoke a shell > > script that then generates a foo.cfg you later include via loadConfig, but > > I've covered that at multiple conferences by now). That said, I'm hopeful > > that the new installer will be more flexible in less hackish ways while > > letting you do things like PXE boot to a shell where you can use mfiutil to > > create a RAID-5 volume and then invoke the installer on that, etc. > > This is something that I very explicitly built in to the design of > bsdinstall. When the installer starts (as well as at several other > points), you are offered an option to bring up a shell specifically to > do things like this. Scripted installs are just shell scripts instead of > a configuration file, so it is trivial to interleave complicated things > like this. Yes, I should have worded it a bit differently in that I do actually think that is true from what little I have seen and the "hopeful" bit more refers to my being able to adopt it locally. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Feb 22 17:38: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 BAC9D106564A; Tue, 22 Feb 2011 17:38:34 +0000 (UTC) (envelope-from datastream.freecity@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 5EA908FC15; Tue, 22 Feb 2011 17:38:34 +0000 (UTC) Received: by gxk7 with SMTP id 7so1130233gxk.13 for ; Tue, 22 Feb 2011 09:38:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5wo3PipLQ0Cqql3o5ZINxnHHCZTiuDWZNZqQ0OmbC/A=; b=Zbg1Bl4xlrtevdlgysxdFWFltJxqr9nUj+b3wUiKBYOvkZrg96y8LdtoeWjJPUWOEs 7dTE+hFRzl7MmQ2PiwHlLGfhG4lRBS10uVlcTTSEr3GkvcysrCNympA66QCGGIaPZzBe DRGfMmk3w2ZArfPsSP+7paIbsqU4JkoAT/krs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=i34fOJZ7NjR2r/oTMzxsSrUDxUZrH7WIsXD7wPkyNZHwp9PPjN+tPyheIPG5AgQCV+ h0LiPnbME+jKVqIGoMgE7LXkarVNV40aVNLKiPIdoTBZTirgmSuyezqn5sYgiiAMOyRI gqxG/KUmBhw1opm2VnF7tYfsB52EkV0W4HnS0= MIME-Version: 1.0 Received: by 10.150.192.8 with SMTP id p8mr3647356ybf.405.1298396313453; Tue, 22 Feb 2011 09:38:33 -0800 (PST) Received: by 10.151.47.7 with HTTP; Tue, 22 Feb 2011 09:38:33 -0800 (PST) In-Reply-To: <201102221544.p1MFiDwv005627@pozo.com> References: <201102221544.p1MFiDwv005627@pozo.com> Date: Wed, 23 Feb 2011 01:38:33 +0800 Message-ID: From: "datastream datastream.freecity" To: Manfred Antar Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Olivier Smedts , freebsd-current@freebsd.org, Dimitry Andric Subject: Re: Can't buildworld since Clang update 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, 22 Feb 2011 17:38:34 -0000 In /etc/make.conf, I only add 'CFLAGS+=-fno-omit-frame-pointer'.And removed all files in /usr/obj. /usr/src sync with http://svn.freebsd.org/base/head. #make buildkernel .... MAKE=make sh /usr/src/sys/conf/newvers.sh G9laptop /usr/local/bin/svnversion clang -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 -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector vers.c clang: warning: argument unused during compilation: '-frename-registers' clang: warning: argument unused during compilation: '-mfpmath=387' linking kernel ld:/usr/src/sys/conf/ldscript.amd64:9: syntax error *** Error code 1 .... On Tue, Feb 22, 2011 at 11:44 PM, Manfred Antar wrote: > At 07:07 AM 2/21/2011, Dimitry Andric wrote: > >On 2011-02-21 11:33, Olivier Smedts wrote: > >>I can't buildworld with Clang since the last update. > >... > >>%cat /etc/src.conf > >>.if !defined(CC) || ${CC} == "cc" > >>CC=clang > >>.endif > >>.if !defined(CXX) || ${CXX} == "c++" > >>CXX=clang++ > >>.endif > >># Don't die on warnings > >>NO_WERROR= > >>WERROR= > > > >Try putting these lines in /etc/make.conf instead. Unfortunately, due > >to the way src.conf is read, it isn't usable for the few cases we need > >to disable clang's integrated assembler, using the '-no-integrated-as' > >option. > > > > > >>/tmp/cc-VUyvc6.s:6:1: warning: ignoring directive for now > >>.intel_syntax noprefix > >>^ > > > >I too am having trouble with buildworld > >I switched back to standard /usr/bin/cc, but make buildworld stops here: > > > >c++ -O2 -pipe > -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include > -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/include > -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support -I. > -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/include > -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS > -D__STDC_CONSTANT_MACROS -DLLVM_HOSTTRIPLE=\"i386-undermydesk-freebsd9.0\" > -I/usr/obj/usr/src/tmp/legacy/usr/include -fno-exceptions -c > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/system_error.cpp > >building static llvmsupport library > >ranlib libllvmsupport.a > >===> lib/clang/libllvmsystem (obj,depend,all,install) > >cd: can't cd to /usr/src/lib/clang/libllvmsystem > >*** Error code 2 > > > >Stop in /usr/src. > >*** Error code 1 > > > >Stop in /usr/src. > >*** Error code 1 > > > >Stop in /usr/src. > > > >Last night i deleted /usr/src and did a fresh cvsup > >Still same problem > > Turns out that cvsup10.us.freebsd.org which i was using is not up to date. > I'm using cvsup.us.freebsd.org now and am getting many new updates. > > > >================================== > >|| null@pozo.com || > >|| Ph. (415) 681-6235 || > >================================== > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Tue Feb 22 18:11: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 8F409106566B for ; Tue, 22 Feb 2011 18:11:00 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4D6A78FC1C for ; Tue, 22 Feb 2011 18:11:00 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:794d:2247:36f9:4086] (unknown [IPv6:2001:7b8:3a7:0:794d:2247:36f9:4086]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 80DDC5C59; Tue, 22 Feb 2011 19:10:59 +0100 (CET) Message-ID: <4D63FC39.3070705@FreeBSD.org> Date: Tue, 22 Feb 2011 19:11:05 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.15pre) Gecko/20110221 Lanikai/3.1.9pre MIME-Version: 1.0 To: "datastream datastream.freecity" References: <201102221544.p1MFiDwv005627@pozo.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Olivier Smedts , freebsd-current@freebsd.org Subject: Re: Can't buildworld since Clang update 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, 22 Feb 2011 18:11:00 -0000 On 2011-02-22 18:38, datastream datastream.freecity wrote: > In /etc/make.conf, I only add 'CFLAGS+=-fno-omit-frame-pointer'.And removed > all files in /usr/obj. /usr/src sync with http://svn.freebsd.org/base/head. > #make buildkernel Before you do "make buildkernel", always run "make buildworld", or at least "make kernel-toolchain". This ensures you have an up-to-date ld (and other tools) under /usr/obj. That said, these steps are normally only needed when e.g. binutils or other toolchain components have been upgraded. This has happened so seldom in the past few years, that people seem to have forgotten how bootstrapping works. :) From owner-freebsd-current@FreeBSD.ORG Tue Feb 22 19:22: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 562481065679; Tue, 22 Feb 2011 19:22:16 +0000 (UTC) (envelope-from eirnym@gmail.com) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by mx1.freebsd.org (Postfix) with ESMTP id A70FE8FC24; Tue, 22 Feb 2011 19:22:15 +0000 (UTC) Received: by bwz13 with SMTP id 13so3808382bwz.17 for ; Tue, 22 Feb 2011 11:22:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=I8PZ/o9tGbFFNLchsLy5vP4rxgGj3oMOx/Y2Pqtoy50=; b=s7T5KN2AvAnrrZC0IGc97VYTogHJnqMHuqSPto+I+IoOowEUvV84mFtKQCZn0KR2Fa xoSEe3LsPDVaSJythcc0bjEte5hzly9XW5sR7nnemxMBce6dp/HoWotnaEnGSqTy7P0C MOY1FVkuX0gLuCk/eVSLpZDr6X4msEpCSoSTc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=SDMGMjjra91akHKzJ85qhDTY3YszrI0djStRUClSMQMHboGiTR6i8lurSyFJyBuoo8 UvvXyznH9PJWkpz2I+F2A3eo0brT0tlrGnb/0lMFvix1OpAre/2g43Alm8uMWlfCxDhe /5/5oL/JdK26ekw96Be9c1fTo+t/3v7ETdMGs= Received: by 10.204.7.213 with SMTP id e21mr2846113bke.47.1298402534081; Tue, 22 Feb 2011 11:22:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.14.141 with HTTP; Tue, 22 Feb 2011 11:21:54 -0800 (PST) In-Reply-To: <4D63FC39.3070705@FreeBSD.org> References: <201102221544.p1MFiDwv005627@pozo.com> <4D63FC39.3070705@FreeBSD.org> From: Eir Nym Date: Tue, 22 Feb 2011 22:21:54 +0300 Message-ID: To: Dimitry Andric Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Olivier Smedts , "datastream datastream.freecity" , freebsd-current@freebsd.org Subject: Re: Can't buildworld since Clang update 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, 22 Feb 2011 19:22:16 -0000 On 22 February 2011 21:11, Dimitry Andric wrote: > On 2011-02-22 18:38, datastream datastream.freecity wrote: >> >> In /etc/make.conf, I only add 'CFLAGS+=3D-fno-omit-frame-pointer'.And >> removed >> all files in /usr/obj. /usr/src sync with >> http://svn.freebsd.org/base/head. >> #make buildkernel > > Before you do "make buildkernel", always run "make buildworld", or at > least "make kernel-toolchain". =C2=A0This ensures you have an up-to-date = ld > (and other tools) under /usr/obj. > > That said, these steps are normally only needed when e.g. binutils or > other toolchain components have been upgraded. =C2=A0This has happened so > seldom in the past few years, that people seem to have forgotten how > bootstrapping works. :) Nope! `make kernel-toolchain` is also important for cross-compile builds to be sure that anything is done. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > From owner-freebsd-current@FreeBSD.ORG Tue Feb 22 19:23:43 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 7B95A10656C0 for ; Tue, 22 Feb 2011 19:23:41 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@FreeBSD.org Date: Tue, 22 Feb 2011 14:23:28 -0500 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201102221423.30652.jkim@FreeBSD.org> Cc: Subject: binutils 2.17.50 and ctfconvert 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, 22 Feb 2011 19:23:43 -0000 Since binutils 2.17.50 import, WITH_CTF=1 & buildworld on amd64 stops like this: ===> lib/librt (all) cc -m32 -march=i686 -mmmx -msse -msse2 -mfancy-math-387 -DCOMPAT_32BIT -isystem /usr/obj/usr/src/lib32/usr/include/ -L/usr/obj/usr/src/lib32/usr/lib32 -B/usr/obj/usr/src/lib32/usr/lib32 -O2 -pipe -fno-omit-frame-pointer -I/usr/src/lib/librt/../libc/include -I/usr/src/lib/librt -fexceptions -Winline -Wall -g -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/lib/librt/aio.c cc -m32 -march=i686 -mmmx -msse -msse2 -mfancy-math-387 -DCOMPAT_32BIT -isystem /usr/obj/usr/src/lib32/usr/include/ -L/usr/obj/usr/src/lib32/usr/lib32 -B/usr/obj/usr/src/lib32/usr/lib32 -pg -O2 -pipe -fno-omit-frame-pointer -I/usr/src/lib/librt/../libc/include -I/usr/src/lib/librt -fexceptions -Winline -Wall -g -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/lib/librt/aio.c -o aio.po ctfconvert -L VERSION aio.po cc -m32 -march=i686 -mmmx -msse -msse2 -mfancy-math-387 -DCOMPAT_32BIT -isystem /usr/obj/usr/src/lib32/usr/include/ -L/usr/obj/usr/src/lib32/usr/lib32 -B/usr/obj/usr/src/lib32/usr/lib32 -fpic -DPIC -O2 -pipe -fno-omit-frame-pointer -I/usr/src/lib/librt/../libc/include -I/usr/src/lib/librt -fexceptions -Winline -Wall -g -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/lib/librt/aio.c -o aio.So ctfconvert -L VERSION aio.o cc -m32 -march=i686 -mmmx -msse -msse2 -mfancy-math-387 -DCOMPAT_32BIT -isystem /usr/obj/usr/src/lib32/usr/include/ -L/usr/obj/usr/src/lib32/usr/lib32 -B/usr/obj/usr/src/lib32/usr/lib32 -O2 -pipe -fno-omit-frame-pointer -I/usr/src/lib/librt/../libc/include -I/usr/src/lib/librt -fexceptions -Winline -Wall -g -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/lib/librt/mq.c ctfconvert -L VERSION aio.So cc -m32 -march=i686 -mmmx -msse -msse2 -mfancy-math-387 -DCOMPAT_32BIT -isystem /usr/obj/usr/src/lib32/usr/include/ -L/usr/obj/usr/src/lib32/usr/lib32 -B/usr/obj/usr/src/lib32/usr/lib32 -pg -O2 -pipe -fno-omit-frame-pointer -I/usr/src/lib/librt/../libc/include -I/usr/src/lib/librt -fexceptions -Winline -Wall -g -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/lib/librt/mq.c -o mq.po ctfconvert -L VERSION mq.o cc -m32 -march=i686 -mmmx -msse -msse2 -mfancy-math-387 -DCOMPAT_32BIT -isystem /usr/obj/usr/src/lib32/usr/include/ -L/usr/obj/usr/src/lib32/usr/lib32 -B/usr/obj/usr/src/lib32/usr/lib32 -fpic -DPIC -O2 -pipe -fno-omit-frame-pointer -I/usr/src/lib/librt/../libc/include -I/usr/src/lib/librt -fexceptions -Winline -Wall -g -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/lib/librt/mq.c -o mq.So ctfconvert -L VERSION mq.po cc -m32 -march=i686 -mmmx -msse -msse2 -mfancy-math-387 -DCOMPAT_32BIT -isystem /usr/obj/usr/src/lib32/usr/include/ -L/usr/obj/usr/src/lib32/usr/lib32 -B/usr/obj/usr/src/lib32/usr/lib32 -O2 -pipe -fno-omit-frame-pointer -I/usr/src/lib/librt/../libc/include -I/usr/src/lib/librt -fexceptions -Winline -Wall -g -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/lib/librt/sigev_thread.c ctfconvert -L VERSION mq.So cc -m32 -march=i686 -mmmx -msse -msse2 -mfancy-math-387 -DCOMPAT_32BIT -isystem /usr/obj/usr/src/lib32/usr/include/ -L/usr/obj/usr/src/lib32/usr/lib32 -B/usr/obj/usr/src/lib32/usr/lib32 -pg -O2 -pipe -fno-omit-frame-pointer -I/usr/src/lib/librt/../libc/include -I/usr/src/lib/librt -fexceptions -Winline -Wall -g -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/lib/librt/sigev_thread.c -o sigev_thread.po ctfconvert -L VERSION sigev_thread.o cc -m32 -march=i686 -mmmx -msse -msse2 -mfancy-math-387 -DCOMPAT_32BIT -isystem /usr/obj/usr/src/lib32/usr/include/ -L/usr/obj/usr/src/lib32/usr/lib32 -B/usr/obj/usr/src/lib32/usr/lib32 -fpic -DPIC -O2 -pipe -fno-omit-frame-pointer -I/usr/src/lib/librt/../libc/include -I/usr/src/lib/librt -fexceptions -Winline -Wall -g -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/lib/librt/sigev_thread.c -o sigev_thread.So ctfconvert -L VERSION sigev_thread.po cc -m32 -march=i686 -mmmx -msse -msse2 -mfancy-math-387 -DCOMPAT_32BIT -isystem /usr/obj/usr/src/lib32/usr/include/ -L/usr/obj/usr/src/lib32/usr/lib32 -B/usr/obj/usr/src/lib32/usr/lib32 -O2 -pipe -fno-omit-frame-pointer -I/usr/src/lib/librt/../libc/include -I/usr/src/lib/librt -fexceptions -Winline -Wall -g -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/lib/librt/timer.c ctfconvert -L VERSION timer.o cc -m32 -march=i686 -mmmx -msse -msse2 -mfancy-math-387 -DCOMPAT_32BIT -isystem /usr/obj/usr/src/lib32/usr/include/ -L/usr/obj/usr/src/lib32/usr/lib32 -B/usr/obj/usr/src/lib32/usr/lib32 -pg -O2 -pipe -fno-omit-frame-pointer -I/usr/src/lib/librt/../libc/include -I/usr/src/lib/librt -fexceptions -Winline -Wall -g -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/lib/librt/timer.c -o timer.po ctfconvert -L VERSION timer.po cc -m32 -march=i686 -mmmx -msse -msse2 -mfancy-math-387 -DCOMPAT_32BIT -isystem /usr/obj/usr/src/lib32/usr/include/ -L/usr/obj/usr/src/lib32/usr/lib32 -B/usr/obj/usr/src/lib32/usr/lib32 -fpic -DPIC -O2 -pipe -fno-omit-frame-pointer -I/usr/src/lib/librt/../libc/include -I/usr/src/lib/librt -fexceptions -Winline -Wall -g -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/lib/librt/timer.c -o timer.So ctfconvert -L VERSION sigev_thread.So ctfconvert -L VERSION timer.So building static rt library building profiled rt library ranlib librt_p.a ranlib librt.a building shared library librt.so.1 BFD: aio.So: invalid SHT_GROUP entry BFD: aio.So: invalid SHT_GROUP entry BFD: aio.So: no group info for section .text.__i686.get_pc_thunk.cx BFD: aio.So: no group info for section .text.__i686.get_pc_thunk.bx BFD: aio.So: unknown [0] section `' in group [__i686.get_pc_thunk.cx] BFD: aio.So: unknown [0] section `' in group [__i686.get_pc_thunk.bx] nm: aio.So: File format not recognized BFD: mq.So: invalid SHT_GROUP entry BFD: mq.So: no group info for section .text.__i686.get_pc_thunk.bx BFD: mq.So: unknown [0] section `' in group [__i686.get_pc_thunk.bx] nm: mq.So: File format not recognized BFD: sigev_thread.So: invalid SHT_GROUP entry BFD: sigev_thread.So: no group info for section .text.__i686.get_pc_thunk.bx BFD: sigev_thread.So: unknown [0] section `' in group [__i686.get_pc_thunk.bx] nm: sigev_thread.So: File format not recognized BFD: timer.So: invalid SHT_GROUP entry BFD: timer.So: no group info for section .text.__i686.get_pc_thunk.bx BFD: timer.So: unknown [0] section `' in group [__i686.get_pc_thunk.bx] nm: timer.So: File format not recognized /usr/obj/usr/src/tmp/usr/bin/ld: timer.So: invalid SHT_GROUP entry /usr/obj/usr/src/tmp/usr/bin/ld: timer.So: no group info for section .text.__i686.get_pc_thunk.bx /usr/obj/usr/src/tmp/usr/bin/ld: timer.So: unknown [0] section `' in group [__i686.get_pc_thunk.bx] timer.So: file not recognized: File format not recognized *** Error code 1 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error Google found NetBSD has a similar looking PR but it is not exactly the same: http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=42986 Note I have '-g' and it only happens at build32. 64-bit library was okay. Does anyone know what went wrong? Thanks, Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Tue Feb 22 20:12: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 50A81106566C for ; Tue, 22 Feb 2011 20:12:38 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout027.mac.com (asmtpout027.mac.com [17.148.16.102]) by mx1.freebsd.org (Postfix) with ESMTP id 366768FC14 for ; Tue, 22 Feb 2011 20:12:37 +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 asmtp027.mac.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) with ESMTPSA id <0LH1009N0C4NF370@asmtp027.mac.com> for freebsd-current@freebsd.org; Tue, 22 Feb 2011 12:12:24 -0800 (PST) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2011-02-22_07:2011-02-22, 2011-02-22, 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-1102220121 From: Chuck Swiger In-reply-to: <4D638050.2010906@netasq.com> Date: Tue, 22 Feb 2011 12:12:23 -0800 Message-id: <6676A005-27F6-4D0D-9F57-2AB624392F89@mac.com> References: <4D6291A5.4050206@netasq.com> <8C8FE4A5-F031-466A-9CB8-46D79EEA280D@mac.com> <4D638050.2010906@netasq.com> To: Jerome Flesch X-Mailer: Apple Mail (2.1082) Cc: freebsd-current@freebsd.org Subject: Re: Process timing issue 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, 22 Feb 2011 20:12:38 -0000 On Feb 22, 2011, at 1:22 AM, Jerome Flesch wrote: >> A scheduler quantum of 10ms (or HZ=100) is a common granularity; probably some other process got the CPU and your timer process didn't run until the next or some later scheduler tick. If you are maxing out the available CPU by running many "openssl speed" tasks, then this behavior is more-or-less expected. >> > > We did most of our tests with kern.hz=1000 (the default FreeBSD value as far as I know) and we also tried with kern.hz=2000 and kern.hz=10000. It didn't change a thing. For a long time kern.hz=100 was the default; more recent versions have switched to kern.hz=1000, which is beneficial for minimizing latency for things like ipfw/dummynet processing, but also involve greater scheduler overhead. kern.hz=10000 is likely to reduce performance and may have odd effects upon certain kernel timers. > Also, we are talking about a process not being scheduled for more than 100ms with only 1 instance of openssl on the same CPU core. Even with a scheduler quantum of 10ms, I find that worrying :/ It depends on what else the machine is doing. Gathering some data via acct/sa might be informative, as you might be running some other tasks via cron or whatever which your testing isn't expecting. > We expected both processes (the test program and openssl) to have each half the CPU time and being scheduled quite often (at least once each 10ms). According to the output of our test program, it works fine for most of the calls to clock_gettime(), but from time to time (about 1 loop in 200000 on my computer), we have a latency pike (>= 100ms). > > Thing is, these pikes wouldn't worry us much if they wouldn't last longer than 1s, but they do on some occasions. Also, are you sure that you don't have ntpdate or ntpd or something else adjusting your system clock underneath you...? Regards, -- -Chuck From owner-freebsd-current@FreeBSD.ORG Tue Feb 22 20:31:34 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 693001065672; Tue, 22 Feb 2011 20:31:34 +0000 (UTC) Date: Tue, 22 Feb 2011 20:31:34 +0000 From: Alexander Best To: Garrett Cooper Message-ID: <20110222203134.GA53262@freebsd.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Cc: Eir Nym , Dimitry Andric , FreeBSD Current Subject: Re: Wow... (<-- blown away at performance) 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, 22 Feb 2011 20:31:34 -0000 On Tue Feb 22 11, Garrett Cooper wrote: > On Tue, Feb 22, 2011 at 2:10 AM, Eir Nym wrote: > > On 22 February 2011 11:15, Garrett Cooper wrote: > >> I don't know what to say, but r218938 screams with flash videos > >> (native Linux speed). Not sure if it's the new binutils or if it's the > >> new linuxulator patches, but I can run multiple instances of youtube > >> in parallel (5 total with other miscellaneous flash animation) without > >> it totally lagging out Firefox/X11, and it appears to close the > >> instances of firefox properly now. Hopefully this version fares better > >> than r218113 did (I think I hit a kernel bug after 2 weeks uptime, > >> where my system just hardlocked for no apparent reason). > >> Anyhow, hope others have similar results. > >> Cheers! > >> -Garrett > >> > >> $ uname -a > >> FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r218938M: > >> Mon Feb 21 23:10:51 PST 2011 > >> gcooper@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 > > > > Which FlashPlayer version do you test? Adobe has made significant > > performance changes in 10.2 (from 10.1). You can search for StageVideo > > performance to learn more about. Youtube already use them since 10.2 > > beta > > linux-f10-flashplugin-10.1r102.65 . The performance increases are > claimed to be "up to 85%" on the Stage Video site, but I'm seeing a > more than 200% increase (now it actually scales between multiple > instances, instead of croaks with one instance, tiling up and down the > screen when moving the window slider for instance or switching tabs). > Besides, it seems like it needs external support from the video > driver, and I'm not sure that that bridge exists in the linuxulator. > Also, it looks like npviewer.bin still hangs to resources on until > Firefox closes (or I kill it :)..), so something still needs to be > resolved there, but that isn't a regression (it's acted that way for > ages), and shouldn't be too hard to do. i think the problem with npviewer.bin having to be killed by hand is a futex issue in combination with a high number of threads. this is the output of a test from darren hart's futex test suite under freebsd 9.0: futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=100000000 threads=1 Result: 18622 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=100000000 threads=2 Result: 15469 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=100000000 threads=3 Result: 12713 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=100000000 threads=4 Result: 12247 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=100000000 threads=5 Result: 11814 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=100000000 threads=6 Result: 13468 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=100000000 threads=8 Result: 12061 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=100000000 threads=10 Result: 12854 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=100000000 threads=12 Result: 12999 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=100000000 threads=16 Result: 12402 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=100000000 threads=24 Result: 9815 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=100000000 threads=32 Result: 8518 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=100000000 threads=64 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=100000000 threads=128 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=100000000 threads=256 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=100000000 threads=512 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=100000000 threads=1024 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR cheers. alex > Thanks, > -Garrett -- a13x From owner-freebsd-current@FreeBSD.ORG Tue Feb 22 20:26: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 1CFB0106566B for ; Tue, 22 Feb 2011 20:26:50 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate.funkthat.com [70.36.235.232]) by mx1.freebsd.org (Postfix) with ESMTP id DD81D8FC1D for ; Tue, 22 Feb 2011 20:26:49 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id p1MJvERg073860 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Feb 2011 11:57:14 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id p1MJvEWT073859; Tue, 22 Feb 2011 11:57:14 -0800 (PST) (envelope-from jmg) Date: Tue, 22 Feb 2011 11:57:13 -0800 From: John-Mark Gurney To: Jerome Flesch Message-ID: <20110222195713.GW66284@funkthat.com> Mail-Followup-To: Jerome Flesch , Chuck Swiger , freebsd-current@freebsd.org References: <4D6291A5.4050206@netasq.com> <8C8FE4A5-F031-466A-9CB8-46D79EEA280D@mac.com> <4D638050.2010906@netasq.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D638050.2010906@netasq.com> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Tue, 22 Feb 2011 11:57:14 -0800 (PST) X-Mailman-Approved-At: Tue, 22 Feb 2011 20:37:17 +0000 Cc: freebsd-current@freebsd.org Subject: Re: Process timing issue 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, 22 Feb 2011 20:26:51 -0000 Jerome Flesch wrote this message on Tue, Feb 22, 2011 at 10:22 +0100: > We expected both processes (the test program and openssl) to have each > half the CPU time and being scheduled quite often (at least once each > 10ms). According to the output of our test program, it works fine for > most of the calls to clock_gettime(), but from time to time (about 1 > loop in 200000 on my computer), we have a latency pike (>= 100ms). Are you sure there isn't a cron task or something else that is suddenly waking up, causing a large CPU spike? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Tue Feb 22 20:46: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 E8543106564A for ; Tue, 22 Feb 2011 20:46:25 +0000 (UTC) (envelope-from eirnym@gmail.com) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by mx1.freebsd.org (Postfix) with ESMTP id 726358FC1D for ; Tue, 22 Feb 2011 20:46:25 +0000 (UTC) Received: by bwz13 with SMTP id 13so3903894bwz.17 for ; Tue, 22 Feb 2011 12:46:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=l46GS8scArmEaet5rjkO9WJhts2Gy07/a9e5p547LEc=; b=PD6WOpVLfvR5+MKLA3ahSQoVqesp3RK4ix1yrpwao03+8gbc1pwn8veV/4LAKTr3ZG QaR1JobcaH2jeQV/P1jUaAJStBoUD1bK/rWcLSTVarlJ1YCoRV0RuF/ivn63DRjAb34z WCdQhQNtxO5UKNvvUFaDt+TSTnMTy3Xm18Lzk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=EYDw9Izrg8BsU9735Sqb7pjDPtB52MCgop2ovy/X6cx6KuQda6Qwg4ibiIU41uFfkR AFNLJnA1QMefUOIoNZ+H810tX5tOnbXwNHL5yjPPdOZ9pSrXJZVgvzOxEtTUdyv0Pqte int7fcB62J7sJoFMvkGz8Ksfq7iO7Mb79GYKw= Received: by 10.204.52.136 with SMTP id i8mr2928036bkg.74.1298407584103; Tue, 22 Feb 2011 12:46:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.14.141 with HTTP; Tue, 22 Feb 2011 12:46:04 -0800 (PST) In-Reply-To: References: From: Eir Nym Date: Tue, 22 Feb 2011 23:46:04 +0300 Message-ID: To: Andrey Smagin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: current repeateble crash in 2 places 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, 22 Feb 2011 20:46:26 -0000 On 21 February 2011 13:26, Andrey Smagin wrote: > today current > crash with loaded mpd5 > > 1st place: > ipwf_chk > ipfw_check_hook > pfil_run_hooks > ip_output > tcp_output =C2=A0 =C2=A0 =C2=A0repeated > tcp_mtudisc =C2=A0 =C2=A0~20 times > tcp_ctlinput > icmp_input > ip_input > swi_net > intr_event_execute_handlers > > 2nd place > flowtable_lookup > flowteble_lookup_mbuf > ip_output > tcp_output =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ~ repeated > tcp_mtudisc =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A020 times > tcp_ctlinput > icmp_input > ip_input > netisr_dispatch_src > ng_iface_rcvdata > ng_apply_item =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0repeated > ng_snd_item =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3 > ng_pppoe_rcvdata_ether =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 times > ng_apply_item > ng_snd_item > ether_demux > ether_input > em_rxeof > em_msix_rx > inthr_event_execute_handlers > ithread_loop > > What does it mean? > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > From owner-freebsd-current@FreeBSD.ORG Tue Feb 22 21:12: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 9E277106566C; Tue, 22 Feb 2011 21:12:03 +0000 (UTC) (envelope-from jamesbrandongooch@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 016608FC1A; Tue, 22 Feb 2011 21:12:02 +0000 (UTC) Received: by wwf26 with SMTP id 26so7531277wwf.31 for ; Tue, 22 Feb 2011 13:12:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=4M6Uu8hAC1zO/eeQ56agzoDJtyOrcWEW4H/qxblQJ04=; b=TW3iGBQWPO/gBQDN4lvWtMdiyoHomO44yNSlFDCRsCCuPMRRLovClkkBD1mg5tJ/K6 gZV8U+uJl/fyxDuMpTJthrjomH6xm2QRtxLiRbVLl/k9nr7kPLB+GrD9X3ocApuKFWNW VC+B/YFSha7g/D12+d5diWJUBUThhhAftGhXM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=vqJEdxFFszEI+Ha84A3VF5DpwXUOEnQmuyeKDEN+XNV7x3hxFly8i23xpW/P7E9jmG AE0bOstm/wMlvp451J6H5K96RpXV3PyskIfMv9QCYeTddrplM1LGB9x8tFJJ7tY311YU PakyI4Ph2C6P0sv+lQdYVzx+LS/VIss9+1gYA= MIME-Version: 1.0 Received: by 10.216.181.199 with SMTP id l49mr3625571wem.68.1298407507561; Tue, 22 Feb 2011 12:45:07 -0800 (PST) Received: by 10.216.244.130 with HTTP; Tue, 22 Feb 2011 12:45:07 -0800 (PST) In-Reply-To: <20110222203134.GA53262@freebsd.org> References: <20110222203134.GA53262@freebsd.org> Date: Tue, 22 Feb 2011 14:45:07 -0600 Message-ID: From: Brandon Gooch To: Alexander Best Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Garrett Cooper , Eir Nym , Dimitry Andric , FreeBSD Current Subject: Re: Wow... (<-- blown away at performance) 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, 22 Feb 2011 21:12:03 -0000 On Tue, Feb 22, 2011 at 2:31 PM, Alexander Best wrote= : > On Tue Feb 22 11, Garrett Cooper wrote: >> On Tue, Feb 22, 2011 at 2:10 AM, Eir Nym wrote: >> > On 22 February 2011 11:15, Garrett Cooper wrote: >> >> =A0 =A0I don't know what to say, but r218938 screams with flash video= s >> >> (native Linux speed). Not sure if it's the new binutils or if it's th= e >> >> new linuxulator patches, but I can run multiple instances of youtube >> >> in parallel (5 total with other miscellaneous flash animation) withou= t >> >> it totally lagging out Firefox/X11, and it appears to close the >> >> instances of firefox properly now. Hopefully this version fares bette= r >> >> than r218113 did (I think I hit a kernel bug after 2 weeks uptime, >> >> where my system just hardlocked for no apparent reason). >> >> =A0 =A0Anyhow, hope others have similar results. >> >> Cheers! >> >> -Garrett >> >> >> >> $ uname -a >> >> FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r218938M: >> >> Mon Feb 21 23:10:51 PST 2011 >> >> gcooper@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA =A0amd64 >> > >> > Which FlashPlayer version do you test? Adobe has made significant >> > performance changes in 10.2 (from 10.1). You can search for StageVideo >> > performance to learn more about. Youtube already use them since 10.2 >> > beta >> >> =A0 =A0 linux-f10-flashplugin-10.1r102.65 . The performance increases ar= e >> claimed to be "up to 85%" on the Stage Video site, but I'm seeing a >> more than 200% increase (now it actually scales between multiple >> instances, instead of croaks with one instance, tiling up and down the >> screen when moving the window slider for instance or switching tabs). >> Besides, it seems like it needs external support from the video >> driver, and I'm not sure that that bridge exists in the linuxulator. >> =A0 =A0 Also, it looks like npviewer.bin still hangs to resources on unt= il >> Firefox closes (or I kill it :)..), so something still needs to be >> resolved there, but that isn't a regression (it's acted that way for >> ages), and shouldn't be too hard to do. > > i think the problem with npviewer.bin having to be killed by hand is a fu= tex > issue in combination with a high number of threads. this is the output of= a > test from darren hart's futex test suite under freebsd 9.0: > > futex_wait: Measure FUTEX_WAIT operations per second > =A0 =A0 =A0 =A0Arguments: iterations=3D100000000 threads=3D1 > Result: 18622 Kiter/s > futex_wait: Measure FUTEX_WAIT operations per second > =A0 =A0 =A0 =A0Arguments: iterations=3D100000000 threads=3D2 > Result: 15469 Kiter/s > futex_wait: Measure FUTEX_WAIT operations per second > =A0 =A0 =A0 =A0Arguments: iterations=3D100000000 threads=3D3 > Result: 12713 Kiter/s > futex_wait: Measure FUTEX_WAIT operations per second > =A0 =A0 =A0 =A0Arguments: iterations=3D100000000 threads=3D4 > Result: 12247 Kiter/s > futex_wait: Measure FUTEX_WAIT operations per second > =A0 =A0 =A0 =A0Arguments: iterations=3D100000000 threads=3D5 > Result: 11814 Kiter/s > futex_wait: Measure FUTEX_WAIT operations per second > =A0 =A0 =A0 =A0Arguments: iterations=3D100000000 threads=3D6 > Result: 13468 Kiter/s > futex_wait: Measure FUTEX_WAIT operations per second > =A0 =A0 =A0 =A0Arguments: iterations=3D100000000 threads=3D8 > Result: 12061 Kiter/s > futex_wait: Measure FUTEX_WAIT operations per second > =A0 =A0 =A0 =A0Arguments: iterations=3D100000000 threads=3D10 > Result: 12854 Kiter/s > futex_wait: Measure FUTEX_WAIT operations per second > =A0 =A0 =A0 =A0Arguments: iterations=3D100000000 threads=3D12 > Result: 12999 Kiter/s > futex_wait: Measure FUTEX_WAIT operations per second > =A0 =A0 =A0 =A0Arguments: iterations=3D100000000 threads=3D16 > Result: 12402 Kiter/s > futex_wait: Measure FUTEX_WAIT operations per second > =A0 =A0 =A0 =A0Arguments: iterations=3D100000000 threads=3D24 > Result: 9815 Kiter/s > futex_wait: Measure FUTEX_WAIT operations per second > =A0 =A0 =A0 =A0Arguments: iterations=3D100000000 threads=3D32 > Result: 8518 Kiter/s > futex_wait: Measure FUTEX_WAIT operations per second > =A0 =A0 =A0 =A0Arguments: iterations=3D100000000 threads=3D64 > =A0 =A0 =A0 =A0ERROR: Resource temporarily unavailable: pthread_create > Result: ERROR > futex_wait: Measure FUTEX_WAIT operations per second > =A0 =A0 =A0 =A0Arguments: iterations=3D100000000 threads=3D128 > =A0 =A0 =A0 =A0ERROR: Resource temporarily unavailable: pthread_create > Result: ERROR > futex_wait: Measure FUTEX_WAIT operations per second > =A0 =A0 =A0 =A0Arguments: iterations=3D100000000 threads=3D256 > =A0 =A0 =A0 =A0ERROR: Resource temporarily unavailable: pthread_create > Result: ERROR > futex_wait: Measure FUTEX_WAIT operations per second > =A0 =A0 =A0 =A0Arguments: iterations=3D100000000 threads=3D512 > =A0 =A0 =A0 =A0ERROR: Resource temporarily unavailable: pthread_create > Result: ERROR > futex_wait: Measure FUTEX_WAIT operations per second > =A0 =A0 =A0 =A0Arguments: iterations=3D100000000 threads=3D1024 > =A0 =A0 =A0 =A0ERROR: Resource temporarily unavailable: pthread_create > Result: ERROR > > cheers. > alex Have you found any method or workaround to mitigate this issue? -Brandon From owner-freebsd-current@FreeBSD.ORG Tue Feb 22 21:13: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 B1E071065693; Tue, 22 Feb 2011 21:13:46 +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 720BD8FC15; Tue, 22 Feb 2011 21:13:46 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.icecube.wisc.edu (Postfix) with ESMTP id BE684582D8; Tue, 22 Feb 2011 15:13:45 -0600 (CST) 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 ddZm2ZCMKBJ9; Tue, 22 Feb 2011 15:13:45 -0600 (CST) Received: from wanderer.tachypleus.net (i3-dhcp-172-16-223-197.icecube.wisc.edu [172.16.223.197]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 87D85582D7; Tue, 22 Feb 2011 15:13:45 -0600 (CST) Message-ID: <4D642709.6080604@freebsd.org> Date: Tue, 22 Feb 2011 15:13:45 -0600 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20110103 Thunderbird/3.1.7 MIME-Version: 1.0 To: John Baldwin References: <201102220745.45695.jhb@freebsd.org> <4D63E3B9.8030308@freebsd.org> <201102221214.58073.jhb@freebsd.org> In-Reply-To: <201102221214.58073.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org, freebsd-current@freebsd.org, freebsd-sysinstall@freebsd.org, grarpamp Subject: Re: FreeBSD Installer Roadmap 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, 22 Feb 2011 21:13:46 -0000 On 02/22/11 11:14, John Baldwin wrote: > On Tuesday, February 22, 2011 11:26:33 am Nathan Whitehorn wrote: >> On 02/22/11 06:45, John Baldwin wrote: >>> On Saturday, February 19, 2011 4:34:11 am grarpamp wrote: >>>> Sysinstall is fine, as I'm sure any replacement will be. So I'll >>>> just note a few things I'd like to see in any such replacement... >>>> >>>> 1 - I used install.cfg's on floppies to clone systems, a lot. Hands >>>> on the box were needed with that. Operators skills were in question, >>>> so having them use the dialog menus properly was a pain and often >>>> resulted in non-zeroed disk or half built systems. And though all >>>> else was cloned, it needed a separate.cfg for each box due >>>> to: >>>> >>>> fqdn, gateway, ip/mask >>>> interface - sometimes changed >>>> root disk - sometimes changed >>>> >>>> Would have killed for a simple console shell script to ask those >>>> questions of the operator, per machine. >>> >>> Actually, you can do that if you are a bit creative (add a few more tools to >>> the mfsroot, and use the 'system' command in install.cfg to invoke a shell >>> script that then generates a foo.cfg you later include via loadConfig, but >>> I've covered that at multiple conferences by now). That said, I'm hopeful >>> that the new installer will be more flexible in less hackish ways while >>> letting you do things like PXE boot to a shell where you can use mfiutil to >>> create a RAID-5 volume and then invoke the installer on that, etc. >> >> This is something that I very explicitly built in to the design of >> bsdinstall. When the installer starts (as well as at several other >> points), you are offered an option to bring up a shell specifically to >> do things like this. Scripted installs are just shell scripts instead of >> a configuration file, so it is trivial to interleave complicated things >> like this. > > Yes, I should have worded it a bit differently in that I do actually think > that is true from what little I have seen and the "hopeful" bit more refers > to my being able to adopt it locally. > Ah, understood. Speaking of which, there is a new amd64 snapshot ISO with bsdinstall on it (an i386 ISO should follow in the next day or so): http://people.freebsd.org/~nwhitehorn/bsdinstall-amd64-20110222.iso.bz2 This is more or less the planned final form of the installer and layout of the install media, so I would very much appreciate testing at this point. Pending a small patch to the distributeworld target currently under review, this will be followed by patches to the release Makefile to change the default installer to bsdinstall in -CURRENT. Barring any objections, I hope to have that second patch in the tree by mid-March. -Nathan From owner-freebsd-current@FreeBSD.ORG Tue Feb 22 21:50:36 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 19E4510656A7; Tue, 22 Feb 2011 21:50:36 +0000 (UTC) Date: Tue, 22 Feb 2011 21:50:36 +0000 From: Alexander Best To: Brandon Gooch Message-ID: <20110222215036.GA66303@freebsd.org> References: <20110222203134.GA53262@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Cc: Garrett Cooper , Eir Nym , Dimitry Andric , FreeBSD Current Subject: Re: Wow... (<-- blown away at performance) 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, 22 Feb 2011 21:50:36 -0000 On Tue Feb 22 11, Brandon Gooch wrote: > On Tue, Feb 22, 2011 at 2:31 PM, Alexander Best wrote: > > On Tue Feb 22 11, Garrett Cooper wrote: > >> On Tue, Feb 22, 2011 at 2:10 AM, Eir Nym wrote: > >> > On 22 February 2011 11:15, Garrett Cooper wrote: > >> >> I don't know what to say, but r218938 screams with flash videos > >> >> (native Linux speed). Not sure if it's the new binutils or if it's the > >> >> new linuxulator patches, but I can run multiple instances of youtube > >> >> in parallel (5 total with other miscellaneous flash animation) without > >> >> it totally lagging out Firefox/X11, and it appears to close the > >> >> instances of firefox properly now. Hopefully this version fares better > >> >> than r218113 did (I think I hit a kernel bug after 2 weeks uptime, > >> >> where my system just hardlocked for no apparent reason). > >> >> Anyhow, hope others have similar results. > >> >> Cheers! > >> >> -Garrett > >> >> > >> >> $ uname -a > >> >> FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r218938M: > >> >> Mon Feb 21 23:10:51 PST 2011 > >> >> gcooper@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 > >> > > >> > Which FlashPlayer version do you test? Adobe has made significant > >> > performance changes in 10.2 (from 10.1). You can search for StageVideo > >> > performance to learn more about. Youtube already use them since 10.2 > >> > beta > >> > >> linux-f10-flashplugin-10.1r102.65 . The performance increases are > >> claimed to be "up to 85%" on the Stage Video site, but I'm seeing a > >> more than 200% increase (now it actually scales between multiple > >> instances, instead of croaks with one instance, tiling up and down the > >> screen when moving the window slider for instance or switching tabs). > >> Besides, it seems like it needs external support from the video > >> driver, and I'm not sure that that bridge exists in the linuxulator. > >> Also, it looks like npviewer.bin still hangs to resources on until > >> Firefox closes (or I kill it :)..), so something still needs to be > >> resolved there, but that isn't a regression (it's acted that way for > >> ages), and shouldn't be too hard to do. > > > > i think the problem with npviewer.bin having to be killed by hand is a futex > > issue in combination with a high number of threads. this is the output of a > > test from darren hart's futex test suite under freebsd 9.0: > > > > futex_wait: Measure FUTEX_WAIT operations per second > > Arguments: iterations=100000000 threads=1 > > Result: 18622 Kiter/s > > futex_wait: Measure FUTEX_WAIT operations per second > > Arguments: iterations=100000000 threads=2 > > Result: 15469 Kiter/s > > futex_wait: Measure FUTEX_WAIT operations per second > > Arguments: iterations=100000000 threads=3 > > Result: 12713 Kiter/s > > futex_wait: Measure FUTEX_WAIT operations per second > > Arguments: iterations=100000000 threads=4 > > Result: 12247 Kiter/s > > futex_wait: Measure FUTEX_WAIT operations per second > > Arguments: iterations=100000000 threads=5 > > Result: 11814 Kiter/s > > futex_wait: Measure FUTEX_WAIT operations per second > > Arguments: iterations=100000000 threads=6 > > Result: 13468 Kiter/s > > futex_wait: Measure FUTEX_WAIT operations per second > > Arguments: iterations=100000000 threads=8 > > Result: 12061 Kiter/s > > futex_wait: Measure FUTEX_WAIT operations per second > > Arguments: iterations=100000000 threads=10 > > Result: 12854 Kiter/s > > futex_wait: Measure FUTEX_WAIT operations per second > > Arguments: iterations=100000000 threads=12 > > Result: 12999 Kiter/s > > futex_wait: Measure FUTEX_WAIT operations per second > > Arguments: iterations=100000000 threads=16 > > Result: 12402 Kiter/s > > futex_wait: Measure FUTEX_WAIT operations per second > > Arguments: iterations=100000000 threads=24 > > Result: 9815 Kiter/s > > futex_wait: Measure FUTEX_WAIT operations per second > > Arguments: iterations=100000000 threads=32 > > Result: 8518 Kiter/s > > futex_wait: Measure FUTEX_WAIT operations per second > > Arguments: iterations=100000000 threads=64 > > ERROR: Resource temporarily unavailable: pthread_create > > Result: ERROR > > futex_wait: Measure FUTEX_WAIT operations per second > > Arguments: iterations=100000000 threads=128 > > ERROR: Resource temporarily unavailable: pthread_create > > Result: ERROR > > futex_wait: Measure FUTEX_WAIT operations per second > > Arguments: iterations=100000000 threads=256 > > ERROR: Resource temporarily unavailable: pthread_create > > Result: ERROR > > futex_wait: Measure FUTEX_WAIT operations per second > > Arguments: iterations=100000000 threads=512 > > ERROR: Resource temporarily unavailable: pthread_create > > Result: ERROR > > futex_wait: Measure FUTEX_WAIT operations per second > > Arguments: iterations=100000000 threads=1024 > > ERROR: Resource temporarily unavailable: pthread_create > > Result: ERROR > > > > cheers. > > alex > > Have you found any method or workaround to mitigate this issue? no. i've increased the kern.threads.max_threads_per_proc value, but that had no effect. so it seems to be a bug in the linuxulator's futex implementation. cheers. alex > > -Brandon -- a13x From owner-freebsd-current@FreeBSD.ORG Tue Feb 22 22:18: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 621E4106564A; Tue, 22 Feb 2011 22:18:34 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from fallbackmx06.syd.optusnet.com.au (fallbackmx06.syd.optusnet.com.au [211.29.132.8]) by mx1.freebsd.org (Postfix) with ESMTP id 4F81D8FC0C; Tue, 22 Feb 2011 22:18:33 +0000 (UTC) Received: from mail36.syd.optusnet.com.au (mail36.syd.optusnet.com.au [211.29.133.76]) by fallbackmx06.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p1MKvt6Z014932; Wed, 23 Feb 2011 07:57:55 +1100 Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail36.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p1MKvoTf025265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Feb 2011 07:57:52 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.4/8.14.4) with ESMTP id p1MKvgeY034606; Wed, 23 Feb 2011 07:57:42 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.4/8.14.4/Submit) id p1MKvfPe034605; Wed, 23 Feb 2011 07:57:41 +1100 (EST) (envelope-from peter) Date: Wed, 23 Feb 2011 07:57:41 +1100 From: Peter Jeremy To: Devin Teske Message-ID: <20110222205741.GA34103@server.vk2pj.dyndns.org> References: <4D35CFFB.3010302@freebsd.org> <201102211612.51233.josh@tcbug.org> <201102220103.20158.josh@tcbug.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vtzGhvizbBRQ85DL" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org, freebsd-sysinstall@freebsd.org, freebsd-arch@freebsd.org Subject: Re: FreeBSD Installer Roadmap 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, 22 Feb 2011 22:18:34 -0000 --vtzGhvizbBRQ85DL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2011-Feb-22 02:50:54 -0800, Devin Teske wrote: >That's the operative word here ("supports"). Lord help us when that >changes to "requires" (that is to say, if/when the FreeBSD kernel >becomes legacy-free with respect to supporting fdisk/disklabel >partitioned disks). When that does come, it will probably be driven by BIOS and hardware vendors dropping support for MBR. Current disks are at the upper limit of what MBR can be support (and that's after several revamps of MBR). Since GPT already provides a superior feature set without MBR's limits, the next step will be to just drop MBR support. And when it does come, FreeBSD needs to be ready with an installer that can cope with non-MBR disks. >We've yet to see a "must have" technology that would require us to >shun sysinstall (as explained earlier, we have no desire whatsoever >to boot from ZFS, gmirror, geli, GPT, or anything else missing from >sysinstall). Whilst _you_ might not be interested, lots of other people _are_ interested in using these features - I personally use a mixture of gmirror, GPT and ZFS root on different systems. Why should other people be forced to avoid these features just because you don't use them? FreeBSD's installer should support the same features as FreeBSD itself for consistency. >pedestals... why would we ever need >8GB for the operating system? >all production data is being stored on enterprise class devices such >as the NEC-D210, and being backed up with tapes such as LTO; Not everyone uses FreeBSD in the same environment as you. >We're no stranger to putting even the Operating System on Life >Support for as long as it takes for our customers to bolster their >budgets for an integrated upgrade strategy. Given that you've already said you are staying with FreeBSD 4.11, why are you at all worried about FreeBSD using a new installed in FreeBSD 9 to support features that don't exist in FreeBSD 4? FreeBSD is primarily a volunteer project. Whilst you may be an expert on the innards of sysinstall, this seems to be a rare skill and no-one (including yourself) has stepped up and offered to add the missing functionality to sysinstall. It's worth noting that the original author of sysinstall considered it to be a temporary stop-gap until something better was developed. The increasing disparity between FreeBSD's features, together with the opaqueness of sysinstall have led to a replacement being developed. No-one is forcing you to replace sysinstall on your legacy systems but if you want sysinstall to remain the default installer, you are going to need to add the missing functionality to it. --=20 Peter Jeremy --vtzGhvizbBRQ85DL Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iEYEARECAAYFAk1kI0UACgkQ/opHv/APuIcwwQCgwLVkfv7xsgCYQMsSfiaco7uY 0PwAn1umUCZhxR6ah5Os+zL7HuBpFCik =5low -----END PGP SIGNATURE----- --vtzGhvizbBRQ85DL-- From owner-freebsd-current@FreeBSD.ORG Tue Feb 22 22:33:14 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 990841065673; Tue, 22 Feb 2011 22:33:14 +0000 (UTC) Date: Tue, 22 Feb 2011 22:33:14 +0000 From: Alexander Best To: Brandon Gooch Message-ID: <20110222223314.GA72748@freebsd.org> References: <20110222203134.GA53262@freebsd.org> <20110222215036.GA66303@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20110222215036.GA66303@freebsd.org> Cc: Garrett Cooper , Eir Nym , Dimitry Andric , FreeBSD Current Subject: Re: Wow... (<-- blown away at performance) 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, 22 Feb 2011 22:33:14 -0000 On Tue Feb 22 11, Alexander Best wrote: > On Tue Feb 22 11, Brandon Gooch wrote: > > On Tue, Feb 22, 2011 at 2:31 PM, Alexander Best wrote: > > > On Tue Feb 22 11, Garrett Cooper wrote: > > >> On Tue, Feb 22, 2011 at 2:10 AM, Eir Nym wrote: > > >> > On 22 February 2011 11:15, Garrett Cooper wrote: > > >> >> I don't know what to say, but r218938 screams with flash videos > > >> >> (native Linux speed). Not sure if it's the new binutils or if it's the > > >> >> new linuxulator patches, but I can run multiple instances of youtube > > >> >> in parallel (5 total with other miscellaneous flash animation) without > > >> >> it totally lagging out Firefox/X11, and it appears to close the > > >> >> instances of firefox properly now. Hopefully this version fares better > > >> >> than r218113 did (I think I hit a kernel bug after 2 weeks uptime, > > >> >> where my system just hardlocked for no apparent reason). > > >> >> Anyhow, hope others have similar results. > > >> >> Cheers! > > >> >> -Garrett > > >> >> > > >> >> $ uname -a > > >> >> FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r218938M: > > >> >> Mon Feb 21 23:10:51 PST 2011 > > >> >> gcooper@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 > > >> > > > >> > Which FlashPlayer version do you test? Adobe has made significant > > >> > performance changes in 10.2 (from 10.1). You can search for StageVideo > > >> > performance to learn more about. Youtube already use them since 10.2 > > >> > beta > > >> > > >> linux-f10-flashplugin-10.1r102.65 . The performance increases are > > >> claimed to be "up to 85%" on the Stage Video site, but I'm seeing a > > >> more than 200% increase (now it actually scales between multiple > > >> instances, instead of croaks with one instance, tiling up and down the > > >> screen when moving the window slider for instance or switching tabs). > > >> Besides, it seems like it needs external support from the video > > >> driver, and I'm not sure that that bridge exists in the linuxulator. > > >> Also, it looks like npviewer.bin still hangs to resources on until > > >> Firefox closes (or I kill it :)..), so something still needs to be > > >> resolved there, but that isn't a regression (it's acted that way for > > >> ages), and shouldn't be too hard to do. > > > > > > i think the problem with npviewer.bin having to be killed by hand is a futex > > > issue in combination with a high number of threads. this is the output of a > > > test from darren hart's futex test suite under freebsd 9.0: > > > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=100000000 threads=1 > > > Result: 18622 Kiter/s > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=100000000 threads=2 > > > Result: 15469 Kiter/s > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=100000000 threads=3 > > > Result: 12713 Kiter/s > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=100000000 threads=4 > > > Result: 12247 Kiter/s > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=100000000 threads=5 > > > Result: 11814 Kiter/s > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=100000000 threads=6 > > > Result: 13468 Kiter/s > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=100000000 threads=8 > > > Result: 12061 Kiter/s > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=100000000 threads=10 > > > Result: 12854 Kiter/s > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=100000000 threads=12 > > > Result: 12999 Kiter/s > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=100000000 threads=16 > > > Result: 12402 Kiter/s > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=100000000 threads=24 > > > Result: 9815 Kiter/s > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=100000000 threads=32 > > > Result: 8518 Kiter/s > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=100000000 threads=64 > > > ERROR: Resource temporarily unavailable: pthread_create > > > Result: ERROR > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=100000000 threads=128 > > > ERROR: Resource temporarily unavailable: pthread_create > > > Result: ERROR > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=100000000 threads=256 > > > ERROR: Resource temporarily unavailable: pthread_create > > > Result: ERROR > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=100000000 threads=512 > > > ERROR: Resource temporarily unavailable: pthread_create > > > Result: ERROR > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=100000000 threads=1024 > > > ERROR: Resource temporarily unavailable: pthread_create > > > Result: ERROR > > > > > > cheers. > > > alex > > > > Have you found any method or workaround to mitigate this issue? i did a ktrace -i and linux_kdump run and the results are quite interesting. with only 1 thread linux_sys_futex() *never* failed with EAGAIN. starting with 2 threads however i'm seeing an increasing number of linux_sys_futex() failures (all with EAGAIN). the overhead is quite massive. linux_kdump > /tmp/futex-failure produced 941 megs of output. doing grep -v "futex_wait" futex-failure > futex-grep produces an output of 192K!! so it's quite obvious that the futex_wait stuff is responsible for causing massive activity, due to the constant failures and retries. here's a bit of output: 32126 futex_wait RET linux_sys_futex -1 errno 35 Resource temporarily unavailable 32125 futex_wait RET linux_sys_futex 0 32126 futex_wait CALL linux_sys_futex(0xffffdb5c,0x81,0x1,0,0,0) 32126 futex_wait RET linux_sys_futex 0 32126 futex_wait CALL linux_sys_futex(0xffffdb5c,0x81,0x1,0,0,0) 32125 futex_wait CALL linux_sys_futex(0xffffdb5c,0x80,0x2,0,0,0) 32126 futex_wait RET linux_sys_futex 0 32125 futex_wait RET linux_sys_futex -1 errno 35 Resource temporarily unavailable 32126 futex_wait CALL linux_sys_futex(0xffffdb5c,0x80,0x2,0,0,0) 32125 futex_wait CALL linux_sys_futex(0xffffdb5c,0x81,0x1,0,0,0) 32126 futex_wait RET linux_sys_futex -1 errno 35 Resource temporarily unavailable 32125 futex_wait RET linux_sys_futex 0 32126 futex_wait CALL linux_sys_futex(0xffffdb5c,0x81,0x1,0,0,0) 32126 futex_wait RET linux_sys_futex 0 32126 futex_wait CALL linux_sys_futex(0xffffdb5c,0x80,0x2,0,0,0) 32125 futex_wait CALL linux_sys_futex(0xffffdb5c,0x81,0x1,0,0,0) 32126 futex_wait RET linux_sys_futex -1 errno 35 Resource temporarily unavailable 32125 futex_wait RET linux_sys_futex 0 32126 futex_wait CALL linux_sys_futex(0xffffdb5c,0x81,0x1,0,0,0) 32126 futex_wait RET linux_sys_futex 0 32126 futex_wait CALL linux_sys_futex(0xffffdb5c,0x80,0x2,0,0,0) 32125 futex_wait CALL linux_sys_futex(0xffffdb5c,0x81,0x1,0,0,0) 32126 futex_wait RET linux_sys_futex -1 errno 35 Resource temporarily unavailable 32125 futex_wait RET linux_sys_futex 0 32126 futex_wait CALL linux_sys_futex(0xffffdb5c,0x81,0x1,0,0,0) 32126 futex_wait RET linux_sys_futex 0 32126 futex_wait CALL linux_sys_futex(0xffffdb5c,0x81,0x1,0,0,0) 32125 futex_wait CALL linux_sys_futex(0xffffdb5c,0x80,0x2,0,0,0) 32126 futex_wait RET linux_sys_futex 0 32125 futex_wait RET linux_sys_futex -1 errno 35 Resource temporarily unavailable 32125 futex_wait CALL linux_sys_futex(0xffffdb5c,0x81,0x1,0,0,0) 32126 futex_wait CALL linux_sys_futex(0xffffdb5c,0x80,0x2,0,0,0) 32125 futex_wait RET linux_sys_futex 0 32126 futex_wait RET linux_sys_futex -1 errno 35 Resource temporarily unavailable 32126 futex_wait CALL linux_sys_futex(0xffffdb5c,0x80,0x2,0,0,0) 32125 futex_wait CALL linux_sys_futex(0xffffdb5c,0x81,0x1,0,0,0) 32126 futex_wait RET linux_sys_futex -1 errno 35 Resource temporarily unavailable 32125 futex_wait RET linux_sys_futex 0 32126 futex_wait CALL linux_sys_futex(0xffffdb5c,0x81,0x1,0,0,0) 32126 futex_wait RET linux_sys_futex 0 32126 futex_wait CALL linux_sys_futex(0xffffdb5c,0x80,0x2,0,0,0) 32125 futex_wait CALL linux_sys_futex(0xffffdb5c,0x81,0x1,0,0,0) 32126 futex_wait RET linux_sys_futex -1 errno 35 Resource temporarily unavailable 32125 futex_wait RET linux_sys_futex 0 32126 futex_wait CALL linux_sys_futex(0xffffdb5c,0x81,0x1,0,0,0) 32126 futex_wait RET linux_sys_futex 0 32126 futex_wait CALL linux_sys_futex(0xffffdb5c,0x80,0x2,0,0,0) 32125 futex_wait CALL linux_sys_futex(0xffffdb5c,0x81,0x1,0,0,0) 32126 futex_wait RET linux_sys_futex -1 errno 35 Resource temporarily unavailable 32125 futex_wait RET linux_sys_futex 0 32126 futex_wait CALL linux_sys_futex(0xffffdb5c,0x81,0x1,0,0,0) 32126 futex_wait RET linux_sys_futex 0 32126 futex_wait CALL linux_sys_futex(0xffffdb5c,0x80,0x2,0,0,0) 32125 futex_wait CALL linux_sys_futex(0xffffdb5c,0x81,0x1,0,0,0) 32126 futex_wait RET linux_sys_futex -1 errno 35 Resource temporarily unavailable cheers. alex > > no. i've increased the kern.threads.max_threads_per_proc value, but that had > no effect. so it seems to be a bug in the linuxulator's futex implementation. > > cheers. > alex > > > > > -Brandon > > -- > a13x -- a13x From owner-freebsd-current@FreeBSD.ORG Wed Feb 23 01:08: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 546011065673 for ; Wed, 23 Feb 2011 01:08:22 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id DBFCF8FC16 for ; Wed, 23 Feb 2011 01:08:21 +0000 (UTC) Received: by eyg7 with SMTP id 7so1284495eyg.13 for ; Tue, 22 Feb 2011 17:08:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=DQApVtOiWNDpVIVpn6q3ksT0vH8R35ZUBoOnCDNDO+s=; b=lsWYcV5CFvjn83/81u4ddOMmeUhIRPW74FYVD1RCDngQjN64xeOVnX98nZc8VZ6F/L egAg17PQZ5tUHBG1ZQw/fnMNk2EzjBZoB30PEv2jwOGt56JycyRTQY/HwvU1ZS4hwl1K CoZapY+VoyBN1PCqyHXtsumjU6plgmYVJW+Og= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=sRtoBb3yJBSsyxsOP2UkAqBe5yICdOl0R6wvfQcse2NZd3mZGB0NgdYS5YB55vXhhK /uMlCfZC2QR4NQmVEK7ce799aaE1pNZPgT2LJJLbexQtMbNghw+yNQFVLyXDp1ajZJIH 4klZ7bE4PyKtn/5EzQjzEhvy8vcAIMY7cLHNM= MIME-Version: 1.0 Received: by 10.213.26.20 with SMTP id b20mr67447ebc.55.1298423300729; Tue, 22 Feb 2011 17:08:20 -0800 (PST) Received: by 10.213.20.135 with HTTP; Tue, 22 Feb 2011 17:08:20 -0800 (PST) In-Reply-To: <20110222195713.GW66284@funkthat.com> References: <4D6291A5.4050206@netasq.com> <8C8FE4A5-F031-466A-9CB8-46D79EEA280D@mac.com> <4D638050.2010906@netasq.com> <20110222195713.GW66284@funkthat.com> Date: Tue, 22 Feb 2011 20:08:20 -0500 Message-ID: From: Ryan Stone To: Jerome Flesch , Chuck Swiger , freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: John-Mark Gurney Subject: Re: Process timing issue 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, 23 Feb 2011 01:08:22 -0000 To debug weird scheduling issues I find it helpful to start by looking at a schedgraph. schedgraph is a tool that can display a graphical representation of what the scheduler was doing over a small slice of time. The one downside is that you have to recompile your kernel to get the hooks that collect the necessary data, but it sounds like your problem is pretty easy to reproduce and so that shouldn't be a big problem. To enable the hooks, put the following in your kernel conf: options KTR options KTR_COMPILE=KTR_SCHED options KTR_MASK=KTR_SCHED options KTR_ENTIRES=(128*1024) Then rebuild and install the new kernel. Next, run your test. The instant that your test has detected the long delay, set the sysctl debug.ktr.mask to 0. The scheduler hooks record data into a ring buffer, so the interesting data can be flushed out within seconds. Clearing that sysctl will stop any further events from being logged, which means that the interesting data will stay there until you go and collect it. You can get the raw data by redirecting the output of "ktrdump -ct" into a file. Then from any machine with a graphical interface(FreeBSD with X installed, Windows, Mac, whatever) and python installed, run: $ python schedgraph.py /path/to/ktrdump/output You can get schedgraph.py from /usr/src/tools/sched. If you want to collect the data again, set the sysctl debug.ktr.mask back to 0x20000000 to restart gathering scheduler data. Ryan From owner-freebsd-current@FreeBSD.ORG Wed Feb 23 01:31:10 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id C0AB01065673; Wed, 23 Feb 2011 01:31:10 +0000 (UTC) Date: Wed, 23 Feb 2011 01:31:10 +0000 From: Alexander Best To: Brandon Gooch Message-ID: <20110223013110.GA92284@freebsd.org> References: <20110222203134.GA53262@freebsd.org> <20110222215036.GA66303@freebsd.org> <20110222223314.GA72748@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20110222223314.GA72748@freebsd.org> Cc: Garrett Cooper , Eir Nym , Dimitry Andric , FreeBSD Current Subject: Re: Wow... (<-- blown away at performance) 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, 23 Feb 2011 01:31:10 -0000 On Tue Feb 22 11, Alexander Best wrote: > On Tue Feb 22 11, Alexander Best wrote: > > On Tue Feb 22 11, Brandon Gooch wrote: > > > On Tue, Feb 22, 2011 at 2:31 PM, Alexander Best wrote: > > > > On Tue Feb 22 11, Garrett Cooper wrote: > > > >> On Tue, Feb 22, 2011 at 2:10 AM, Eir Nym wrote: > > > >> > On 22 February 2011 11:15, Garrett Cooper wrote: > > > >> >> I don't know what to say, but r218938 screams with flash videos > > > >> >> (native Linux speed). Not sure if it's the new binutils or if it's the > > > >> >> new linuxulator patches, but I can run multiple instances of youtube > > > >> >> in parallel (5 total with other miscellaneous flash animation) without > > > >> >> it totally lagging out Firefox/X11, and it appears to close the > > > >> >> instances of firefox properly now. Hopefully this version fares better > > > >> >> than r218113 did (I think I hit a kernel bug after 2 weeks uptime, > > > >> >> where my system just hardlocked for no apparent reason). > > > >> >> Anyhow, hope others have similar results. > > > >> >> Cheers! > > > >> >> -Garrett > > > >> >> > > > >> >> $ uname -a > > > >> >> FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r218938M: > > > >> >> Mon Feb 21 23:10:51 PST 2011 > > > >> >> gcooper@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 > > > >> > > > > >> > Which FlashPlayer version do you test? Adobe has made significant > > > >> > performance changes in 10.2 (from 10.1). You can search for StageVideo > > > >> > performance to learn more about. Youtube already use them since 10.2 > > > >> > beta > > > >> > > > >> linux-f10-flashplugin-10.1r102.65 . The performance increases are > > > >> claimed to be "up to 85%" on the Stage Video site, but I'm seeing a > > > >> more than 200% increase (now it actually scales between multiple > > > >> instances, instead of croaks with one instance, tiling up and down the > > > >> screen when moving the window slider for instance or switching tabs). > > > >> Besides, it seems like it needs external support from the video > > > >> driver, and I'm not sure that that bridge exists in the linuxulator. > > > >> Also, it looks like npviewer.bin still hangs to resources on until > > > >> Firefox closes (or I kill it :)..), so something still needs to be > > > >> resolved there, but that isn't a regression (it's acted that way for > > > >> ages), and shouldn't be too hard to do. > > > > > > > > i think the problem with npviewer.bin having to be killed by hand is a futex > > > > issue in combination with a high number of threads. this is the output of a > > > > test from darren hart's futex test suite under freebsd 9.0: > > > > > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=1 > > > > Result: 18622 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=2 > > > > Result: 15469 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=3 > > > > Result: 12713 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=4 > > > > Result: 12247 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=5 > > > > Result: 11814 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=6 > > > > Result: 13468 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=8 > > > > Result: 12061 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=10 > > > > Result: 12854 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=12 > > > > Result: 12999 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=16 > > > > Result: 12402 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=24 > > > > Result: 9815 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=32 > > > > Result: 8518 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=64 > > > > ERROR: Resource temporarily unavailable: pthread_create > > > > Result: ERROR > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=128 > > > > ERROR: Resource temporarily unavailable: pthread_create > > > > Result: ERROR > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=256 > > > > ERROR: Resource temporarily unavailable: pthread_create > > > > Result: ERROR > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=512 > > > > ERROR: Resource temporarily unavailable: pthread_create > > > > Result: ERROR > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=1024 > > > > ERROR: Resource temporarily unavailable: pthread_create > > > > Result: ERROR > > > > > > > > cheers. > > > > alex > > > > > > Have you found any method or workaround to mitigate this issue? > > i did a ktrace -i and linux_kdump run and the results are quite interesting. > with only 1 thread linux_sys_futex() *never* failed with EAGAIN. starting > with 2 threads however i'm seeing an increasing number of linux_sys_futex() > failures (all with EAGAIN). it seems however that the cause for the tests with 64-1024 threads to fail is linux_mmap(): 10070 futex_wait CALL linux_clone(0x3d0f00,0xfc20d4b4,0xfc20dbd8,0xffffd9bc,0xfc20dbd8) 10122 futex_wait RET linux_fork 0 10122 futex_wait CALL linux_set_robust_list(0xf820dbe0,0xc) 10122 futex_wait RET linux_set_robust_list 0 10122 futex_wait CALL linux_sys_futex(0xffffdb48,0x80,0,0,0,0) 10070 futex_wait RET linux_clone 10123/0x278b 10123 futex_wait RET linux_fork 0 10070 futex_wait CALL linux_mmap2(0,0x4000000,0x3,0x20022,0xffffffff,0) 10123 futex_wait CALL linux_set_robust_list(0xfc20dbe0,0xc) 10123 futex_wait RET linux_set_robust_list 0 10123 futex_wait CALL linux_sys_futex(0xffffdb48,0x80,0,0,0,0) 10070 futex_wait RET linux_mmap2 -1 errno 12 Cannot allocate memory 10070 futex_wait CALL write(0x2,0xffffb2c8,0x44) 10070 futex_wait GIO fd 2 wrote 68 bytes " \^[[1;33mERROR\^[[0m: Resource temporarily unavailable: pthread_create " 10070 futex_wait RET write 68/0x44 10070 futex_wait CALL linux_sys_futex(0xffffdb48,0x81,0x7fffffff,0,0,0) cheers. alex > > the overhead is quite massive. linux_kdump > /tmp/futex-failure produced 941 > megs of output. doing > grep -v "futex_wait" futex-failure > futex-grep > produces an output of 192K!! so it's quite obvious that the futex_wait stuff > is responsible for causing massive activity, due to the constant failures and > retries. > > here's a bit of output: > > 32126 futex_wait RET linux_sys_futex -1 errno 35 Resource temporarily unavailable > 32125 futex_wait RET linux_sys_futex 0 > 32126 futex_wait CALL linux_sys_futex(0xffffdb5c,0x81,0x1,0,0,0) > 32126 futex_wait RET linux_sys_futex 0 > 32126 futex_wait CALL linux_sys_futex(0xffffdb5c,0x81,0x1,0,0,0) > 32125 futex_wait CALL linux_sys_futex(0xffffdb5c,0x80,0x2,0,0,0) > 32126 futex_wait RET linux_sys_futex 0 > 32125 futex_wait RET linux_sys_futex -1 errno 35 Resource temporarily unavailable > 32126 futex_wait CALL linux_sys_futex(0xffffdb5c,0x80,0x2,0,0,0) > 32125 futex_wait CALL linux_sys_futex(0xffffdb5c,0x81,0x1,0,0,0) > 32126 futex_wait RET linux_sys_futex -1 errno 35 Resource temporarily unavailable > 32125 futex_wait RET linux_sys_futex 0 > 32126 futex_wait CALL linux_sys_futex(0xffffdb5c,0x81,0x1,0,0,0) > 32126 futex_wait RET linux_sys_futex 0 > 32126 futex_wait CALL linux_sys_futex(0xffffdb5c,0x80,0x2,0,0,0) > 32125 futex_wait CALL linux_sys_futex(0xffffdb5c,0x81,0x1,0,0,0) > 32126 futex_wait RET linux_sys_futex -1 errno 35 Resource temporarily unavailable > 32125 futex_wait RET linux_sys_futex 0 > 32126 futex_wait CALL linux_sys_futex(0xffffdb5c,0x81,0x1,0,0,0) > 32126 futex_wait RET linux_sys_futex 0 > 32126 futex_wait CALL linux_sys_futex(0xffffdb5c,0x80,0x2,0,0,0) > 32125 futex_wait CALL linux_sys_futex(0xffffdb5c,0x81,0x1,0,0,0) > 32126 futex_wait RET linux_sys_futex -1 errno 35 Resource temporarily unavailable > 32125 futex_wait RET linux_sys_futex 0 > 32126 futex_wait CALL linux_sys_futex(0xffffdb5c,0x81,0x1,0,0,0) > 32126 futex_wait RET linux_sys_futex 0 > 32126 futex_wait CALL linux_sys_futex(0xffffdb5c,0x81,0x1,0,0,0) > 32125 futex_wait CALL linux_sys_futex(0xffffdb5c,0x80,0x2,0,0,0) > 32126 futex_wait RET linux_sys_futex 0 > 32125 futex_wait RET linux_sys_futex -1 errno 35 Resource temporarily unavailable > 32125 futex_wait CALL linux_sys_futex(0xffffdb5c,0x81,0x1,0,0,0) > 32126 futex_wait CALL linux_sys_futex(0xffffdb5c,0x80,0x2,0,0,0) > 32125 futex_wait RET linux_sys_futex 0 > 32126 futex_wait RET linux_sys_futex -1 errno 35 Resource temporarily unavailable > 32126 futex_wait CALL linux_sys_futex(0xffffdb5c,0x80,0x2,0,0,0) > 32125 futex_wait CALL linux_sys_futex(0xffffdb5c,0x81,0x1,0,0,0) > 32126 futex_wait RET linux_sys_futex -1 errno 35 Resource temporarily unavailable > 32125 futex_wait RET linux_sys_futex 0 > 32126 futex_wait CALL linux_sys_futex(0xffffdb5c,0x81,0x1,0,0,0) > 32126 futex_wait RET linux_sys_futex 0 > 32126 futex_wait CALL linux_sys_futex(0xffffdb5c,0x80,0x2,0,0,0) > 32125 futex_wait CALL linux_sys_futex(0xffffdb5c,0x81,0x1,0,0,0) > 32126 futex_wait RET linux_sys_futex -1 errno 35 Resource temporarily unavailable > 32125 futex_wait RET linux_sys_futex 0 > 32126 futex_wait CALL linux_sys_futex(0xffffdb5c,0x81,0x1,0,0,0) > 32126 futex_wait RET linux_sys_futex 0 > 32126 futex_wait CALL linux_sys_futex(0xffffdb5c,0x80,0x2,0,0,0) > 32125 futex_wait CALL linux_sys_futex(0xffffdb5c,0x81,0x1,0,0,0) > 32126 futex_wait RET linux_sys_futex -1 errno 35 Resource temporarily unavailable > 32125 futex_wait RET linux_sys_futex 0 > 32126 futex_wait CALL linux_sys_futex(0xffffdb5c,0x81,0x1,0,0,0) > 32126 futex_wait RET linux_sys_futex 0 > 32126 futex_wait CALL linux_sys_futex(0xffffdb5c,0x80,0x2,0,0,0) > 32125 futex_wait CALL linux_sys_futex(0xffffdb5c,0x81,0x1,0,0,0) > 32126 futex_wait RET linux_sys_futex -1 errno 35 Resource temporarily unavailable > > cheers. > alex > > > > > no. i've increased the kern.threads.max_threads_per_proc value, but that had > > no effect. so it seems to be a bug in the linuxulator's futex implementation. > > > > cheers. > > alex > > > > > > > > -Brandon > > > > -- > > a13x > > -- > a13x -- a13x From owner-freebsd-current@FreeBSD.ORG Wed Feb 23 02:00:10 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 08F071065670; Wed, 23 Feb 2011 02:00:10 +0000 (UTC) Date: Wed, 23 Feb 2011 02:00:08 +0000 From: Alexander Best To: Brandon Gooch Message-ID: <20110223020008.GA94832@freebsd.org> References: <20110222203134.GA53262@freebsd.org> <20110222215036.GA66303@freebsd.org> <20110222223314.GA72748@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20110222223314.GA72748@freebsd.org> Cc: Garrett Cooper , Eir Nym , Dimitry Andric , FreeBSD Current Subject: Re: Wow... (<-- blown away at performance) 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, 23 Feb 2011 02:00:10 -0000 On Tue Feb 22 11, Alexander Best wrote: > On Tue Feb 22 11, Alexander Best wrote: > > On Tue Feb 22 11, Brandon Gooch wrote: > > > On Tue, Feb 22, 2011 at 2:31 PM, Alexander Best wrote: > > > > On Tue Feb 22 11, Garrett Cooper wrote: > > > >> On Tue, Feb 22, 2011 at 2:10 AM, Eir Nym wrote: > > > >> > On 22 February 2011 11:15, Garrett Cooper wrote: > > > >> >> I don't know what to say, but r218938 screams with flash videos > > > >> >> (native Linux speed). Not sure if it's the new binutils or if it's the > > > >> >> new linuxulator patches, but I can run multiple instances of youtube > > > >> >> in parallel (5 total with other miscellaneous flash animation) without > > > >> >> it totally lagging out Firefox/X11, and it appears to close the > > > >> >> instances of firefox properly now. Hopefully this version fares better > > > >> >> than r218113 did (I think I hit a kernel bug after 2 weeks uptime, > > > >> >> where my system just hardlocked for no apparent reason). > > > >> >> Anyhow, hope others have similar results. > > > >> >> Cheers! > > > >> >> -Garrett > > > >> >> > > > >> >> $ uname -a > > > >> >> FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r218938M: > > > >> >> Mon Feb 21 23:10:51 PST 2011 > > > >> >> gcooper@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 > > > >> > > > > >> > Which FlashPlayer version do you test? Adobe has made significant > > > >> > performance changes in 10.2 (from 10.1). You can search for StageVideo > > > >> > performance to learn more about. Youtube already use them since 10.2 > > > >> > beta > > > >> > > > >> linux-f10-flashplugin-10.1r102.65 . The performance increases are > > > >> claimed to be "up to 85%" on the Stage Video site, but I'm seeing a > > > >> more than 200% increase (now it actually scales between multiple > > > >> instances, instead of croaks with one instance, tiling up and down the > > > >> screen when moving the window slider for instance or switching tabs). > > > >> Besides, it seems like it needs external support from the video > > > >> driver, and I'm not sure that that bridge exists in the linuxulator. > > > >> Also, it looks like npviewer.bin still hangs to resources on until > > > >> Firefox closes (or I kill it :)..), so something still needs to be > > > >> resolved there, but that isn't a regression (it's acted that way for > > > >> ages), and shouldn't be too hard to do. > > > > > > > > i think the problem with npviewer.bin having to be killed by hand is a futex > > > > issue in combination with a high number of threads. this is the output of a > > > > test from darren hart's futex test suite under freebsd 9.0: > > > > > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=1 > > > > Result: 18622 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=2 > > > > Result: 15469 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=3 > > > > Result: 12713 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=4 > > > > Result: 12247 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=5 > > > > Result: 11814 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=6 > > > > Result: 13468 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=8 > > > > Result: 12061 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=10 > > > > Result: 12854 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=12 > > > > Result: 12999 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=16 > > > > Result: 12402 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=24 > > > > Result: 9815 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=32 > > > > Result: 8518 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=64 > > > > ERROR: Resource temporarily unavailable: pthread_create > > > > Result: ERROR > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=128 > > > > ERROR: Resource temporarily unavailable: pthread_create > > > > Result: ERROR > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=256 > > > > ERROR: Resource temporarily unavailable: pthread_create > > > > Result: ERROR > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=512 > > > > ERROR: Resource temporarily unavailable: pthread_create > > > > Result: ERROR > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=1024 > > > > ERROR: Resource temporarily unavailable: pthread_create > > > > Result: ERROR > > > > > > > > cheers. > > > > alex > > > > > > Have you found any method or workaround to mitigate this issue? > > i did a ktrace -i and linux_kdump run and the results are quite interesting. > with only 1 thread linux_sys_futex() *never* failed with EAGAIN. starting > with 2 threads however i'm seeing an increasing number of linux_sys_futex() > failures (all with EAGAIN). > > the overhead is quite massive. linux_kdump > /tmp/futex-failure produced 941 > megs of output. doing > grep -v "futex_wait" futex-failure > futex-grep > produces an output of 192K!! so it's quite obvious that the futex_wait stuff > is responsible for causing massive activity, due to the constant failures and > retries. i ran kdump, instead of linux_kdump and it seems the freebsd function returning EAGAIN is nanosleep(2): 929 futex_wait CALL nanosleep(0xffffdb5c,0x81,0x1,0,0,0) 9929 futex_wait RET nanosleep 0 9929 futex_wait CALL nanosleep(0xffffdb5c,0x81,0x1,0,0,0) 9928 futex_wait CALL nanosleep(0xffffdb5c,0x80,0x2,0,0,0) 9929 futex_wait RET nanosleep 0 9928 futex_wait RET nanosleep -1 errno 35 Resource temporarily unavailable 9929 futex_wait CALL nanosleep(0xffffdb5c,0x81,0x1,0,0,0) 9928 futex_wait CALL nanosleep(0xffffdb5c,0x80,0x2,0,0,0) 9929 futex_wait RET nanosleep 0 9928 futex_wait RET nanosleep -1 errno 35 Resource temporarily unavailable 9929 futex_wait CALL nanosleep(0xffffdb5c,0x80,0x2,0,0,0) 9928 futex_wait CALL nanosleep(0xffffdb5c,0x81,0x1,0,0,0) 9929 futex_wait RET nanosleep -1 errno 35 Resource temporarily unavailable 9928 futex_wait RET nanosleep 0 9929 futex_wait CALL nanosleep(0xffffdb5c,0x81,0x1,0,0,0) 9929 futex_wait RET nanosleep 0 9929 futex_wait CALL nanosleep(0xffffdb5c,0x80,0x2,0,0,0) 9928 futex_wait CALL nanosleep(0xffffdb5c,0x81,0x1,0,0,0) 9929 futex_wait RET nanosleep -1 errno 35 Resource temporarily unavailable 9928 futex_wait RET nanosleep 0 9929 futex_wait CALL nanosleep(0xffffdb5c,0x81,0x1,0,0,0) 9929 futex_wait RET nanosleep 0 9928 futex_wait CALL nanosleep(0xffffdb5c,0x81,0x1,0,0,0) 9929 futex_wait CALL nanosleep(0xffffdb5c,0x80,0x2,0,0,0) 9928 futex_wait RET nanosleep 0 9929 futex_wait RET nanosleep -1 errno 35 Resource temporarily unavailable 9929 futex_wait CALL nanosleep(0xffffdb5c,0x80,0x2,0,0,0) 9928 futex_wait CALL nanosleep(0xffffdb5c,0x81,0x1,0,0,0) 9929 futex_wait RET nanosleep -1 errno 35 Resource temporarily unavailable so this seems to be the location in linux_futex.c where error gets set to EAGAIN: static int futex_sleep(struct futex *f, struct waiting_proc *wp, int timeout) { int error; FUTEX_ASSERT_LOCKED(f); LINUX_CTR4(sys_futex, "futex_sleep enter uaddr %p wp %p timo %d ref %d", f->f_uaddr, wp, timeout, f->f_refcount); error = sx_sleep(wp, &f->f_lck, PCATCH, "futex", timeout); ^^^^ according to nanosleep(2) however EAGAIN is not a valid return value...i'm lost. :( cheers. alex > > here's a bit of output: > > 32126 futex_wait RET linux_sys_futex -1 errno 35 Resource temporarily unavailable > 32125 futex_wait RET linux_sys_futex 0 > 32126 futex_wait CALL linux_sys_futex(0xffffdb5c,0x81,0x1,0,0,0) > 32126 futex_wait RET linux_sys_futex 0 > 32126 futex_wait CALL linux_sys_futex(0xffffdb5c,0x81,0x1,0,0,0) > 32125 futex_wait CALL linux_sys_futex(0xffffdb5c,0x80,0x2,0,0,0) > 32126 futex_wait RET linux_sys_futex 0 > 32125 futex_wait RET linux_sys_futex -1 errno 35 Resource temporarily unavailable > 32126 futex_wait CALL linux_sys_futex(0xffffdb5c,0x80,0x2,0,0,0) > 32125 futex_wait CALL linux_sys_futex(0xffffdb5c,0x81,0x1,0,0,0) > 32126 futex_wait RET linux_sys_futex -1 errno 35 Resource temporarily unavailable > 32125 futex_wait RET linux_sys_futex 0 > 32126 futex_wait CALL linux_sys_futex(0xffffdb5c,0x81,0x1,0,0,0) > 32126 futex_wait RET linux_sys_futex 0 > 32126 futex_wait CALL linux_sys_futex(0xffffdb5c,0x80,0x2,0,0,0) > 32125 futex_wait CALL linux_sys_futex(0xffffdb5c,0x81,0x1,0,0,0) > 32126 futex_wait RET linux_sys_futex -1 errno 35 Resource temporarily unavailable > 32125 futex_wait RET linux_sys_futex 0 > 32126 futex_wait CALL linux_sys_futex(0xffffdb5c,0x81,0x1,0,0,0) > 32126 futex_wait RET linux_sys_futex 0 > 32126 futex_wait CALL linux_sys_futex(0xffffdb5c,0x80,0x2,0,0,0) > 32125 futex_wait CALL linux_sys_futex(0xffffdb5c,0x81,0x1,0,0,0) > 32126 futex_wait RET linux_sys_futex -1 errno 35 Resource temporarily unavailable > 32125 futex_wait RET linux_sys_futex 0 > 32126 futex_wait CALL linux_sys_futex(0xffffdb5c,0x81,0x1,0,0,0) > 32126 futex_wait RET linux_sys_futex 0 > 32126 futex_wait CALL linux_sys_futex(0xffffdb5c,0x81,0x1,0,0,0) > 32125 futex_wait CALL linux_sys_futex(0xffffdb5c,0x80,0x2,0,0,0) > 32126 futex_wait RET linux_sys_futex 0 > 32125 futex_wait RET linux_sys_futex -1 errno 35 Resource temporarily unavailable > 32125 futex_wait CALL linux_sys_futex(0xffffdb5c,0x81,0x1,0,0,0) > 32126 futex_wait CALL linux_sys_futex(0xffffdb5c,0x80,0x2,0,0,0) > 32125 futex_wait RET linux_sys_futex 0 > 32126 futex_wait RET linux_sys_futex -1 errno 35 Resource temporarily unavailable > 32126 futex_wait CALL linux_sys_futex(0xffffdb5c,0x80,0x2,0,0,0) > 32125 futex_wait CALL linux_sys_futex(0xffffdb5c,0x81,0x1,0,0,0) > 32126 futex_wait RET linux_sys_futex -1 errno 35 Resource temporarily unavailable > 32125 futex_wait RET linux_sys_futex 0 > 32126 futex_wait CALL linux_sys_futex(0xffffdb5c,0x81,0x1,0,0,0) > 32126 futex_wait RET linux_sys_futex 0 > 32126 futex_wait CALL linux_sys_futex(0xffffdb5c,0x80,0x2,0,0,0) > 32125 futex_wait CALL linux_sys_futex(0xffffdb5c,0x81,0x1,0,0,0) > 32126 futex_wait RET linux_sys_futex -1 errno 35 Resource temporarily unavailable > 32125 futex_wait RET linux_sys_futex 0 > 32126 futex_wait CALL linux_sys_futex(0xffffdb5c,0x81,0x1,0,0,0) > 32126 futex_wait RET linux_sys_futex 0 > 32126 futex_wait CALL linux_sys_futex(0xffffdb5c,0x80,0x2,0,0,0) > 32125 futex_wait CALL linux_sys_futex(0xffffdb5c,0x81,0x1,0,0,0) > 32126 futex_wait RET linux_sys_futex -1 errno 35 Resource temporarily unavailable > 32125 futex_wait RET linux_sys_futex 0 > 32126 futex_wait CALL linux_sys_futex(0xffffdb5c,0x81,0x1,0,0,0) > 32126 futex_wait RET linux_sys_futex 0 > 32126 futex_wait CALL linux_sys_futex(0xffffdb5c,0x80,0x2,0,0,0) > 32125 futex_wait CALL linux_sys_futex(0xffffdb5c,0x81,0x1,0,0,0) > 32126 futex_wait RET linux_sys_futex -1 errno 35 Resource temporarily unavailable > > cheers. > alex > > > > > no. i've increased the kern.threads.max_threads_per_proc value, but that had > > no effect. so it seems to be a bug in the linuxulator's futex implementation. > > > > cheers. > > alex > > > > > > > > -Brandon > > > > -- > > a13x > > -- > a13x -- a13x From owner-freebsd-current@FreeBSD.ORG Wed Feb 23 02:03: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 F1E39106564A; Wed, 23 Feb 2011 02:03:19 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id A7CC38FC0A; Wed, 23 Feb 2011 02:03:19 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:794d:2247:36f9:4086] (unknown [IPv6:2001:7b8:3a7:0:794d:2247:36f9:4086]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id B4D615C59; Wed, 23 Feb 2011 03:03:08 +0100 (CET) Message-ID: <4D646ADC.9090804@FreeBSD.org> Date: Wed, 23 Feb 2011 03:03:08 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.15pre) Gecko/20110221 Lanikai/3.1.9pre MIME-Version: 1.0 To: Jung-uk Kim References: <201102221423.30652.jkim@FreeBSD.org> In-Reply-To: <201102221423.30652.jkim@FreeBSD.org> Content-Type: multipart/mixed; boundary="------------090008070301020106080100" Cc: Rui Paulo , freebsd-current@FreeBSD.org Subject: Re: binutils 2.17.50 and ctfconvert 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, 23 Feb 2011 02:03:20 -0000 This is a multi-part message in MIME format. --------------090008070301020106080100 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 2011-02-22 20:23, Jung-uk Kim wrote: > Since binutils 2.17.50 import, WITH_CTF=1& buildworld on amd64 stops > like this: ... > cc -m32 -march=i686 -mmmx -msse -msse2 -mfancy-math-387 -DCOMPAT_32BIT > -isystem /usr/obj/usr/src/lib32/usr/include/ > -L/usr/obj/usr/src/lib32/usr/lib32 > -B/usr/obj/usr/src/lib32/usr/lib32 -fpic -DPIC -O2 -pipe > -fno-omit-frame-pointer -I/usr/src/lib/librt/../libc/include > -I/usr/src/lib/librt -fexceptions -Winline -Wall -g -std=gnu99 > -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k > -Wno-uninitialized -Wno-pointer-sign -c /usr/src/lib/librt/aio.c -o > aio.So > ctfconvert -L VERSION aio.o ... > BFD: aio.So: invalid SHT_GROUP entry > BFD: aio.So: invalid SHT_GROUP entry > BFD: aio.So: no group info for section .text.__i686.get_pc_thunk.cx > BFD: aio.So: no group info for section .text.__i686.get_pc_thunk.bx > BFD: aio.So: unknown [0] section `' in group [__i686.get_pc_thunk.cx] > BFD: aio.So: unknown [0] section `' in group [__i686.get_pc_thunk.bx] > nm: aio.So: File format not recognized ... > Google found NetBSD has a similar looking PR but it is not exactly the > same: > > http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=42986 What I gather from that bug report is that apparently ctfconvert can corrupt object files with debug info, if you do not pass -g to it. There is some logic in bsd.lib.mk to add '-g' to CTFFLAGS, if DEBUG_FLAGS contains '-g', but in lib/librt/Makefile you can see: ... CFLAGS+=-Winline -Wall -g ... It looks like the -g flag is not detected, so ctfconvert is run without -g, and it corrupts the .So file. I have no clue yet why this suddenly appears after upgrading to binutils 2.17.50, but it is likely due to a slightly different output format. In any case, just removing the -g from CFLAGS in lib/librt/Makefile made the build32 stage complete successfully for me, and since that is the lsat stage of the amd64 build, I assume the rest will be OK too. For now, I propose to commit the attached diff, and then we try to find out why: 1) ctfconvert does not get -g passed when it is needed 2) ctfconvert corrupts .o files when -g is not passed :) --------------090008070301020106080100 Content-Type: text/plain; name="librt-ctf-1.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="librt-ctf-1.diff" Index: lib/librt/Makefile =================================================================== --- lib/librt/Makefile (revision 218951) +++ lib/librt/Makefile (working copy) @@ -6,7 +6,7 @@ .ifndef NO_THREAD_STACK_UNWIND CFLAGS+=-fexceptions .endif -CFLAGS+=-Winline -Wall -g +CFLAGS+=-Winline -Wall DPADD= ${LIBPTHREAD} LDADD= -lpthread --------------090008070301020106080100-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 23 02:48: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 DD431106564A; Wed, 23 Feb 2011 02:48:01 +0000 (UTC) (envelope-from yanegomi@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 1B4948FC0A; Wed, 23 Feb 2011 02:48:00 +0000 (UTC) Received: by wwf26 with SMTP id 26so7818755wwf.31 for ; Tue, 22 Feb 2011 18:48:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=UVyPshlPFC08rOW8I/1SQtJ+yR8DV+55k7+0VRwDGvg=; b=CsX++js1ObzvHyLojTM+l7C5gheVysYmSsf4svdjOoTSm9wZM2sQEBiruXZtezjJZn Ks6F52aXDSWMnuMH8fPmrax2xffCONnovjIgY8ASLPqG4r4Zn5HEV0iIGQnChzYE4MNZ uULp00uAEAEemUJGwAlhc/tn+cOHztkgZSD5c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=CzzkYqVBoKQMQLEiW5kKzz9SheFE/plPo8fkDXRI63MBlMgHNjHvcu+BhpVBzymaEy Iaf5T9qwXwZMRrMLKoX7oJK44OUqoJq6M3GKSHhtcMZW4y3DGyV739UTyejhalnjabP/ 9uFBgdcyHC5JI/NOaZPMHRvjsRKu+FKeqJpRE= MIME-Version: 1.0 Received: by 10.216.144.205 with SMTP id n55mr4006175wej.5.1298429279324; Tue, 22 Feb 2011 18:47:59 -0800 (PST) Received: by 10.216.15.74 with HTTP; Tue, 22 Feb 2011 18:47:59 -0800 (PST) In-Reply-To: <20110223020008.GA94832@freebsd.org> References: <20110222203134.GA53262@freebsd.org> <20110222215036.GA66303@freebsd.org> <20110222223314.GA72748@freebsd.org> <20110223020008.GA94832@freebsd.org> Date: Tue, 22 Feb 2011 18:47:59 -0800 Message-ID: From: Garrett Cooper To: Alexander Best Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Brandon Gooch , Eir Nym , Dimitry Andric , FreeBSD Current Subject: Re: Wow... (<-- blown away at performance) 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, 23 Feb 2011 02:48:01 -0000 On Tue, Feb 22, 2011 at 6:00 PM, Alexander Best wrote= : > On Tue Feb 22 11, Alexander Best wrote: >> On Tue Feb 22 11, Alexander Best wrote: >> > On Tue Feb 22 11, Brandon Gooch wrote: >> > > On Tue, Feb 22, 2011 at 2:31 PM, Alexander Best wrote: >> > > > On Tue Feb 22 11, Garrett Cooper wrote: >> > > >> On Tue, Feb 22, 2011 at 2:10 AM, Eir Nym wrote= : >> > > >> > On 22 February 2011 11:15, Garrett Cooper = wrote: >> > > >> >> =A0 =A0I don't know what to say, but r218938 screams with flas= h videos >> > > >> >> (native Linux speed). Not sure if it's the new binutils or if = it's the >> > > >> >> new linuxulator patches, but I can run multiple instances of y= outube >> > > >> >> in parallel (5 total with other miscellaneous flash animation)= without >> > > >> >> it totally lagging out Firefox/X11, and it appears to close th= e >> > > >> >> instances of firefox properly now. Hopefully this version fare= s better >> > > >> >> than r218113 did (I think I hit a kernel bug after 2 weeks upt= ime, >> > > >> >> where my system just hardlocked for no apparent reason). >> > > >> >> =A0 =A0Anyhow, hope others have similar results. >> > > >> >> Cheers! >> > > >> >> -Garrett >> > > >> >> >> > > >> >> $ uname -a >> > > >> >> FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r21= 8938M: >> > > >> >> Mon Feb 21 23:10:51 PST 2011 >> > > >> >> gcooper@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA =A0amd6= 4 >> > > >> > >> > > >> > Which FlashPlayer version do you test? Adobe has made significa= nt >> > > >> > performance changes in 10.2 (from 10.1). You can search for Sta= geVideo >> > > >> > performance to learn more about. Youtube already use them since= 10.2 >> > > >> > beta >> > > >> >> > > >> =A0 =A0 linux-f10-flashplugin-10.1r102.65 . The performance incre= ases are >> > > >> claimed to be "up to 85%" on the Stage Video site, but I'm seeing= a >> > > >> more than 200% increase (now it actually scales between multiple >> > > >> instances, instead of croaks with one instance, tiling up and dow= n the >> > > >> screen when moving the window slider for instance or switching ta= bs). >> > > >> Besides, it seems like it needs external support from the video >> > > >> driver, and I'm not sure that that bridge exists in the linuxulat= or. >> > > >> =A0 =A0 Also, it looks like npviewer.bin still hangs to resources= on until >> > > >> Firefox closes (or I kill it :)..), so something still needs to b= e >> > > >> resolved there, but that isn't a regression (it's acted that way = for >> > > >> ages), and shouldn't be too hard to do. >> > > > >> > > > i think the problem with npviewer.bin having to be killed by hand = is a futex >> > > > issue in combination with a high number of threads. this is the ou= tput of a >> > > > test from darren hart's futex test suite under freebsd 9.0: >> > > > >> > > > futex_wait: Measure FUTEX_WAIT operations per second >> > > > =A0 =A0 =A0 =A0Arguments: iterations=3D100000000 threads=3D1 >> > > > Result: 18622 Kiter/s >> > > > futex_wait: Measure FUTEX_WAIT operations per second >> > > > =A0 =A0 =A0 =A0Arguments: iterations=3D100000000 threads=3D2 >> > > > Result: 15469 Kiter/s >> > > > futex_wait: Measure FUTEX_WAIT operations per second >> > > > =A0 =A0 =A0 =A0Arguments: iterations=3D100000000 threads=3D3 >> > > > Result: 12713 Kiter/s >> > > > futex_wait: Measure FUTEX_WAIT operations per second >> > > > =A0 =A0 =A0 =A0Arguments: iterations=3D100000000 threads=3D4 >> > > > Result: 12247 Kiter/s >> > > > futex_wait: Measure FUTEX_WAIT operations per second >> > > > =A0 =A0 =A0 =A0Arguments: iterations=3D100000000 threads=3D5 >> > > > Result: 11814 Kiter/s >> > > > futex_wait: Measure FUTEX_WAIT operations per second >> > > > =A0 =A0 =A0 =A0Arguments: iterations=3D100000000 threads=3D6 >> > > > Result: 13468 Kiter/s >> > > > futex_wait: Measure FUTEX_WAIT operations per second >> > > > =A0 =A0 =A0 =A0Arguments: iterations=3D100000000 threads=3D8 >> > > > Result: 12061 Kiter/s >> > > > futex_wait: Measure FUTEX_WAIT operations per second >> > > > =A0 =A0 =A0 =A0Arguments: iterations=3D100000000 threads=3D10 >> > > > Result: 12854 Kiter/s >> > > > futex_wait: Measure FUTEX_WAIT operations per second >> > > > =A0 =A0 =A0 =A0Arguments: iterations=3D100000000 threads=3D12 >> > > > Result: 12999 Kiter/s >> > > > futex_wait: Measure FUTEX_WAIT operations per second >> > > > =A0 =A0 =A0 =A0Arguments: iterations=3D100000000 threads=3D16 >> > > > Result: 12402 Kiter/s >> > > > futex_wait: Measure FUTEX_WAIT operations per second >> > > > =A0 =A0 =A0 =A0Arguments: iterations=3D100000000 threads=3D24 >> > > > Result: 9815 Kiter/s >> > > > futex_wait: Measure FUTEX_WAIT operations per second >> > > > =A0 =A0 =A0 =A0Arguments: iterations=3D100000000 threads=3D32 >> > > > Result: 8518 Kiter/s >> > > > futex_wait: Measure FUTEX_WAIT operations per second >> > > > =A0 =A0 =A0 =A0Arguments: iterations=3D100000000 threads=3D64 >> > > > =A0 =A0 =A0 =A0ERROR: Resource temporarily unavailable: pthread_cr= eate >> > > > Result: ERROR >> > > > futex_wait: Measure FUTEX_WAIT operations per second >> > > > =A0 =A0 =A0 =A0Arguments: iterations=3D100000000 threads=3D128 >> > > > =A0 =A0 =A0 =A0ERROR: Resource temporarily unavailable: pthread_cr= eate >> > > > Result: ERROR >> > > > futex_wait: Measure FUTEX_WAIT operations per second >> > > > =A0 =A0 =A0 =A0Arguments: iterations=3D100000000 threads=3D256 >> > > > =A0 =A0 =A0 =A0ERROR: Resource temporarily unavailable: pthread_cr= eate >> > > > Result: ERROR >> > > > futex_wait: Measure FUTEX_WAIT operations per second >> > > > =A0 =A0 =A0 =A0Arguments: iterations=3D100000000 threads=3D512 >> > > > =A0 =A0 =A0 =A0ERROR: Resource temporarily unavailable: pthread_cr= eate >> > > > Result: ERROR >> > > > futex_wait: Measure FUTEX_WAIT operations per second >> > > > =A0 =A0 =A0 =A0Arguments: iterations=3D100000000 threads=3D1024 >> > > > =A0 =A0 =A0 =A0ERROR: Resource temporarily unavailable: pthread_cr= eate >> > > > Result: ERROR >> > > > >> > > > cheers. >> > > > alex >> > > >> > > Have you found any method or workaround to mitigate this issue? >> >> i did a ktrace -i and linux_kdump run and the results are quite interest= ing. >> with only 1 thread linux_sys_futex() *never* failed with EAGAIN. startin= g >> with 2 threads however i'm seeing an increasing number of linux_sys_fute= x() >> failures (all with EAGAIN). >> >> the overhead is quite massive. linux_kdump > /tmp/futex-failure produced= 941 >> megs of output. doing >> grep -v "futex_wait" futex-failure > futex-grep >> produces an output of 192K!! so it's quite obvious that the futex_wait s= tuff >> is responsible for causing massive activity, due to the constant failure= s and >> retries. > > i ran kdump, instead of linux_kdump and it seems the freebsd function ret= urning > EAGAIN is nanosleep(2): > > 929 futex_wait CALL =A0nanosleep(0xffffdb5c,0x81,0x1,0,0,0) > =A09929 futex_wait RET =A0 nanosleep 0 > =A09929 futex_wait CALL =A0nanosleep(0xffffdb5c,0x81,0x1,0,0,0) > =A09928 futex_wait CALL =A0nanosleep(0xffffdb5c,0x80,0x2,0,0,0) > =A09929 futex_wait RET =A0 nanosleep 0 > =A09928 futex_wait RET =A0 nanosleep -1 errno 35 Resource temporarily una= vailable > =A09929 futex_wait CALL =A0nanosleep(0xffffdb5c,0x81,0x1,0,0,0) > =A09928 futex_wait CALL =A0nanosleep(0xffffdb5c,0x80,0x2,0,0,0) > =A09929 futex_wait RET =A0 nanosleep 0 > =A09928 futex_wait RET =A0 nanosleep -1 errno 35 Resource temporarily una= vailable > =A09929 futex_wait CALL =A0nanosleep(0xffffdb5c,0x80,0x2,0,0,0) > =A09928 futex_wait CALL =A0nanosleep(0xffffdb5c,0x81,0x1,0,0,0) > =A09929 futex_wait RET =A0 nanosleep -1 errno 35 Resource temporarily una= vailable > =A09928 futex_wait RET =A0 nanosleep 0 > =A09929 futex_wait CALL =A0nanosleep(0xffffdb5c,0x81,0x1,0,0,0) > =A09929 futex_wait RET =A0 nanosleep 0 > =A09929 futex_wait CALL =A0nanosleep(0xffffdb5c,0x80,0x2,0,0,0) > =A09928 futex_wait CALL =A0nanosleep(0xffffdb5c,0x81,0x1,0,0,0) > =A09929 futex_wait RET =A0 nanosleep -1 errno 35 Resource temporarily una= vailable > =A09928 futex_wait RET =A0 nanosleep 0 > =A09929 futex_wait CALL =A0nanosleep(0xffffdb5c,0x81,0x1,0,0,0) > =A09929 futex_wait RET =A0 nanosleep 0 > =A09928 futex_wait CALL =A0nanosleep(0xffffdb5c,0x81,0x1,0,0,0) > =A09929 futex_wait CALL =A0nanosleep(0xffffdb5c,0x80,0x2,0,0,0) > =A09928 futex_wait RET =A0 nanosleep 0 > =A09929 futex_wait RET =A0 nanosleep -1 errno 35 Resource temporarily una= vailable > =A09929 futex_wait CALL =A0nanosleep(0xffffdb5c,0x80,0x2,0,0,0) > =A09928 futex_wait CALL =A0nanosleep(0xffffdb5c,0x81,0x1,0,0,0) > =A09929 futex_wait RET =A0 nanosleep -1 errno 35 Resource temporarily una= vailable > > so this seems to be the location in linux_futex.c where error gets set to > EAGAIN: > > static int > futex_sleep(struct futex *f, struct waiting_proc *wp, int timeout) > { > =A0 =A0 =A0 =A0int error; > > =A0 =A0 =A0 =A0FUTEX_ASSERT_LOCKED(f); > =A0 =A0 =A0 =A0LINUX_CTR4(sys_futex, "futex_sleep enter uaddr %p wp %p ti= mo %d ref %d", > =A0 =A0 =A0 =A0 =A0 =A0f->f_uaddr, wp, timeout, f->f_refcount); > =A0 =A0 =A0 =A0error =3D sx_sleep(wp, &f->f_lck, PCATCH, "futex", timeout= ); > =A0 =A0 =A0 =A0^^^^ > > according to nanosleep(2) however EAGAIN is not a valid return value...i'= m > lost. :( Don't trust the manpage young padawan (I wish one could, but not all manpages are updated in a timely manner, in particular the kernel ones I've discovered :(...). The one spot where it could be completely screwing things up is with timer_create (it's the one logical spot in sys/kern/... that returns EAGAIN), and this might make sense if our clock values weren't being translated over properly for the linuxulator and clocks were getting screwed up somewhere. Well, that and clock_nanosleep, isn't implemented, and I wouldn't be so sure if it's sane when compared to what Linux's clocks/timers do (sane being equivalent, not necessarily right). Something I ranted about in another PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/150095 . So, that might be something worth looking into or not. It's up to you *shrugs*. HTH, -Garrett From owner-freebsd-current@FreeBSD.ORG Wed Feb 23 03:23: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 4AFDD1065673; Wed, 23 Feb 2011 03:23:52 +0000 (UTC) (envelope-from dteske@vicor.com) Received: from postoffice.vicor.com (postoffice.vicor.com [69.26.56.53]) by mx1.freebsd.org (Postfix) with ESMTP id 2BF138FC0A; Wed, 23 Feb 2011 03:23:51 +0000 (UTC) Received: from [210.177.209.182] (port=12866 helo=[192.168.1.151]) by postoffice.vicor.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71) (envelope-from ) id 1Ps5KL-0000Az-Ir; Tue, 22 Feb 2011 19:23:51 -0800 Mime-Version: 1.0 (Apple Message framework v1081) From: Devin Teske In-Reply-To: <20110222205741.GA34103@server.vk2pj.dyndns.org> Date: Tue, 22 Feb 2011 19:23:43 -0800 Message-Id: <6A5ECC9D-9EF4-4331-9BB0-E14FE6087D53@vicor.com> References: <4D35CFFB.3010302@freebsd.org> <201102211612.51233.josh@tcbug.org> <201102220103.20158.josh@tcbug.org> <20110222205741.GA34103@server.vk2pj.dyndns.org> To: Peter Jeremy X-Mailer: Apple Mail (2.1081) X-Scan-Signature: 2deb3881d101993f5b9fe028e1f948e6 X-Scan-Host: postoffice.vicor.com X-Mailman-Approved-At: Wed, 23 Feb 2011 03:34:58 +0000 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org, freebsd-sysinstall@freebsd.org, freebsd-arch@freebsd.org Subject: Re: FreeBSD Installer Roadmap 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, 23 Feb 2011 03:23:52 -0000 On Feb 22, 2011, at 12:57 PM, Peter Jeremy wrote: > On 2011-Feb-22 02:50:54 -0800, Devin Teske wrote: >> That's the operative word here ("supports"). Lord help us when that >> changes to "requires" (that is to say, if/when the FreeBSD kernel >> becomes legacy-free with respect to supporting fdisk/disklabel >> partitioned disks). >=20 > When that does come, it will probably be driven by BIOS and hardware > vendors dropping support for MBR. Current disks are at the upper > limit of what MBR can be support (and that's after several revamps of > MBR). Since GPT already provides a superior feature set without MBR's > limits, the next step will be to just drop MBR support. And when it > does come, FreeBSD needs to be ready with an installer that can cope > with non-MBR disks. All very true. Though admittedly we're [as a technological society] still a long long = ways off from dropping support for MBR in even the most modern BIOS'. >=20 >> We've yet to see a "must have" technology that would require us to >> shun sysinstall (as explained earlier, we have no desire whatsoever >> to boot from ZFS, gmirror, geli, GPT, or anything else missing from >> sysinstall). >=20 > Whilst _you_ might not be interested, lots of other people _are_ > interested in using these features - I personally use a mixture of > gmirror, GPT and ZFS root on different systems. Excellent. And the likes of us (enterprise) will be watching the likes = of you (non-enterprise) for many years to come to see how you fare in = your travels. =46rom time to time we'll be checking in on the list and = perusing list archives to see how well you fare. I don't know if you remember, but I can remember 10+ years ago when = ReiserFS (the *killer* filesystem -- sorry, I couldn't resist) hit the = Linux scene. There were wild reports of comprehensive data loss even in = the 3rd year of its production cycle. It was stories like that which = kept down the rate of adoption because many enterprises adopt the same = "wait and see" attitude. We call it the "great shake out" and all new = technologies must have one before being adopted by the largest = enterprises. > Why should other > people be forced to avoid these features just because you don't use > them? They shouldn't. We encourage others to dive head-long into the soupy mix = and be our guinea pigs for us. Innovation is no place for the enterprises that run the market place (or = even the World). (in a very serious tone) Would you rather your bank call you up and = explain that because they tried some new technology that caused a crash = in the data center, you won't have access to your bank account for the = next few hours whilst they reboot the master server? Just as I suspect your answer would be no, it should be self-evident = that when a critical system goes down, there is not always the luxury of = being able to drop to gdb/kdb and diagnose the root-cause (rather, = disaster recovery procedures often demand focusing your efforts on = getting said service -- if not the original machine, a replacement = machine -- back online as fast as humanly possible). Whereas others may = have the luxury of providing backtraces, core dumps, and swapfiles to = the authors of some new kernel device driver to eventually have some = critical bug fixed, the downtime required to cull those resources would = decimate any profit-driven business model which relies on service = uptime. It's very easy to forget that -- while playing with new technologies is = both fun _and_ exciting -- businesses that make the world go-'round = demand more than just the promise of stability, they demand the numbers = to prove it (and even then, may still require their own engineers to = perform an "in-house bake-out" of their own which involves the added = complexity of working with their own code). Rolling in any replacement = anytime anywhere requires "burn-in" metrics to show that the technology = can reproduce an acceptable fault-to-performance ratio. Of course, it = goes without saying that said stringent testing requires both resources = and man-hours. > FreeBSD's installer should support the same features as FreeBSD > itself for consistency. I don't disagree. That's a laudable goal for all Operating Systems. = Though with due respect, I don't think any one installer for any = operating system allows you to achieve all permutations of which the OS = itself supports. >=20 >> pedestals... why would we ever need >8GB for the operating system? >> all production data is being stored on enterprise class devices such >> as the NEC-D210, and being backed up with tapes such as LTO; >=20 > Not everyone uses FreeBSD in the same environment as you. Oh how society would stagnate if we _did_. Thank goodness we _don't_ = operate in the same environments (for your sake and mine). >=20 >> We're no stranger to putting even the Operating System on Life >> Support for as long as it takes for our customers to bolster their >> budgets for an integrated upgrade strategy. >=20 > Given that you've already said you are staying with FreeBSD 4.11, We are migrating to FreeBSD-8.1 this year and plan to do so with = sysinstall. The whole point about this thread is, that we plan to use sysinstall for = FreeBSD-9 and later too. I simply can't be bothered to migrate thousands = of lines of code (which are the culmination of multiple man-years) to a = new installer that is not vetted in-house yet -- and because at least 3 = other people on this list have expressed interest in our life-support = for their own enterprise organizations, I am pressing forward with the = minor effort that-it-is to make our work public. You question the expenditure of resources whilst we question the = decision to completely dump such a tried-and-true technology. A better = decision would have been to offer both sysinstall _and_ bsdinstall in = FreeBSD-9 and then offer only bsdinstall in FreeBSD-10 (it even has a = nice mental picture to it ... FreeBSD-10 being the legacy-free = installation method). Personally, I find the immediate jump to be rather = maligned from the spirit of enterprise development. > why are you at all worried about FreeBSD using a new installed in > FreeBSD 9 to support features that don't exist in FreeBSD 4? You misunderstood the entire thread. We are migrating from FreeBSD-4 to = FreeBSD-8 this year and have already migrated thousands of lines of code = from RELENG_4 to RELENG_8 last year for the big-jump. This thread was = created because it was announced that RELENG_9 will surreptitiously drop = sysinstall completely in favor of bsdinstall without so much as a = "honeymoon period." > FreeBSD is primarily a volunteer project. Whilst you may be an expert > on the innards of sysinstall, this seems to be a rare skill and no-one > (including yourself) has stepped up and offered to add the missing > functionality to sysinstall. Innovation is bourne-of necessity -- and we don't need said "missing" = functionality. sysinstall is fully-featured for us. Though, the answer you're looking for is likely one of the following: (a) We are the only people in the World skilled enough make these = additions to sysinstall (and we've made our stance very clear... that it = would be a waste of our time to make such additions because we don't use = these technologies). (b) There are other people in the World capable of making these = additions, but they hold the same views. (c) There are other people in the World capable of making these = additions, but they would rather funnel all changes into a new product, = avoiding destabilization of sysinstall. All other people (those that are not well-versed enough to add these = features to sysinstall) fall clearly into two camps: (1) They'd like to see the additions made to sysinstall, but simply = don't know how to go about doing so. (2) They simply want to see sysinstall die for its iniquities. The latter group perhaps representing the majority of opinions that I've = observed in the past few months on this (and other) lists. But, I assure you that the reason that sysinstall has not had these = additions is more likely due to the fact that anybody/everybody that = _is_ comfortable with adding to the current state of sysinstall is = simply too busy to donate their hours. As you said... FreeBSD is = primarily a volunteer project. > It's worth noting that the original > author of sysinstall considered it to be a temporary stop-gap until > something better was developed. Yes, this has been noted a thousand times over, it's in the man-page, = it's been said on the lists, and does not need repeating. Yet, obviously time speaks for itself ... 15+ years of production use = and still going ("temporary" or not, something must have been done right = to win the respect of hardened C experts -- of which are directly = responsible for extending its life for those 15+ years). Just look at = the commit logs ... do you see the same disparaging overtones in the = commit messages? no. Do you see the developers that are actively working = on sysinstall bashing it like you do? no. On the contrary, the = developers that _do_ maintain sysinstall are all constructive and = productive members of the community. As an external observer's point of view... it's very easy to quote a = one-liner that serves ones own desires ("but the author said..."). Lord = help us if we were all held accountable to what we said 15+ years ago = about our own products. The fact remains that even if the author said = "this is a heaping pile of spraint", it doesn't change the fact that he = developed something that was in-fact elegant regardless of whether the = original author thought-so or not. By this same sentiment Einstein himself called the general theory of = relativity a minor stepping stone and an incomplete view of the = universal laws of physics (he died before he could marry the = fundamentals of quantum mechanics with the same laws that govern large = bodies in astrophysics -- dubbed in his time the [elusive] unified field = theorem). Does that mean that the initial work was any less magnanimous? = Pay homage to your roots and don't trash the people that maintain the = products that got you where you are today. > The increasing disparity between > FreeBSD's features, together with the opaqueness of sysinstall have > led to a replacement being developed. Excellent. As I said before, I welcome our new bsdinstall overlords. I'm = still undecided as to whether bsdinstall implements enough sysinstall = features to be useful for us, and with that sentiment it is that we = decide to put sysinstall on life-support until that can be answered = (which could take months to answer, and if the answer is _no_, then = we'll extend sysinstall's life-support even further until bsdinstall can = be made to support the same featureset that sysinstall provides -- = mostly speaking about scripting abilities here ... which includes much = more than just simply pre-configuring the disk allocation metrics as you = will see upon full-release of our automated install platform in coming = weeks/months). So, I don't see why you must balk at this. We're going to spend a _LOT_ = of voluntary time over the next coming years to enhance bsdinstall so = that it is as feature-rich as sysinstall is when it comes to = scriptability. > No-one is forcing you to > replace sysinstall on your legacy systems It's true that I brought FreeBSD-4.11 into the discussion, but = everything discussed is in relation to RELENG_9. > but if you want sysinstall > to remain the default installer, you are going to need to add the > missing functionality to it. *sigh* I don't _need_ to do anything. The people in the enterprise = circuit agree with our stance (you are thus far alone in thinking that = sysinstall is utterly worthless unless it supports GPT, ZFS, geli, = gmirror, and a host of other things). >=20 > --=20 > Peter Jeremy -- Cheers, Devin Teske -> CONTACT INFORMATION <- Business Solutions Consultant II FIS - fisglobal.com 510-735-5650 Mobile 510-621-2038 Office 510-621-2020 Office Fax 909-477-4578 Home/Fax devin.teske@fisglobal.com -> LEGAL DISCLAIMER <- This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy. -> FUN STUFF <- -----BEGIN GEEK CODE BLOCK----- Version 3.12 GAT/CS/B/CC/E/IT/MC/M/MU/P/S/TW d+(++) s: a- C+++@$ UB++++$ P++++@$ = L++++$ E- W+++ N? o? K? w@ O M++$ V- PS+>++ PE@ Y+ PGP-> t(+) 5? X(+) R(-) tv+ = b+>++ DI+ D+(++) G++ e>++++ h r+++ z+++ ------END GEEK CODE BLOCK------ http://www.geekcode.com/ -> END TRANSMISSION <- From owner-freebsd-current@FreeBSD.ORG Wed Feb 23 03:41: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 ACA511065702; Wed, 23 Feb 2011 03:41:07 +0000 (UTC) (envelope-from yanegomi@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 E15C58FC0C; Wed, 23 Feb 2011 03:41:06 +0000 (UTC) Received: by wwf26 with SMTP id 26so7856394wwf.31 for ; Tue, 22 Feb 2011 19:41:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=eop9jk/KnHlMvlr35MojGUWg0ejyUcaEUWEHUyfSASU=; b=BfsgF2YS63a79u5pNKqwbwIp01+YjM3YhoUFL9nTnfxeBu4tAiO49YbXf/CzsD5B8e 8QmPWR7wXxCoGcrFFTsK7sct8cZ+bwjIE3UmVQjKOnUkSYrFo8ftH5yhN5Etd6G+VzDV 3+1G7ci8wjDydmttKslP7YAH4Jyi6zHExWB8Y= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=rYYFiLtrcwAG47N/4s1t1itN+jkK3lSrZZRNVIMC7KJ6UbjjqwQfTalsGhHUaZBCQs kQROo/ElVNENrrdjDrNSMat1Ha07ZyntH3htF/zKZC0JwhC5aKH8AdwpNgeQB+L2wf2m Rm9EkNYwDP57rkaivoLiNsCSV+RE3lZycC1Ds= MIME-Version: 1.0 Received: by 10.216.46.193 with SMTP id r43mr4032089web.20.1298432465780; Tue, 22 Feb 2011 19:41:05 -0800 (PST) Sender: yanegomi@gmail.com Received: by 10.216.15.74 with HTTP; Tue, 22 Feb 2011 19:41:05 -0800 (PST) In-Reply-To: <6A5ECC9D-9EF4-4331-9BB0-E14FE6087D53@vicor.com> References: <4D35CFFB.3010302@freebsd.org> <201102211612.51233.josh@tcbug.org> <201102220103.20158.josh@tcbug.org> <20110222205741.GA34103@server.vk2pj.dyndns.org> <6A5ECC9D-9EF4-4331-9BB0-E14FE6087D53@vicor.com> Date: Tue, 22 Feb 2011 19:41:05 -0800 X-Google-Sender-Auth: NNh4L_1OSHmM-D0bpt3GQOEazHg Message-ID: From: Garrett Cooper To: Devin Teske Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, freebsd-sysinstall@freebsd.org, Peter Jeremy , freebsd-arch@freebsd.org Subject: Re: FreeBSD Installer Roadmap 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, 23 Feb 2011 03:41:07 -0000 On Tue, Feb 22, 2011 at 7:23 PM, Devin Teske wrote: > > On Feb 22, 2011, at 12:57 PM, Peter Jeremy wrote: > >> On 2011-Feb-22 02:50:54 -0800, Devin Teske wrote: >>> That's the operative word here ("supports"). Lord help us when that >>> changes to "requires" (that is to say, if/when the FreeBSD kernel >>> becomes legacy-free with respect to supporting fdisk/disklabel >>> partitioned disks). >> >> When that does come, it will probably be driven by BIOS and hardware >> vendors dropping support for MBR. =A0Current disks are at the upper >> limit of what MBR can be support (and that's after several revamps of >> MBR). =A0Since GPT already provides a superior feature set without MBR's >> limits, the next step will be to just drop MBR support. =A0And when it >> does come, FreeBSD needs to be ready with an installer that can cope >> with non-MBR disks. While I love a good discussion (and there have been a number of good points for either side on here), should we agree to switch the default over to bsdinstall, leave sysinstall in (lumps or no lumps), then over the period of the next 2~3 major (that amounts to 4~6 years) releases, and retire sysinstall to the happy hunting grounds? sysinstall didn't take up that much space on the release media I thought, and it might be doable to map both sets of media so that sysinstall can work in harmony on bsdinstall's release media? Preparing custom releases to use the sysinstall init_path isn't that bad, so it would at least give the legacy folks time to transition over while us guinea pigs burn in the new wax :)... Sound good? Thanks! -Garrett From owner-freebsd-current@FreeBSD.ORG Wed Feb 23 05:26: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 0CD7A106566C; Wed, 23 Feb 2011 05:26:16 +0000 (UTC) (envelope-from dteske@vicor.com) Received: from postoffice.vicor.com (postoffice.vicor.com [69.26.56.53]) by mx1.freebsd.org (Postfix) with ESMTP id E1CDF8FC12; Wed, 23 Feb 2011 05:26:15 +0000 (UTC) Received: from [210.177.209.182] (port=13723 helo=[192.168.1.151]) by postoffice.vicor.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71) (envelope-from ) id 1Ps7Ep-0000b3-Vz; Tue, 22 Feb 2011 21:26:15 -0800 Mime-Version: 1.0 (Apple Message framework v1081) From: Devin Teske In-Reply-To: Date: Tue, 22 Feb 2011 21:26:09 -0800 Message-Id: <816E26D1-C34D-4A40-BA4F-6C486D622DAD@vicor.com> References: <4D35CFFB.3010302@freebsd.org> <201102211612.51233.josh@tcbug.org> <201102220103.20158.josh@tcbug.org> <20110222205741.GA34103@server.vk2pj.dyndns.org> <6A5ECC9D-9EF4-4331-9BB0-E14FE6087D53@vicor.com> To: Garrett Cooper X-Mailer: Apple Mail (2.1081) X-Scan-Signature: ef46d7595948ee90861d7f47ac6dd61a X-Scan-Host: postoffice.vicor.com X-Mailman-Approved-At: Wed, 23 Feb 2011 05:39:12 +0000 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, freebsd-sysinstall@freebsd.org, Peter Jeremy , freebsd-arch@freebsd.org Subject: Re: FreeBSD Installer Roadmap 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, 23 Feb 2011 05:26:16 -0000 On Feb 22, 2011, at 7:41 PM, Garrett Cooper wrote: > On Tue, Feb 22, 2011 at 7:23 PM, Devin Teske wrote: >> >> On Feb 22, 2011, at 12:57 PM, Peter Jeremy wrote: >> >>> On 2011-Feb-22 02:50:54 -0800, Devin Teske wrote: >>>> That's the operative word here ("supports"). Lord help us when that >>>> changes to "requires" (that is to say, if/when the FreeBSD kernel >>>> becomes legacy-free with respect to supporting fdisk/disklabel >>>> partitioned disks). >>> >>> When that does come, it will probably be driven by BIOS and hardware >>> vendors dropping support for MBR. Current disks are at the upper >>> limit of what MBR can be support (and that's after several revamps of >>> MBR). Since GPT already provides a superior feature set without MBR's >>> limits, the next step will be to just drop MBR support. And when it >>> does come, FreeBSD needs to be ready with an installer that can cope >>> with non-MBR disks. > > While I love a good discussion (and there have been a number of good > points for either side on here), should we agree to switch the default > over to bsdinstall, leave sysinstall in (lumps or no lumps), then over > the period of the next 2~3 major (that amounts to 4~6 years) releases, > and retire sysinstall to the happy hunting grounds? sysinstall didn't > take up that much space on the release media I thought, and it might > be doable to map both sets of media so that sysinstall can work in > harmony on bsdinstall's release media? > > Preparing custom releases to use the sysinstall init_path isn't that > bad, so it would at least give the legacy folks time to transition > over while us guinea pigs burn in the new wax :)... > > Sound good? Love it. Absolutely love it. You are a uniter, sir (tips hat)! > > Thanks! > -Garrett -- Cheers, Devin Teske -> CONTACT INFORMATION <- Business Solutions Consultant II FIS - fisglobal.com 510-735-5650 Mobile 510-621-2038 Office 510-621-2020 Office Fax 909-477-4578 Home/Fax devin.teske@fisglobal.com -> LEGAL DISCLAIMER <- This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy. -> END TRANSMISSION <- From owner-freebsd-current@FreeBSD.ORG Wed Feb 23 06:08: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 A652D106566C; Wed, 23 Feb 2011 06:08:00 +0000 (UTC) (envelope-from yanegomi@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 D75188FC15; Wed, 23 Feb 2011 06:07:59 +0000 (UTC) Received: by wwf26 with SMTP id 26so7947244wwf.31 for ; Tue, 22 Feb 2011 22:07:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=YIt8GPdjvnqLDj6Hev3aJJXBL113xh/a4ZCuFyaCbsc=; b=GgoyGZL9PfQTqh9Vz4ErG5F/fOZYjzk8QAc4a3/Dh7v4GrtpwW/kjwAfayhhfs76md CcIjEVop9COWW++IBj+rLsKfKmhH+cS6L8X2Avgcw7rhU/gFmflqsFx75wl04JQpnHPj B3ET5Fn032R9M83aa9Jx3QSoA4cXj4Nodczh4= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=dnLywsyfyKrmjt5DnjVbUzp9FDm12JHkF+otJ9S1Dzdvtk0CwKjNp80Iy4Y96XDW4E waHUcGXpudrZsSviRSPCSytGss3Xq5Z/742JRVPAcHkC/E5TSUurfVVYoOtuvVaJ5kWs +d7YcwNOLJaaKxSw5cCmhMVcLF0kSK/voYJFg= MIME-Version: 1.0 Received: by 10.216.155.1 with SMTP id i1mr4171649wek.0.1298441278721; Tue, 22 Feb 2011 22:07:58 -0800 (PST) Sender: yanegomi@gmail.com Received: by 10.216.15.74 with HTTP; Tue, 22 Feb 2011 22:07:58 -0800 (PST) In-Reply-To: <816E26D1-C34D-4A40-BA4F-6C486D622DAD@vicor.com> References: <4D35CFFB.3010302@freebsd.org> <201102211612.51233.josh@tcbug.org> <201102220103.20158.josh@tcbug.org> <20110222205741.GA34103@server.vk2pj.dyndns.org> <6A5ECC9D-9EF4-4331-9BB0-E14FE6087D53@vicor.com> <816E26D1-C34D-4A40-BA4F-6C486D622DAD@vicor.com> Date: Tue, 22 Feb 2011 22:07:58 -0800 X-Google-Sender-Auth: yiitFnnI2XoURSNKILkJE2jV7DU Message-ID: From: Garrett Cooper To: Devin Teske Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, freebsd-sysinstall@freebsd.org, Peter Jeremy , freebsd-arch@freebsd.org Subject: Re: FreeBSD Installer Roadmap 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, 23 Feb 2011 06:08:00 -0000 On Tue, Feb 22, 2011 at 9:26 PM, Devin Teske wrote: > > On Feb 22, 2011, at 7:41 PM, Garrett Cooper wrote: > >> On Tue, Feb 22, 2011 at 7:23 PM, Devin Teske wrote: >>> >>> On Feb 22, 2011, at 12:57 PM, Peter Jeremy wrote: >>> >>>> On 2011-Feb-22 02:50:54 -0800, Devin Teske wrote: >>>>> That's the operative word here ("supports"). Lord help us when that >>>>> changes to "requires" (that is to say, if/when the FreeBSD kernel >>>>> becomes legacy-free with respect to supporting fdisk/disklabel >>>>> partitioned disks). >>>> >>>> When that does come, it will probably be driven by BIOS and hardware >>>> vendors dropping support for MBR. =A0Current disks are at the upper >>>> limit of what MBR can be support (and that's after several revamps of >>>> MBR). =A0Since GPT already provides a superior feature set without MBR= 's >>>> limits, the next step will be to just drop MBR support. =A0And when it >>>> does come, FreeBSD needs to be ready with an installer that can cope >>>> with non-MBR disks. >> >> While I love a good discussion (and there have been a number of good >> points for either side on here), should we agree to switch the default >> over to bsdinstall, leave sysinstall in (lumps or no lumps), then over >> the period of the next 2~3 major (that amounts to 4~6 years) releases, >> and retire sysinstall to the happy hunting grounds? sysinstall didn't >> take up that much space on the release media I thought, and it might >> be doable to map both sets of media so that sysinstall can work in >> harmony on bsdinstall's release media? >> >> Preparing custom releases to use the sysinstall init_path isn't that >> bad, so it would at least give the legacy folks time to transition >> over while us guinea pigs burn in the new wax :)... >> >> Sound good? > > Love it. Absolutely love it. You are a uniter, sir (tips hat)! Well, it's just a proposal. It needs to be presented to a) re@, b) they need to tentatively accept, and someone needs to a) do the work of integrating both pieces together and b) ensure it works in both cases, c) test, test test, d) commit. All of this needs to be done before 9.0-RELEASE. So I wouldn't say "success!" just yet, but we're on the right path. Switching stuff overnight is impossible for something like sysinstall. I'm having to deal with similar issues transitioning acquisition MIBs over to the acquiree company's style and requirements. Providing an ample transition plan is one of the great things I've noticed about BSD anyhow in areas like these :)... it shows real planning and architecture. Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Wed Feb 23 06:51: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 3EF15106566B; Wed, 23 Feb 2011 06:51:19 +0000 (UTC) (envelope-from m.e.sanliturk@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 A605C8FC0A; Wed, 23 Feb 2011 06:51:18 +0000 (UTC) Received: by vws16 with SMTP id 16so2664160vws.13 for ; Tue, 22 Feb 2011 22:51:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=IcjbxkHN6u98R1sBhKZxVHPUkfOElh8tCZga2U4/Ik4=; b=J7REbfd7hqcm5Nq4JMFsAXvhC9UOnABw/fha4jXveoplEAW81y1AoC2p4kMK+o40XU 2Vg19z260cRXV/r4BTWzo4e2TIgA/N0f05BL78njvq01EUg7LlQCPQFU3Pfn+VnQPKJi JnSX0LCcBbWJFfZ5BCMC3L1O/y/LieD0z2yTU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=RtitDscbEnE5PWKipd3l+WBmELkCoFj5sSGXrubWL56iCMYlqnz5ZnoE2DcTwrfTHx c4qW6caqKL7XPopDNjkH3SD1ooqF+XUy2cO2fb+dOphGmFxftrYY5usaDFygqTnkw9/l ckWTMg0ML9js3nHUavZ8OWFTXn2Hzujvcr63M= MIME-Version: 1.0 Received: by 10.52.164.36 with SMTP id yn4mr5436419vdb.307.1298442130093; Tue, 22 Feb 2011 22:22:10 -0800 (PST) Received: by 10.52.166.74 with HTTP; Tue, 22 Feb 2011 22:22:10 -0800 (PST) In-Reply-To: References: <4D35CFFB.3010302@freebsd.org> <201102211612.51233.josh@tcbug.org> <201102220103.20158.josh@tcbug.org> <20110222205741.GA34103@server.vk2pj.dyndns.org> <6A5ECC9D-9EF4-4331-9BB0-E14FE6087D53@vicor.com> Date: Wed, 23 Feb 2011 01:22:10 -0500 Message-ID: From: Mehmet Erol Sanliturk To: Garrett Cooper Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org, Devin Teske , freebsd-sysinstall@freebsd.org, Peter Jeremy , freebsd-arch@freebsd.org Subject: Re: FreeBSD Installer Roadmap 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, 23 Feb 2011 06:51:19 -0000 On Tue, Feb 22, 2011 at 10:41 PM, Garrett Cooper wrote: > On Tue, Feb 22, 2011 at 7:23 PM, Devin Teske wrote: > > > > On Feb 22, 2011, at 12:57 PM, Peter Jeremy wrote: > > > >> On 2011-Feb-22 02:50:54 -0800, Devin Teske wrote: > >>> That's the operative word here ("supports"). Lord help us when that > >>> changes to "requires" (that is to say, if/when the FreeBSD kernel > >>> becomes legacy-free with respect to supporting fdisk/disklabel > >>> partitioned disks). > >> > >> When that does come, it will probably be driven by BIOS and hardware > >> vendors dropping support for MBR. Current disks are at the upper > >> limit of what MBR can be support (and that's after several revamps of > >> MBR). Since GPT already provides a superior feature set without MBR's > >> limits, the next step will be to just drop MBR support. And when it > >> does come, FreeBSD needs to be ready with an installer that can cope > >> with non-MBR disks. > > While I love a good discussion (and there have been a number of good > points for either side on here), should we agree to switch the default > over to bsdinstall, leave sysinstall in (lumps or no lumps), then over > the period of the next 2~3 major (that amounts to 4~6 years) releases, > and retire sysinstall to the happy hunting grounds? sysinstall didn't > take up that much space on the release media I thought, and it might > be doable to map both sets of media so that sysinstall can work in > harmony on bsdinstall's release media? > > Preparing custom releases to use the sysinstall init_path isn't that > bad, so it would at least give the legacy folks time to transition > over while us guinea pigs burn in the new wax :)... > > Sound good? > > Thanks! > -Garrett > Yes , very much . My suggestion is to include the item sysinstall in BSD-Install by Nathan Whitehorn as an option in installation start up menu . In that way , existing installation works will be upward compatible with bsdinstall . My another suggestion is to move installation startup menu part into /boot/install/ directory for each architecture and allow platform specific installers by using common parts from common directories . For example , in PC-based installations ( amd64 , i386 , ... ) PC-BSD pc-sysinstall will be usable from bsdinstall as an option at present . In that form , the initial installation menu will be seen in PC environment as follows : bsdinstall ( by Nathan Whitehorn ) pc-sysinstall ( by Kris Moore ) sysinstall ( by John Hubbard ) Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-current@FreeBSD.ORG Wed Feb 23 10:24:32 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 49F6A1065674; Wed, 23 Feb 2011 10:24:32 +0000 (UTC) Date: Wed, 23 Feb 2011 10:24:32 +0000 From: Alexander Best To: Garrett Cooper Message-ID: <20110223102432.GA36810@freebsd.org> References: <20110222203134.GA53262@freebsd.org> <20110222215036.GA66303@freebsd.org> <20110222223314.GA72748@freebsd.org> <20110223020008.GA94832@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Cc: Brandon Gooch , Eir Nym , Dimitry Andric , FreeBSD Current Subject: Re: Wow... (<-- blown away at performance) 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, 23 Feb 2011 10:24:32 -0000 On Tue Feb 22 11, Garrett Cooper wrote: > On Tue, Feb 22, 2011 at 6:00 PM, Alexander Best wrote: > > On Tue Feb 22 11, Alexander Best wrote: > >> On Tue Feb 22 11, Alexander Best wrote: > >> > On Tue Feb 22 11, Brandon Gooch wrote: > >> > > On Tue, Feb 22, 2011 at 2:31 PM, Alexander Best wrote: > >> > > > On Tue Feb 22 11, Garrett Cooper wrote: > >> > > >> On Tue, Feb 22, 2011 at 2:10 AM, Eir Nym wrote: > >> > > >> > On 22 February 2011 11:15, Garrett Cooper wrote: > >> > > >> >> I don't know what to say, but r218938 screams with flash videos > >> > > >> >> (native Linux speed). Not sure if it's the new binutils or if it's the > >> > > >> >> new linuxulator patches, but I can run multiple instances of youtube > >> > > >> >> in parallel (5 total with other miscellaneous flash animation) without > >> > > >> >> it totally lagging out Firefox/X11, and it appears to close the > >> > > >> >> instances of firefox properly now. Hopefully this version fares better > >> > > >> >> than r218113 did (I think I hit a kernel bug after 2 weeks uptime, > >> > > >> >> where my system just hardlocked for no apparent reason). > >> > > >> >> Anyhow, hope others have similar results. > >> > > >> >> Cheers! > >> > > >> >> -Garrett > >> > > >> >> > >> > > >> >> $ uname -a > >> > > >> >> FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r218938M: > >> > > >> >> Mon Feb 21 23:10:51 PST 2011 > >> > > >> >> gcooper@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 > >> > > >> > > >> > > >> > Which FlashPlayer version do you test? Adobe has made significant > >> > > >> > performance changes in 10.2 (from 10.1). You can search for StageVideo > >> > > >> > performance to learn more about. Youtube already use them since 10.2 > >> > > >> > beta > >> > > >> > >> > > >> linux-f10-flashplugin-10.1r102.65 . The performance increases are > >> > > >> claimed to be "up to 85%" on the Stage Video site, but I'm seeing a > >> > > >> more than 200% increase (now it actually scales between multiple > >> > > >> instances, instead of croaks with one instance, tiling up and down the > >> > > >> screen when moving the window slider for instance or switching tabs). > >> > > >> Besides, it seems like it needs external support from the video > >> > > >> driver, and I'm not sure that that bridge exists in the linuxulator. > >> > > >> Also, it looks like npviewer.bin still hangs to resources on until > >> > > >> Firefox closes (or I kill it :)..), so something still needs to be > >> > > >> resolved there, but that isn't a regression (it's acted that way for > >> > > >> ages), and shouldn't be too hard to do. > >> > > > > >> > > > i think the problem with npviewer.bin having to be killed by hand is a futex > >> > > > issue in combination with a high number of threads. this is the output of a > >> > > > test from darren hart's futex test suite under freebsd 9.0: > >> > > > > >> > > > futex_wait: Measure FUTEX_WAIT operations per second > >> > > > Arguments: iterations=100000000 threads=1 > >> > > > Result: 18622 Kiter/s > >> > > > futex_wait: Measure FUTEX_WAIT operations per second > >> > > > Arguments: iterations=100000000 threads=2 > >> > > > Result: 15469 Kiter/s > >> > > > futex_wait: Measure FUTEX_WAIT operations per second > >> > > > Arguments: iterations=100000000 threads=3 > >> > > > Result: 12713 Kiter/s > >> > > > futex_wait: Measure FUTEX_WAIT operations per second > >> > > > Arguments: iterations=100000000 threads=4 > >> > > > Result: 12247 Kiter/s > >> > > > futex_wait: Measure FUTEX_WAIT operations per second > >> > > > Arguments: iterations=100000000 threads=5 > >> > > > Result: 11814 Kiter/s > >> > > > futex_wait: Measure FUTEX_WAIT operations per second > >> > > > Arguments: iterations=100000000 threads=6 > >> > > > Result: 13468 Kiter/s > >> > > > futex_wait: Measure FUTEX_WAIT operations per second > >> > > > Arguments: iterations=100000000 threads=8 > >> > > > Result: 12061 Kiter/s > >> > > > futex_wait: Measure FUTEX_WAIT operations per second > >> > > > Arguments: iterations=100000000 threads=10 > >> > > > Result: 12854 Kiter/s > >> > > > futex_wait: Measure FUTEX_WAIT operations per second > >> > > > Arguments: iterations=100000000 threads=12 > >> > > > Result: 12999 Kiter/s > >> > > > futex_wait: Measure FUTEX_WAIT operations per second > >> > > > Arguments: iterations=100000000 threads=16 > >> > > > Result: 12402 Kiter/s > >> > > > futex_wait: Measure FUTEX_WAIT operations per second > >> > > > Arguments: iterations=100000000 threads=24 > >> > > > Result: 9815 Kiter/s > >> > > > futex_wait: Measure FUTEX_WAIT operations per second > >> > > > Arguments: iterations=100000000 threads=32 > >> > > > Result: 8518 Kiter/s > >> > > > futex_wait: Measure FUTEX_WAIT operations per second > >> > > > Arguments: iterations=100000000 threads=64 > >> > > > ERROR: Resource temporarily unavailable: pthread_create > >> > > > Result: ERROR > >> > > > futex_wait: Measure FUTEX_WAIT operations per second > >> > > > Arguments: iterations=100000000 threads=128 > >> > > > ERROR: Resource temporarily unavailable: pthread_create > >> > > > Result: ERROR > >> > > > futex_wait: Measure FUTEX_WAIT operations per second > >> > > > Arguments: iterations=100000000 threads=256 > >> > > > ERROR: Resource temporarily unavailable: pthread_create > >> > > > Result: ERROR > >> > > > futex_wait: Measure FUTEX_WAIT operations per second > >> > > > Arguments: iterations=100000000 threads=512 > >> > > > ERROR: Resource temporarily unavailable: pthread_create > >> > > > Result: ERROR > >> > > > futex_wait: Measure FUTEX_WAIT operations per second > >> > > > Arguments: iterations=100000000 threads=1024 > >> > > > ERROR: Resource temporarily unavailable: pthread_create > >> > > > Result: ERROR > >> > > > > >> > > > cheers. > >> > > > alex > >> > > > >> > > Have you found any method or workaround to mitigate this issue? > >> > >> i did a ktrace -i and linux_kdump run and the results are quite interesting. > >> with only 1 thread linux_sys_futex() *never* failed with EAGAIN. starting > >> with 2 threads however i'm seeing an increasing number of linux_sys_futex() > >> failures (all with EAGAIN). > >> > >> the overhead is quite massive. linux_kdump > /tmp/futex-failure produced 941 > >> megs of output. doing > >> grep -v "futex_wait" futex-failure > futex-grep > >> produces an output of 192K!! so it's quite obvious that the futex_wait stuff > >> is responsible for causing massive activity, due to the constant failures and > >> retries. > > > > i ran kdump, instead of linux_kdump and it seems the freebsd function returning > > EAGAIN is nanosleep(2): > > > > 929 futex_wait CALL nanosleep(0xffffdb5c,0x81,0x1,0,0,0) > > 9929 futex_wait RET nanosleep 0 > > 9929 futex_wait CALL nanosleep(0xffffdb5c,0x81,0x1,0,0,0) > > 9928 futex_wait CALL nanosleep(0xffffdb5c,0x80,0x2,0,0,0) > > 9929 futex_wait RET nanosleep 0 > > 9928 futex_wait RET nanosleep -1 errno 35 Resource temporarily unavailable > > 9929 futex_wait CALL nanosleep(0xffffdb5c,0x81,0x1,0,0,0) > > 9928 futex_wait CALL nanosleep(0xffffdb5c,0x80,0x2,0,0,0) > > 9929 futex_wait RET nanosleep 0 > > 9928 futex_wait RET nanosleep -1 errno 35 Resource temporarily unavailable > > 9929 futex_wait CALL nanosleep(0xffffdb5c,0x80,0x2,0,0,0) > > 9928 futex_wait CALL nanosleep(0xffffdb5c,0x81,0x1,0,0,0) > > 9929 futex_wait RET nanosleep -1 errno 35 Resource temporarily unavailable > > 9928 futex_wait RET nanosleep 0 > > 9929 futex_wait CALL nanosleep(0xffffdb5c,0x81,0x1,0,0,0) > > 9929 futex_wait RET nanosleep 0 > > 9929 futex_wait CALL nanosleep(0xffffdb5c,0x80,0x2,0,0,0) > > 9928 futex_wait CALL nanosleep(0xffffdb5c,0x81,0x1,0,0,0) > > 9929 futex_wait RET nanosleep -1 errno 35 Resource temporarily unavailable > > 9928 futex_wait RET nanosleep 0 > > 9929 futex_wait CALL nanosleep(0xffffdb5c,0x81,0x1,0,0,0) > > 9929 futex_wait RET nanosleep 0 > > 9928 futex_wait CALL nanosleep(0xffffdb5c,0x81,0x1,0,0,0) > > 9929 futex_wait CALL nanosleep(0xffffdb5c,0x80,0x2,0,0,0) > > 9928 futex_wait RET nanosleep 0 > > 9929 futex_wait RET nanosleep -1 errno 35 Resource temporarily unavailable > > 9929 futex_wait CALL nanosleep(0xffffdb5c,0x80,0x2,0,0,0) > > 9928 futex_wait CALL nanosleep(0xffffdb5c,0x81,0x1,0,0,0) > > 9929 futex_wait RET nanosleep -1 errno 35 Resource temporarily unavailable > > > > so this seems to be the location in linux_futex.c where error gets set to > > EAGAIN: > > > > static int > > futex_sleep(struct futex *f, struct waiting_proc *wp, int timeout) > > { > > int error; > > > > FUTEX_ASSERT_LOCKED(f); > > LINUX_CTR4(sys_futex, "futex_sleep enter uaddr %p wp %p timo %d ref %d", > > f->f_uaddr, wp, timeout, f->f_refcount); > > error = sx_sleep(wp, &f->f_lck, PCATCH, "futex", timeout); > > ^^^^ > > > > according to nanosleep(2) however EAGAIN is not a valid return value...i'm > > lost. :( > > Don't trust the manpage young padawan (I wish one could, but not > all manpages are updated in a timely manner, in particular the kernel > ones I've discovered :(...). The one spot where it could be completely > screwing things up is with timer_create (it's the one logical spot in > sys/kern/... that returns EAGAIN), and this might make sense if our > clock values weren't being translated over properly for the > linuxulator and clocks were getting screwed up somewhere. > Well, that and clock_nanosleep, isn't implemented, and I wouldn't > be so sure if it's sane when compared to what Linux's clocks/timers do > (sane being equivalent, not necessarily right). > Something I ranted about in another PR: > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/150095 . > So, that might be something worth looking into or not. It's up to > you *shrugs*. thanks a lot for the help. i'll defenately check that one out. i also found maybe another cause for the problems via google. it might be that the futex code or maybe linux threads in general are using PTHREAD_SCOPE_SYSTEM and not PTHREAD_SCOPE_PROCESS. using PTHREAD_SCOPE_PROCESS no thread limits seem to apply. PTHREAD_SCOPE_SYSTEM on the other hand seems to be limited by two sysctl's: kern.threads.max_threads_per_proc kern.threads.max_groups_per_proc the latter one however doesn't exist anymore in 9.0 CURRENT and i can't find any hint about what happend to it. this would also make sense, since kern.threads.max_groups_per_proc used to be preset to 50 and if you have a look at the testcase you'll see that with 32 threads the test succeeds, while with 64 threads it fails. cheers. alex > HTH, > -Garrett -- a13x From owner-freebsd-current@FreeBSD.ORG Wed Feb 23 12:56:46 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 385011065783; Wed, 23 Feb 2011 12:56:46 +0000 (UTC) Date: Wed, 23 Feb 2011 12:56:46 +0000 From: Alexander Best To: Garrett Cooper Message-ID: <20110223125646.GA51930@freebsd.org> References: <20110222203134.GA53262@freebsd.org> <20110222215036.GA66303@freebsd.org> <20110222223314.GA72748@freebsd.org> <20110223020008.GA94832@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Cc: Brandon Gooch , Eir Nym , Dimitry Andric , FreeBSD Current Subject: Re: Wow... (<-- blown away at performance) 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, 23 Feb 2011 12:56:46 -0000 On Tue Feb 22 11, Garrett Cooper wrote: > On Tue, Feb 22, 2011 at 6:00 PM, Alexander Best wrote: > > On Tue Feb 22 11, Alexander Best wrote: > >> On Tue Feb 22 11, Alexander Best wrote: > >> > On Tue Feb 22 11, Brandon Gooch wrote: > >> > > On Tue, Feb 22, 2011 at 2:31 PM, Alexander Best wrote: > >> > > > On Tue Feb 22 11, Garrett Cooper wrote: > >> > > >> On Tue, Feb 22, 2011 at 2:10 AM, Eir Nym wrote: > >> > > >> > On 22 February 2011 11:15, Garrett Cooper wrote: > >> > > >> >> I don't know what to say, but r218938 screams with flash videos > >> > > >> >> (native Linux speed). Not sure if it's the new binutils or if it's the > >> > > >> >> new linuxulator patches, but I can run multiple instances of youtube > >> > > >> >> in parallel (5 total with other miscellaneous flash animation) without > >> > > >> >> it totally lagging out Firefox/X11, and it appears to close the > >> > > >> >> instances of firefox properly now. Hopefully this version fares better > >> > > >> >> than r218113 did (I think I hit a kernel bug after 2 weeks uptime, > >> > > >> >> where my system just hardlocked for no apparent reason). > >> > > >> >> Anyhow, hope others have similar results. > >> > > >> >> Cheers! > >> > > >> >> -Garrett > >> > > >> >> > >> > > >> >> $ uname -a > >> > > >> >> FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r218938M: > >> > > >> >> Mon Feb 21 23:10:51 PST 2011 > >> > > >> >> gcooper@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 > >> > > >> > > >> > > >> > Which FlashPlayer version do you test? Adobe has made significant > >> > > >> > performance changes in 10.2 (from 10.1). You can search for StageVideo > >> > > >> > performance to learn more about. Youtube already use them since 10.2 > >> > > >> > beta > >> > > >> > >> > > >> linux-f10-flashplugin-10.1r102.65 . The performance increases are > >> > > >> claimed to be "up to 85%" on the Stage Video site, but I'm seeing a > >> > > >> more than 200% increase (now it actually scales between multiple > >> > > >> instances, instead of croaks with one instance, tiling up and down the > >> > > >> screen when moving the window slider for instance or switching tabs). > >> > > >> Besides, it seems like it needs external support from the video > >> > > >> driver, and I'm not sure that that bridge exists in the linuxulator. > >> > > >> Also, it looks like npviewer.bin still hangs to resources on until > >> > > >> Firefox closes (or I kill it :)..), so something still needs to be > >> > > >> resolved there, but that isn't a regression (it's acted that way for > >> > > >> ages), and shouldn't be too hard to do. > >> > > > > >> > > > i think the problem with npviewer.bin having to be killed by hand is a futex > >> > > > issue in combination with a high number of threads. this is the output of a > >> > > > test from darren hart's futex test suite under freebsd 9.0: > >> > > > > >> > > > futex_wait: Measure FUTEX_WAIT operations per second > >> > > > Arguments: iterations=100000000 threads=1 > >> > > > Result: 18622 Kiter/s > >> > > > futex_wait: Measure FUTEX_WAIT operations per second > >> > > > Arguments: iterations=100000000 threads=2 > >> > > > Result: 15469 Kiter/s > >> > > > futex_wait: Measure FUTEX_WAIT operations per second > >> > > > Arguments: iterations=100000000 threads=3 > >> > > > Result: 12713 Kiter/s > >> > > > futex_wait: Measure FUTEX_WAIT operations per second > >> > > > Arguments: iterations=100000000 threads=4 > >> > > > Result: 12247 Kiter/s > >> > > > futex_wait: Measure FUTEX_WAIT operations per second > >> > > > Arguments: iterations=100000000 threads=5 > >> > > > Result: 11814 Kiter/s > >> > > > futex_wait: Measure FUTEX_WAIT operations per second > >> > > > Arguments: iterations=100000000 threads=6 > >> > > > Result: 13468 Kiter/s > >> > > > futex_wait: Measure FUTEX_WAIT operations per second > >> > > > Arguments: iterations=100000000 threads=8 > >> > > > Result: 12061 Kiter/s > >> > > > futex_wait: Measure FUTEX_WAIT operations per second > >> > > > Arguments: iterations=100000000 threads=10 > >> > > > Result: 12854 Kiter/s > >> > > > futex_wait: Measure FUTEX_WAIT operations per second > >> > > > Arguments: iterations=100000000 threads=12 > >> > > > Result: 12999 Kiter/s > >> > > > futex_wait: Measure FUTEX_WAIT operations per second > >> > > > Arguments: iterations=100000000 threads=16 > >> > > > Result: 12402 Kiter/s > >> > > > futex_wait: Measure FUTEX_WAIT operations per second > >> > > > Arguments: iterations=100000000 threads=24 > >> > > > Result: 9815 Kiter/s > >> > > > futex_wait: Measure FUTEX_WAIT operations per second > >> > > > Arguments: iterations=100000000 threads=32 > >> > > > Result: 8518 Kiter/s > >> > > > futex_wait: Measure FUTEX_WAIT operations per second > >> > > > Arguments: iterations=100000000 threads=64 > >> > > > ERROR: Resource temporarily unavailable: pthread_create > >> > > > Result: ERROR > >> > > > futex_wait: Measure FUTEX_WAIT operations per second > >> > > > Arguments: iterations=100000000 threads=128 > >> > > > ERROR: Resource temporarily unavailable: pthread_create > >> > > > Result: ERROR > >> > > > futex_wait: Measure FUTEX_WAIT operations per second > >> > > > Arguments: iterations=100000000 threads=256 > >> > > > ERROR: Resource temporarily unavailable: pthread_create > >> > > > Result: ERROR > >> > > > futex_wait: Measure FUTEX_WAIT operations per second > >> > > > Arguments: iterations=100000000 threads=512 > >> > > > ERROR: Resource temporarily unavailable: pthread_create > >> > > > Result: ERROR > >> > > > futex_wait: Measure FUTEX_WAIT operations per second > >> > > > Arguments: iterations=100000000 threads=1024 > >> > > > ERROR: Resource temporarily unavailable: pthread_create > >> > > > Result: ERROR > >> > > > > >> > > > cheers. > >> > > > alex > >> > > > >> > > Have you found any method or workaround to mitigate this issue? > >> > >> i did a ktrace -i and linux_kdump run and the results are quite interesting. > >> with only 1 thread linux_sys_futex() *never* failed with EAGAIN. starting > >> with 2 threads however i'm seeing an increasing number of linux_sys_futex() > >> failures (all with EAGAIN). > >> > >> the overhead is quite massive. linux_kdump > /tmp/futex-failure produced 941 > >> megs of output. doing > >> grep -v "futex_wait" futex-failure > futex-grep > >> produces an output of 192K!! so it's quite obvious that the futex_wait stuff > >> is responsible for causing massive activity, due to the constant failures and > >> retries. > > > > i ran kdump, instead of linux_kdump and it seems the freebsd function returning > > EAGAIN is nanosleep(2): > > > > 929 futex_wait CALL nanosleep(0xffffdb5c,0x81,0x1,0,0,0) > > 9929 futex_wait RET nanosleep 0 > > 9929 futex_wait CALL nanosleep(0xffffdb5c,0x81,0x1,0,0,0) > > 9928 futex_wait CALL nanosleep(0xffffdb5c,0x80,0x2,0,0,0) > > 9929 futex_wait RET nanosleep 0 > > 9928 futex_wait RET nanosleep -1 errno 35 Resource temporarily unavailable > > 9929 futex_wait CALL nanosleep(0xffffdb5c,0x81,0x1,0,0,0) > > 9928 futex_wait CALL nanosleep(0xffffdb5c,0x80,0x2,0,0,0) > > 9929 futex_wait RET nanosleep 0 > > 9928 futex_wait RET nanosleep -1 errno 35 Resource temporarily unavailable > > 9929 futex_wait CALL nanosleep(0xffffdb5c,0x80,0x2,0,0,0) > > 9928 futex_wait CALL nanosleep(0xffffdb5c,0x81,0x1,0,0,0) > > 9929 futex_wait RET nanosleep -1 errno 35 Resource temporarily unavailable > > 9928 futex_wait RET nanosleep 0 > > 9929 futex_wait CALL nanosleep(0xffffdb5c,0x81,0x1,0,0,0) > > 9929 futex_wait RET nanosleep 0 > > 9929 futex_wait CALL nanosleep(0xffffdb5c,0x80,0x2,0,0,0) > > 9928 futex_wait CALL nanosleep(0xffffdb5c,0x81,0x1,0,0,0) > > 9929 futex_wait RET nanosleep -1 errno 35 Resource temporarily unavailable > > 9928 futex_wait RET nanosleep 0 > > 9929 futex_wait CALL nanosleep(0xffffdb5c,0x81,0x1,0,0,0) > > 9929 futex_wait RET nanosleep 0 > > 9928 futex_wait CALL nanosleep(0xffffdb5c,0x81,0x1,0,0,0) > > 9929 futex_wait CALL nanosleep(0xffffdb5c,0x80,0x2,0,0,0) > > 9928 futex_wait RET nanosleep 0 > > 9929 futex_wait RET nanosleep -1 errno 35 Resource temporarily unavailable > > 9929 futex_wait CALL nanosleep(0xffffdb5c,0x80,0x2,0,0,0) > > 9928 futex_wait CALL nanosleep(0xffffdb5c,0x81,0x1,0,0,0) > > 9929 futex_wait RET nanosleep -1 errno 35 Resource temporarily unavailable > > > > so this seems to be the location in linux_futex.c where error gets set to > > EAGAIN: > > > > static int > > futex_sleep(struct futex *f, struct waiting_proc *wp, int timeout) > > { > > int error; > > > > FUTEX_ASSERT_LOCKED(f); > > LINUX_CTR4(sys_futex, "futex_sleep enter uaddr %p wp %p timo %d ref %d", > > f->f_uaddr, wp, timeout, f->f_refcount); > > error = sx_sleep(wp, &f->f_lck, PCATCH, "futex", timeout); > > ^^^^ > > > > according to nanosleep(2) however EAGAIN is not a valid return value...i'm > > lost. :( > > Don't trust the manpage young padawan (I wish one could, but not > all manpages are updated in a timely manner, in particular the kernel > ones I've discovered :(...). The one spot where it could be completely > screwing things up is with timer_create (it's the one logical spot in > sys/kern/... that returns EAGAIN), and this might make sense if our > clock values weren't being translated over properly for the > linuxulator and clocks were getting screwed up somewhere. > Well, that and clock_nanosleep, isn't implemented, and I wouldn't > be so sure if it's sane when compared to what Linux's clocks/timers do > (sane being equivalent, not necessarily right). > Something I ranted about in another PR: > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/150095 . i applied the patch (the 2nd one) and that didn't solve the issue. > So, that might be something worth looking into or not. It's up to > you *shrugs*. > HTH, > -Garrett -- a13x From owner-freebsd-current@FreeBSD.ORG Wed Feb 23 13:15: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 6A330106566C; Wed, 23 Feb 2011 13:15:46 +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 360EB8FC15; Wed, 23 Feb 2011 13:15:46 +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 A2E6846B0C; Wed, 23 Feb 2011 08:15:45 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.10]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id AEEC88A01D; Wed, 23 Feb 2011 08:15:44 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Date: Wed, 23 Feb 2011 07:51:29 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.4-CBSD-20110107; KDE/4.4.5; amd64; ; ) References: <20110222215036.GA66303@freebsd.org> In-Reply-To: <20110222215036.GA66303@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201102230751.29885.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 23 Feb 2011 08:15:44 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=0.5 required=4.2 tests=BAYES_00,MAY_BE_FORGED, RDNS_DYNAMIC autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Brandon Gooch , Alexander Best , Eir Nym , Dimitry Andric , Garrett Cooper Subject: Re: Wow... (<-- blown away at performance) 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, 23 Feb 2011 13:15:46 -0000 On Tuesday, February 22, 2011 4:50:36 pm Alexander Best wrote: > On Tue Feb 22 11, Brandon Gooch wrote: > > On Tue, Feb 22, 2011 at 2:31 PM, Alexander Best wrote: > > > On Tue Feb 22 11, Garrett Cooper wrote: > > >> On Tue, Feb 22, 2011 at 2:10 AM, Eir Nym wrote: > > >> > On 22 February 2011 11:15, Garrett Cooper wrote: > > >> >> I don't know what to say, but r218938 screams with flash videos > > >> >> (native Linux speed). Not sure if it's the new binutils or if it's the > > >> >> new linuxulator patches, but I can run multiple instances of youtube > > >> >> in parallel (5 total with other miscellaneous flash animation) without > > >> >> it totally lagging out Firefox/X11, and it appears to close the > > >> >> instances of firefox properly now. Hopefully this version fares better > > >> >> than r218113 did (I think I hit a kernel bug after 2 weeks uptime, > > >> >> where my system just hardlocked for no apparent reason). > > >> >> Anyhow, hope others have similar results. > > >> >> Cheers! > > >> >> -Garrett > > >> >> > > >> >> $ uname -a > > >> >> FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r218938M: > > >> >> Mon Feb 21 23:10:51 PST 2011 > > >> >> gcooper@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 > > >> > > > >> > Which FlashPlayer version do you test? Adobe has made significant > > >> > performance changes in 10.2 (from 10.1). You can search for StageVideo > > >> > performance to learn more about. Youtube already use them since 10.2 > > >> > beta > > >> > > >> linux-f10-flashplugin-10.1r102.65 . The performance increases are > > >> claimed to be "up to 85%" on the Stage Video site, but I'm seeing a > > >> more than 200% increase (now it actually scales between multiple > > >> instances, instead of croaks with one instance, tiling up and down the > > >> screen when moving the window slider for instance or switching tabs). > > >> Besides, it seems like it needs external support from the video > > >> driver, and I'm not sure that that bridge exists in the linuxulator. > > >> Also, it looks like npviewer.bin still hangs to resources on until > > >> Firefox closes (or I kill it :)..), so something still needs to be > > >> resolved there, but that isn't a regression (it's acted that way for > > >> ages), and shouldn't be too hard to do. > > > > > > i think the problem with npviewer.bin having to be killed by hand is a futex > > > issue in combination with a high number of threads. this is the output of a > > > test from darren hart's futex test suite under freebsd 9.0: > > > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=100000000 threads=1 > > > Result: 18622 Kiter/s > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=100000000 threads=2 > > > Result: 15469 Kiter/s > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=100000000 threads=3 > > > Result: 12713 Kiter/s > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=100000000 threads=4 > > > Result: 12247 Kiter/s > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=100000000 threads=5 > > > Result: 11814 Kiter/s > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=100000000 threads=6 > > > Result: 13468 Kiter/s > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=100000000 threads=8 > > > Result: 12061 Kiter/s > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=100000000 threads=10 > > > Result: 12854 Kiter/s > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=100000000 threads=12 > > > Result: 12999 Kiter/s > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=100000000 threads=16 > > > Result: 12402 Kiter/s > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=100000000 threads=24 > > > Result: 9815 Kiter/s > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=100000000 threads=32 > > > Result: 8518 Kiter/s > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=100000000 threads=64 > > > ERROR: Resource temporarily unavailable: pthread_create > > > Result: ERROR > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=100000000 threads=128 > > > ERROR: Resource temporarily unavailable: pthread_create > > > Result: ERROR > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=100000000 threads=256 > > > ERROR: Resource temporarily unavailable: pthread_create > > > Result: ERROR > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=100000000 threads=512 > > > ERROR: Resource temporarily unavailable: pthread_create > > > Result: ERROR > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=100000000 threads=1024 > > > ERROR: Resource temporarily unavailable: pthread_create > > > Result: ERROR > > > > > > cheers. > > > alex > > > > Have you found any method or workaround to mitigate this issue? > > no. i've increased the kern.threads.max_threads_per_proc value, but that had > no effect. so it seems to be a bug in the linuxulator's futex implementation. You can try http://www.freebsd.org/~jhb/patches/futex_share.patch Not sure if it will solve your issue, but it might help if multiple processes (Linux processes, not just multiple FreeBSD processes masquerading as threads in a single Linux process) are involved. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Feb 23 13:22: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 48070106566B; Wed, 23 Feb 2011 13:22:38 +0000 (UTC) (envelope-from datastream.freecity@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 E2BD98FC22; Wed, 23 Feb 2011 13:22:35 +0000 (UTC) Received: by gyh4 with SMTP id 4so2031626gyh.13 for ; Wed, 23 Feb 2011 05:22:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=FNhiA9kXi3G7N2oz4nIqBMwINSDCnk2nTV80Fl4sGog=; b=WeFHGxFtKkETQ4J9TGhDjWdf0vLgmFXKz4fPtAjRoXctfzUGmAI3Hnf45x8RhuWBPy Zhh0akNvLXJIU04IIYfX2jhR6LZEze1PeHRurxO6UA5/AIllnQInleYEqPf0xO+78clr 7+B0CFSY0Xf70BdGeNqSrJIGPLxrFzv17Tp6c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=xK7gCg2hlyqsDdRcMS6W+M902SCmpwyQyf2pQhgABNquOJ5q+qed2Tj+/UgcwoO6i9 MqIQQu9v5W+jidpu81cc1r++UytcKPA2Jzxx26CDDnKp/1FiBf2AZpp1v3i+ceVCLC5V robMVvq9bTpWGI/tRfdjQ3YG107+FDy1efOd0= MIME-Version: 1.0 Received: by 10.150.192.8 with SMTP id p8mr4991816ybf.405.1298467354627; Wed, 23 Feb 2011 05:22:34 -0800 (PST) Received: by 10.151.47.7 with HTTP; Wed, 23 Feb 2011 05:22:34 -0800 (PST) In-Reply-To: <4D63D28B.4080900@FreeBSD.org> References: <4D627FBE.1070700@FreeBSD.org> <4D63D28B.4080900@FreeBSD.org> Date: Wed, 23 Feb 2011 21:22:34 +0800 Message-ID: From: "datastream datastream.freecity" To: Dimitry Andric Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Olivier Smedts , freebsd-current@freebsd.org Subject: Re: Can't buildworld since Clang update 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, 23 Feb 2011 13:22:38 -0000 I deleted all files in /usr/src and /usr/obj. it changes nothing, i still get same error. In /etc/make.conf: .if !defined(CC) || ${CC} == "cc" CC=clang .endif .if !defined(CXX) || ${CXX} == "c++" CXX=clang++ .endif # Don't die on warnings NO_WERROR= WERROR= STRIP= CFLAGS+=-fno-omit-frame-pointer On Tue, Feb 22, 2011 at 11:13 PM, Dimitry Andric wrote: > On 2011-02-22 15:37, datastream datastream.freecity wrote: > >> I add '-no-integrated-as' in /etc/make.conf,but I still failed. >> > > Don't do that. The few instances where the integrated assembler needs > to be disabled are already covered. > > > ... > > /usr/obj/usr/src/tmp/lib/libthr.so.3: undefined reference to >> `_rtld_get_stack_prot' >> > > Something seems to be seriously wrong in your tree. Can you try to blow > away /usr/obj entirely, remove the -no-integrated-as flag from > make.conf, and try again? > From owner-freebsd-current@FreeBSD.ORG Wed Feb 23 13:02:30 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 13AB7106566B for ; Wed, 23 Feb 2011 13:02:30 +0000 (UTC) (envelope-from mitya@cabletv.dp.ua) Received: from mail.cabletv.dp.ua (mail.cabletv.dp.ua [193.34.20.8]) by mx1.freebsd.org (Postfix) with ESMTP id C4DD58FC08 for ; Wed, 23 Feb 2011 13:02:29 +0000 (UTC) Received: from [193.34.20.2] (helo=m18.cabletv.dp.ua) by mail.cabletv.dp.ua with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PsE2z-000HaB-Mt for freebsd-current@freebsd.org; Wed, 23 Feb 2011 14:42:25 +0200 Message-ID: <4D64FF99.2070908@cabletv.dp.ua> Date: Wed, 23 Feb 2011 14:37:45 +0200 From: Mitya User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; ru-RU; rv:1.9.2.13) Gecko/20101213 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 23 Feb 2011 13:25:59 +0000 Subject: Cosmetic path to bsdinstall 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, 23 Feb 2011 13:02:30 -0000 Add usually used RAID controller --- usr.sbin/bsdinstall/partedit/part_wizard.c.orig 2011-02-19 17:22:06.000000000 +0200 +++ usr.sbin/bsdinstall/partedit/part_wizard.c 2011-02-21 17:20:28.000000000 +0200 @@ -122,6 +122,18 @@ strcat(diskdesc, " ATA Hard Disk"); else if (strncmp(pp->lg_name, "da", 2) == 0) strcat(diskdesc, " SCSI Hard Disk"); + else if (strncmp(pp->lg_name, "aacd", 4) == 0) + strcat(diskdesc, " Adaptec Raid Disk"); + else if (strncmp(pp->lg_name, "amrd", 4) == 0) + strcat(diskdesc, " LSI Raid Disk"); + else if (strncmp(pp->lg_name, "mfid", 4) == 0) + strcat(diskdesc, " LSI Raid Disk"); + else if (strncmp(pp->lg_name, "mlxd", 4) == 0) + strcat(diskdesc, " Mylex Raid Disk"); + else if (strncmp(pp->lg_name, "twed", 4) == 0) + strcat(diskdesc, " 3ware Raid Disk"); + else if (strncmp(pp->lg_name, "pst", 3) == 0) + strcat(diskdesc, " Promise Raid Disk"); else if (strncmp(pp->lg_name, "md", 2) == 0) strcat(diskdesc, " Memory Disk"); else if (strncmp(pp->lg_name, "cd", 2) == 0) { From owner-freebsd-current@FreeBSD.ORG Wed Feb 23 13:31: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 75A75106566C for ; Wed, 23 Feb 2011 13:31:56 +0000 (UTC) (envelope-from rbgarga@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id C8E718FC0A for ; Wed, 23 Feb 2011 13:31:55 +0000 (UTC) Received: by fxm19 with SMTP id 19so4792261fxm.13 for ; Wed, 23 Feb 2011 05:31:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=1noBvkIAAGUppQ9VND8JXMHxZYLUrxHtdkXmjllSHqw=; b=TGigL1vF01EI6rM+7NfZ01rrwW9rlbSjxzLrjVF4Y5odpzPsd6U9isDwxqyE2/7EPh SOGQNF8HgQ3QVmgIflg5J2Vw2uVXIsES9NEq8v7FxGhVjS/JrcLHUaDpU/nVjNeWhyiK ZYpQTCLD0BsSNtKcXXXS8KfTxZZyBGl8JAQns= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=NDHGMN/TVQaEtBy/XkXthTOw911uKjf71fIjXsVPgyMUsApwt2D4Kg3XdFbDgyGfAn hVRiN1OI4m/6t0O4SjSGhCsby1tMQ0b5lu/p692+rUjZEpu0Y9dL8xMg2yt/KCN6hf0k KG0LtRqdZX4jQ3OpgqmcF4RHiCkuwoUBH+N0A= Received: by 10.223.63.75 with SMTP id a11mr2109991fai.88.1298467914076; Wed, 23 Feb 2011 05:31:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.98.203 with HTTP; Wed, 23 Feb 2011 05:31:34 -0800 (PST) In-Reply-To: References: <4D627FBE.1070700@FreeBSD.org> <4D63D28B.4080900@FreeBSD.org> From: Renato Botelho Date: Wed, 23 Feb 2011 10:31:34 -0300 Message-ID: To: "datastream datastream.freecity" Content-Type: text/plain; charset=ISO-8859-1 Cc: Olivier Smedts , freebsd-current@freebsd.org, Dimitry Andric Subject: Re: Can't buildworld since Clang update 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, 23 Feb 2011 13:31:56 -0000 On Wed, Feb 23, 2011 at 10:22 AM, datastream datastream.freecity wrote: > I deleted all files in /usr/src and /usr/obj. it changes nothing, i still > get same error. > > In /etc/make.conf: > .if !defined(CC) || ${CC} == "cc" > CC=clang > .endif > .if !defined(CXX) || ${CXX} == "c++" > CXX=clang++ > .endif > # Don't die on warnings > NO_WERROR= > WERROR= > STRIP= > CFLAGS+=-fno-omit-frame-pointer I'm not having problems here, my /etc/make.conf contains: .if ${.CURDIR:N*usr/src*}=="" . if !defined(CC) || ${CC} == "cc" CC=clang . endif . if !defined(CXX) || ${CXX} == "c++" CXX=clang++ . endif # Don't die on warnings NO_WERROR= WERROR= .endif And my /etc/src.conf: .if !defined(CC) || ${CC} == "cc" CC=clang .endif .if !defined(CXX) || ${CXX} == "c++" CXX=clang++ .endif # Don't die on warnings NO_WERROR= WERROR= It's building fine with clang. -- Renato Botelho From owner-freebsd-current@FreeBSD.ORG Wed Feb 23 13:45:19 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 7F8FF1065673; Wed, 23 Feb 2011 13:45:19 +0000 (UTC) Date: Wed, 23 Feb 2011 13:45:19 +0000 From: Alexander Best To: John Baldwin Message-ID: <20110223134519.GA59694@freebsd.org> References: <20110222215036.GA66303@freebsd.org> <201102230751.29885.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201102230751.29885.jhb@freebsd.org> Cc: Brandon Gooch , Garrett Cooper , freebsd-current@freebsd.org, Dimitry Andric , Eir Nym Subject: Re: Wow... (<-- blown away at performance) 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, 23 Feb 2011 13:45:19 -0000 On Wed Feb 23 11, John Baldwin wrote: > On Tuesday, February 22, 2011 4:50:36 pm Alexander Best wrote: > > On Tue Feb 22 11, Brandon Gooch wrote: > > > On Tue, Feb 22, 2011 at 2:31 PM, Alexander Best > wrote: > > > > On Tue Feb 22 11, Garrett Cooper wrote: > > > >> On Tue, Feb 22, 2011 at 2:10 AM, Eir Nym wrote: > > > >> > On 22 February 2011 11:15, Garrett Cooper wrote: > > > >> >> I don't know what to say, but r218938 screams with flash videos > > > >> >> (native Linux speed). Not sure if it's the new binutils or if it's > the > > > >> >> new linuxulator patches, but I can run multiple instances of youtube > > > >> >> in parallel (5 total with other miscellaneous flash animation) > without > > > >> >> it totally lagging out Firefox/X11, and it appears to close the > > > >> >> instances of firefox properly now. Hopefully this version fares > better > > > >> >> than r218113 did (I think I hit a kernel bug after 2 weeks uptime, > > > >> >> where my system just hardlocked for no apparent reason). > > > >> >> Anyhow, hope others have similar results. > > > >> >> Cheers! > > > >> >> -Garrett > > > >> >> > > > >> >> $ uname -a > > > >> >> FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r218938M: > > > >> >> Mon Feb 21 23:10:51 PST 2011 > > > >> >> gcooper@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 > > > >> > > > > >> > Which FlashPlayer version do you test? Adobe has made significant > > > >> > performance changes in 10.2 (from 10.1). You can search for > StageVideo > > > >> > performance to learn more about. Youtube already use them since 10.2 > > > >> > beta > > > >> > > > >> linux-f10-flashplugin-10.1r102.65 . The performance increases are > > > >> claimed to be "up to 85%" on the Stage Video site, but I'm seeing a > > > >> more than 200% increase (now it actually scales between multiple > > > >> instances, instead of croaks with one instance, tiling up and down the > > > >> screen when moving the window slider for instance or switching tabs). > > > >> Besides, it seems like it needs external support from the video > > > >> driver, and I'm not sure that that bridge exists in the linuxulator. > > > >> Also, it looks like npviewer.bin still hangs to resources on until > > > >> Firefox closes (or I kill it :)..), so something still needs to be > > > >> resolved there, but that isn't a regression (it's acted that way for > > > >> ages), and shouldn't be too hard to do. > > > > > > > > i think the problem with npviewer.bin having to be killed by hand is a > futex > > > > issue in combination with a high number of threads. this is the output > of a > > > > test from darren hart's futex test suite under freebsd 9.0: > > > > > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=1 > > > > Result: 18622 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=2 > > > > Result: 15469 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=3 > > > > Result: 12713 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=4 > > > > Result: 12247 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=5 > > > > Result: 11814 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=6 > > > > Result: 13468 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=8 > > > > Result: 12061 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=10 > > > > Result: 12854 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=12 > > > > Result: 12999 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=16 > > > > Result: 12402 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=24 > > > > Result: 9815 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=32 > > > > Result: 8518 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=64 > > > > ERROR: Resource temporarily unavailable: pthread_create > > > > Result: ERROR > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=128 > > > > ERROR: Resource temporarily unavailable: pthread_create > > > > Result: ERROR > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=256 > > > > ERROR: Resource temporarily unavailable: pthread_create > > > > Result: ERROR > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=512 > > > > ERROR: Resource temporarily unavailable: pthread_create > > > > Result: ERROR > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=1024 > > > > ERROR: Resource temporarily unavailable: pthread_create > > > > Result: ERROR > > > > > > > > cheers. > > > > alex > > > > > > Have you found any method or workaround to mitigate this issue? > > > > no. i've increased the kern.threads.max_threads_per_proc value, but that had > > no effect. so it seems to be a bug in the linuxulator's futex > implementation. > > You can try http://www.freebsd.org/~jhb/patches/futex_share.patch > > Not sure if it will solve your issue, but it might help if multiple > processes (Linux processes, not just multiple FreeBSD processes > masquerading as threads in a single Linux process) are involved. no unfortunately. i don't think the failures with threads 64-1024 are futex related, since linux_mmap2() returns -ENOMEN and thus seems responsible. however even with your patch i still see lots of linux_sys_futex() calls failing with -EAGAIN in the range of 2-32 threads. it seems nanosleep is failing. either because some linux timespecs aren't converted to their *BSD equivalents properly or another reason could be that CLOCK_MONOTONIC and CLOCK_REALTIME aren't yet honoured in linux_futex.c, but simply discarded. the actual place in linux_futex.c where EAGAIN gets handed over to the linuxulator is here: static int futex_sleep(struct futex *f, struct waiting_proc *wp, int timeout) { int error; FUTEX_ASSERT_LOCKED(f); LINUX_CTR4(sys_futex, "futex_sleep enter uaddr %p wp %p timo %d ref %d", f->f_uaddr, wp, timeout, f->f_refcount); error = sx_sleep(wp, &f->f_lck, PCATCH, "futex", timeout); // HERE EAGAIN GETS RETURNED cheers. alex > > -- > John Baldwin -- a13x From owner-freebsd-current@FreeBSD.ORG Wed Feb 23 16:04: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 9CC96106566C for ; Wed, 23 Feb 2011 16:04:16 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 5914A8FC0A for ; Wed, 23 Feb 2011 16:04:16 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:1131:79f:9a2b:b0a3] (unknown [IPv6:2001:7b8:3a7:0:1131:79f:9a2b:b0a3]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 4AB565C37; Wed, 23 Feb 2011 17:04:15 +0100 (CET) Message-ID: <4D653007.9080103@FreeBSD.org> Date: Wed, 23 Feb 2011 17:04:23 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.15pre) Gecko/20110221 Lanikai/3.1.9pre MIME-Version: 1.0 To: "datastream datastream.freecity" References: <4D627FBE.1070700@FreeBSD.org> <4D63D28B.4080900@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Olivier Smedts , freebsd-current@freebsd.org Subject: Re: Can't buildworld since Clang update 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, 23 Feb 2011 16:04:16 -0000 On 2011-02-23 14:22, datastream datastream.freecity wrote: > I deleted all files in /usr/src and /usr/obj. it changes nothing, i still > get same error. > > In /etc/make.conf: > .if !defined(CC) || ${CC} == "cc" > CC=clang > .endif > .if !defined(CXX) || ${CXX} == "c++" > CXX=clang++ > .endif > # Don't die on warnings > NO_WERROR= > WERROR= > STRIP= > CFLAGS+=-fno-omit-frame-pointer I just did a full buildworld and buildkernel with exactly these settings (deleted src.conf), and it worked fine. Is there any more information you can supply? E.g. which exact revision of the tree are you trying to build, which version of clang are you using, version of binutils, or any other non-default environment settings? From owner-freebsd-current@FreeBSD.ORG Wed Feb 23 16:24: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 05DBF1065695 for ; Wed, 23 Feb 2011 16:24:27 +0000 (UTC) (envelope-from james-freebsd-current@jrv.org) Received: from zimbra.jrv.org (rrcs-24-73-246-106.sw.biz.rr.com [24.73.246.106]) by mx1.freebsd.org (Postfix) with ESMTP id BC9588FC29 for ; Wed, 23 Feb 2011 16:24:26 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zimbra.jrv.org (Postfix) with ESMTP id 950A016A070; Wed, 23 Feb 2011 10:15:25 -0600 (CST) X-Virus-Scanned: amavisd-new at zimbra.housenet.jrv Received: from zimbra.jrv.org ([127.0.0.1]) by localhost (zimbra.housenet.jrv [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KKsYMMI-JIqi; Wed, 23 Feb 2011 10:15:16 -0600 (CST) Received: from [10.0.2.15] (adsl-99-66-60-250.dsl.aus2tx.sbcglobal.net [99.66.60.250]) by zimbra.jrv.org (Postfix) with ESMTPSA id B3C1D16A04E; Wed, 23 Feb 2011 10:15:15 -0600 (CST) Message-ID: <4D65328D.3050709@jrv.org> Date: Wed, 23 Feb 2011 10:15:09 -0600 From: "James R. Van Artsdalen" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Peter Jeremy References: <4D35CFFB.3010302@freebsd.org> <201102211612.51233.josh@tcbug.org> <201102220103.20158.josh@tcbug.org> <20110222205741.GA34103@server.vk2pj.dyndns.org> In-Reply-To: <20110222205741.GA34103@server.vk2pj.dyndns.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Devin Teske , freebsd-sysinstall@freebsd.org, freebsd-arch@freebsd.org Subject: Re: FreeBSD Installer Roadmap 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, 23 Feb 2011 16:24:27 -0000 On 2/22/2011 2:57 PM, Peter Jeremy wrote: > When that does come, it will probably be driven by BIOS and hardware > vendors dropping support for MBR. MBR is not a BIOS concept. MBR is an OS thing. The BIOS does not care or know what kind of partitioning you use, or if you partition at all. A GPT disk with FreeBSD should boot fine on a quarter-century-old IBM PC/AT, until FreeBSD's "don't support 80286" message. There may be SSDs that know about MBR - I don't know - but otherwise hardware does not care either. >> We've yet to see a "must have" technology that would require us to >> shun sysinstall (as explained earlier, we have no desire whatsoever >> to boot from ZFS, gmirror, geli, GPT, or anything else missing from >> sysinstall). Two vendors have released 3 TB disks and there will be more large disks released before 9.0-RELEASE. sysinstall needs to behave well with them. As stated, it's common to boot from ZFS, mirrors, or GPT disks. These aren't blocker issues now. From owner-freebsd-current@FreeBSD.ORG Wed Feb 23 16:33: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 C3EFE1065679; Wed, 23 Feb 2011 16:33:25 +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 948B68FC1E; Wed, 23 Feb 2011 16:33:25 +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 2F47A46B0C; Wed, 23 Feb 2011 11:33:25 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.10]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 564978A009; Wed, 23 Feb 2011 11:33:24 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Date: Wed, 23 Feb 2011 11:33:10 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.4-CBSD-20110107; KDE/4.4.5; amd64; ; ) References: <4D35CFFB.3010302@freebsd.org> <20110222205741.GA34103@server.vk2pj.dyndns.org> <4D65328D.3050709@jrv.org> In-Reply-To: <4D65328D.3050709@jrv.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201102231133.10571.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 23 Feb 2011 11:33:24 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=0.5 required=4.2 tests=BAYES_00,MAY_BE_FORGED, RDNS_DYNAMIC autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: freebsd-arch@freebsd.org, Devin Teske , "James R. Van Artsdalen" , Peter Jeremy , freebsd-sysinstall@freebsd.org Subject: Re: FreeBSD Installer Roadmap 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, 23 Feb 2011 16:33:25 -0000 On Wednesday, February 23, 2011 11:15:09 am James R. Van Artsdalen wrote: > On 2/22/2011 2:57 PM, Peter Jeremy wrote: > > When that does come, it will probably be driven by BIOS and hardware > > vendors dropping support for MBR. > > MBR is not a BIOS concept. MBR is an OS thing. The BIOS does not care > or know what kind of partitioning you use, or if you partition at all. That is mostly true. There are some SCSI BIOSes that would examine the MBR and infer what C/H/S geometry the OS was expecting from the MBR. The original dedicated disk dummy MBR triggered a divide by zero in one of these BIOS ROMs. > A GPT disk with FreeBSD should boot fine on a quarter-century-old IBM > PC/AT, until FreeBSD's "don't support 80286" message. Even a GPT has a legacy MBR (the PMBR) at the front of the disk (it marks the entire disk as in use by a special 0xee partition or some such). -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Feb 23 16:58: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 D1D46106564A; Wed, 23 Feb 2011 16:58:03 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (unknown [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id 5C8948FC08; Wed, 23 Feb 2011 16:58:03 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 1448EE8C0C; Wed, 23 Feb 2011 16:58:00 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=subject :from:to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; s=mail; bh=r9ebRg1WT/cH ZBvs8e7wc+amF1I=; b=PiAlD0xcVmpfaWZaIpCOG84eVfp1w98XM7h7dPJ+Y/hr lV3Ke6edgvoln5dGTwGuXAAPAMsGWnGsiO8xF1vjlZdQrjJL5YA1UG0yMeF+SCJ4 3Sp3OyaogLqRNd13YsvIOcg31lEu7+VDMjXa5A0BkiHdydH3wgiMU33XlSyBEu0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s=mail; b=W6QJUD KXN0n0T6lb3CypgjFm2Tti46/ZHQoMkxtASEIg/FyBellREybkGgCQfkGuw7t6fO sD5yBNYScalW13gdRH3iwBVJ5zUbfDPCnEA6nyBwuS+nlQdTYEqrDunavI/++hWI 7T4lQ7EJf+KYr0H7ak4DkyLL+6eYo7HJWgenQ= Received: from [192.168.0.10] (client-86-31-236-253.oxfd.adsl.virginmedia.com [86.31.236.253]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id AAA65E8BA7; Wed, 23 Feb 2011 16:57:59 +0000 (GMT) From: Bruce Cran To: John Baldwin In-Reply-To: <201102231133.10571.jhb@freebsd.org> References: <4D35CFFB.3010302@freebsd.org> <20110222205741.GA34103@server.vk2pj.dyndns.org> <4D65328D.3050709@jrv.org> <201102231133.10571.jhb@freebsd.org> Content-Type: text/plain; charset="us-ascii" Date: Wed, 23 Feb 2011 16:57:56 +0000 Message-ID: <1298480276.2895.5.camel@core.nessbank> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-sysinstall@freebsd.org, freebsd-current@freebsd.org, Devin Teske , "James R. Van Artsdalen" , freebsd-arch@freebsd.org Subject: Re: FreeBSD Installer Roadmap 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, 23 Feb 2011 16:58:03 -0000 On Wed, 2011-02-23 at 11:33 -0500, John Baldwin wrote: > That is mostly true. There are some SCSI BIOSes that would examine the MBR > and infer what C/H/S geometry the OS was expecting from the MBR. The > original dedicated disk dummy MBR triggered a divide by zero in one of these > BIOS ROMs. I guess RAID BIOS's read through the MBR too: my Gigabyte board has an Intel AHCI BIOS (1.20E seems to be the problematic revision) with fakeraid that hangs (requiring a CMOS reset) if you install FreeBSD physically after Windows 7 x64 for example - and some IBM laptops have a bug related to repair partitions and FreeBSD too (http://wiki.pcbsd.org/index.php/Laptops), so they must read the MBR too. -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Wed Feb 23 19:11: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 E35DA106566C for ; Wed, 23 Feb 2011 19:11:49 +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 6873E8FC14 for ; Wed, 23 Feb 2011 19:11:49 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PsK7o-0002oy-DW for freebsd-current@freebsd.org; Wed, 23 Feb 2011 20:11:48 +0100 Received: from cpe-188-129-81-71.dynamic.amis.hr ([188.129.81.71]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 23 Feb 2011 20:11:48 +0100 Received: from ivoras by cpe-188-129-81-71.dynamic.amis.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 23 Feb 2011 20:11:48 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Wed, 23 Feb 2011 20:11:35 +0100 Lines: 71 Message-ID: References: <20110222203134.GA53262@freebsd.org> <20110222215036.GA66303@freebsd.org> <20110222223314.GA72748@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: cpe-188-129-81-71.dynamic.amis.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: <20110222223314.GA72748@freebsd.org> Subject: Re: Wow... (<-- blown away at performance) 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, 23 Feb 2011 19:11:50 -0000 On 22/02/2011 23:33, Alexander Best wrote: >>>>> Also, it looks like npviewer.bin still hangs to resources on until >>>>> Firefox closes (or I kill it :)..), so something still needs to be >>>>> resolved there, but that isn't a regression (it's acted that way for >>>>> ages), and shouldn't be too hard to do. While on the subject - any ideas why npviewer.bin is present as so many processes? They all appear to have some identical properties, most curiously their memory usage, so shouldn't they be threads? betelgeuse:~> ps axu | grep npv ivoras 7775 0.0 1.3 695332 55760 ?? S 8:03pm 0:11.84 /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugin /usr/local/lib/browser_plugins/libflashplayer.so --connection /org/wrappe ivoras 7787 0.0 1.3 695332 55760 ?? I 8:03pm 0:01.86 /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugin /usr/local/lib/browser_plugins/libflashplayer.so --connection /org/wrappe ivoras 7788 0.0 1.3 695332 55760 ?? I 8:03pm 0:01.55 /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugin /usr/local/lib/browser_plugins/libflashplayer.so --connection /org/wrappe ivoras 7789 0.0 1.3 695332 55760 ?? I 8:03pm 0:01.56 /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugin /usr/local/lib/browser_plugins/libflashplayer.so --connection /org/wrappe ivoras 7790 0.0 1.3 695332 55760 ?? I 8:03pm 0:01.56 /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugin /usr/local/lib/browser_plugins/libflashplayer.so --connection /org/wrappe ivoras 7791 0.0 1.3 695332 55760 ?? I 8:03pm 0:01.55 /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugin /usr/local/lib/browser_plugins/libflashplayer.so --connection /org/wrappe ivoras 7792 0.0 1.3 695332 55760 ?? I 8:03pm 0:01.55 /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugin /usr/local/lib/browser_plugins/libflashplayer.so --connection /org/wrappe ivoras 7793 0.0 1.3 695332 55760 ?? I 8:03pm 0:01.51 /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugin /usr/local/lib/browser_plugins/libflashplayer.so --connection /org/wrappe ivoras 7794 0.0 1.3 695332 55760 ?? I 8:03pm 0:00.00 /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugin /usr/local/lib/browser_plugins/libflashplayer.so --connection /org/wrappe ivoras 7795 0.0 1.3 695332 55760 ?? S 8:03pm 0:00.01 /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugin /usr/local/lib/browser_plugins/libflashplayer.so --connection /org/wrappe ivoras 7796 0.0 1.3 695332 55760 ?? I 8:03pm 0:00.44 /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugin /usr/local/lib/browser_plugins/libflashplayer.so --connection /org/wrappe ivoras 7797 0.0 1.3 695332 55760 ?? S 8:03pm 0:03.56 /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugin /usr/local/lib/browser_plugins/libflashplayer.so --connection /org/wrappe ivoras 7798 0.0 1.3 695332 55760 ?? I 8:03pm 0:01.41 /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugin /usr/local/lib/browser_plugins/libflashplayer.so --connection /org/wrappe ivoras 7799 0.0 1.3 695332 55760 ?? I 8:03pm 0:01.41 /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugin /usr/local/lib/browser_plugins/libflashplayer.so --connection /org/wrappe ivoras 7800 0.0 1.3 695332 55760 ?? I 8:03pm 0:01.40 /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugin /usr/local/lib/browser_plugins/libflashplayer.so --connection /org/wrappe ivoras 7801 0.0 1.3 695332 55760 ?? I 8:03pm 0:01.38 /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugin /usr/local/lib/browser_plugins/libflashplayer.so --connection /org/wrappe ivoras 7802 0.0 1.3 695332 55760 ?? I 8:03pm 0:01.40 /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugin /usr/local/lib/browser_plugins/libflashplayer.so --connection /org/wrappe ivoras 7803 0.0 1.3 695332 55760 ?? I 8:03pm 0:01.40 /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugin /usr/local/lib/browser_plugins/libflashplayer.so --connection /org/wrappe ivoras 7804 0.0 1.3 695332 55760 ?? I 8:03pm 0:01.41 /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugin /usr/local/lib/browser_plugins/libflashplayer.so --connection /org/wrappe ivoras 7805 0.0 1.3 695332 55760 ?? I 8:03pm 0:01.38 /usr/local/lib/ns From owner-freebsd-current@FreeBSD.ORG Wed Feb 23 20:09:26 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 0D66C106566B; Wed, 23 Feb 2011 20:09:25 +0000 (UTC) Date: Wed, 23 Feb 2011 20:09:25 +0000 From: Alexander Best To: John Baldwin Message-ID: <20110223200925.GA17299@freebsd.org> References: <20110222215036.GA66303@freebsd.org> <201102230751.29885.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201102230751.29885.jhb@freebsd.org> Cc: Brandon Gooch , Eir Nym , freebsd-current@freebsd.org, Dimitry Andric , Garrett Cooper Subject: Re: Wow... (<-- blown away at performance) 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, 23 Feb 2011 20:09:26 -0000 On Wed Feb 23 11, John Baldwin wrote: > On Tuesday, February 22, 2011 4:50:36 pm Alexander Best wrote: > > On Tue Feb 22 11, Brandon Gooch wrote: > > > On Tue, Feb 22, 2011 at 2:31 PM, Alexander Best > wrote: > > > > On Tue Feb 22 11, Garrett Cooper wrote: > > > >> On Tue, Feb 22, 2011 at 2:10 AM, Eir Nym wrote: > > > >> > On 22 February 2011 11:15, Garrett Cooper wrote: > > > >> >> I don't know what to say, but r218938 screams with flash videos > > > >> >> (native Linux speed). Not sure if it's the new binutils or if it's > the > > > >> >> new linuxulator patches, but I can run multiple instances of youtube > > > >> >> in parallel (5 total with other miscellaneous flash animation) > without > > > >> >> it totally lagging out Firefox/X11, and it appears to close the > > > >> >> instances of firefox properly now. Hopefully this version fares > better > > > >> >> than r218113 did (I think I hit a kernel bug after 2 weeks uptime, > > > >> >> where my system just hardlocked for no apparent reason). > > > >> >> Anyhow, hope others have similar results. > > > >> >> Cheers! > > > >> >> -Garrett > > > >> >> > > > >> >> $ uname -a > > > >> >> FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r218938M: > > > >> >> Mon Feb 21 23:10:51 PST 2011 > > > >> >> gcooper@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 > > > >> > > > > >> > Which FlashPlayer version do you test? Adobe has made significant > > > >> > performance changes in 10.2 (from 10.1). You can search for > StageVideo > > > >> > performance to learn more about. Youtube already use them since 10.2 > > > >> > beta > > > >> > > > >> linux-f10-flashplugin-10.1r102.65 . The performance increases are > > > >> claimed to be "up to 85%" on the Stage Video site, but I'm seeing a > > > >> more than 200% increase (now it actually scales between multiple > > > >> instances, instead of croaks with one instance, tiling up and down the > > > >> screen when moving the window slider for instance or switching tabs). > > > >> Besides, it seems like it needs external support from the video > > > >> driver, and I'm not sure that that bridge exists in the linuxulator. > > > >> Also, it looks like npviewer.bin still hangs to resources on until > > > >> Firefox closes (or I kill it :)..), so something still needs to be > > > >> resolved there, but that isn't a regression (it's acted that way for > > > >> ages), and shouldn't be too hard to do. > > > > > > > > i think the problem with npviewer.bin having to be killed by hand is a > futex > > > > issue in combination with a high number of threads. this is the output > of a > > > > test from darren hart's futex test suite under freebsd 9.0: > > > > > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=1 > > > > Result: 18622 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=2 > > > > Result: 15469 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=3 > > > > Result: 12713 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=4 > > > > Result: 12247 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=5 > > > > Result: 11814 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=6 > > > > Result: 13468 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=8 > > > > Result: 12061 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=10 > > > > Result: 12854 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=12 > > > > Result: 12999 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=16 > > > > Result: 12402 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=24 > > > > Result: 9815 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=32 > > > > Result: 8518 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=64 > > > > ERROR: Resource temporarily unavailable: pthread_create > > > > Result: ERROR > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=128 > > > > ERROR: Resource temporarily unavailable: pthread_create > > > > Result: ERROR > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=256 > > > > ERROR: Resource temporarily unavailable: pthread_create > > > > Result: ERROR > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=512 > > > > ERROR: Resource temporarily unavailable: pthread_create > > > > Result: ERROR > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=1024 > > > > ERROR: Resource temporarily unavailable: pthread_create > > > > Result: ERROR > > > > > > > > cheers. > > > > alex > > > > > > Have you found any method or workaround to mitigate this issue? > > > > no. i've increased the kern.threads.max_threads_per_proc value, but that had > > no effect. so it seems to be a bug in the linuxulator's futex > implementation. i was able to "fix" the issue with threads 2-32, where linux_sys_futex() was repeatedly failing with -EAGAIN by setting kern.smp.disabled=1. if you compare this output to the one beforehand with SMP enabled you'll notice a massive increase in Kiter/s, due to linux_sys_futex() now not failing once at all: futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=100000000 threads=1 Result: 18732 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=100000000 threads=2 Result: 17445 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=100000000 threads=3 Result: 18594 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=100000000 threads=4 Result: 18676 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=100000000 threads=5 Result: 18704 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=100000000 threads=6 Result: 18732 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=100000000 threads=8 Result: 18622 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=100000000 threads=10 Result: 18540 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=100000000 threads=12 Result: 18567 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=100000000 threads=16 Result: 18486 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=100000000 threads=24 Result: 18540 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=100000000 threads=32 Result: 18567 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=100000000 threads=64 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=100000000 threads=128 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=100000000 threads=256 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=100000000 threads=512 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=100000000 threads=1024 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR ... threads 64-1024 still fail, but as i pointed out beforehand that's not an issue with futexes, but with linux_mmap2() failing with -ENOMEM. cheers. alex > > You can try http://www.freebsd.org/~jhb/patches/futex_share.patch > > Not sure if it will solve your issue, but it might help if multiple > processes (Linux processes, not just multiple FreeBSD processes > masquerading as threads in a single Linux process) are involved. > > -- > John Baldwin -- a13x From owner-freebsd-current@FreeBSD.ORG Wed Feb 23 20:20: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 AE0E7106566B; Wed, 23 Feb 2011 20:20:28 +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 7D53F8FC1C; Wed, 23 Feb 2011 20:20:28 +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 29C8846B03; Wed, 23 Feb 2011 15:20:28 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.10]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3F3768A009; Wed, 23 Feb 2011 15:20:27 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Date: Wed, 23 Feb 2011 15:17:06 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.4-CBSD-20110107; KDE/4.4.5; amd64; ; ) References: <20110222223314.GA72748@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201102231517.06962.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 23 Feb 2011 15:20:27 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=0.5 required=4.2 tests=BAYES_00,MAY_BE_FORGED, RDNS_DYNAMIC autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Ivan Voras Subject: Re: Wow... (<-- blown away at performance) 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, 23 Feb 2011 20:20:28 -0000 On Wednesday, February 23, 2011 2:11:35 pm Ivan Voras wrote: > On 22/02/2011 23:33, Alexander Best wrote: > > >>>>> Also, it looks like npviewer.bin still hangs to resources on until > >>>>> Firefox closes (or I kill it :)..), so something still needs to be > >>>>> resolved there, but that isn't a regression (it's acted that way for > >>>>> ages), and shouldn't be too hard to do. > > While on the subject - any ideas why npviewer.bin is present as so many > processes? They all appear to have some identical properties, most > curiously their memory usage, so shouldn't they be threads? Threads in Linux processes show up as individual processes. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Feb 23 21:01: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 46B3E106566B for ; Wed, 23 Feb 2011 21:01:35 +0000 (UTC) (envelope-from kingedgar@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 C8BAB8FC0A for ; Wed, 23 Feb 2011 21:01:34 +0000 (UTC) Received: by wwb31 with SMTP id 31so415867wwb.31 for ; Wed, 23 Feb 2011 13:01:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=kAgcIE3i2iEive4LJxkVYEUoekibuoNOhbDDUbWq/Gw=; b=R2PnVBKrVzSeSTZPE9fUwpJsqeCO+MtnoyOT9oXyig0OJfDm2+9hY8NLf95TBNYrQy uCu9jLjW4NxYxJlyZPqHP0UmqwnzIUMLZu4wcIyZgJfzj45DNFbpwkZ7jdnqqi933HPw +etA7HzhkFxXT98wKGUa3mRU5R0rTlQhSSz+o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=oTxiiqGc11GD2E0o1e1K/++xBjaEa8LdhdMLAI4uAAt5SuAmTDcyONQtc3FfXgFQIn hcRWs0hzmp1qiM2gGPeegnuj5mxwenZqFJHrzXQ2mH0WFjf262O2PKzfUN7+5ZKOA4kO vLdGc90BQytsvJUbBiR8H5DogDWF4ZzDyKlY4= MIME-Version: 1.0 Received: by 10.216.163.69 with SMTP id z47mr4045087wek.43.1298493149410; Wed, 23 Feb 2011 12:32:29 -0800 (PST) Received: by 10.216.38.71 with HTTP; Wed, 23 Feb 2011 12:32:28 -0800 (PST) In-Reply-To: <86lj1s3pv0.fsf@gmail.com> References: <20101213214556.GC2038@garage.freebsd.pl> <8662upxg76.fsf@gmail.com> <86lj1s3pv0.fsf@gmail.com> Date: Wed, 23 Feb 2011 14:32:28 -0600 Message-ID: From: Jason Garrett To: freebsd-current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Next ZFSv28 patchset ready for testing. 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, 23 Feb 2011 21:01:35 -0000 On Mon, Feb 7, 2011 at 08:01, Anonymous wrote: > Anonymous writes: > > > Pawel Jakub Dawidek writes: > > > >> The new patchset is ready for testing: > >> > >> http://people.freebsd.org/~pjd/patches/zfs_20101212.patch.bz2 > >> > > > > `-e' option in zdb(8) now looks under /dev/dsk by default > > > > $ zdb -ec blah > > > > Configuration for import: > > vdev_children: 1 > > version: 6 > > vdev_tree: > > children[0]: > > phys_path: '/dev/gptid/A-B-C-D-E' > > path: '/dev/dsk/gptid/A-B-C-D-E' > > zdb: can't open 'blah': No such file or directory > > Exit 1 > > How about below diff then? > > %% > --- cddl/contrib/opensolaris/lib/libzfs/common/libzfs_import.c~ > +++ cddl/contrib/opensolaris/lib/libzfs/common/libzfs_import.c > @@ -1129,7 +1129,11 @@ zpool_find_import_impl(libzfs_handle_t * > char *end, **dir = iarg->path; > size_t pathleft; > nvlist_t *ret = NULL; > +#ifdef sun > static char *default_dir = "/dev/dsk"; > +#else > + static char *default_dir = "/dev"; > +#endif > pool_list_t pools = { 0 }; > pool_entry_t *pe, *penext; > vdev_entry_t *ve, *venext; > %% > > > > > $ zdb -p /dev -ec blah > > > > Traversing all blocks to verify metadata checksums and verify nothing > leaked ... > > Assertion failed: (mp->initialized == B_TRUE), file > /usr/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common/kernel.c, > line 130. > > Exit 134 > > I can't reproduce anymore, at least as of ch188544. > Has there been any recent developments with these patches (eg. Will they apply and build on latest checkouts?) ? > _______________________________________________ > 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 Feb 23 22:09: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 B1B2A106564A for ; Wed, 23 Feb 2011 22:09:56 +0000 (UTC) (envelope-from ivoras@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 5C7A08FC15 for ; Wed, 23 Feb 2011 22:09:56 +0000 (UTC) Received: by qyk27 with SMTP id 27so3077607qyk.13 for ; Wed, 23 Feb 2011 14:09:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=rzbLV1GGmwcm7j4HpfpyPUkc0nKquf2Pg800xDlUA9c=; b=LqcYJ/QR/deTFbs6TAmrI/KamqmHu5K4V9qSZNDcFn0gdRbshNKbZVALRsjB9Y/kzj bSEUZF+tXfQCtxSVvaLLxn/bAnFcXUb+zcDqRig710EU1hdR0O4eOIvX7V52D1opMLhh AQp0y9VRsMBKE7B2CtcmIIVkafgNqkIvKsL80= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=jGY68e+yzRzf4xFiTRb3u363pHbxSnl5shDulM/VaEL6FLC2HS2AUooByffkD7U1iw VH0lLc0+5J2RUlMWLe1cIDH4ifJEuVHM9e9w7if8zTB/ap4KtyUm6ZAfRdxIZgTeT+Gm bYCYDi2tFU7OjttYL3NRYhKjdrsia0BEupyZA= Received: by 10.224.2.70 with SMTP id 6mr3961381qai.83.1298497255093; Wed, 23 Feb 2011 13:40:55 -0800 (PST) MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.229.188.140 with HTTP; Wed, 23 Feb 2011 13:40:15 -0800 (PST) In-Reply-To: <201102231517.06962.jhb@freebsd.org> References: <20110222223314.GA72748@freebsd.org> <201102231517.06962.jhb@freebsd.org> From: Ivan Voras Date: Wed, 23 Feb 2011 22:40:15 +0100 X-Google-Sender-Auth: SWlEgyxWVVr7dz3pkVlhnxGfrws Message-ID: To: John Baldwin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: Wow... (<-- blown away at performance) 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, 23 Feb 2011 22:09:56 -0000 On 23 February 2011 21:17, John Baldwin wrote: > On Wednesday, February 23, 2011 2:11:35 pm Ivan Voras wrote: >> On 22/02/2011 23:33, Alexander Best wrote: >> >> >>>>> =C2=A0 =C2=A0 =C2=A0Also, it looks like npviewer.bin still hangs t= o resources on > until >> >>>>> Firefox closes (or I kill it :)..), so something still needs to be >> >>>>> resolved there, but that isn't a regression (it's acted that way f= or >> >>>>> ages), and shouldn't be too hard to do. >> >> While on the subject - any ideas why npviewer.bin is present as so many >> processes? They all appear to have some identical properties, most >> curiously their memory usage, so shouldn't they be threads? > > Threads in Linux processes show up as individual processes. Ah, ok. This was "fixed" in Linux (in their nptl project cca 2005) so I assumed it was also fixed here. From owner-freebsd-current@FreeBSD.ORG Wed Feb 23 22:28: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 503DE106566B for ; Wed, 23 Feb 2011 22:28:33 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 232AB8FC19 for ; Wed, 23 Feb 2011 22:28:33 +0000 (UTC) Received: by iyj12 with SMTP id 12so3289604iyj.13 for ; Wed, 23 Feb 2011 14:28:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.171.197 with SMTP id i5mr114558ibz.54.1298500112548; Wed, 23 Feb 2011 14:28:32 -0800 (PST) Received: by 10.231.149.79 with HTTP; Wed, 23 Feb 2011 14:28:32 -0800 (PST) In-Reply-To: References: <20101213214556.GC2038@garage.freebsd.pl> <8662upxg76.fsf@gmail.com> <86lj1s3pv0.fsf@gmail.com> Date: Wed, 23 Feb 2011 23:28:32 +0100 Message-ID: From: Olivier Smedts To: Jason Garrett Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current Subject: Re: Next ZFSv28 patchset ready for testing. 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, 23 Feb 2011 22:28:33 -0000 2011/2/23 Jason Garrett : > On Mon, Feb 7, 2011 at 08:01, Anonymous wrote: > >> Anonymous writes: >> >> > Pawel Jakub Dawidek writes: >> > >> >> The new patchset is ready for testing: >> >> >> >> =A0 =A0 =A0http://people.freebsd.org/~pjd/patches/zfs_20101212.patch.= bz2 >> >> >> > >> > `-e' option in zdb(8) now looks under /dev/dsk by default >> > >> > =A0 $ zdb -ec blah >> > >> > =A0 Configuration for import: >> > =A0 =A0 =A0 =A0 =A0 vdev_children: 1 >> > =A0 =A0 =A0 =A0 =A0 version: 6 >> > =A0 =A0 =A0 =A0 =A0 vdev_tree: >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 children[0]: >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 phys_path: '/dev/gptid/A-B-C-D-E' >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 path: '/dev/dsk/gptid/A-B-C-D-E' >> > =A0 zdb: can't open 'blah': No such file or directory >> > =A0 Exit 1 >> >> How about below diff then? >> >> %% >> --- cddl/contrib/opensolaris/lib/libzfs/common/libzfs_import.c~ >> +++ cddl/contrib/opensolaris/lib/libzfs/common/libzfs_import.c >> @@ -1129,7 +1129,11 @@ zpool_find_import_impl(libzfs_handle_t * >> =A0 =A0 =A0 =A0char *end, **dir =3D iarg->path; >> =A0 =A0 =A0 =A0size_t pathleft; >> =A0 =A0 =A0 =A0nvlist_t *ret =3D NULL; >> +#ifdef sun >> =A0 =A0 =A0 =A0static char *default_dir =3D "/dev/dsk"; >> +#else >> + =A0 =A0 =A0 static char *default_dir =3D "/dev"; >> +#endif >> =A0 =A0 =A0 =A0pool_list_t pools =3D { 0 }; >> =A0 =A0 =A0 =A0pool_entry_t *pe, *penext; >> =A0 =A0 =A0 =A0vdev_entry_t *ve, *venext; >> %% >> >> > >> > =A0 $ zdb -p /dev -ec blah >> > >> > =A0 Traversing all blocks to verify metadata checksums and verify noth= ing >> leaked ... >> > =A0 Assertion failed: (mp->initialized =3D=3D B_TRUE), file >> /usr/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpoo= l/common/kernel.c, >> line 130. >> > =A0 Exit 134 >> >> I can't reproduce anymore, at least as of ch188544. >> > > Has there been any recent developments with these patches (eg. Will they > apply and build on latest checkouts?) ? I'm successfuly using the following on latest 9-CURRENT : http://people.freebsd.org/~mm/patches/zfs/v28/head-zfsv28-20110219-nopython= .patch.xz If you want patches for 8-STABLE, look at the directory contents. Cheers --=20 Olivier Smedts=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 _ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 ASCII ribbon campaign ( ) e-mail: olivier@gid0.org=A0 =A0 =A0 =A0 - against HTML email & vCards=A0 X www: http://www.gid0.org=A0 =A0 - against proprietary attachments / \ =A0 "Il y a seulement 10 sortes de gens dans le monde : =A0 ceux qui comprennent le binaire, =A0 et ceux qui ne le comprennent pas." From owner-freebsd-current@FreeBSD.ORG Wed Feb 23 23:10:24 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 0E591106566C; Wed, 23 Feb 2011 23:10:24 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) by mx1.freebsd.org (Postfix) with ESMTP id 9C8B98FC12; Wed, 23 Feb 2011 23:10:23 +0000 (UTC) Received: from turtle.stack.nl (turtle.stack.nl [IPv6:2001:610:1108:5010::132]) by mx1.stack.nl (Postfix) with ESMTP id 0C6101DD748; Thu, 24 Feb 2011 00:10:21 +0100 (CET) Received: by turtle.stack.nl (Postfix, from userid 1677) id E804417363; Thu, 24 Feb 2011 00:10:20 +0100 (CET) Date: Thu, 24 Feb 2011 00:10:20 +0100 From: Jilles Tjoelker To: Hajimu UMEMOTO Message-ID: <20110223231020.GA69292@stack.nl> References: <20110220181713.C13400@maildrop.int.zabbadoz.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Bjoern A. Zeeb" , FreeBSD current mailing list Subject: Re: CFR: importing openresolv 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, 23 Feb 2011 23:10:24 -0000 On Tue, Feb 22, 2011 at 02:51:06AM +0900, Hajimu UMEMOTO wrote: > >>>>> On Tue, 22 Feb 2011 01:50:17 +0900 > >>>>> Hajimu UMEMOTO said: > bz> Do you have an updated patch for 3.4.1 or 3.3.6? I'd like to help to > bz> you get it in for 9.0-R. I wouldn't even mind if some ports would > bz> conflict with it for a while not making the situation any worse than > bz> it is these days. > ume> I didn't notice that openresolv was updated. I'll soon make a new > ume> diff for 3.4.1. > ume> hrs@ noticed that ppp(8) and uhsoctl(8) in our base tree touch > ume> /etc/resolv.conf. We need to change them to use resovlconf(8). > I've updated a patch for 3.4.1: > http://www.imasy.or.jp/~ume/FreeBSD/openresolv-20110222.diff.gz > If you have the previous patch applied, make sure to remove > src/contrib/openresolv and src/sbin/resolvconf before applying new > one. This looks like it can work, but note that it depends on some 9-CURRENT sh(1) features: * A printf(1) builtin, required to run without /usr. I don't see a sane way to avoid this. * Some of the expansion changes, required for the line: iface="${line#\# resolv.conf from *}" This can be avoided by changing that line to: iface=${line#\# resolv.conf from *} -- Jilles Tjoelker From owner-freebsd-current@FreeBSD.ORG Thu Feb 24 07:26:31 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 29CC1106564A for ; Thu, 24 Feb 2011 07:26:31 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from doug-optiplex.ka9q.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 0C85814F410 for ; Thu, 24 Feb 2011 07:26:31 +0000 (UTC) Message-ID: <4D660826.7020609@FreeBSD.org> Date: Wed, 23 Feb 2011 23:26:30 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20110129 Thunderbird/3.1.7 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: Problem with a port after clang'ifying 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, 24 Feb 2011 07:26:31 -0000 I followed the instructions at: http://wiki.freebsd.org/BuildingFreeBSDWithClang and everything went quite well. The system built fine, and runs fine for most of my ports. There is one minor one, misc/wmweather+ that crashes every time I start it. The trace looks like this: #0 strcasecmp (s1=Variable "s1" is not available. ) at /home/svn/head/lib/libc/string/strcasecmp.c:48 48 while (tolower(*us1) == tolower(*us2++)) (gdb) bt #0 strcasecmp (s1=Variable "s1" is not available. ) at /home/svn/head/lib/libc/string/strcasecmp.c:48 #1 0x0000000800988259 in CreateColors (display=0x802cf5000, attributes=0x7fffffffd590, colors=0x802c4fd00, ncolors=5, image_pixels=0x802cb75e0, mask_pixels=0x802cb7610, mask_pixel_index=0x7fffffffcf4c, alloc_pixels=0x802cb7670, nalloc_pixels=0x7fffffffcf48, used_pixels=0x802cb76a0, nused_pixels=0x7fffffffcf44) at create.c:657 #2 0x0000000800989764 in xpmParseDataAndCreate (display=0x802cf5000, data=0x7fffffffcfb0, image_return=0x7fffffffd498, shapeimage_return=0x7fffffffd490, image=0x7fffffffd430, info=0x7fffffffd3f0, attributes=0x7fffffffd590) at create.c:2127 #3 0x0000000800985403 in XpmCreateImageFromData (display=0x802cf5000, data=0x61e4c0, image_return=0x7fffffffd498, shapeimage_return=0x7fffffffd490, attributes=0x7fffffffd590) at CrIFrDat.c:66 #4 0x0000000800985693 in XpmCreatePixmapFromData (display=0x802cf5000, d=169, data=Variable "data" is not available. ) at CrPFrDat.c:60 #5 0x0000000000412d66 in GetXPM (wmgen=0x7fffffffd580, pixmap_bytes=0x61e4c0) at wmgeneral-x11.c:117 #6 0x0000000000409e54 in init_font (i=0) at font.c:61 #7 0x0000000000409f75 in DrawChar (x=32, y=29, c=Variable "c" is not available. ) at font.c:143 #8 0x000000000040a198 in DrawString (x=32, y=29, str=Variable "str" is not available. ) at font.c:72 #9 0x0000000000406160 in DrawDisplay (force=Variable "force" is not available. ) at dock.c:457 #10 0x00000000004077a0 in update_dock () at dock.c:229 #11 0x00000000004124a7 in main (argc=1, argv=0x7fffffffd970) at wmweather+.c:737 The ports were all compiled with gcc of course, recompiling (still with gcc) after clang'ifying didn't help. Oddly enough, this is a very simple port, so far all my other complex ports (including things like firefox + flash, tbird, pidgin, etc.) are all working fine. Suggestions welcome, 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 Thu Feb 24 07:26: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 AAD6210656C1; Thu, 24 Feb 2011 07:26:56 +0000 (UTC) (envelope-from datastream.freecity@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 4CB0F8FC1C; Thu, 24 Feb 2011 07:26:56 +0000 (UTC) Received: by gxk7 with SMTP id 7so152466gxk.13 for ; Wed, 23 Feb 2011 23:26:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Ru4fe52DVpZNubH5EZJt3dIUetlAiAma/vxOc1Iddls=; b=KpUJ3K27RwK45+FqiwqcU4umUk4YRNVALAN0PDX44S2kY1ZF/PkZHsx6xMYi8SvMsf pjsoIhPS9UpiTDJBdWrPJiTFQ8k1Igqp86YH5FPuWbIvxg708wrG2YtZCEpbBQC/RyVL mvuknWlk0FVPBsVNAPBlaatxMvjCsfP7sCk2g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Dx6+cYjMuIS82GisSN9jzn+F7LC9MTGABOZNGrwCBiH3FVryx5zrVkKrIdqjD2nv6w K5WhjwklCiyo/OHbC3luHtXEGxZ+YypQEKPQD88LCPs1/uTGy62L+0+1v8NaSaREwMdI oxWWAHxqEnTV3MImJTtoU4PzNq6Yo8cQ+kZDk= MIME-Version: 1.0 Received: by 10.151.44.20 with SMTP id w20mr1363285ybj.177.1298532414830; Wed, 23 Feb 2011 23:26:54 -0800 (PST) Received: by 10.151.47.7 with HTTP; Wed, 23 Feb 2011 23:26:54 -0800 (PST) In-Reply-To: <4D653007.9080103@FreeBSD.org> References: <4D627FBE.1070700@FreeBSD.org> <4D63D28B.4080900@FreeBSD.org> <4D653007.9080103@FreeBSD.org> Date: Thu, 24 Feb 2011 15:26:54 +0800 Message-ID: From: "datastream datastream.freecity" To: Dimitry Andric Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Olivier Smedts , freebsd-current@freebsd.org Subject: Re: Can't buildworld since Clang update 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, 24 Feb 2011 07:26:56 -0000 I removed /etc/src.conf.binutils is 2.15. #svn info /usr/src Path: /usr/src URL: http://svn.freebsd.org/base/head Repository Root: http://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 218985 Node Kind: directory Schedule: normal Last Changed Author: brucec Last Changed Rev: 218985 Last Changed Date: 2011-02-24 05:45:28 +0800 (Thu, 24 Feb 2011) #cat /etc/make.conf .if ${.CURDIR:N*usr/src*}=="" .if !defined(CC) || ${CC} == "cc" CC=clang .endif .if !defined(CXX) || ${CXX} == "c++" CXX=clang++ .endif NO_WERROR= WERROR= .endif #printenv TERM=xterm FTP_PASSIVE_MODE=YES BLOCKSIZE=K MAIL=/var/mail/root PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/bin:/usr/local/sbin:/usr/X11R6/bin:/usr/local/afs/bin:/root/bin:/usr/local/texlive/2007/bin/i386-freebsd:/usr/local/kde4/bin SHELL=/bin/csh HOME=/root USER=root HOSTTYPE=FreeBSD VENDOR=unknown OSTYPE=FreeBSD MACHTYPE=unknown SHLVL=1 PWD=/root LOGNAME=root GROUP=wheel HOST=datastream-laptop.people.163.org REMOTEHOST= LSCOLORS=ExGxFxdxCxegedabagExEx CLICOLOR=yes MANPATH=/usr/share/man:/usr/local/man:/usr/X11R6/man:/usr/local/lib/perl5/5.8.8/man:/usr/local/lib/perl5/5.8.8/perl/man:/usr/local/texlive/2007/texmf/doc/man EDITOR=ee PAGER=less #clang -v FreeBSD clang version 2.8 (tags/RELEASE_28 115870) 20101007 Target: x86_64-undermydesk-freebsd9.0 Thread model: posix On Thu, Feb 24, 2011 at 12:04 AM, Dimitry Andric wrote: > On 2011-02-23 14:22, datastream datastream.freecity wrote: > >> I deleted all files in /usr/src and /usr/obj. it changes nothing, i still >> get same error. >> >> In /etc/make.conf: >> .if !defined(CC) || ${CC} == "cc" >> CC=clang >> .endif >> .if !defined(CXX) || ${CXX} == "c++" >> CXX=clang++ >> .endif >> # Don't die on warnings >> NO_WERROR= >> WERROR= >> STRIP= >> CFLAGS+=-fno-omit-frame-pointer >> > > I just did a full buildworld and buildkernel with exactly these settings > (deleted src.conf), and it worked fine. Is there any more information > you can supply? E.g. which exact revision of the tree are you trying to > build, which version of clang are you using, version of binutils, or any > other non-default environment settings? > From owner-freebsd-current@FreeBSD.ORG Thu Feb 24 14:22: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 D3D691065672 for ; Thu, 24 Feb 2011 14:22:07 +0000 (UTC) (envelope-from jerome.flesch@netasq.com) Received: from work.netasq.com (mars.netasq.com [91.212.116.3]) by mx1.freebsd.org (Postfix) with ESMTP id 586198FC12 for ; Thu, 24 Feb 2011 14:22:06 +0000 (UTC) Received: from pc_jf.netasq.com (unknown [10.2.200.254]) by work.netasq.com (Postfix) with ESMTPSA id 629C8740004; Thu, 24 Feb 2011 15:20:42 +0100 (CET) Message-ID: <4D6668B7.5070005@netasq.com> Date: Thu, 24 Feb 2011 15:18:31 +0100 From: Jerome Flesch User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.16) Gecko/20110106 Thunderbird/3.0.11 MIME-Version: 1.0 To: Ryan Stone References: <4D6291A5.4050206@netasq.com> <8C8FE4A5-F031-466A-9CB8-46D79EEA280D@mac.com> <4D638050.2010906@netasq.com> <20110222195713.GW66284@funkthat.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080808040407020805030706" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: John-Mark Gurney , freebsd-current@freebsd.org Subject: Re: Process timing issue 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, 24 Feb 2011 14:22:08 -0000 This is a cryptographically signed message in MIME format. --------------ms080808040407020805030706 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Thanks for your explanations. It helped greatly. Using ktrdump and=20 schedgraph.py and after modifying our test program to set and unset=20 automatically debug.ktr.mask, I've been able to get useful information. First, It made me realize that task switching, with default settings and = 2 active processes, only occurs each 100ms. Knowing that, expecting a=20 latency time around 100ms was kind of silly :) Next, it seems most of the latency pikes are due to a process starting=20 or waking up. For instance, it usually happens when the openssl speed=20 test is started (=20 http://jflesch.kwain.net/~jflesch/sys_latence/sched/sched_graph_openssl_s= tart.png=20 ) or when pagedaemon wakes up (I forgot to disable the swap and my test=20 program used too much memory to store the result values ...). I'm not=20 sure why, but when we start openssl, it is often allowed to run for >=3D = 300ms, even with our test program set to real time priority. My=20 intuition is that, at first, it's considered as an interactive process,=20 until the scheduler realizes it's not. But then, does anyone know why it = would take more than 300ms for the scheduler to realize that ? Anyway, by setting kern.sched.interact=3D5 (so openssl isn't considered a= s=20 an interactive process), kern.sched.slice=3D3 (to get an high enough=20 scheduling resolution), and our program to real-time priority, we got=20 rid of both problems. I'm just a little bit worried about=20 kern.sched.slice=3D3. Is there any known side effect when reducing slices= =20 size ? Also, another issue remain: We were hoping to keep our program with a=20 normal priority. However when we set our test program to a normal=20 priority (but still an higher priority than openssl), both get 50% of=20 the CPU (I guess this is to be expected), and from time to time we have=20 a "hiccup" in the scheduling:=20 http://jflesch.kwain.net/~jflesch/sys_latence/sched/sched_graph_hicups.pn= g=20 =2E Is there any way to avoid them ? In other words, is it possible to=20 make sure that the low priority process never gets more CPU time than=20 the high priority one ? On 23.02.2011 02:08, Ryan Stone wrote: > To debug weird scheduling issues I find it helpful to start by looking > at a schedgraph. schedgraph is a tool that can display a graphical > representation of what the scheduler was doing over a small slice of > time. The one downside is that you have to recompile your kernel to > get the hooks that collect the necessary data, but it sounds like your > problem is pretty easy to reproduce and so that shouldn't be a big > problem. > > To enable the hooks, put the following in your kernel conf: > > options KTR > options KTR_COMPILE=3DKTR_SCHED > options KTR_MASK=3DKTR_SCHED > options KTR_ENTIRES=3D(128*1024) > > Then rebuild and install the new kernel. Next, run your test. The > instant that your test has detected the long delay, set the sysctl > debug.ktr.mask to 0. The scheduler hooks record data into a ring > buffer, so the interesting data can be flushed out within seconds. > Clearing that sysctl will stop any further events from being logged, > which means that the interesting data will stay there until you go and > collect it. > > You can get the raw data by redirecting the output of "ktrdump -ct" > into a file. Then from any machine with a graphical interface(FreeBSD > with X installed, Windows, Mac, whatever) and python installed, run: > $ python schedgraph.py /path/to/ktrdump/output > > You can get schedgraph.py from /usr/src/tools/sched. > > If you want to collect the data again, set the sysctl debug.ktr.mask > back to 0x20000000 to restart gathering scheduler data. > > Ryan > --------------ms080808040407020805030706-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 24 15:00: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 17A09106566C for ; Thu, 24 Feb 2011 15:00:51 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from agogare.doit.wisc.edu (agogare.doit.wisc.edu [144.92.197.211]) by mx1.freebsd.org (Postfix) with ESMTP id DFA6A8FC16 for ; Thu, 24 Feb 2011 15:00:50 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth2.wiscmail.wisc.edu by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0LH40080KN1E1J00@smtpauth2.wiscmail.wisc.edu> for freebsd-current@freebsd.org; Thu, 24 Feb 2011 09:00:50 -0600 (CST) Received: from comporellon.tachypleus.net ([unknown] [76.210.68.25]) by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0LH400GXJN19SJ30@smtpauth2.wiscmail.wisc.edu>; Thu, 24 Feb 2011 09:00:46 -0600 (CST) Date: Thu, 24 Feb 2011 09:00:44 -0600 From: Nathan Whitehorn In-reply-to: <4D64FF99.2070908@cabletv.dp.ua> To: Mitya Message-id: <4D66729C.6040303@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=76.210.68.25 X-Spam-PmxInfo: Server=avs-13, Version=5.6.0.2009776, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.2.24.145415, SenderIP=76.210.68.25 References: <4D64FF99.2070908@cabletv.dp.ua> User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20101214 Thunderbird/3.1.7 Cc: freebsd-current@freebsd.org Subject: Re: Cosmetic path to bsdinstall 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, 24 Feb 2011 15:00:51 -0000 Thanks! I've received basically this patch from a couple people now. I'm going to investigate whether this is a more generic way to get this information (so the list doesn't grow infinitely long), and will commit this if I can't. Having CAM devices be part of newbus would simplify this a very great deal... -Nathan On 02/23/11 06:37, Mitya wrote: > Add usually used RAID controller > > --- usr.sbin/bsdinstall/partedit/part_wizard.c.orig 2011-02-19 > 17:22:06.000000000 +0200 > +++ usr.sbin/bsdinstall/partedit/part_wizard.c 2011-02-21 > 17:20:28.000000000 +0200 > @@ -122,6 +122,18 @@ > strcat(diskdesc, " ATA Hard Disk"); > else if (strncmp(pp->lg_name, "da", 2) == 0) > strcat(diskdesc, " SCSI Hard Disk"); > + else if (strncmp(pp->lg_name, "aacd", 4) == 0) > + strcat(diskdesc, " Adaptec Raid Disk"); > + else if (strncmp(pp->lg_name, "amrd", 4) == 0) > + strcat(diskdesc, " LSI Raid Disk"); > + else if (strncmp(pp->lg_name, "mfid", 4) == 0) > + strcat(diskdesc, " LSI Raid Disk"); > + else if (strncmp(pp->lg_name, "mlxd", 4) == 0) > + strcat(diskdesc, " Mylex Raid Disk"); > + else if (strncmp(pp->lg_name, "twed", 4) == 0) > + strcat(diskdesc, " 3ware Raid Disk"); > + else if (strncmp(pp->lg_name, "pst", 3) == 0) > + strcat(diskdesc, " Promise Raid Disk"); > else if (strncmp(pp->lg_name, "md", 2) == 0) > strcat(diskdesc, " Memory Disk"); > else if (strncmp(pp->lg_name, "cd", 2) == 0) { > _______________________________________________ > 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 Feb 24 15:28:13 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 2BD71106566C; Thu, 24 Feb 2011 15:28:13 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (unknown [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id D8FBD8FC0A; Thu, 24 Feb 2011 15:28:12 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id BE6B3E8BA7; Thu, 24 Feb 2011 15:28:07 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=date:from :to:cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=mail; bh=uG0f5nxfImkd yPoZCqP1sDzigdc=; b=h857xwv9ibgQ+z4exP2CBhkwGLzqGt45FGBg4JHyOeWK 4IheDdmYGiIDP+abv+tyvDoIbXYTs6yXD3FWP40qpCXc+jiLCfrGnyHZ/66NokFU rgp+nkQbQUZx9emT9DgRQOO8P6FOvWR6/OfmJntL4jRJT3vzNfQTQeO2GI22ZH8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=date:from:to :cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; q=dns; s=mail; b=SfRoJd ugxOPje6hWqGX1MioR82uGk8AtN2tIsPHUhRGIVjRPtN7JfNP2i11GIkwZ2MiF3r Af5NMNrWoea0iu7YUnPyyfML8skci6bNVtuJb+bREDaQNmjiUPIlCWmIQayPFSWt mRLboDX5s20deaPCeIPxyEa7LlbsLUJ8s2ENQ= Received: from unknown (client-86-31-236-253.oxfd.adsl.virginmedia.com [86.31.236.253]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id 6E1F6E75E6; Thu, 24 Feb 2011 15:28:07 +0000 (GMT) Date: Thu, 24 Feb 2011 15:27:59 +0000 From: Bruce Cran To: Nathan Whitehorn Message-ID: <20110224152759.00003c4e@unknown> In-Reply-To: <4D66729C.6040303@freebsd.org> References: <4D64FF99.2070908@cabletv.dp.ua> <4D66729C.6040303@freebsd.org> X-Mailer: Claws Mail 3.7.8cvs9 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Mitya Subject: Re: Cosmetic path to bsdinstall 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, 24 Feb 2011 15:28:13 -0000 On Thu, 24 Feb 2011 09:00:44 -0600 Nathan Whitehorn wrote: > Having CAM devices be part of newbus would > simplify this a very great deal... It's required if we're ever going to have suspend/resume working properly because currently CAM doesn't get a suspend notification, so doesn't know to spin-down disks etc. -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Thu Feb 24 17:34:10 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 4450D1065694 for ; Thu, 24 Feb 2011 17:34:10 +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 3AFCB8FC1C for ; Thu, 24 Feb 2011 17:34:08 +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 TAA11869; Thu, 24 Feb 2011 19:34:05 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <4D66968C.9030705@freebsd.org> Date: Thu, 24 Feb 2011 19:34:04 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20101213 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jerome Flesch References: <4D6291A5.4050206@netasq.com> <8C8FE4A5-F031-466A-9CB8-46D79EEA280D@mac.com> <4D638050.2010906@netasq.com> <20110222195713.GW66284@funkthat.com> <4D6668B7.5070005@netasq.com> In-Reply-To: <4D6668B7.5070005@netasq.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Process timing issue 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, 24 Feb 2011 17:34:10 -0000 on 24/02/2011 16:18 Jerome Flesch said the following: > Thanks for your explanations. It helped greatly. Using ktrdump and schedgraph.py > and after modifying our test program to set and unset automatically > debug.ktr.mask, I've been able to get useful information. > > First, It made me realize that task switching, with default settings and 2 active > processes, only occurs each 100ms. Knowing that, expecting a latency time around > 100ms was kind of silly :) > > Next, it seems most of the latency pikes are due to a process starting or waking > up. For instance, it usually happens when the openssl speed test is started ( > http://jflesch.kwain.net/~jflesch/sys_latence/sched/sched_graph_openssl_start.png > ) or when pagedaemon wakes up (I forgot to disable the swap and my test program > used too much memory to store the result values ...). I'm not sure why, but when > we start openssl, it is often allowed to run for >= 300ms, even with our test > program set to real time priority. My intuition is that, at first, it's considered > as an interactive process, until the scheduler realizes it's not. But then, does > anyone know why it would take more than 300ms for the scheduler to realize that ? > > Anyway, by setting kern.sched.interact=5 (so openssl isn't considered as an > interactive process), kern.sched.slice=3 (to get an high enough scheduling > resolution), and our program to real-time priority, we got rid of both problems. > I'm just a little bit worried about kern.sched.slice=3. Is there any known side > effect when reducing slices size ? > > Also, another issue remain: We were hoping to keep our program with a normal > priority. However when we set our test program to a normal priority (but still an > higher priority than openssl), both get 50% of the CPU (I guess this is to be > expected), and from time to time we have a "hiccup" in the scheduling: > http://jflesch.kwain.net/~jflesch/sys_latence/sched/sched_graph_hicups.png . Is > there any way to avoid them ? In other words, is it possible to make sure that the > low priority process never gets more CPU time than the high priority one ? The problems that you describe here sound very much like the issues that John Baldwin has been trying to solve a short while ago. My recollection is that he committed some improvements for real time priority processes. Perhaps he'll have some additional insights based on his observations and testing. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Feb 24 17:45: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 76579106564A for ; Thu, 24 Feb 2011 17:45:05 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout028.mac.com (asmtpout028.mac.com [17.148.16.103]) by mx1.freebsd.org (Postfix) with ESMTP id 542F68FC1B for ; Thu, 24 Feb 2011 17:45:04 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from sa-nc-common3-156.static.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp028.mac.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LH40082GRTF0J80@asmtp028.mac.com>; Thu, 24 Feb 2011 08:44:06 -0800 (PST) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2011-02-24_07:2011-02-24, 2011-02-24, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1102240067 From: Marcel Moolenaar In-reply-to: <4D66729C.6040303@freebsd.org> Date: Thu, 24 Feb 2011 08:44:03 -0800 Message-id: <73BC2611-5CB0-4604-BC42-D91DB8380079@mac.com> References: <4D64FF99.2070908@cabletv.dp.ua> <4D66729C.6040303@freebsd.org> To: Nathan Whitehorn X-Mailer: Apple Mail (2.1082) Cc: freebsd-current@freebsd.org, Mitya Subject: Re: Cosmetic path to bsdinstall 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, 24 Feb 2011 17:45:05 -0000 On Feb 24, 2011, at 7:00 AM, Nathan Whitehorn wrote: > Thanks! I've received basically this patch from a couple people now. I'm going to investigate whether this is a more generic way to get this information (so the list doesn't grow infinitely long), and will commit this if I can't. Having CAM devices be part of newbus would simplify this a very great deal... See: http://people.freebsd.org/~marcel/gpt.diff It was my initial attempt of creating a generic (ncurses-based) partition editor that uses gpart. (the name of the patch relates to the perforce branch it was done on, not the partitioning scheme). In it you'll find a diff for sbin/pe/disk.c that contains logic for presenting a friendly "disk" name. Not complete, but maybe good for inspiration... FYI, -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Thu Feb 24 18:46: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 4B4CF10656C4; Thu, 24 Feb 2011 18:46:17 +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 07DE98FC14; Thu, 24 Feb 2011 18:46:17 +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 7C44E46B06; Thu, 24 Feb 2011 13:46:16 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.10]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 79A1F8A027; Thu, 24 Feb 2011 13:46:15 -0500 (EST) From: John Baldwin To: Andriy Gapon Date: Thu, 24 Feb 2011 13:46:13 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.4-CBSD-20110107; KDE/4.4.5; amd64; ; ) References: <4D6291A5.4050206@netasq.com> <4D6668B7.5070005@netasq.com> <4D66968C.9030705@freebsd.org> In-Reply-To: <4D66968C.9030705@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201102241346.13724.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 24 Feb 2011 13:46:15 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=0.5 required=4.2 tests=BAYES_00,MAY_BE_FORGED, RDNS_DYNAMIC autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: freebsd-current@freebsd.org, Jerome Flesch Subject: Re: Process timing issue 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, 24 Feb 2011 18:46:17 -0000 On Thursday, February 24, 2011 12:34:04 pm Andriy Gapon wrote: > on 24/02/2011 16:18 Jerome Flesch said the following: > > Thanks for your explanations. It helped greatly. Using ktrdump and schedgraph.py > > and after modifying our test program to set and unset automatically > > debug.ktr.mask, I've been able to get useful information. > > > > First, It made me realize that task switching, with default settings and 2 active > > processes, only occurs each 100ms. Knowing that, expecting a latency time around > > 100ms was kind of silly :) > > > > Next, it seems most of the latency pikes are due to a process starting or waking > > up. For instance, it usually happens when the openssl speed test is started ( > > http://jflesch.kwain.net/~jflesch/sys_latence/sched/sched_graph_openssl_start.png > > ) or when pagedaemon wakes up (I forgot to disable the swap and my test program > > used too much memory to store the result values ...). I'm not sure why, but when > > we start openssl, it is often allowed to run for >= 300ms, even with our test > > program set to real time priority. My intuition is that, at first, it's considered > > as an interactive process, until the scheduler realizes it's not. But then, does > > anyone know why it would take more than 300ms for the scheduler to realize that ? > > > > Anyway, by setting kern.sched.interact=5 (so openssl isn't considered as an > > interactive process), kern.sched.slice=3 (to get an high enough scheduling > > resolution), and our program to real-time priority, we got rid of both problems. > > I'm just a little bit worried about kern.sched.slice=3. Is there any known side > > effect when reducing slices size ? > > > > Also, another issue remain: We were hoping to keep our program with a normal > > priority. However when we set our test program to a normal priority (but still an > > higher priority than openssl), both get 50% of the CPU (I guess this is to be > > expected), and from time to time we have a "hiccup" in the scheduling: > > http://jflesch.kwain.net/~jflesch/sys_latence/sched/sched_graph_hicups.png . Is > > there any way to avoid them ? In other words, is it possible to make sure that the > > low priority process never gets more CPU time than the high priority one ? > > The problems that you describe here sound very much like the issues that John > Baldwin has been trying to solve a short while ago. My recollection is that he > committed some improvements for real time priority processes. Perhaps he'll have > some additional insights based on his observations and testing. Well, the changes I made to 9 simply made rtprio more important than interactive so that rtprio will always preempt interactive time-sharing threads. I'm not quite sure that this is exactly the same. Note that by default ULE does give interactive processes realtime priority, so that is why openssl would not yield early on during startup. As to why it takes the scheduler 300ms to decide openssl is a CPU hog, that I'm less sure of. You'd have to look at the interactive scoring stuff in ULE to debug that. How are you setting your program to a "normal" priority that is still higher than openssl? Are you using nice? Hmm, during your hiccup it looks like openssl got two time slices back to back rather than a single slice. Also, note that in the hiccup graph, both threads have the same priority (183), so openssl effectively has the same priority as timecheck. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Feb 24 20:14: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 EF2B5106564A; Thu, 24 Feb 2011 20:14:22 +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 BD93E8FC18; Thu, 24 Feb 2011 20:14:22 +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 6076146B06; Thu, 24 Feb 2011 15:14:22 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.10]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 616BD8A009; Thu, 24 Feb 2011 15:14:21 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 24 Feb 2011 15:11:24 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.4-CBSD-20110107; KDE/4.4.5; amd64; ; ) References: <4D64FF99.2070908@cabletv.dp.ua> <4D66729C.6040303@freebsd.org> <20110224152759.00003c4e@unknown> In-Reply-To: <20110224152759.00003c4e@unknown> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201102241511.24989.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 24 Feb 2011 15:14:21 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=0.5 required=4.2 tests=BAYES_00,MAY_BE_FORGED, RDNS_DYNAMIC autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Bruce Cran , Mitya , Nathan Whitehorn Subject: Re: Cosmetic path to bsdinstall 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, 24 Feb 2011 20:14:23 -0000 On Thursday, February 24, 2011 10:27:59 am Bruce Cran wrote: > On Thu, 24 Feb 2011 09:00:44 -0600 > Nathan Whitehorn wrote: > > > Having CAM devices be part of newbus would > > simplify this a very great deal... > > It's required if we're ever going to have suspend/resume working > properly because currently CAM doesn't get a suspend notification, so > doesn't know to spin-down disks etc. The controllers get a suspend notification though (via device_suspend() hooks that drivers like mpt, etc. could register for) and could then use that to post a suspend of the associated buses. That doesn't require CAM to use new-bus though. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Feb 24 20:14: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 79F441065674; Thu, 24 Feb 2011 20:14:24 +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 4C8D48FC08; Thu, 24 Feb 2011 20:14:24 +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 0385D46B1A; Thu, 24 Feb 2011 15:14:24 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.10]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3B9FD8A01D; Thu, 24 Feb 2011 15:14:23 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 24 Feb 2011 15:14:19 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.4-CBSD-20110107; KDE/4.4.5; amd64; ; ) References: <4D64FF99.2070908@cabletv.dp.ua> <4D66729C.6040303@freebsd.org> In-Reply-To: <4D66729C.6040303@freebsd.org> MIME-Version: 1.0 Message-Id: <201102241514.19727.jhb@freebsd.org> Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 24 Feb 2011 15:14:23 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=0.5 required=4.2 tests=BAYES_00,MAY_BE_FORGED, RDNS_DYNAMIC autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Mitya , Nathan Whitehorn Subject: Re: Cosmetic path to bsdinstall 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, 24 Feb 2011 20:14:24 -0000 On Thursday, February 24, 2011 10:00:44 am Nathan Whitehorn wrote: > Thanks! I've received basically this patch from a couple people now. I'm > going to investigate whether this is a more generic way to get this > information (so the list doesn't grow infinitely long), and will commit > this if I can't. Having CAM devices be part of newbus would simplify > this a very great deal... Note that all these disk devices are not CAM devices, so CAM changing to use new-bus wouldn't really matter one whit. They do all show up as 'DISK' GEOM's however (I also hacked on a GEOM-based libdisk replacement at one point, though probably less developed than Marcel's. I used libgeom to discover DISK devices.) Given that disk_create() already hooks into GEOM, that is probably the right way to discover disks in a generic fashion. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Feb 24 20:17: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 8EF25106571E for ; Thu, 24 Feb 2011 20:17:48 +0000 (UTC) (envelope-from yanegomi@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 22AAA8FC0A for ; Thu, 24 Feb 2011 20:17:47 +0000 (UTC) Received: by wwb31 with SMTP id 31so1238573wwb.31 for ; Thu, 24 Feb 2011 12:17:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ocCWH35vCrx3SciAI0Ai25JVjivDK/vz5n1HhaEJD44=; b=gLdCxeJp/6262FIiAOvaCvkhx4d1djzbTMNgkCtTWriDC8lEVSivRFxzjO/nXLJ1sk cM3s24d9RFw8/LUVdnQiS+3JQofkwNSH/gL+90OdCSjST7J1i0jBzK6xmecRTa+jfzMl nps3ZmcsCEN83evduDJnrBaBb1B98P5AGkIBY= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=lwJCj5o5mCQDWY9I8OsHEGi7frh7NWvcoZwM5nultEg8fg3+4oS7jqhI4UbBVtSq6w rUZqzAwTaQ+MzS5qhs2JB9XNZs/LRexxZaxk9XD5LuKh27zQguvIH9xO+LxB3JqczMtZ odmWOJ+g0fOk67I6qiV9dVRilGDHUMBA+DGGE= MIME-Version: 1.0 Received: by 10.216.169.71 with SMTP id m49mr1278111wel.4.1298578666913; Thu, 24 Feb 2011 12:17:46 -0800 (PST) Sender: yanegomi@gmail.com Received: by 10.216.15.74 with HTTP; Thu, 24 Feb 2011 12:17:46 -0800 (PST) In-Reply-To: <4D64FF99.2070908@cabletv.dp.ua> References: <4D64FF99.2070908@cabletv.dp.ua> Date: Thu, 24 Feb 2011 12:17:46 -0800 X-Google-Sender-Auth: XjrQDinTXSTMlJuNb_pOTtDgIAw Message-ID: From: Garrett Cooper To: Mitya Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: Cosmetic path to bsdinstall 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, 24 Feb 2011 20:17:48 -0000 On Wed, Feb 23, 2011 at 4:37 AM, Mitya wrote: > Add usually used RAID controller > > --- usr.sbin/bsdinstall/partedit/part_wizard.c.orig =A0 =A02011-02-19 > 17:22:06.000000000 +0200 > +++ usr.sbin/bsdinstall/partedit/part_wizard.c =A0 =A02011-02-21 > 17:20:28.000000000 +0200 > @@ -122,6 +122,18 @@ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 strcat(diskdesc, " ATA Hard Disk"= ); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 else if (strncmp(pp->lg_name, "da", 2) = =3D=3D 0) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 strcat(diskdesc, " SCSI Hard Disk= "); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0else if (strncmp(pp->lg_name, "aacd", 4)= =3D=3D 0) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0strcat(diskdesc, " Adaptec Raid = Disk"); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0else if (strncmp(pp->lg_name, "amrd", 4)= =3D=3D 0) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0strcat(diskdesc, " LSI Raid Disk= "); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0else if (strncmp(pp->lg_name, "mfid", 4)= =3D=3D 0) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0strcat(diskdesc, " LSI Raid Disk= "); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0else if (strncmp(pp->lg_name, "mlxd", 4)= =3D=3D 0) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0strcat(diskdesc, " Mylex Raid Di= sk"); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0else if (strncmp(pp->lg_name, "twed", 4)= =3D=3D 0) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0strcat(diskdesc, " 3ware Raid Di= sk"); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0else if (strncmp(pp->lg_name, "pst", 3) = =3D=3D 0) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0strcat(diskdesc, " Promise Raid = Disk"); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 else if (strncmp(pp->lg_name, "md", 2) = =3D=3D 0) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 strcat(diskdesc, " Memory Disk"); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 else if (strncmp(pp->lg_name, "cd", 2) = =3D=3D 0) { You forgot "twad" :). Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Thu Feb 24 20:35: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 E7BE3106566B for ; Thu, 24 Feb 2011 20:35:54 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from adsum.doit.wisc.edu (adsum.doit.wisc.edu [144.92.197.210]) by mx1.freebsd.org (Postfix) with ESMTP id B8D908FC0A for ; Thu, 24 Feb 2011 20:35:54 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth1.wiscmail.wisc.edu by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0LH500G102JT6200@smtpauth1.wiscmail.wisc.edu>; Thu, 24 Feb 2011 14:35:53 -0600 (CST) Received: from anacreon.physics.wisc.edu (anacreon.physics.wisc.edu [128.104.160.176]) by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0LH5008FC2JR8Q30@smtpauth1.wiscmail.wisc.edu>; Thu, 24 Feb 2011 14:35:51 -0600 (CST) Date: Thu, 24 Feb 2011 14:35:51 -0600 From: Nathan Whitehorn In-reply-to: <201102241514.19727.jhb@freebsd.org> To: John Baldwin Message-id: <4D66C127.6060701@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=128.104.160.176 X-Spam-PmxInfo: Server=avs-14, Version=5.6.0.2009776, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.2.24.202414, SenderIP=128.104.160.176 References: <4D64FF99.2070908@cabletv.dp.ua> <4D66729C.6040303@freebsd.org> <201102241514.19727.jhb@freebsd.org> User-Agent: Mozilla/5.0 (X11; U; FreeBSD powerpc; en-US; rv:1.9.2.13) Gecko/20110104 Thunderbird/3.1.7 Cc: freebsd-current@freebsd.org, Mitya Subject: Re: Cosmetic path to bsdinstall 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, 24 Feb 2011 20:35:55 -0000 On 02/24/11 14:14, John Baldwin wrote: > On Thursday, February 24, 2011 10:00:44 am Nathan Whitehorn wrote: >> Thanks! I've received basically this patch from a couple people now. I'm >> going to investigate whether this is a more generic way to get this >> information (so the list doesn't grow infinitely long), and will commit >> this if I can't. Having CAM devices be part of newbus would simplify >> this a very great deal... > Note that all these disk devices are not CAM devices, so CAM changing to > use new-bus wouldn't really matter one whit. They do all show up as 'DISK' > GEOM's however (I also hacked on a GEOM-based libdisk replacement at one > point, though probably less developed than Marcel's. I used libgeom to > discover DISK devices.) Given that disk_create() already hooks into GEOM, > that is probably the right way to discover disks in a generic fashion. Right, stepping through that is how I build the list. Adding a device description to the XML actually seems like a good idea (and maybe the drive serial number?). Would anyone have any objections to me starting to go through and do that? -Nathan From owner-freebsd-current@FreeBSD.ORG Thu Feb 24 20:38:25 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 5369E106566C; Thu, 24 Feb 2011 20:38:25 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@FreeBSD.org Date: Thu, 24 Feb 2011 15:38:15 -0500 User-Agent: KMail/1.6.2 References: <4D64FF99.2070908@cabletv.dp.ua> <20110224152759.00003c4e@unknown> <201102241511.24989.jhb@freebsd.org> In-Reply-To: <201102241511.24989.jhb@freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201102241538.17592.jkim@FreeBSD.org> Cc: Bruce Cran , Mitya , Nathan Whitehorn Subject: Re: Cosmetic path to bsdinstall 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, 24 Feb 2011 20:38:25 -0000 On Thursday 24 February 2011 03:11 pm, John Baldwin wrote: > On Thursday, February 24, 2011 10:27:59 am Bruce Cran wrote: > > On Thu, 24 Feb 2011 09:00:44 -0600 > > > > Nathan Whitehorn wrote: > > > Having CAM devices be part of newbus would > > > simplify this a very great deal... > > > > It's required if we're ever going to have suspend/resume working > > properly because currently CAM doesn't get a suspend > > notification, so doesn't know to spin-down disks etc. > > The controllers get a suspend notification though (via > device_suspend() hooks that drivers like mpt, etc. could register > for) and could then use that to post a suspend of the associated > buses. That doesn't require CAM to use new-bus though. FYI, I've been using the following hack for a while now: http://people.freebsd.org/~jkim/ada_suspend.diff Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Thu Feb 24 20:45: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 68BB1106564A; Thu, 24 Feb 2011 20:45:18 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (unknown [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id EA43C8FC1A; Thu, 24 Feb 2011 20:45:17 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id A3042E8C22; Thu, 24 Feb 2011 20:45:02 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=date:from :to:cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=mail; bh=liJUSHRZZDFT eNgF9VHkPoxCFgc=; b=NhkRqsRNXjKAK1JtBWWsqncOnvPfLnSvRat02aaAql9C CzSxJyTmbMCANe82WmO6baM8xbfjvMj6Cuu+oEuzBRVguzF2n5C/i+9HT1ESBY5Q 3XvKR/3dxqJsB8W2xd4HbdtsDEciuI1l6gEErJIPUHxCTo/29jr0GdMNGg3bzQc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=date:from:to :cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; q=dns; s=mail; b=chZ29c NKwTzBKXV6KCtQDB5ldoekwCrR8dRSHrEu1mbALIKpnH5ocKyvGDJqRwe/vMlVeN YR2Yi0bWuLs4c7Rsw8G93ItRs5epBLJffr2uzL4IcCly7dUyCzqsq9vIStvQ3q5Z pOeCmADJAxGC0JdIPa46XmYKkWe1kP1x5A+6w= Received: from unknown (client-86-31-236-253.oxfd.adsl.virginmedia.com [86.31.236.253]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id 2EC64E8BA7; Thu, 24 Feb 2011 20:45:02 +0000 (GMT) Date: Thu, 24 Feb 2011 20:44:54 +0000 From: Bruce Cran To: Jung-uk Kim Message-ID: <20110224204454.00002435@unknown> In-Reply-To: <201102241538.17592.jkim@FreeBSD.org> References: <4D64FF99.2070908@cabletv.dp.ua> <20110224152759.00003c4e@unknown> <201102241511.24989.jhb@freebsd.org> <201102241538.17592.jkim@FreeBSD.org> X-Mailer: Claws Mail 3.7.8cvs9 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, Mitya , Nathan Whitehorn Subject: Re: Cosmetic path to bsdinstall 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, 24 Feb 2011 20:45:18 -0000 On Thu, 24 Feb 2011 15:38:15 -0500 Jung-uk Kim wrote: > FYI, I've been using the following hack for a while now: > > http://people.freebsd.org/~jkim/ada_suspend.diff Thanks, I'd given up trying to fix this because I was under the impression it needed newbus. I'll see if I can get something similar committed so at least another part of suspend/resume works. I think someone mentioned there was documentation somewhere that was going to be put on the Wiki about what needs done in order to get suspend/resume working properly. Does anyone know where that might be? -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Thu Feb 24 20:58:41 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 129421065693 for ; Thu, 24 Feb 2011 20:58:41 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from doug-optiplex.ka9q.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 2328417990D for ; Thu, 24 Feb 2011 20:58:13 +0000 (UTC) Message-ID: <4D66C664.2070105@FreeBSD.org> Date: Thu, 24 Feb 2011 12:58:12 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20110129 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org References: <4D660826.7020609@FreeBSD.org> In-Reply-To: <4D660826.7020609@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: Re: Problem with a port after clang'ifying 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, 24 Feb 2011 20:58:41 -0000 A little more information. Using -O0 or -O1 in CFLAGS the resulting binary works. The default of -O2 crashes, with or without -fno-strict-aliasing. hth, 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 Thu Feb 24 21:53: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 7976A106566B for ; Thu, 24 Feb 2011 21:53:56 +0000 (UTC) (envelope-from jamesbrandongooch@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 1C03B8FC16 for ; Thu, 24 Feb 2011 21:53:55 +0000 (UTC) Received: by ywf9 with SMTP id 9so224357ywf.13 for ; Thu, 24 Feb 2011 13:53:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=Q+6dvzCOlYaS7cFd0lkKT8hj5GTYqk9OjM5D0+vHjDc=; b=nxAz5sTN017IJ269fu6HBIhI1tpjOM11Nln1Ar291WrzlCKcXKvI/y+vDgslfkPefW vwN9LxC6U3vHQwdNjD2pgAJpCHc6TLnwm9X3ZHO0VD6pAkUtAeECblBfOJVaO8duMqn9 /G5lHcra0TvCVhd73Lbwb5MJAW4KvGurSBHCs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=OUywJo4RI3NbKSW2tiWbaRKot+kJoBftqUaUaPG6XYyS0Z/h+e4KcSAiwydlhT8sxO mTR61Y5B/42vIUhJUCVkK8TjNrTAFBnJweqKJswt206HgJdwNyIbQ3JGe5gBd3qo2C4K qrrkxnb+c22WWvO40DY9H3i3xeOpJ9aCzJNCQ= Received: by 10.236.109.164 with SMTP id s24mr2611805yhg.89.1298584432927; Thu, 24 Feb 2011 13:53:52 -0800 (PST) Received: from [192.168.1.101] ([24.112.22.136]) by mx.google.com with ESMTPS id g63sm5919043yhd.15.2011.02.24.13.53.50 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 24 Feb 2011 13:53:51 -0800 (PST) References: <4D64FF99.2070908@cabletv.dp.ua> <20110224152759.00003c4e@unknown> <201102241511.24989.jhb@freebsd.org> <201102241538.17592.jkim@FreeBSD.org> <20110224204454.00002435@unknown> In-Reply-To: <20110224204454.00002435@unknown> Mime-Version: 1.0 (iPhone Mail 8C148) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <9EEE560B-0976-413D-8CCF-4D9AF12E59DD@gmail.com> X-Mailer: iPhone Mail (8C148) From: Brandon Gooch Date: Thu, 24 Feb 2011 15:53:27 -0600 To: Bruce Cran Cc: "freebsd-current@FreeBSD.org" , Mitya , Nathan Whitehorn , Jung-uk Kim Subject: Re: Cosmetic path to bsdinstall 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, 24 Feb 2011 21:53:56 -0000 On Feb 24, 2011, at 2:44 PM, Bruce Cran wrote: > On Thu, 24 Feb 2011 15:38:15 -0500 > Jung-uk Kim wrote: >=20 >> FYI, I've been using the following hack for a while now: >>=20 >> http://people.freebsd.org/~jkim/ada_suspend.diff >=20 > Thanks, I'd given up trying to fix this because I was under the > impression it needed newbus. I'll see if I can get something similar > committed so at least another part of suspend/resume works. >=20 > I think someone mentioned there was documentation somewhere that was > going to be put on the Wiki about what needs done in order to get > suspend/resume working properly. Does anyone know where that might be? >=20 > --=20 > Bruce Cran > _______________________________________________ > 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"= I'd also be interested in reading about this, as I often field questions fro= m my colleagues... -Brandon From owner-freebsd-current@FreeBSD.ORG Thu Feb 24 21:53: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 A450C106564A for ; Thu, 24 Feb 2011 21:53:57 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 5F1638FC0A for ; Thu, 24 Feb 2011 21:53:57 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:fdb7:fce5:9afe:c59f] (unknown [IPv6:2001:7b8:3a7:0:fdb7:fce5:9afe:c59f]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 6356D5C37; Thu, 24 Feb 2011 22:53:56 +0100 (CET) Message-ID: <4D66D37D.2010903@FreeBSD.org> Date: Thu, 24 Feb 2011 22:54:05 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.15pre) Gecko/20110221 Lanikai/3.1.9pre MIME-Version: 1.0 To: "datastream datastream.freecity" References: <4D627FBE.1070700@FreeBSD.org> <4D63D28B.4080900@FreeBSD.org> <4D653007.9080103@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Olivier Smedts , freebsd-current@freebsd.org Subject: Re: Can't buildworld since Clang update 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, 24 Feb 2011 21:53:57 -0000 On 2011-02-24 08:26, datastream datastream.freecity wrote: > I removed /etc/src.conf.binutils is 2.15. ... Ok, I managed to reproduce your error, on an old snapshot with clang 2.8 and binutils 2.15. It turns out it is caused by an upstream change, which was intended to work around problems in the configure scripts of some ports. Unfortunately, it also has the side effect of sometimes picking the wrong libraries to link with, which can lead to the error you have seen. I have committed a fix for this in r219011; can you please update to at least that revision, blow away your /usr/obj just to be sure, and try to rebuild? It should now work properly. From owner-freebsd-current@FreeBSD.ORG Thu Feb 24 22:10:29 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 25EA11065673; Thu, 24 Feb 2011 22:10:29 +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 EB5D48FC17; Thu, 24 Feb 2011 22:10:28 +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 9A89046B03; Thu, 24 Feb 2011 17:10:28 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.10]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B93D58A009; Thu, 24 Feb 2011 17:10:27 -0500 (EST) From: John Baldwin To: Nathan Whitehorn Date: Thu, 24 Feb 2011 17:07:58 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.4-CBSD-20110107; KDE/4.4.5; amd64; ; ) References: <4D64FF99.2070908@cabletv.dp.ua> <201102241514.19727.jhb@freebsd.org> <4D66C127.6060701@freebsd.org> In-Reply-To: <4D66C127.6060701@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201102241707.58995.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 24 Feb 2011 17:10:27 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=0.5 required=4.2 tests=BAYES_00,MAY_BE_FORGED, RDNS_DYNAMIC autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: freebsd-current@freebsd.org, Mitya Subject: Re: Cosmetic path to bsdinstall 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, 24 Feb 2011 22:10:29 -0000 On Thursday, February 24, 2011 3:35:51 pm Nathan Whitehorn wrote: > On 02/24/11 14:14, John Baldwin wrote: > > On Thursday, February 24, 2011 10:00:44 am Nathan Whitehorn wrote: > >> Thanks! I've received basically this patch from a couple people now. I'm > >> going to investigate whether this is a more generic way to get this > >> information (so the list doesn't grow infinitely long), and will commit > >> this if I can't. Having CAM devices be part of newbus would simplify > >> this a very great deal... > > Note that all these disk devices are not CAM devices, so CAM changing to > > use new-bus wouldn't really matter one whit. They do all show up as 'DISK' > > GEOM's however (I also hacked on a GEOM-based libdisk replacement at one > > point, though probably less developed than Marcel's. I used libgeom to > > discover DISK devices.) Given that disk_create() already hooks into GEOM, > > that is probably the right way to discover disks in a generic fashion. > > Right, stepping through that is how I build the list. Adding a device > description to the XML actually seems like a good idea (and maybe the > drive serial number?). Would anyone have any objections to me starting > to go through and do that? I think that would be fine, but I don't think GEOM knows about those properties yet? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Feb 24 22:25:44 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id EEB2C106566C; Thu, 24 Feb 2011 22:25:43 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@FreeBSD.org Date: Thu, 24 Feb 2011 17:25:32 -0500 User-Agent: KMail/1.6.2 References: <4D64FF99.2070908@cabletv.dp.ua> <20110224204454.00002435@unknown> <9EEE560B-0976-413D-8CCF-4D9AF12E59DD@gmail.com> In-Reply-To: <9EEE560B-0976-413D-8CCF-4D9AF12E59DD@gmail.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201102241725.33387.jkim@FreeBSD.org> Cc: Brandon Gooch , Bruce Cran , "freebsd-current@FreeBSD.org" , Mitya , Nathan Whitehorn Subject: TODOs for suspend/resume (Re: Cosmetic path to bsdinstall) 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, 24 Feb 2011 22:25:44 -0000 On Thursday 24 February 2011 04:53 pm, Brandon Gooch wrote: > On Feb 24, 2011, at 2:44 PM, Bruce Cran wrote: > > On Thu, 24 Feb 2011 15:38:15 -0500 > > > > Jung-uk Kim wrote: > >> FYI, I've been using the following hack for a while now: > >> > >> http://people.freebsd.org/~jkim/ada_suspend.diff > > > > Thanks, I'd given up trying to fix this because I was under the > > impression it needed newbus. I'll see if I can get something > > similar committed so at least another part of suspend/resume > > works. > > > > I think someone mentioned there was documentation somewhere that > > was going to be put on the Wiki about what needs done in order to > > get suspend/resume working properly. Does anyone know where that > > might be? > > > > -- > > Bruce Cran > > I'd also be interested in reading about this, as I often field > questions from my colleagues... I am not aware of such documentation. Mostly the problem is in device drivers. Someone should start a list of misbehaving device drivers first if needed. However, it is not easy because several layers are involved, i.e., bus drivers (acpi, isa, pci, usb, ...) and their children (acpi_video, atkbdc, ath, ums...) and we don't know for sure what's to blame. Also, many complaints are related to GPU issues. Currently, we rely on simple VGA registers or VESA BIOS (if vesa.ko is loaded) but many modern GPUs simply don't care about these any more. So, we need GPU-specific drivers (as Linux does it via KMS nowadays). The only workaround for these problems is using X.org with "right" device drivers ATM. Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Thu Feb 24 22:56:40 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 A18591065675; Thu, 24 Feb 2011 22:56:40 +0000 (UTC) (envelope-from gabor@kovesdan.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id 5BA588FC0A; Thu, 24 Feb 2011 22:56:40 +0000 (UTC) Received: from server.mypc.hu (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id 939D614E426E; Thu, 24 Feb 2011 23:40:49 +0100 (CET) X-Virus-Scanned: amavisd-new at server.mypc.hu Received: from server.mypc.hu ([127.0.0.1]) by server.mypc.hu (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 5fgl44anh58T; Thu, 24 Feb 2011 23:40:47 +0100 (CET) Received: from [193.137.158.146] (unknown [193.137.158.146]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id 108C614E412A; Thu, 24 Feb 2011 23:40:46 +0100 (CET) Message-ID: <4D66DE70.9000100@kovesdan.org> Date: Thu, 24 Feb 2011 22:40:48 +0000 From: Gabor Kovesdan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; pt-PT; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: current@FreeBSD.org, i18n@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 24 Feb 2011 23:13:26 +0000 Cc: Subject: HEADSUP: BSD iconv coming to the base system with default off 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, 24 Feb 2011 22:56:40 -0000 Hi Folks, I've got some time again to keep working on iconv. The last time I posted a patch, there were problems with some ports but apart from this it proved to be quite mature, so I decided to commit it to the base system but the default setting will be disabled. It can be enabled by setting the WITH_ICONV knob but whoever does it will take into account that it may break some ports from being built. However, this change will help me with future work and will also help interested people in getting involved in the testing. The rather big changeset is coming soon. Regards, Gabor Kovesdan From owner-freebsd-current@FreeBSD.ORG Fri Feb 25 02:12: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 929A9106566B for ; Fri, 25 Feb 2011 02:12:06 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 18AD48FC0A for ; Fri, 25 Feb 2011 02:12:05 +0000 (UTC) Received: from ur.gsoft.com.au (Ur.gsoft.com.au [203.31.81.44]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id p1P2BxxK011835 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 25 Feb 2011 12:42:00 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Daniel O'Connor" In-Reply-To: <4D6291A5.4050206@netasq.com> Date: Fri, 25 Feb 2011 12:41:58 +1030 Content-Transfer-Encoding: quoted-printable Message-Id: <0691A273-3363-4FC2-B2C6-5995A628C801@gsoft.com.au> References: <4D6291A5.4050206@netasq.com> To: Jerome Flesch X-Mailer: Apple Mail (2.1082) X-Spam-Score: -2.51 () ALL_TRUSTED,BAYES_00,T_RP_MATCHES_RCVD X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: freebsd-current@freebsd.org Subject: Re: Process timing issue 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, 25 Feb 2011 02:12:06 -0000 On 22/02/2011, at 2:54, Jerome Flesch wrote: > While investigating a timing issue with one of our program, we found = out something weird: We've written a small test program that just calls = clock_gettime() a lot of times and checks that the time difference = between calls makes sense. In the end, it seems it doesn't always do. >=20 > Calling twice in a row clock_gettime() takes usually less than 1ms. = But with an average load, about 1 time in 200000, more than 10ms are = spent between both calls for no apparent reason. According to our tests, = when it happens, the time between both calls can go from few = milliseconds to many seconds (our best score so far is 10 seconds :). = Same goes for gettimeofday(). >=20 > To reproduce this issue, we use the small test program joined to this = mail and openssl speed test commands (usually 'openssl speed -elapsed = dsa2048'). It only appears if one of these openssl speed test run on the = same core than our test progam, so we have to start as many openssl = instances as there are cores on the test computer. This sounds like a problem I have trying to read from a FIFO in hardware = over USB. Most of the time the libusb poll thread doesn't take very long, but = every now and then it takes too long and my FIFO fills up (~75msec). If you do find a solution I would be very interested :) In the end I wrote a kernel driver which read & buffered the data, but I = suppose that is not possible for you. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-current@FreeBSD.ORG Fri Feb 25 07:48:26 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 63F13106564A for ; Fri, 25 Feb 2011 07:48:26 +0000 (UTC) (envelope-from swell.k@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id A78368FC2B for ; Fri, 25 Feb 2011 07:48:25 +0000 (UTC) Received: by ewy28 with SMTP id 28so541543ewy.13 for ; Thu, 24 Feb 2011 23:48:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:cc:subject:in-reply-to:references :references:date:message-id:user-agent:mime-version:content-type :content-transfer-encoding; bh=PDnT7SAqDOYutYIBE2aDjKQK67541wVYK6sRT8wO9NM=; b=EkXQ2U7i8wepb1Kor4vg2GWJqsjSl0Yps78BFmYIEmvFrEEU1SYEKvzz4JYY3dn6Z1 gvszfFrND5qd7LCJdIjaptmqtxhwwYxM6+sM19M03hR1t6qOFfM8Np/qprYn8e99/5M0 oxeEuHKN+1e7/89b0sOxVVZXbBqVr3ZKsEHQ4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:in-reply-to:references:date:message-id :user-agent:mime-version:content-type:content-transfer-encoding; b=pE+7TiJSmyX4PRiRjQ3MSOQZdFfEHzowPFqRN8LS/JCkDjLpqyyzDXS6JNMHedMuGU ycerKQZW8Cb7jPQWazdT2AxBK2dLBWHnuv3qIeWP0v7eqxTPtn9UdLBaMxNa6fRsSTRS 0HWNIgohf+M3E0GEaQy6CHJ6iwjoR4NSt0cUg= Received: by 10.213.99.204 with SMTP id v12mr287993ebn.53.1298620104108; Thu, 24 Feb 2011 23:48:24 -0800 (PST) Received: from localhost ([46.182.126.126]) by mx.google.com with ESMTPS id u1sm318102eeh.16.2011.02.24.23.48.19 (version=SSLv3 cipher=OTHER); Thu, 24 Feb 2011 23:48:22 -0800 (PST) From: Anonymous To: Gabor Kovesdan In-Reply-To: <4D66DE70.9000100@kovesdan.org> References: <4C16C5B5.1070308@FreeBSD.org> <867hlzq4lb.fsf@gmail.com> <867hlzufl6.fsf@gmail.com> <4C1A7A57.3000006@FreeBSD.org> <86bpb9z77g.fsf@gmail.com> <4C2F7917.7040900@FreeBSD.org> <86pqz29sy2.fsf@gmail.com> <86mxu4sj0n.fsf@gmail.com> <4C35EF85.6010905@FreeBSD.org> <86lj8ot09d.fsf@gmail.com> <86hbilha0s.fsf@gmail.com> References: <4C16C5B5.1070308@FreeBSD.org> <867hlzq4lb.fsf@gmail.com> <867hlzufl6.fsf@gmail.com> <4C1A7A57.3000006@FreeBSD.org> <86bpb9z77g.fsf@gmail.com> <4C2F7917.7040900@FreeBSD.org> <86pqz29sy2.fsf@gmail.com> <86mxu4sj0n.fsf@gmail.com> <4C35EF85.6010905@FreeBSD.org> <86lj8ot09d.fsf@gmail.com> <4C6A6D0B.4010908@FreeBSD.org> <4D66DE70.9000100@kovesdan.org> Date: Fri, 25 Feb 2011 10:48:13 +0300 Message-ID: <86wrko5zcy.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; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, freebsd-i18n@FreeBSD.org Subject: Re: HEADSUP: BSD iconv coming to the base system with default off 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, 25 Feb 2011 07:48:26 -0000 Anonymous writes in "[CFT] BSDL iconv in base system": > I guess gettext hanging is due to ABI incompatibility, too. > > $ cat foo.po > msgid "" > msgstr "" > "Content-Type: text/plain; charset=3DUTF-8\n" > "Content-Transfer-Encoding: 8bit\n" > > msgid "don=E2=80=99t" > msgstr "do not" > > $ msgmerge foo.po /dev/null # GNU iconv > . done. > msgid "" > msgstr "" > "Content-Type: text/plain; charset=3DUTF-8\n" > "Content-Transfer-Encoding: 8bit\n" > > #~ msgid "don=E2=80=99t" > #~ msgstr "do not" > > $ msgmerge foo.po /dev/null # BSD iconv > . done. > msgid "" > load: 0.10 cmd: msgmerge 65132 [runnable] 2.74r 2.72u 0.00s 23% 2844k > ^C > (gdb) bt > #0 _citrus_iconv_none_iconv_convert (ci=3D0x80f00f190, in=3D0x7fffffff= 0b40, inbytes=3D0x7fffffff0b40, out=3D0x7fffffff0b48, outbytes=3D0x7fffffff= 0b50, flags=3D0, > invalids=3D0x7fffffff0aa0) at /usr/src/lib/libiconv_modules/iconv_n= one/citrus_iconv_none.c:119 > len =3D 1 > e2big =3D 0 > #1 0x00000008064b9142 in _citrus_iconv_convert (cv=3D0x80f00f190, in= =3D0x7fffffff0b38, inbytes=3D0x7fffffff0b40, out=3D0x7fffffff0b48, outbytes= =3D0x7fffffff0b50, > flags=3D0, nresults=3D0x7fffffff0aa0) at citrus_iconv.h:60 > No locals. > #2 0x00000008064b90b2 in libiconv (handle=3D0x80f00f190, in=3D0x7fffff= ff0b38, szin=3D0x7fffffff0b40, out=3D0x7fffffff0b48, szout=3D0x7fffffff0b50) > at /usr/src/lib/libc/iconv/iconv.c:147 > ret =3D 0 > err =3D 0 > #3 0x00000008036db20a in wrap (mp=3D0x80f020400, stream=3D0x80f0123c0,= line_prefix=3D0x0, extra_indent=3D0, css_class=3D0x80370a2f0 "msgstr", > name=3D0x80370a3a9 "msgstr", value=3D0x80f01f0b0 "Content-Type: tex= t/plain; charset=3DUTF-8\nContent-Transfer-Encoding: 8bit\n", do_wrap=3Dund= ecided, > page_width=3D79, charset=3D0x7fffffff0d80 "UTF-8") at write-po.c:724 > #4 0x00000008036dcbdd in message_print (mp=3D0x80f020400, stream=3D0x8= 0f0123c0, charset=3D0x7fffffff0d80 "UTF-8", page_width=3D79, blank_line=3Df= alse, debug=3Dfalse) > at write-po.c:1283 > #5 0x00000008036dd736 in msgdomain_list_print_po (mdlp=3D0x80f0071c0, = stream=3D0x80f0123c0, page_width=3D79, debug=3Dfalse) at write-po.c:1511 > #6 0x00000008036d8859 in msgdomain_list_print (mdlp=3D0x80f0071c0, fil= ename=3D0x80370a0a6 "standard output", output_syntax=3D0x40d7b0, force=3Dfa= lse, debug=3Dfalse) > at write-catalog.c:246 > #7 0x0000000000403604 in main (argc=3D3, argv=3D0x7fffffff0ff0) at msg= merge.c:463 Above test still hangs as of r219023M with similar trace. Should I file a PR or bsdiconv isn't supposed to work in such a way? > > It's a bit tweaked version, though. > > %% > Index: devel/gettext/Makefile > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > RCS file: /a/.cvsup/ports/devel/gettext/Makefile,v > retrieving revision 1.87 > diff -u -p -r1.87 Makefile > --- devel/gettext/Makefile 3 Jun 2010 09:46:38 -0000 1.87 > +++ devel/gettext/Makefile 23 Aug 2010 10:04:26 -0000 > @@ -28,7 +28,7 @@ CONFIGURE_ENV=3D ACLOCAL=3D"${TRUE}" \ > AUTOHEADER=3D"${TRUE}" \ > MAKEINFO=3D"makeinfo --no-split" \ > CPPFLAGS=3D"-I${LOCALBASE}/include" \ > - LDFLAGS=3D"-L${LOCALBASE}/lib" \ > + LDFLAGS=3D"-L${LOCALBASE}/lib -liconv" \ > EMACS=3D"no" > CONFIGURE_ARGS=3D --disable-csharp --disable-threads --disable-openmp \ > --with-included-gettext --with-included-glib \ > @@ -65,6 +65,8 @@ pre-extract: > .endif >=20=20 > post-patch: > + @${REINPLACE_CMD} 's/-DENABLE_RELOCATABLE=3D1//' \ > + ${WRKSRC}/gettext-runtime/intl/Makefile.in > @${FIND} ${WRKSRC} -name configure -print | ${XARGS} \ > ${REINPLACE_CMD} -e 's|mkdir gmkdir|mkdir|' > .if defined (NOPORTDOCS) > %% From owner-freebsd-current@FreeBSD.ORG Fri Feb 25 07:50:42 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 CB20A1065744; Fri, 25 Feb 2011 07:50:42 +0000 (UTC) (envelope-from datastream.freecity@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 5ADDC8FC20; Fri, 25 Feb 2011 07:50:42 +0000 (UTC) Received: by yxl31 with SMTP id 31so733298yxl.13 for ; Thu, 24 Feb 2011 23:50:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=YHxTtUfPc1VAIe6fa0owZFHmUnHivnskoXtG5JLcBBY=; b=PU8c+Qy7d7y4LJEJgwzZ6DgBNqkOa80tTKiLpT97EEnjhqaMgnMw8fzgh+NO8ni1cq fezyMMNFVHt2U5ViyhYF5FlrYivSPByQwxQp5i/8WPfAs9A13vpWXQRrBcD8D8h4MV8J T8MRVexqYhF98RlsS/EujYkjJuOSdccN2qk6c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=tGKgWxx8sZxlj4BBaz6Ttdjx4PRIpMn1KDIVyZJ/ua4n0gF5B2LUa7edblmIQq2+Uo vYvYlh+1k6Xe+5S1mLLJXKD7y/1XYobmxPqI6D7tSFG+sz+gylQV5eAOLiGeF7lSCKfM FEHZ2OoAT7lCwlqzqZ1srlHsG5FD7Mb0i20TE= MIME-Version: 1.0 Received: by 10.151.40.5 with SMTP id s5mr3246115ybj.63.1298620241649; Thu, 24 Feb 2011 23:50:41 -0800 (PST) Received: by 10.151.47.7 with HTTP; Thu, 24 Feb 2011 23:50:41 -0800 (PST) In-Reply-To: <4D66D37D.2010903@FreeBSD.org> References: <4D627FBE.1070700@FreeBSD.org> <4D63D28B.4080900@FreeBSD.org> <4D653007.9080103@FreeBSD.org> <4D66D37D.2010903@FreeBSD.org> Date: Fri, 25 Feb 2011 15:50:41 +0800 Message-ID: From: "datastream datastream.freecity" To: Dimitry Andric Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Olivier Smedts , freebsd-current@freebsd.org Subject: Re: Can't buildworld since Clang update 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, 25 Feb 2011 07:50:43 -0000 It works.make buildworld works ok now.Thinks Dimitry Andric. On Fri, Feb 25, 2011 at 5:54 AM, Dimitry Andric wrote: > On 2011-02-24 08:26, datastream datastream.freecity wrote: > >> I removed /etc/src.conf.binutils is 2.15. >> > ... > > Ok, I managed to reproduce your error, on an old snapshot with clang 2.8 > and binutils 2.15. It turns out it is caused by an upstream change, > which was intended to work around problems in the configure scripts of > some ports. > > Unfortunately, it also has the side effect of sometimes picking the > wrong libraries to link with, which can lead to the error you have seen. > > I have committed a fix for this in r219011; can you please update to at > least that revision, blow away your /usr/obj just to be sure, and try to > rebuild? It should now work properly. > From owner-freebsd-current@FreeBSD.ORG Fri Feb 25 08:11: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 06ABD106566C for ; Fri, 25 Feb 2011 08:11:19 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (unknown [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id 85D558FC14 for ; Fri, 25 Feb 2011 08:11:18 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id B8619E76FF; Fri, 25 Feb 2011 08:11:15 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=subject :from:to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; s=mail; bh=FpSySQLTK4m6 s9/bkafVhKAHW9g=; b=kaW6B6TUD6oYw5lDH9bfulD4wdBm7qfYXYmSOq1HS5cr 0SAWoPm4DFk8I0mopWjhCaoL7LIlr344KuJRpXZHKjE/2mBZwHy7ks0lLZUd5J6Q doBo+P0PC3SCzxa1glr8b8htqyg2Rs3okJh02qyycL+MVjBkT63JByVoxo9OJ5w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s=mail; b=niCF8y sWL9EBIPmGpwJepx9QpQ2L6xeNKoi59o2UVYNhK0dqtNSAWXRFTf0Qxv47gi5uSt 4l3wIBzWJuV2fDCbCSbS4lvdfDHRKaxiZSRbGEneRNb2YZ825PIAJF134czNIcq/ Lk3EF3Y0DNYeEgeDys4Ny8LZhQFR9fpQ6T6sE= Received: from [192.168.0.10] (client-86-31-236-253.oxfd.adsl.virginmedia.com [86.31.236.253]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id 5E2DDE76E8; Fri, 25 Feb 2011 08:11:15 +0000 (GMT) From: Bruce Cran To: Olivier Smedts In-Reply-To: References: <20101213214556.GC2038@garage.freebsd.pl> <8662upxg76.fsf@gmail.com> <86lj1s3pv0.fsf@gmail.com> Content-Type: text/plain; charset="us-ascii" Date: Fri, 25 Feb 2011 08:11:06 +0000 Message-ID: <1298621466.42510.1.camel@core.nessbank> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Jason Garrett , freebsd-current Subject: Re: Next ZFSv28 patchset ready for testing. 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, 25 Feb 2011 08:11:19 -0000 On Wed, 2011-02-23 at 23:28 +0100, Olivier Smedts wrote: > I'm successfuly using the following on latest 9-CURRENT : > http://people.freebsd.org/~mm/patches/zfs/v28/head-zfsv28-20110219-nopython.patch.xz sys/cddl/compat/opensolaris/sys/sysmacros.h will fail to patch on the latest -CURRENT but that's because the changes have already been added. -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Fri Feb 25 09:33: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 8AB9A106566B; Fri, 25 Feb 2011 09:33:48 +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 491AD8FC15; Fri, 25 Feb 2011 09:33:48 +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 1Psu3W-0004K2-QD; Fri, 25 Feb 2011 09:33:46 +0000 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 1Psu3W-00037i-M9; Fri, 25 Feb 2011 09:33:46 +0000 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 p1P9XkvN015692; Fri, 25 Feb 2011 09:33:46 GMT (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 p1P9XkGX015691; Fri, 25 Feb 2011 09:33:46 GMT (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: Fri, 25 Feb 2011 09:33:46 +0000 From: Anton Shterenlikht To: freebsd-current@freebsd.org, freebsd-ia64@freebsd.org Message-ID: <20110225093345.GA2123@mech-cluster241.men.bris.ac.uk> Mail-Followup-To: freebsd-current@freebsd.org, freebsd-ia64@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: ieee denormal on ia64? 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, 25 Feb 2011 09:33:48 -0000 Can somebody please confirm that denormal are not available on ia64, see below. Thanks Anton ----- Forwarded message from FX ----- > What about denormal? The FreeBSD manpage for fpsetmask() at http://tinyurl.com/64oo7zh says: > #define FP_X_DNML 0x02 /* denormal */ so it is, in principle, available. However, looking at the FreeBSD 8 source tree, I see for sys/ia64/include/ieeefp.h: #define FP_X_INV IA64_FPSR_TRAP_VD /* invalid operation exception */ #define FP_X_DZ IA64_FPSR_TRAP_ZD /* divide-by-zero exception */ #define FP_X_OFL IA64_FPSR_TRAP_OD /* overflow exception */ #define FP_X_UFL IA64_FPSR_TRAP_UD /* underflow exception */ #define FP_X_IMP IA64_FPSR_TRAP_ID /* imprecise(inexact) exception */ which means underflow is not a supported exception, while it is for amd64: #define FP_X_DNML 0x02 /* denormal */ and also for i386: #define FP_X_DNML 0x02 /* denormal */ So, in this case, it's actually an OS issue! Cheers, FX ----- End forwarded message ----- -- 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 Fri Feb 25 09:59: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 BAAF51065673 for ; Fri, 25 Feb 2011 09:59:06 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8CAE18FC16 for ; Fri, 25 Feb 2011 09:59:06 +0000 (UTC) Received: by iyj12 with SMTP id 12so846178iyj.13 for ; Fri, 25 Feb 2011 01:59:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.241.68 with SMTP id ld4mr531369icb.447.1298627945242; Fri, 25 Feb 2011 01:59:05 -0800 (PST) Received: by 10.231.149.79 with HTTP; Fri, 25 Feb 2011 01:59:04 -0800 (PST) In-Reply-To: <1298621466.42510.1.camel@core.nessbank> References: <20101213214556.GC2038@garage.freebsd.pl> <8662upxg76.fsf@gmail.com> <86lj1s3pv0.fsf@gmail.com> <1298621466.42510.1.camel@core.nessbank> Date: Fri, 25 Feb 2011 10:59:04 +0100 Message-ID: From: Olivier Smedts To: Bruce Cran Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Jason Garrett , freebsd-current Subject: Re: Next ZFSv28 patchset ready for testing. 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, 25 Feb 2011 09:59:06 -0000 2011/2/25 Bruce Cran : > On Wed, 2011-02-23 at 23:28 +0100, Olivier Smedts wrote: > >> I'm successfuly using the following on latest 9-CURRENT : >> http://people.freebsd.org/~mm/patches/zfs/v28/head-zfsv28-20110219-nopyt= hon.patch.xz > > sys/cddl/compat/opensolaris/sys/sysmacros.h will fail to patch on the > latest -CURRENT but that's because the changes have already been added. Added ? The patch fails because the svn tag is not expanded, but what the patch does is remove the file. You can do so after patching if it failed. --=20 Olivier Smedts=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 _ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 ASCII ribbon campaign ( ) e-mail: olivier@gid0.org=A0 =A0 =A0 =A0 - against HTML email & vCards=A0 X www: http://www.gid0.org=A0 =A0 - against proprietary attachments / \ =A0 "Il y a seulement 10 sortes de gens dans le monde : =A0 ceux qui comprennent le binaire, =A0 et ceux qui ne le comprennent pas." From owner-freebsd-current@FreeBSD.ORG Fri Feb 25 11:38: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 7EF3B106566B for ; Fri, 25 Feb 2011 11:38:48 +0000 (UTC) (envelope-from brucec@muon.cran.org.uk) Received: from muon.cran.org.uk (unknown [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id 42D9A8FC0C for ; Fri, 25 Feb 2011 11:38:48 +0000 (UTC) Received: by muon.cran.org.uk (Postfix, from userid 1001) id 9EBBFE8171; Fri, 25 Feb 2011 11:38:47 +0000 (GMT) Date: Fri, 25 Feb 2011 11:38:47 +0000 From: Bruce Cran To: Olivier Smedts Message-ID: <20110225113847.GB2042@muon.cran.org.uk> References: <20101213214556.GC2038@garage.freebsd.pl> <8662upxg76.fsf@gmail.com> <86lj1s3pv0.fsf@gmail.com> <1298621466.42510.1.camel@core.nessbank> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Bruce Cran , Jason Garrett , freebsd-current Subject: Re: Next ZFSv28 patchset ready for testing. 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, 25 Feb 2011 11:38:48 -0000 On Fri, Feb 25, 2011 at 10:59:04AM +0100, Olivier Smedts wrote: > > Added ? The patch fails because the svn tag is not expanded, but what > the patch does is remove the file. You can do so after patching if it > failed. It looks like there are two patches to sysmacros.h - the first adds SIGNOF and highbit and the second then removes the file. -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Fri Feb 25 12:08: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 811FB106564A for ; Fri, 25 Feb 2011 12:08:27 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 50F7E8FC14 for ; Fri, 25 Feb 2011 12:08:27 +0000 (UTC) Received: by iyj12 with SMTP id 12so926249iyj.13 for ; Fri, 25 Feb 2011 04:08:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.241.68 with SMTP id ld4mr650837icb.447.1298635706470; Fri, 25 Feb 2011 04:08:26 -0800 (PST) Received: by 10.231.149.79 with HTTP; Fri, 25 Feb 2011 04:08:26 -0800 (PST) In-Reply-To: <20110225113847.GB2042@muon.cran.org.uk> References: <20101213214556.GC2038@garage.freebsd.pl> <8662upxg76.fsf@gmail.com> <86lj1s3pv0.fsf@gmail.com> <1298621466.42510.1.camel@core.nessbank> <20110225113847.GB2042@muon.cran.org.uk> Date: Fri, 25 Feb 2011 13:08:26 +0100 Message-ID: From: Olivier Smedts To: Bruce Cran Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Jason Garrett , freebsd-current Subject: Re: Next ZFSv28 patchset ready for testing. 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, 25 Feb 2011 12:08:27 -0000 2011/2/25 Bruce Cran : > On Fri, Feb 25, 2011 at 10:59:04AM +0100, Olivier Smedts wrote: >> >> Added ? The patch fails because the svn tag is not expanded, but what >> the patch does is remove the file. You can do so after patching if it >> failed. > > It looks like there are two patches to sysmacros.h - the first adds SIGNO= F and > highbit and the second then removes the file. Not the same sysmacros.h, the one patched is sys/cddl/contrib/opensolaris/uts/common/sys/sysmacros.h, the other one you referenced (sys/cddl/compat/opensolaris/sys/sysmacros.h) is removed by the patch. BTW, even for the first one, I have no problem applying the patch cleanly on 9-CURRENT, svn revision 219027. --=20 Olivier Smedts=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 _ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 ASCII ribbon campaign ( ) e-mail: olivier@gid0.org=A0 =A0 =A0 =A0 - against HTML email & vCards=A0 X www: http://www.gid0.org=A0 =A0 - against proprietary attachments / \ =A0 "Il y a seulement 10 sortes de gens dans le monde : =A0 ceux qui comprennent le binaire, =A0 et ceux qui ne le comprennent pas." From owner-freebsd-current@FreeBSD.ORG Fri Feb 25 12:29: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 B2E5C106564A for ; Fri, 25 Feb 2011 12:29:04 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (unknown [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id 654EC8FC0A for ; Fri, 25 Feb 2011 12:29:04 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 9A363E8171; Fri, 25 Feb 2011 12:29:01 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=subject :from:to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; s=mail; bh=OSvSogR7aqQy 2pjCF4nyfTU+hv8=; b=c7MW23dVRDhbwocX7DC3KcQpLe22Xw0nTj1VqieBgVaK NniqQiePk9KU4zZahKSL4FRlNmA22U7X4MnlBoHtb/4SwhwVpa4I7IA4rUbeoLN5 Rcp8Zabb2i6vS8nenl5YTbiEnqCtRc3GLB0+0NnM5+f2za7X9nicVRuea4+NFd0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s=mail; b=P3Tsld ZZMZeVgpQXSlezYdL/rgGJ82AFTjn8IWFEc8zV6Wf0vS+1K5w79Tu7J+iOSWUJSJ 7mO1U8KVoWP4s17bZYbL63/ZarW727yYpUuTR/39SDdIwDJ3rdkSTAuVBLrqXKsu Eci2L0G9um7443WKaKAc5mTVNPpWQdZZicaWE= Received: from [192.168.0.10] (client-86-31-236-253.oxfd.adsl.virginmedia.com [86.31.236.253]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id 55609E76FF; Fri, 25 Feb 2011 12:29:01 +0000 (GMT) From: Bruce Cran To: Olivier Smedts In-Reply-To: References: <20101213214556.GC2038@garage.freebsd.pl> <8662upxg76.fsf@gmail.com> <86lj1s3pv0.fsf@gmail.com> <1298621466.42510.1.camel@core.nessbank> <20110225113847.GB2042@muon.cran.org.uk> Content-Type: text/plain; charset="us-ascii" Date: Fri, 25 Feb 2011 12:28:50 +0000 Message-ID: <1298636930.2930.5.camel@core.nessbank> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Jason Garrett , freebsd-current Subject: Re: Next ZFSv28 patchset ready for testing. 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, 25 Feb 2011 12:29:04 -0000 On Fri, 2011-02-25 at 13:08 +0100, Olivier Smedts wrote: > Not the same sysmacros.h, the one patched is > sys/cddl/contrib/opensolaris/uts/common/sys/sysmacros.h, the other one > you referenced (sys/cddl/compat/opensolaris/sys/sysmacros.h) is > removed by the patch. So it is - apologies for the noise. -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Fri Feb 25 13:08: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 89E5B106566B; Fri, 25 Feb 2011 13:08:43 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from services.ipt.ru (services.ipt.ru [194.62.233.110]) by mx1.freebsd.org (Postfix) with ESMTP id 0A6C48FC0A; Fri, 25 Feb 2011 13:08:42 +0000 (UTC) Received: from gate.ipt.ru ([194.62.233.123] helo=h30.sp.ipt.ru) by services.ipt.ru with esmtp (Exim 4.54 (FreeBSD)) id 1Pswuc-00022I-Vv; Fri, 25 Feb 2011 15:36:47 +0300 From: Boris Samorodov To: freebsd-current@FreeBSD.org Date: Fri, 25 Feb 2011 15:36:46 +0300 Message-ID: <71444321@h30.sp.ipt.ru> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: dim@FreeBSD.org Subject: [clang] regression: tmpfs is not mounted from fstab 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, 25 Feb 2011 13:08:43 -0000 Hi! I can't mount tmpfs from fstab if world/kernel are build by clang, however just making world with gcc works fine. The last revision I've tested: ----- % uname -a FreeBSD h30.sp.ipt.ru 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r219024: Fri Feb 25 13:17:07 MSK 2011 bsam@h30.sp.ipt.ru:/usr/obj/usr/src/sys/BB i386 ----- The previos clang kernel at r218879 works. Mounting from rc.conf works as well. -- WBR, bsam From owner-freebsd-current@FreeBSD.ORG Fri Feb 25 13:28: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 B52961065674; Fri, 25 Feb 2011 13:28:43 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from services.ipt.ru (services.ipt.ru [194.62.233.110]) by mx1.freebsd.org (Postfix) with ESMTP id 6C8FF8FC14; Fri, 25 Feb 2011 13:28:43 +0000 (UTC) Received: from gate.ipt.ru ([194.62.233.123] helo=h30.sp.ipt.ru) by services.ipt.ru with esmtp (Exim 4.54 (FreeBSD)) id 1Psxis-00026d-9t; Fri, 25 Feb 2011 16:28:42 +0300 From: Boris Samorodov To: freebsd-current@FreeBSD.org References: <71444321@h30.sp.ipt.ru> Date: Fri, 25 Feb 2011 16:28:41 +0300 In-Reply-To: <71444321@h30.sp.ipt.ru> (Boris Samorodov's message of "Fri, 25 Feb 2011 15:36:46 +0300") Message-ID: <05361206@h30.sp.ipt.ru> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: dim@FreeBSD.org Subject: Re: [clang] regression: tmpfs is not mounted from fstab 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, 25 Feb 2011 13:28:43 -0000 On Fri, 25 Feb 2011 15:36:46 +0300 Boris Samorodov wrote: > I can't mount tmpfs from fstab if world/kernel are build by clang, Sorry, should have mentioned earlier, tmpfs module is loaded. The diagnostic message is: ----- mount: tmpfs: Operation not supported by device ----- -- WBR, bsam From owner-freebsd-current@FreeBSD.ORG Fri Feb 25 13:33:29 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 44622106566C for ; Fri, 25 Feb 2011 13:33:29 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 048B78FC0A for ; Fri, 25 Feb 2011 13:33:29 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:914f:fc6f:5e8c:fccc] (unknown [IPv6:2001:7b8:3a7:0:914f:fc6f:5e8c:fccc]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 109375C37; Fri, 25 Feb 2011 14:33:28 +0100 (CET) Message-ID: <4D67AFB2.2040104@FreeBSD.org> Date: Fri, 25 Feb 2011 14:33:38 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.15pre) Gecko/20110221 Lanikai/3.1.9pre MIME-Version: 1.0 To: Boris Samorodov References: <71444321@h30.sp.ipt.ru> In-Reply-To: <71444321@h30.sp.ipt.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: [clang] regression: tmpfs is not mounted from fstab 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, 25 Feb 2011 13:33:29 -0000 On 2011-02-25 13:36, Boris Samorodov wrote: > I can't mount tmpfs from fstab if world/kernel are build by clang, > however just making world with gcc works fine. The cause of this issue is a problem with the way clang's integrated assembler handles global symbols that are not referenced. This problem has been submitted upstream, and it is fixed meanwhile, so I will import a new clang snapshot soon. For now, please build kernels with "-no-integrated-as" added to COPTFLAGS, that should fix it. From owner-freebsd-current@FreeBSD.ORG Fri Feb 25 15:03:40 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 CD6ED1065672; Fri, 25 Feb 2011 15:03:40 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from adsum.doit.wisc.edu (adsum.doit.wisc.edu [144.92.197.210]) by mx1.freebsd.org (Postfix) with ESMTP id 9A4F48FC19; Fri, 25 Feb 2011 15:03:40 +0000 (UTC) MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_+Gto84ci2qSTVw4E+ff1fA)" Received: from avs-daemon.smtpauth1.wiscmail.wisc.edu by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0LH600C04HU3X600@smtpauth1.wiscmail.wisc.edu>; Fri, 25 Feb 2011 09:03:39 -0600 (CST) Received: from comporellon.tachypleus.net ([unknown] [76.210.68.25]) by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0LH6001Y6HU0FJ30@smtpauth1.wiscmail.wisc.edu>; Fri, 25 Feb 2011 09:03:38 -0600 (CST) Date: Fri, 25 Feb 2011 09:03:32 -0600 From: Nathan Whitehorn In-reply-to: <201102241707.58995.jhb@freebsd.org> To: John Baldwin Message-id: <4D67C4C4.5030909@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=76.210.68.25 X-Spam-PmxInfo: Server=avs-10, Version=5.6.0.2009776, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.2.25.145716, SenderIP=76.210.68.25 References: <4D64FF99.2070908@cabletv.dp.ua> <201102241514.19727.jhb@freebsd.org> <4D66C127.6060701@freebsd.org> <201102241707.58995.jhb@freebsd.org> User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20101214 Thunderbird/3.1.7 Cc: freebsd-current@freebsd.org, Mitya Subject: Re: Cosmetic path to bsdinstall 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, 25 Feb 2011 15:03:40 -0000 This is a multi-part message in MIME format. --Boundary_(ID_+Gto84ci2qSTVw4E+ff1fA) Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT On 02/24/11 16:07, John Baldwin wrote: > On Thursday, February 24, 2011 3:35:51 pm Nathan Whitehorn wrote: >> On 02/24/11 14:14, John Baldwin wrote: >>> On Thursday, February 24, 2011 10:00:44 am Nathan Whitehorn wrote: >>>> Thanks! I've received basically this patch from a couple people now. I'm >>>> going to investigate whether this is a more generic way to get this >>>> information (so the list doesn't grow infinitely long), and will commit >>>> this if I can't. Having CAM devices be part of newbus would simplify >>>> this a very great deal... >>> Note that all these disk devices are not CAM devices, so CAM changing to >>> use new-bus wouldn't really matter one whit. They do all show up as 'DISK' >>> GEOM's however (I also hacked on a GEOM-based libdisk replacement at one >>> point, though probably less developed than Marcel's. I used libgeom to >>> discover DISK devices.) Given that disk_create() already hooks into GEOM, >>> that is probably the right way to discover disks in a generic fashion. >> Right, stepping through that is how I build the list. Adding a device >> description to the XML actually seems like a good idea (and maybe the >> drive serial number?). Would anyone have any objections to me starting >> to go through and do that? > I think that would be fine, but I don't think GEOM knows about those > properties yet? It doesn't, but the attached patch changes that. I've added a new field to struct disk (d_descr) meant to hold a human-readable description of the disk, and changed several drivers (cd, ada, ad) to fill it with their model strings. I've also modified geom_disk's config XML to report the disk ident and description. If there aren't any objections, I'll commit this at the end of the day. -Nathan --Boundary_(ID_+Gto84ci2qSTVw4E+ff1fA) Content-type: text/plain; name=geom-ident-descr.diff Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=geom-ident-descr.diff Index: cam/scsi/scsi_cd.c =================================================================== --- cam/scsi/scsi_cd.c (revision 219031) +++ cam/scsi/scsi_cd.c (working copy) @@ -724,6 +724,12 @@ softc->disk->d_strategy = cdstrategy; softc->disk->d_ioctl = cdioctl; softc->disk->d_name = "cd"; + cam_strvis(softc->disk->d_descr, cgd->inq_data.vendor, + sizeof(cgd->inq_data.vendor), sizeof(softc->disk->d_descr)); + strlcat(softc->disk->d_descr, " ", sizeof(softc->disk->d_descr)); + cam_strvis(&softc->disk->d_descr[strlen(softc->disk->d_descr)], + cgd->inq_data.product, sizeof(cgd->inq_data.product), + sizeof(softc->disk->d_descr) - strlen(softc->disk->d_descr)); softc->disk->d_unit = periph->unit_number; softc->disk->d_drv1 = periph; if (cpi.maxio == 0) Index: cam/ata/ata_da.c =================================================================== --- cam/ata/ata_da.c (revision 219031) +++ cam/ata/ata_da.c (working copy) @@ -746,6 +746,8 @@ softc->disk->d_flags |= DISKFLAG_CANDELETE; strlcpy(softc->disk->d_ident, cgd->serial_num, MIN(sizeof(softc->disk->d_ident), cgd->serial_num_len + 1)); + strlcpy(softc->disk->d_descr, cgd->ident_data.model, + MIN(sizeof(softc->disk->d_descr), sizeof(cgd->ident_data.model))); softc->disk->d_hba_vendor = cpi.hba_vendor; softc->disk->d_hba_device = cpi.hba_device; softc->disk->d_hba_subvendor = cpi.hba_subvendor; Index: dev/ata/ata-disk.c =================================================================== --- dev/ata/ata-disk.c (revision 219031) +++ dev/ata/ata-disk.c (working copy) @@ -145,6 +145,8 @@ adp->disk->d_flags |= DISKFLAG_CANDELETE; strlcpy(adp->disk->d_ident, atadev->param.serial, sizeof(adp->disk->d_ident)); + strlcpy(adp->disk->d_descr, atadev->param.model, + sizeof(adp->disk->d_descr)); parent = device_get_parent(ch->dev); if (parent != NULL && device_get_parent(parent) != NULL && (device_get_devclass(parent) == Index: geom/geom_disk.c =================================================================== --- geom/geom_disk.c (revision 219031) +++ geom/geom_disk.c (working copy) @@ -371,6 +371,8 @@ indent, dp->d_fwheads); sbuf_printf(sb, "%s%u\n", indent, dp->d_fwsectors); + sbuf_printf(sb, "%s%s\n", indent, dp->d_ident); + sbuf_printf(sb, "%s%s\n", indent, dp->d_descr); } } Index: geom/geom_disk.h =================================================================== --- geom/geom_disk.h (revision 219031) +++ geom/geom_disk.h (working copy) @@ -85,6 +85,7 @@ u_int d_stripeoffset; u_int d_stripesize; char d_ident[DISK_IDENT_SIZE]; + char d_descr[DISK_IDENT_SIZE]; uint16_t d_hba_vendor; uint16_t d_hba_device; uint16_t d_hba_subvendor; --Boundary_(ID_+Gto84ci2qSTVw4E+ff1fA)-- From owner-freebsd-current@FreeBSD.ORG Fri Feb 25 15:58: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 5CF2E1065672; Fri, 25 Feb 2011 15:58:45 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from services.ipt.ru (services.ipt.ru [194.62.233.110]) by mx1.freebsd.org (Postfix) with ESMTP id 13E5E8FC0C; Fri, 25 Feb 2011 15:58:44 +0000 (UTC) Received: from gate.ipt.ru ([194.62.233.123] helo=h30.sp.ipt.ru) by services.ipt.ru with esmtp (Exim 4.54 (FreeBSD)) id 1Pt043-0002KN-Kx; Fri, 25 Feb 2011 18:58:43 +0300 From: Boris Samorodov To: Dimitry Andric References: <71444321@h30.sp.ipt.ru> <4D67AFB2.2040104@FreeBSD.org> Date: Fri, 25 Feb 2011 18:58:43 +0300 In-Reply-To: <4D67AFB2.2040104@FreeBSD.org> (Dimitry Andric's message of "Fri, 25 Feb 2011 14:33:38 +0100") Message-ID: <25043276@h30.sp.ipt.ru> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-current@FreeBSD.org Subject: Re: [clang] regression: tmpfs is not mounted from fstab 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, 25 Feb 2011 15:58:45 -0000 On Fri, 25 Feb 2011 14:33:38 +0100 Dimitry Andric wrote: > On 2011-02-25 13:36, Boris Samorodov wrote: > > I can't mount tmpfs from fstab if world/kernel are build by clang, > > however just making world with gcc works fine. > The cause of this issue is a problem with the way clang's integrated > assembler handles global symbols that are not referenced. > This problem has been submitted upstream, and it is fixed meanwhile, so > I will import a new clang snapshot soon. > For now, please build kernels with "-no-integrated-as" added to > COPTFLAGS, that should fix it. FYI unfortunately this does not help. Full build log is here: ftp://ftp.bsam.ru/pub/tmp/bk.log.bz2 -- WBR, bsam From owner-freebsd-current@FreeBSD.ORG Fri Feb 25 22: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 7B1D7106564A; Fri, 25 Feb 2011 22:57:34 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (mail.in-addr.com [IPv6:2001:470:8:162::1]) by mx1.freebsd.org (Postfix) with ESMTP id 407E28FC08; Fri, 25 Feb 2011 22:57:34 +0000 (UTC) Received: from gjp by noop.in-addr.com with local (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Pt6bL-000D8E-EZ; Fri, 25 Feb 2011 17:57:31 -0500 Date: Fri, 25 Feb 2011 17:57:31 -0500 From: Gary Palmer To: Garrett Cooper Message-ID: <20110225225731.GA90641@in-addr.com> References: <4D64FF99.2070908@cabletv.dp.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on noop.in-addr.com); SAEximRunCond expanded to false Cc: freebsd-current@freebsd.org, Mitya Subject: Re: Cosmetic path to bsdinstall 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, 25 Feb 2011 22:57:34 -0000 On Thu, Feb 24, 2011 at 12:17:46PM -0800, Garrett Cooper wrote: > On Wed, Feb 23, 2011 at 4:37 AM, Mitya wrote: > > Add usually used RAID controller > > > > --- usr.sbin/bsdinstall/partedit/part_wizard.c.orig ? ?2011-02-19 > > 17:22:06.000000000 +0200 > > +++ usr.sbin/bsdinstall/partedit/part_wizard.c ? ?2011-02-21 > > 17:20:28.000000000 +0200 > > @@ -122,6 +122,18 @@ > > ? ? ? ? ? ? ? ? ? ? strcat(diskdesc, " ATA Hard Disk"); > > ? ? ? ? ? ? ? ? else if (strncmp(pp->lg_name, "da", 2) == 0) > > ? ? ? ? ? ? ? ? ? ? strcat(diskdesc, " SCSI Hard Disk"); > > + ? ? ? ? ? ? ? ?else if (strncmp(pp->lg_name, "aacd", 4) == 0) > > + ? ? ? ? ? ? ? ? ? ?strcat(diskdesc, " Adaptec Raid Disk"); > > + ? ? ? ? ? ? ? ?else if (strncmp(pp->lg_name, "amrd", 4) == 0) > > + ? ? ? ? ? ? ? ? ? ?strcat(diskdesc, " LSI Raid Disk"); > > + ? ? ? ? ? ? ? ?else if (strncmp(pp->lg_name, "mfid", 4) == 0) > > + ? ? ? ? ? ? ? ? ? ?strcat(diskdesc, " LSI Raid Disk"); > > + ? ? ? ? ? ? ? ?else if (strncmp(pp->lg_name, "mlxd", 4) == 0) > > + ? ? ? ? ? ? ? ? ? ?strcat(diskdesc, " Mylex Raid Disk"); > > + ? ? ? ? ? ? ? ?else if (strncmp(pp->lg_name, "twed", 4) == 0) > > + ? ? ? ? ? ? ? ? ? ?strcat(diskdesc, " 3ware Raid Disk"); > > + ? ? ? ? ? ? ? ?else if (strncmp(pp->lg_name, "pst", 3) == 0) > > + ? ? ? ? ? ? ? ? ? ?strcat(diskdesc, " Promise Raid Disk"); > > ? ? ? ? ? ? ? ? else if (strncmp(pp->lg_name, "md", 2) == 0) > > ? ? ? ? ? ? ? ? ? ? strcat(diskdesc, " Memory Disk"); > > ? ? ? ? ? ? ? ? else if (strncmp(pp->lg_name, "cd", 2) == 0) { > > You forgot "twad" :). AFAIK the 3ware devices that attach with the twa driver register the volumes through CAM and appear as da, not twad. Hence why the driver is in the "RAID controllers interfaced to the SCSI subsystem" section of GENERIC Regards, Gary From owner-freebsd-current@FreeBSD.ORG Fri Feb 25 23:24: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 667211065670; Fri, 25 Feb 2011 23:24:06 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout022.mac.com (asmtpout022.mac.com [17.148.16.97]) by mx1.freebsd.org (Postfix) with ESMTP id 4C4398FC0A; Fri, 25 Feb 2011 23:24:06 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from sa-nc-common3-156.static.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp022.mac.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LH70053Z503RV50@asmtp022.mac.com>; Fri, 25 Feb 2011 15:24:05 -0800 (PST) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2011-02-25_08:2011-02-25, 2011-02-25, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1102250151 From: Marcel Moolenaar In-reply-to: <20110225093345.GA2123@mech-cluster241.men.bris.ac.uk> Date: Fri, 25 Feb 2011 15:24:03 -0800 Message-id: <6809984C-1CEA-4BB6-AC6E-EFC65FCBBBBE@mac.com> References: <20110225093345.GA2123@mech-cluster241.men.bris.ac.uk> To: Anton Shterenlikht X-Mailer: Apple Mail (2.1082) Cc: freebsd-current@freebsd.org, freebsd-ia64@freebsd.org Subject: Re: ieee denormal on ia64? 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, 25 Feb 2011 23:24:06 -0000 On Feb 25, 2011, at 1:33 AM, Anton Shterenlikht wrote: > Can somebody please confirm that denormal > are not available on ia64, see below. Itanium has denormals. However FP_X_DNML has not been defined, because it's non-standard: ns1% svn log -c121332 lib/libc/ia64/gen/fpsetmask.c ------------------------------------------------------------------------ r121332 | marcel | 2003-10-22 02:00:07 -0700 (Wed, 22 Oct 2003) | 11 lines The FP status register allows for 6 traps to be masked. One of them, the denormal/unnormal trap, is not a standard IEEE trap. We did not exclude it from being returned by fpgetmask(), nor did we make sure that fpsetmask() didn't clobber it. Since the non-IEEE trap is not part of fp_except_t, users of ifpgetmask()/fpsetmask() would be confronted with unexpected behaviour, one of which is a SIGFPE for denormal/unnormal FP results. This commit makes sure that we don't leak the denormal/unnormal mask bit in fp_except_t and also that we don't clobber it. ------------------------------------------------------------------------ -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Sat Feb 26 00:10: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 C52551065670; Sat, 26 Feb 2011 00:10:37 +0000 (UTC) (envelope-from pyunyh@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 65C918FC0C; Sat, 26 Feb 2011 00:10:37 +0000 (UTC) Received: by iyj12 with SMTP id 12so1530685iyj.13 for ; Fri, 25 Feb 2011 16:10:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:date:to:cc:subject:message-id:reply-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=ERsXC5plJ00+qEb3HnWGOa8y1adLwxit6b9P6R/lY/8=; b=iXyFklv7rewL6kes1/D8z9WB59qHSaydKRznz/MQo9kJAZv2jLvEUmgshaFUvzGqAP i1m8VE3im+1Qdpw9CIwTK68kgYrFX8dqGeTuVqpS8gJwc6/00aXQUMxTXCAqiWp2/pOC D1s+YwUmFaOyopYY1X2y3mY4GZjXzi5RW7VCA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=K3qM3RaXjcU12ljquPeSqeVtoE0dBIciZKBHftXNToc68xSnfY5qZzPm7F0qJ1uV0s z3kcjuvJ7/dchQ59ZRzH8G927EJpIR236m27bp7wMSEd/cpEi3gMFcpCJPLuM+74KVXd SogJ0XJDRk77iP1rdWa+Yz+9R/R7L6/GDfN0Y= Received: by 10.42.164.201 with SMTP id h9mr1497510icy.108.1298677728478; Fri, 25 Feb 2011 15:48:48 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id xa8sm830005icb.22.2011.02.25.15.48.42 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 25 Feb 2011 15:48:44 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 25 Feb 2011 15:48:44 -0800 From: YongHyeon PYUN Date: Fri, 25 Feb 2011 15:48:44 -0800 To: Gary Jennejohn Message-ID: <20110225234844.GA1485@michelle.cdnetworks.com> References: <4D268557.2090704@ee.lbl.gov> <4D268B98.3080906@ee.lbl.gov> <4D269B72.4040709@ee.lbl.gov> <20110107115306.2bfd15d8@ernst.jennejohn.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110107115306.2bfd15d8@ernst.jennejohn.org> User-Agent: Mutt/1.4.2.3i Cc: FreeBSD Current , Ed Schouten , Craig Leres , Garrett Cooper Subject: Re: xterm -C and TIOCCONS vs. PRIV_TTY_CONSOLE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2011 00:10:38 -0000 On Fri, Jan 07, 2011 at 11:53:06AM +0100, Gary Jennejohn wrote: > On Thu, 6 Jan 2011 21:09:05 -0800 > Garrett Cooper wrote: > > > On Thu, Jan 6, 2011 at 8:49 PM, Craig Leres wrote: > > > On 01/06/11 20:05, Garrett Cooper wrote: > > >> Just to make sure we're both on the same page: > > >> > > >> $ grep xterm /etc/ttys > > >> ttyv0 "/usr/libexec/getty Pc" ? ? ? ? xterm ? on ?secure > > >> ttyv1 "/usr/libexec/getty Pc" ? ? ? ? xterm ? on ?secure > > >> ttyv2 "/usr/libexec/getty Pc" ? ? ? ? xterm ? on ?secure > > >> ttyv3 "/usr/libexec/getty Pc" ? ? ? ? xterm ? on ?secure > > >> ttyv4 "/usr/libexec/getty Pc" ? ? ? ? xterm ? on ?secure > > >> ttyv5 "/usr/libexec/getty Pc" ? ? ? ? xterm ? on ?secure > > >> ttyv6 "/usr/libexec/getty Pc" ? ? ? ? xterm ? on ?secure > > >> ttyv7 "/usr/libexec/getty Pc" ? ? ? ? xterm ? on ?secure > > >> ttyv8 "/usr/local/bin/xdm -nodaemon" ?xterm ? off secure > > > > > > No, that's not what mine looks like. I changed it to match and rebooted > > > but it doesn't help with the TIOCCONS issue. > > > > > > When I run xinit, it starts up the xterm -C which does a TIOCCONS. The > > > 8.1 kernel checks for PRIV_TTY_CONSOLE which isn't set and denies the > > > request: > > > > > > ? ? ? ?case TIOCCONS: > > > ? ? ? ? ? ? ? ?/* Set terminal as console TTY. */ > > > ? ? ? ? ? ? ? ?if (*(int *)data) { > > > ? ? ? ? ? ? ? ? ? ? ? ?error = priv_check(td, PRIV_TTY_CONSOLE); > > > ? ? ? ? ? ? ? ? ? ? ? ?if (error) > > > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?return (error); > > > > > > ? ? ? ? ? ? ? ? ? ? ? ?/* > > > ? ? ? ? ? ? ? ? ? ? ? ? * XXX: constty should really need to be locked! > > > ? ? ? ? ? ? ? ? ? ? ? ? * XXX: allow disconnected constty's to be stolen! > > > ? ? ? ? ? ? ? ? ? ? ? ? */ > > > > > > ? ? ? ? ? ? ? ? ? ? ? ?if (constty == tp) > > > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?return (0); > > > ? ? ? ? ? ? ? ? ? ? ? ?if (constty != NULL) > > > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?return (EBUSY); > > > > > > ? ? ? ? ? ? ? ? ? ? ? ?tty_unlock(tp); > > > ? ? ? ? ? ? ? ? ? ? ? ?constty_set(tp); > > > ? ? ? ? ? ? ? ? ? ? ? ?tty_lock(tp); > > > ? ? ? ? ? ? ? ?} else if (constty == tp) { > > > ? ? ? ? ? ? ? ? ? ? ? ?constty_clear(); > > > ? ? ? ? ? ? ? ?} > > > ? ? ? ? ? ? ? ?return (0); > > > > > > > > > There's nothing I see in all of /usr/src that turns on PRIV_TTY_CONSOLE > > > in any case. You could rewrite the above like this: > > > > > > ? ? ? ?case TIOCCONS: > > > ? ? ? ? ? ? ? ?/* Set terminal as console TTY. */ > > > ? ? ? ? ? ? ? ?if (*(int *)data) { > > > ? ? ? ? ? ? ? ? ? ? ? ?return (EPERM) > > > ? ? ? ? ? ? ? ?} else if (constty == tp) { > > > ? ? ? ? ? ? ? ? ? ? ? ?constty_clear(); > > > ? ? ? ? ? ? ? ?} > > > ? ? ? ? ? ? ? ?return (0); > > > > > > and it won't change any behavior. > > > > Ok -- figured I would ask about the obvious. I wish I could help > > you further right now, but unfortunately I have a lot on my plate. > > I've CCed ed@ and the list again so that someone else might be able to > > chime in and help you further. > > > > I'd say there are a few factors which come into play here: > 1) the setting of security.bsd.suser_enabled, default 1 > 2) kern_tty.c checking for a cred which is never set > 3) whether xterm is setuid root > > a) suser_enabled is almost guaranteed to be 1 on OP's system since just > about nothing works when it is set to 0 (tried that) > b) the kernel checking for the cred PRIV_TTY_CONSOLE is probably a bug > since it never gets set anywhere. However, this usually isn't noticed > because > c) xterm is generally setuid root and the logic in priv_check_cred() in > kern_priv.c doesn't even look at what cred is set to, except for a few > which can raise some limits, because cr_uid is 0 (super user) > > So, the crux of the matter is whether OP's xterm is setuid root. My > xterm is and I can run 'xterm -C' without a problem. > It seems I'm seeing this one on 8.2R. Of course, xterm is setuid root. I hacked tty.c to return success for TIOCCONS so was able to see kernel messages but messages passed through syslog still does not work. :-( From owner-freebsd-current@FreeBSD.ORG Sat Feb 26 15:59:42 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 6435F1065670 for ; Sat, 26 Feb 2011 15:59:42 +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 F17AA8FC08 for ; Sat, 26 Feb 2011 15:59:41 +0000 (UTC) Received: by bwz12 with SMTP id 12so3065691bwz.13 for ; Sat, 26 Feb 2011 07:59:40 -0800 (PST) Received: by 10.204.0.65 with SMTP id 1mr3139157bka.111.1298734181594; Sat, 26 Feb 2011 07:29:41 -0800 (PST) Received: from julie.lab.techwires.net (dslb-094-217-128-237.pools.arcor-ip.net [94.217.128.237]) by mx.google.com with ESMTPS id j11sm1183485bka.0.2011.02.26.07.29.39 (version=SSLv3 cipher=OTHER); Sat, 26 Feb 2011 07:29:40 -0800 (PST) Sender: Bernhard Schmidt From: Bernhard Schmidt To: freebsd-current@freebsd.org Date: Sat, 26 Feb 2011 16:25:41 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-RELEASE; KDE/4.5.5; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201102261625.41522.bschmidt@freebsd.org> Subject: cardbus and kldunload issue 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, 26 Feb 2011 15:59:42 -0000 Hi, while working on a wireless driver for a Cardbus card I stumbled over an issue which bugs me quite a bit. The device: % none3@pci0:22:0:0: class=0x028000 card=0x107f1043 chip=0x02011814 rev=0x01 hdr=0x00 Loading the module attaches nicely to the device: # kldload if_ral % ral0: mem 0xf4800000-0xf4801fff irq 16 at device 0.0 on cardbus0 % ral0: MAC/BBP RT2560 (rev 0x04), RF RT2525 % ral0: [ITHREAD] # pciconf -l % ral0@pci0:22:0:0: class=0x028000 card=0x107f1043 chip=0x02011814 rev=0x01 hdr=0x00 Though, kldunload doesn't detach the device, it doesn't even call the module's detach function. # kldunload if_ral # pciconf -l % ral0@pci0:22:0:0: class=0x028000 card=0x107f1043 chip=0x02011814 rev=0x01 hdr=0x00 # kldstat % Id Refs Address Size Name % 1 27 0xffffffff80100000 e640a0 kernel # ifconfig ral0 % ral0: flags=8802 metric 0 mtu 2290 % ether 00:0e:a6:a6:1b:70 % media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) % status: no carrier And of course trying to use the device at that point will result in instant panics. Playing around a bit I've noticed that changing the bus name in: % DRIVER_MODULE(ral, pci, ral_pci_driver, ral_devclass, 0, 0); from pci to cardbus makes a big difference. On module unload the detach function is then called as expected. So, question is, are we doing some too strict checks on module unload while matching the bus? Or is this expected behavior and the drivers are supposed to indiciated that they support both pci and cardbus? I don't see the later anywhere in tree. -- Bernhard From owner-freebsd-current@FreeBSD.ORG Sat Feb 26 18: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 602CD106566B for ; Sat, 26 Feb 2011 18:11:52 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id 7F35D8FC08 for ; Sat, 26 Feb 2011 18:11:51 +0000 (UTC) Received: from [88.217.16.195] (helo=localhost.my.domain) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1PtNTG-0003EM-MR for freebsd-current@freebsd.org; Sat, 26 Feb 2011 17:58:19 +0100 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.my.domain (8.14.4/8.14.3) with ESMTP id p1QGwGCR004984 for ; Sat, 26 Feb 2011 17:58:17 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.14.4/8.14.3/Submit) id p1QGwG5u004983 for freebsd-current@freebsd.org; Sat, 26 Feb 2011 17:58:16 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Sat, 26 Feb 2011 17:58:15 +0100 From: Matthias Apitz To: freebsd-current@freebsd.org Message-ID: <20110226165815.GA4953@tinyCurrent> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="ikeVEW9yuYc//A+q" Content-Disposition: inline X-Operating-System: FreeBSD 8.0-CURRENT (i386) User-Agent: Mutt/1.5.21 (2010-09-15) X-Con-Id: 51246 X-Originating-IP: 88.217.16.195 Subject: snd_hda(4): speaker DISABLED after update to 9-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2011 18:11:52 -0000 --ikeVEW9yuYc//A+q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello, I've installed 9-CURRENT on a laptop which worked fine before with 7.0-REL, concerning the sound via snd_hda(4). Now there is only sound coming out from the headphone jack and I don't see how to enable the speaker again. Btw: Why is this now so different on the same hardware with the same driver? $ cat /dev/sndstat FreeBSD Audio Driver (newpcm: 32bit 2009061500/i386) Installed devices: pcm0: (play/rec) default pcm1: (rec) pcm2: (rec) I'm attaching as well the grep'ed dmesg output for 'hdac' and 'pcm'. Could someone please give me a hint how to get the speaker working again? Thanks in advance matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ --ikeVEW9yuYc//A+q Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="pcm.txt" hdac0: OSS: pcm (pcm) hdac0: OSS: pcm (pcm) hdac0: OSS: pcm (pcm) hdac0: OSS: pcm (pcm) hdac0: OSS: pcm (pcm) hdac0: OSS: pcm, speaker, line, mic, monitor hdac0: OSS: pcm, speaker, line, mic, monitor hdac0: OSS: pcm, speaker, line, mic, monitor hdac0: OSS: pcm, speaker, line, mic, monitor pcm0: at cad 1 nid 1 on hdac0 pcm0: +--------------------------------------+ pcm0: | DUMPING PCM Playback/Record Channels | pcm0: +--------------------------------------+ pcm0: pcm0: Playback: pcm0: pcm0: Stream cap: 0x00000001 pcm0: PCM pcm0: PCM cap: 0x000e0160 pcm0: 16 20 24 bits, 44 48 96 KHz pcm0: DAC: 2 4 3 5 6 pcm0: pcm0: Record: pcm0: pcm0: Stream cap: 0x00000005 pcm0: AC3 PCM pcm0: PCM cap: 0x001e0160 pcm0: 16 20 24 32 bits, 44 48 96 KHz pcm0: ADC: 10 pcm0: pcm0: +-------------------------------+ pcm0: | DUMPING Playback/Record Paths | pcm0: +-------------------------------+ pcm0: pcm0: Playback: pcm0: pcm0: nid=20 [pin: Line-out (Green Jack)] pcm0: | pcm0: + <- nid=12 [audio mixer] [src: pcm, speaker, line, mic, monitor] pcm0: | pcm0: + <- nid=2 [audio output] [src: pcm] pcm0: + <- nid=11 [audio mixer] [src: speaker, line, mic, monitor] pcm0: | pcm0: + <- nid=24 [pin: Mic (Pink Jack)] [src: mic] pcm0: + <- nid=25 [pin: Mic (Pink Jack)] [src: monitor] pcm0: + <- nid=26 [pin: Line-in (Blue Jack)] [src: line] pcm0: + <- nid=29 [beep widget] [src: speaker] pcm0: pcm0: nid=22 [pin: Line-out (Orange Jack)] pcm0: | pcm0: + <- nid=14 [audio mixer] [src: pcm, speaker, line, mic, monitor] pcm0: | pcm0: + <- nid=4 [audio output] [src: pcm] pcm0: + <- nid=11 [audio mixer] [src: speaker, line, mic, monitor] pcm0: | pcm0: + <- nid=24 [pin: Mic (Pink Jack)] [src: mic] pcm0: + <- nid=25 [pin: Mic (Pink Jack)] [src: monitor] pcm0: + <- nid=26 [pin: Line-in (Blue Jack)] [src: line] pcm0: + <- nid=29 [beep widget] [src: speaker] pcm0: pcm0: nid=21 [pin: Line-out (Black Jack)] pcm0: | pcm0: + <- nid=13 [audio mixer] [src: pcm, speaker, line, mic, monitor] pcm0: | pcm0: + <- nid=3 [audio output] [src: pcm] pcm0: + <- nid=11 [audio mixer] [src: speaker, line, mic, monitor] pcm0: | pcm0: + <- nid=24 [pin: Mic (Pink Jack)] [src: mic] pcm0: + <- nid=25 [pin: Mic (Pink Jack)] [src: monitor] pcm0: + <- nid=26 [pin: Line-in (Blue Jack)] [src: line] pcm0: + <- nid=29 [beep widget] [src: speaker] pcm0: pcm0: nid=23 [pin: Line-out (Grey Jack)] pcm0: | pcm0: + <- nid=15 [audio mixer] [src: pcm, speaker, line, mic, monitor] pcm0: | pcm0: + <- nid=5 [audio output] [src: pcm] pcm0: + <- nid=11 [audio mixer] [src: speaker, line, mic, monitor] pcm0: | pcm0: + <- nid=24 [pin: Mic (Pink Jack)] [src: mic] pcm0: + <- nid=25 [pin: Mic (Pink Jack)] [src: monitor] pcm0: + <- nid=26 [pin: Line-in (Blue Jack)] [src: line] pcm0: + <- nid=29 [beep widget] [src: speaker] pcm0: pcm0: nid=30 [pin: SPDIF-out (Black Jack)] pcm0: | pcm0: + <- nid=6 [audio output] [src: pcm] pcm0: pcm0: Record: pcm0: pcm0: nid=10 [audio input] pcm0: | pcm0: + <- nid=31 [pin: SPDIF-in (Orange Jack)] [src: dig1] pcm0: pcm0: +-------------------------+ pcm0: | DUMPING Volume Controls | pcm0: +-------------------------+ pcm0: pcm0: Master Volume (OSS: vol) pcm0: | pcm0: +- ctl 12 (nid 12 out): -64/0dB (65 steps) pcm0: +- ctl 13 (nid 12 in 0): mute pcm0: +- ctl 14 (nid 12 in 1): mute pcm0: +- ctl 15 (nid 13 out): -64/0dB (65 steps) pcm0: +- ctl 16 (nid 13 in 0): mute pcm0: +- ctl 17 (nid 13 in 1): mute pcm0: +- ctl 18 (nid 14 out): -64/0dB (65 steps) pcm0: +- ctl 19 (nid 14 in 0): mute pcm0: +- ctl 20 (nid 14 in 1): mute pcm0: +- ctl 21 (nid 15 out): -64/0dB (65 steps) pcm0: +- ctl 22 (nid 15 in 0): mute pcm0: +- ctl 23 (nid 15 in 1): mute pcm0: +- ctl 24 (nid 20 in ): mute pcm0: +- ctl 25 (nid 21 in ): mute pcm0: +- ctl 26 (nid 22 in ): mute pcm0: +- ctl 27 (nid 23 in ): mute pcm0: pcm0: PCM Volume (OSS: pcm) pcm0: | pcm0: +- ctl 13 (nid 12 in 0): mute pcm0: +- ctl 16 (nid 13 in 0): mute pcm0: +- ctl 19 (nid 14 in 0): mute pcm0: +- ctl 22 (nid 15 in 0): mute pcm0: pcm0: Microphone Volume (OSS: mic) pcm0: | pcm0: +- ctl 4 (nid 11 in 0): -35/30dB (66 steps) + mute pcm0: pcm0: Microphone2 Volume (OSS: monitor) pcm0: | pcm0: +- ctl 5 (nid 11 in 1): -35/30dB (66 steps) + mute pcm0: pcm0: Line-in Volume (OSS: line) pcm0: | pcm0: +- ctl 6 (nid 11 in 2): -35/30dB (66 steps) + mute pcm0: pcm0: Speaker/Beep Volume (OSS: speaker) pcm0: | pcm0: +- ctl 9 (nid 11 in 5): -35/30dB (66 steps) + mute pcm0: pcm0: Input Monitoring Level (OSS: igain) pcm0: | pcm0: +- ctl 14 (nid 12 in 1): mute pcm0: +- ctl 17 (nid 13 in 1): mute pcm0: +- ctl 20 (nid 14 in 1): mute pcm0: +- ctl 23 (nid 15 in 1): mute pcm0: pcm0: Enabling Soft PCM volume pcm0: Mixer "vol": pcm0: Mixer "pcm": pcm0: Mixer "speaker": pcm0: Mixer "line": pcm0: Mixer "mic": pcm0: Mixer "igain": pcm0: Mixer "monitor": pcm0: Soft PCM mixer ENABLED pcm0: clone manager: deadline=750ms flags=0x8000001e pcm0: sndbuf_setmap 3ec60000, 4000; 0xe46f6000 -> 3ec60000 pcm0: sndbuf_setmap 3ec70000, 4000; 0xe4706000 -> 3ec70000 pcm1: at cad 1 nid 1 on hdac0 pcm1: +--------------------------------------+ pcm1: | DUMPING PCM Playback/Record Channels | pcm1: +--------------------------------------+ pcm1: pcm1: Record: pcm1: pcm1: Stream cap: 0x00000001 pcm1: PCM pcm1: PCM cap: 0x00060160 pcm1: 16 20 bits, 44 48 96 KHz pcm1: ADC: 7 pcm1: pcm1: +-------------------------------+ pcm1: | DUMPING Playback/Record Paths | pcm1: +-------------------------------+ pcm1: pcm1: Record: pcm1: pcm1: nid=7 [audio input] pcm1: | pcm1: + <- nid=24 [pin: Mic (Pink Jack)] [src: mic] pcm1: + <- nid=26 [pin: Line-in (Blue Jack)] [src: line] pcm1: pcm1: +-------------------------+ pcm1: | DUMPING Volume Controls | pcm1: +-------------------------+ pcm1: pcm1: Microphone Volume (OSS: mic) pcm1: | pcm1: +- ctl 1 (nid 7 in 0): 0/35dB (36 steps) + mute pcm1: pcm1: Recording Level (OSS: rec) pcm1: | pcm1: +- ctl 1 (nid 7 in 0): 0/35dB (36 steps) + mute pcm1: pcm1: Mixer "mic": pcm1: Mixer "rec": pcm1: clone manager: deadline=750ms flags=0x8000001e pcm1: sndbuf_setmap 3ec80000, 4000; 0xe4716000 -> 3ec80000 pcm2: at cad 1 nid 1 on hdac0 pcm2: +--------------------------------------+ pcm2: | DUMPING PCM Playback/Record Channels | pcm2: +--------------------------------------+ pcm2: pcm2: Record: pcm2: pcm2: Stream cap: 0x00000001 pcm2: PCM pcm2: PCM cap: 0x00060160 pcm2: 16 20 bits, 44 48 96 KHz pcm2: ADC: 8 pcm2: pcm2: +-------------------------------+ pcm2: | DUMPING Playback/Record Paths | pcm2: +-------------------------------+ pcm2: pcm2: Record: pcm2: pcm2: nid=8 [audio input] pcm2: | pcm2: + <- nid=25 [pin: Mic (Pink Jack)] [src: monitor] pcm2: pcm2: +-------------------------+ pcm2: | DUMPING Volume Controls | pcm2: +-------------------------+ pcm2: pcm2: clone manager: deadline=750ms flags=0x8000001e pcm2: sndbuf_setmap 3ec90000, 4000; 0xe4726000 -> 3ec90000 --ikeVEW9yuYc//A+q Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="hdac.txt" hdac0: mem 0xffef8000-0xffefbfff irq 16 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: attempting to allocate 1 MSI vectors (1 supported) hdac0: using IRQ 256 for MSI hdac0: Caps: OSS 4, ISS 4, BSS 0, NSDO 1, 64bit, CORB 256, RIRB 256 hdac0: Probing codec #0... hdac0: HDA Codec #0: Unknown Codec hdac0: HDA Codec ID: 0x10573055 hdac0: Vendor: 0x1057 hdac0: Device: 0x3055 hdac0: Revision: 0x07 hdac0: Stepping: 0x00 hdac0: PCI Subvendor: 0x107c1734 hdac0: Found modem FG nid=1 startnode=2 endnode=38 total=36 hdac0: Probing codec #1... hdac0: HDA Codec #1: Realtek ALC880 hdac0: HDA Codec ID: 0x10ec0880 hdac0: Vendor: 0x10ec hdac0: Device: 0x0880 hdac0: Revision: 0x08 hdac0: Stepping: 0x00 hdac0: PCI Subvendor: 0x107c1734 hdac0: Found audio FG nid=1 startnode=2 endnode=34 total=32 hdac0: hdac0: Processing modem FG cad=0 nid=1... hdac0: hdac0: Processing audio FG cad=1 nid=1... hdac0: GPIO: 0x40000002 NumGPIO=2 NumGPO=0 NumGPI=0 GPIWake=0 GPIUnsol=1 hdac0: nid 20 0x01014010 as 1 seq 0 Line-out Jack jack 1 loc 1 color Green misc 0 hdac0: nid 21 0x01011012 as 1 seq 2 Line-out Jack jack 1 loc 1 color Black misc 0 hdac0: nid 22 0x01016011 as 1 seq 1 Line-out Jack jack 1 loc 1 color Orange misc 0 hdac0: nid 23 0x01012014 as 1 seq 4 Line-out Jack jack 1 loc 1 color Grey misc 0 hdac0: nid 24 0x01a19830 as 3 seq 0 Mic Jack jack 1 loc 1 color Pink misc 8 hdac0: nid 25 0x02a19c40 as 4 seq 0 Mic Jack jack 1 loc 2 color Pink misc 12 hdac0: nid 26 0x01813031 as 3 seq 1 Line-in Jack jack 1 loc 1 color Blue misc 0 hdac0: nid 27 0x02014c20 as 2 seq 0 Line-out Jack jack 1 loc 2 color Green misc 12 hdac0: nid 28 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 hdac0: Patching widget caps nid=29 0x00400000 -> 0x00700000 hdac0: nid 30 0x0144111e as 1 seq 14 SPDIF-out Jack jack 4 loc 1 color Black misc 1 hdac0: nid 31 0x01c46150 as 5 seq 0 SPDIF-in Jack jack 4 loc 1 color Orange misc 1 hdac0: Patched pins configuration: hdac0: nid 20 0x01014010 as 1 seq 0 Line-out Jack jack 1 loc 1 color Green misc 0 hdac0: nid 21 0x01011012 as 1 seq 2 Line-out Jack jack 1 loc 1 color Black misc 0 hdac0: nid 22 0x01016011 as 1 seq 1 Line-out Jack jack 1 loc 1 color Orange misc 0 hdac0: nid 23 0x01012014 as 1 seq 4 Line-out Jack jack 1 loc 1 color Grey misc 0 hdac0: nid 24 0x01a19830 as 3 seq 0 Mic Jack jack 1 loc 1 color Pink misc 8 hdac0: nid 25 0x02a19c40 as 4 seq 0 Mic Jack jack 1 loc 2 color Pink misc 12 hdac0: nid 26 0x01813031 as 3 seq 1 Line-in Jack jack 1 loc 1 color Blue misc 0 hdac0: nid 27 0x02014c20 as 2 seq 0 Line-out Jack jack 1 loc 2 color Green misc 12 hdac0: nid 28 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 [DISABLED] hdac0: nid 30 0x0144111e as 1 seq 14 SPDIF-out Jack jack 4 loc 1 color Black misc 1 hdac0: nid 31 0x01c46150 as 5 seq 0 SPDIF-in Jack jack 4 loc 1 color Orange misc 1 hdac0: 5 associations found: hdac0: Association 0 (1) out: hdac0: Pin nid=20 seq=0 hdac0: Pin nid=22 seq=1 hdac0: Pin nid=21 seq=2 hdac0: Pin nid=23 seq=4 hdac0: Pin nid=30 seq=14 hdac0: Association 1 (2) out: hdac0: Pin nid=27 seq=0 hdac0: Association 2 (3) in: hdac0: Pin nid=24 seq=0 hdac0: Pin nid=26 seq=1 hdac0: Association 3 (4) in: hdac0: Pin nid=25 seq=0 hdac0: Association 4 (5) in: hdac0: Pin nid=31 seq=0 hdac0: Tracing association 0 (1) hdac0: Pin 20 traced to DAC 2 hdac0: Pin 22 traced to DAC 4 hdac0: Pin 21 traced to DAC 3 hdac0: Pin 23 traced to DAC 5 hdac0: Pin 30 traced to DAC 6 hdac0: Association 0 (1) trace succeeded hdac0: Tracing association 1 (2) hdac0: Unable to trace pin 27 seq 0 with min nid 0 hdac0: Association 1 (2) trace failed hdac0: Tracing association 2 (3) hdac0: Pin 24 traced to ADC 7 hdac0: Pin 26 traced to ADC 7 hdac0: Association 2 (3) trace succeeded hdac0: Tracing association 3 (4) hdac0: Pin 25 traced to ADC 8 hdac0: Association 3 (4) trace succeeded hdac0: Tracing association 4 (5) hdac0: Unable to trace pin 31 to ADC 9, undo traces hdac0: Pin 31 traced to ADC 10 hdac0: Association 4 (5) trace succeeded hdac0: Tracing input monitor hdac0: Tracing other input monitors hdac0: Tracing nid 24 to out hdac0: nid 24 is input monitor hdac0: Tracing nid 25 to out hdac0: nid 25 is input monitor hdac0: Tracing nid 26 to out hdac0: nid 26 is input monitor hdac0: Tracing nid 31 to out hdac0: Tracing beeper hdac0: nid 29 traced to out hdac0: FG config/quirks: forcestereo ivref50 ivref80 ivref100 ivref hdac0: hdac0: +-------------------+ hdac0: | DUMPING HDA NODES | hdac0: +-------------------+ hdac0: hdac0: Default Parameter hdac0: ----------------- hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0560 hdac0: 16 20 24 bits, 44 48 96 192 KHz hdac0: IN amp: 0x00000000 hdac0: OUT amp: 0x00000000 hdac0: hdac0: nid: 2 hdac0: Name: audio output hdac0: Widget cap: 0x00000411 hdac0: PWR STEREO hdac0: Association: 0 (0x00000001) hdac0: OSS: pcm (pcm) hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0560 hdac0: 16 20 24 bits, 44 48 96 192 KHz hdac0: hdac0: nid: 3 hdac0: Name: audio output hdac0: Widget cap: 0x00000411 hdac0: PWR STEREO hdac0: Association: 0 (0x00000004) hdac0: OSS: pcm (pcm) hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0560 hdac0: 16 20 24 bits, 44 48 96 192 KHz hdac0: hdac0: nid: 4 hdac0: Name: audio output hdac0: Widget cap: 0x00000411 hdac0: PWR STEREO hdac0: Association: 0 (0x00000002) hdac0: OSS: pcm (pcm) hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0160 hdac0: 16 20 24 bits, 44 48 96 KHz hdac0: hdac0: nid: 5 hdac0: Name: audio output hdac0: Widget cap: 0x00000411 hdac0: PWR STEREO hdac0: Association: 0 (0x00000010) hdac0: OSS: pcm (pcm) hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0160 hdac0: 16 20 24 bits, 44 48 96 KHz hdac0: hdac0: nid: 6 hdac0: Name: audio output hdac0: Widget cap: 0x00000211 hdac0: DIGITAL STEREO hdac0: Association: 0 (0x00004000) hdac0: OSS: pcm (pcm) hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x001e0160 hdac0: 16 20 24 32 bits, 44 48 96 KHz hdac0: hdac0: nid: 7 hdac0: Name: audio input hdac0: Widget cap: 0x0010051b hdac0: PWR STEREO hdac0: Association: 2 (0x00000003) hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x00060160 hdac0: 16 20 bits, 44 48 96 KHz hdac0: Input amp: 0x80032300 hdac0: mute=1 step=35 size=3 offset=0 hdac0: connections: 7 hdac0: | hdac0: + <- nid=24 [pin: Mic (Pink Jack)] (selected) hdac0: + [DISABLED] <- nid=25 [pin: Mic (Pink Jack)] hdac0: + <- nid=26 [pin: Line-in (Blue Jack)] hdac0: + [DISABLED] <- nid=27 [pin: Line-out (Green Jack)] [DISABLED] hdac0: + [DISABLED] <- nid=28 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=20 [pin: Line-out (Green Jack)] hdac0: + [DISABLED] <- nid=21 [pin: Line-out (Black Jack)] hdac0: hdac0: nid: 8 hdac0: Name: audio input hdac0: Widget cap: 0x0010051b hdac0: PWR STEREO hdac0: Association: 3 (0x00000001) hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x00060160 hdac0: 16 20 bits, 44 48 96 KHz hdac0: Input amp: 0x80032300 hdac0: mute=1 step=35 size=3 offset=0 hdac0: connections: 7 hdac0: | hdac0: + [DISABLED] <- nid=24 [pin: Mic (Pink Jack)] hdac0: + <- nid=25 [pin: Mic (Pink Jack)] (selected) hdac0: + [DISABLED] <- nid=26 [pin: Line-in (Blue Jack)] hdac0: + [DISABLED] <- nid=27 [pin: Line-out (Green Jack)] [DISABLED] hdac0: + [DISABLED] <- nid=28 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=20 [pin: Line-out (Green Jack)] hdac0: + [DISABLED] <- nid=21 [pin: Line-out (Black Jack)] hdac0: hdac0: nid: 9 [DISABLED] hdac0: Name: audio input hdac0: Widget cap: 0x0010051b hdac0: PWR STEREO hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x00060160 hdac0: 16 20 bits, 44 48 96 KHz hdac0: Input amp: 0x80032300 hdac0: mute=1 step=35 size=3 offset=0 hdac0: connections: 10 hdac0: | hdac0: + [DISABLED] <- nid=24 [pin: Mic (Pink Jack)] (selected) hdac0: + <- nid=25 [pin: Mic (Pink Jack)] hdac0: + <- nid=26 [pin: Line-in (Blue Jack)] hdac0: + <- nid=27 [pin: Line-out (Green Jack)] [DISABLED] hdac0: + [DISABLED] <- nid=28 [pin: Speaker (None)] [DISABLED] hdac0: + <- nid=11 [audio mixer] hdac0: + <- nid=20 [pin: Line-out (Green Jack)] hdac0: + <- nid=21 [pin: Line-out (Black Jack)] hdac0: + <- nid=22 [pin: Line-out (Orange Jack)] hdac0: + <- nid=23 [pin: Line-out (Grey Jack)] hdac0: hdac0: nid: 10 hdac0: Name: audio input hdac0: Widget cap: 0x00100391 hdac0: DIGITAL UNSOL STEREO hdac0: Association: 4 (0x00000001) hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x001e0160 hdac0: 16 20 24 32 bits, 44 48 96 KHz hdac0: connections: 1 hdac0: | hdac0: + <- nid=31 [pin: SPDIF-in (Orange Jack)] hdac0: hdac0: nid: 11 hdac0: Name: audio mixer hdac0: Widget cap: 0x0020010b hdac0: STEREO hdac0: Association: -2 (0x00000000) hdac0: OSS: speaker, line, mic, monitor hdac0: Input amp: 0x80034123 hdac0: mute=1 step=65 size=3 offset=35 hdac0: connections: 8 hdac0: | hdac0: + <- nid=24 [pin: Mic (Pink Jack)] hdac0: + <- nid=25 [pin: Mic (Pink Jack)] hdac0: + <- nid=26 [pin: Line-in (Blue Jack)] hdac0: + [DISABLED] <- nid=27 [pin: Line-out (Green Jack)] [DISABLED] hdac0: + [DISABLED] <- nid=28 [pin: Speaker (None)] [DISABLED] hdac0: + <- nid=29 [beep widget] hdac0: + [DISABLED] <- nid=20 [pin: Line-out (Green Jack)] hdac0: + [DISABLED] <- nid=21 [pin: Line-out (Black Jack)] hdac0: hdac0: nid: 12 hdac0: Name: audio mixer hdac0: Widget cap: 0x0020010f hdac0: STEREO hdac0: Association: 0 (0x00000001) hdac0: OSS: pcm, speaker, line, mic, monitor hdac0: Output amp: 0x00034040 hdac0: mute=0 step=64 size=3 offset=64 hdac0: Input amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 2 hdac0: | hdac0: + <- nid=2 [audio output] hdac0: + <- nid=11 [audio mixer] hdac0: hdac0: nid: 13 hdac0: Name: audio mixer hdac0: Widget cap: 0x0020010f hdac0: STEREO hdac0: Association: 0 (0x00000004) hdac0: OSS: pcm, speaker, line, mic, monitor hdac0: Output amp: 0x00034040 hdac0: mute=0 step=64 size=3 offset=64 hdac0: Input amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 2 hdac0: | hdac0: + <- nid=3 [audio output] hdac0: + <- nid=11 [audio mixer] hdac0: hdac0: nid: 14 hdac0: Name: audio mixer hdac0: Widget cap: 0x0020010f hdac0: STEREO hdac0: Association: 0 (0x00000002) hdac0: OSS: pcm, speaker, line, mic, monitor hdac0: Output amp: 0x00034040 hdac0: mute=0 step=64 size=3 offset=64 hdac0: Input amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 2 hdac0: | hdac0: + <- nid=4 [audio output] hdac0: + <- nid=11 [audio mixer] hdac0: hdac0: nid: 15 hdac0: Name: audio mixer hdac0: Widget cap: 0x0020010f hdac0: STEREO hdac0: Association: 0 (0x00000010) hdac0: OSS: pcm, speaker, line, mic, monitor hdac0: Output amp: 0x00034040 hdac0: mute=0 step=64 size=3 offset=64 hdac0: Input amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 2 hdac0: | hdac0: + <- nid=5 [audio output] hdac0: + <- nid=11 [audio mixer] hdac0: hdac0: nid: 16 [DISABLED] hdac0: Name: audio selector hdac0: Widget cap: 0x00300101 hdac0: STEREO hdac0: connections: 4 hdac0: | hdac0: + <- nid=12 [audio mixer] (selected) hdac0: + <- nid=13 [audio mixer] hdac0: + <- nid=14 [audio mixer] hdac0: + <- nid=15 [audio mixer] hdac0: hdac0: nid: 17 [DISABLED] hdac0: Name: audio selector hdac0: Widget cap: 0x00300101 hdac0: STEREO hdac0: connections: 4 hdac0: | hdac0: + <- nid=12 [audio mixer] (selected) hdac0: + <- nid=13 [audio mixer] hdac0: + <- nid=14 [audio mixer] hdac0: + <- nid=15 [audio mixer] hdac0: hdac0: nid: 18 [DISABLED] hdac0: Name: audio selector hdac0: Widget cap: 0x00300101 hdac0: STEREO hdac0: connections: 4 hdac0: | hdac0: + <- nid=12 [audio mixer] (selected) hdac0: + <- nid=13 [audio mixer] hdac0: + <- nid=14 [audio mixer] hdac0: + <- nid=15 [audio mixer] hdac0: hdac0: nid: 19 [DISABLED] hdac0: Name: audio selector hdac0: Widget cap: 0x00300101 hdac0: STEREO hdac0: connections: 4 hdac0: | hdac0: + <- nid=12 [audio mixer] (selected) hdac0: + <- nid=13 [audio mixer] hdac0: + <- nid=14 [audio mixer] hdac0: + <- nid=15 [audio mixer] hdac0: hdac0: nid: 20 hdac0: Name: pin: Line-out (Green Jack) hdac0: Widget cap: 0x0040018d hdac0: UNSOL STEREO hdac0: Association: 0 (0x00000001) hdac0: Pin cap: 0x0000003f hdac0: ISC TRQD PDC HP OUT IN hdac0: Pin config: 0x01014010 hdac0: Pin control: 0x00000040 OUT hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 1 hdac0: | hdac0: + <- nid=12 [audio mixer] hdac0: hdac0: nid: 21 hdac0: Name: pin: Line-out (Black Jack) hdac0: Widget cap: 0x0040018d hdac0: UNSOL STEREO hdac0: Association: 0 (0x00000004) hdac0: Pin cap: 0x0000003f hdac0: ISC TRQD PDC HP OUT IN hdac0: Pin config: 0x01011012 hdac0: Pin control: 0x00000040 OUT hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 1 hdac0: | hdac0: + <- nid=13 [audio mixer] hdac0: hdac0: nid: 22 hdac0: Name: pin: Line-out (Orange Jack) hdac0: Widget cap: 0x0040018d hdac0: UNSOL STEREO hdac0: Association: 0 (0x00000002) hdac0: Pin cap: 0x0000003f hdac0: ISC TRQD PDC HP OUT IN hdac0: Pin config: 0x01016011 hdac0: Pin control: 0x00000040 OUT hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 1 hdac0: | hdac0: + <- nid=14 [audio mixer] hdac0: hdac0: nid: 23 hdac0: Name: pin: Line-out (Grey Jack) hdac0: Widget cap: 0x0040018d hdac0: UNSOL STEREO hdac0: Association: 0 (0x00000010) hdac0: Pin cap: 0x0000003f hdac0: ISC TRQD PDC HP OUT IN hdac0: Pin config: 0x01012014 hdac0: Pin control: 0x00000040 OUT hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 1 hdac0: | hdac0: + <- nid=15 [audio mixer] hdac0: hdac0: nid: 24 hdac0: Name: pin: Mic (Pink Jack) hdac0: Widget cap: 0x0040018d hdac0: UNSOL STEREO hdac0: Association: 2 (0x00000001) hdac0: OSS: mic (mic) hdac0: Pin cap: 0x0000133f hdac0: ISC TRQD PDC HP OUT IN VREF[ 50 80 HIZ ] hdac0: Pin config: 0x01a19830 hdac0: Pin control: 0x00000024 IN VREFs hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 1 hdac0: | hdac0: + [DISABLED] <- nid=16 [audio selector] [DISABLED] hdac0: hdac0: nid: 25 hdac0: Name: pin: Mic (Pink Jack) hdac0: Widget cap: 0x0040018d hdac0: UNSOL STEREO hdac0: Association: 3 (0x00000001) hdac0: OSS: monitor (monitor) hdac0: Pin cap: 0x0000133f hdac0: ISC TRQD PDC HP OUT IN VREF[ 50 80 HIZ ] hdac0: Pin config: 0x02a19c40 hdac0: Pin control: 0x00000024 IN VREFs hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 1 hdac0: | hdac0: + [DISABLED] <- nid=17 [audio selector] [DISABLED] hdac0: hdac0: nid: 26 hdac0: Name: pin: Line-in (Blue Jack) hdac0: Widget cap: 0x0040018d hdac0: UNSOL STEREO hdac0: Association: 2 (0x00000002) hdac0: OSS: line (line) hdac0: Pin cap: 0x0000133f hdac0: ISC TRQD PDC HP OUT IN VREF[ 50 80 HIZ ] hdac0: Pin config: 0x01813031 hdac0: Pin control: 0x00000024 IN VREFs hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 1 hdac0: | hdac0: + [DISABLED] <- nid=18 [audio selector] [DISABLED] hdac0: hdac0: nid: 27 [DISABLED] hdac0: Name: pin: Line-out (Green Jack) hdac0: Widget cap: 0x0040018d hdac0: UNSOL STEREO hdac0: Pin cap: 0x0000133f hdac0: ISC TRQD PDC HP OUT IN VREF[ 50 80 HIZ ] hdac0: Pin config: 0x02014c20 hdac0: Pin control: 0x00000000 hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 1 hdac0: | hdac0: + [DISABLED] <- nid=19 [audio selector] [DISABLED] hdac0: hdac0: nid: 28 [DISABLED] hdac0: Name: pin: Speaker (None) hdac0: Widget cap: 0x00400001 hdac0: STEREO hdac0: Pin cap: 0x00000020 hdac0: IN hdac0: Pin config: 0x411111f0 hdac0: Pin control: 0x00000000 hdac0: hdac0: nid: 29 hdac0: Name: beep widget hdac0: Widget cap: 0x00700000 hdac0: Association: -2 (0x00000000) hdac0: OSS: speaker (speaker) hdac0: hdac0: nid: 30 hdac0: Name: pin: SPDIF-out (Black Jack) hdac0: Widget cap: 0x00400300 hdac0: DIGITAL hdac0: Association: 0 (0x00004000) hdac0: Pin cap: 0x00000010 hdac0: OUT hdac0: Pin config: 0x0144111e hdac0: Pin control: 0x00000040 OUT hdac0: connections: 1 hdac0: | hdac0: + <- nid=6 [audio output] hdac0: hdac0: nid: 31 hdac0: Name: pin: SPDIF-in (Orange Jack) hdac0: Widget cap: 0x00400200 hdac0: DIGITAL hdac0: Association: 4 (0x00000001) hdac0: OSS: dig1 (dig1) hdac0: Pin cap: 0x00000020 hdac0: IN hdac0: Pin config: 0x01c46150 hdac0: Pin control: 0x00000020 IN hdac0: hdac0: nid: 32 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00040 hdac0: PROC hdac0: hdac0: nid: 33 [DISABLED] hdac0: Name: volume widget hdac0: Widget cap: 0x00600080 hdac0: UNSOL hdac0: pcm0: at cad 1 nid 1 on hdac0 pcm1: at cad 1 nid 1 on hdac0 pcm2: at cad 1 nid 1 on hdac0 --ikeVEW9yuYc//A+q-- From owner-freebsd-current@FreeBSD.ORG Sat Feb 26 18:55: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 CBE071065672; Sat, 26 Feb 2011 18:55: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 A01958FC18; Sat, 26 Feb 2011 18:55:23 +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 p1QItMHP082497; Sat, 26 Feb 2011 13:55:22 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p1QItMib082476; Sat, 26 Feb 2011 18:55:22 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 26 Feb 2011 18:55:22 GMT Message-Id: <201102261855.p1QItMib082476@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2011 18:55:24 -0000 TB --- 2011-02-26 17:15:06 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2011-02-26 17:15:06 - starting HEAD tinderbox run for ia64/ia64 TB --- 2011-02-26 17:15:06 - cleaning the object tree TB --- 2011-02-26 17:15:18 - cvsupping the source tree TB --- 2011-02-26 17:15:18 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2011-02-26 17:15:32 - building world TB --- 2011-02-26 17:15:32 - MAKEOBJDIRPREFIX=/obj TB --- 2011-02-26 17:15:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-02-26 17:15:32 - TARGET=ia64 TB --- 2011-02-26 17:15:32 - TARGET_ARCH=ia64 TB --- 2011-02-26 17:15:32 - TZ=UTC TB --- 2011-02-26 17:15:32 - __MAKE_CONF=/dev/null TB --- 2011-02-26 17:15:32 - cd /src TB --- 2011-02-26 17:15:32 - /usr/bin/make -B buildworld >>> World build started on Sat Feb 26 17:15:33 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 Sat Feb 26 18:40:08 UTC 2011 TB --- 2011-02-26 18:40:09 - generating LINT kernel config TB --- 2011-02-26 18:40:09 - cd /src/sys/ia64/conf TB --- 2011-02-26 18:40:09 - /usr/bin/make -B LINT TB --- 2011-02-26 18:40:09 - building LINT kernel TB --- 2011-02-26 18:40:09 - MAKEOBJDIRPREFIX=/obj TB --- 2011-02-26 18:40:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-02-26 18:40:09 - TARGET=ia64 TB --- 2011-02-26 18:40:09 - TARGET_ARCH=ia64 TB --- 2011-02-26 18:40:09 - TZ=UTC TB --- 2011-02-26 18:40:09 - __MAKE_CONF=/dev/null TB --- 2011-02-26 18:40:09 - cd /src TB --- 2011-02-26 18:40:09 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Feb 26 18:40:09 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 [...] /src/sys/netinet/sctp_sysctl.c:641: error: 'struct sctp_sysctl' has no member named 'sctp_rttvar_eqret' /src/sys/netinet/sctp_sysctl.c:641: error: 'struct sctp_sysctl' has no member named 'sctp_rttvar_eqret' /src/sys/netinet/sctp_sysctl.c:641: error: 'SCTPCTL_RTTVAR_EQRET_MAX' undeclared (first use in this function) /src/sys/netinet/sctp_sysctl.c:641: error: 'struct sctp_sysctl' has no member named 'sctp_rttvar_eqret' /src/sys/netinet/sctp_sysctl.c: At top level: /src/sys/netinet/sctp_sysctl.c:1109: error: 'struct sctp_sysctl' has no member named 'sctp_rttvar_bw' /src/sys/netinet/sctp_sysctl.c:1113: error: 'struct sctp_sysctl' has no member named 'sctp_rttvar_rtt' /src/sys/netinet/sctp_sysctl.c:1117: error: 'struct sctp_sysctl' has no member named 'sctp_rttvar_eqret' *** 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-02-26 18:55:22 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-02-26 18:55:22 - ERROR: failed to build lint kernel TB --- 2011-02-26 18:55:22 - 4862.27 user 819.19 system 6015.38 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sat Feb 26 19:05: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 B5053106564A for ; Sat, 26 Feb 2011 19:05:46 +0000 (UTC) (envelope-from onemda@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 6F3458FC19 for ; Sat, 26 Feb 2011 19:05:46 +0000 (UTC) Received: by vxc34 with SMTP id 34so2561778vxc.13 for ; Sat, 26 Feb 2011 11:05:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=s8esLE26yLmZolMlCq8WFgKskd+rzsa37R3tJaU0x7E=; b=G0s24vVTF65Un7J77ZvNawMJe/VIvWHA0vs8v2Ik3P0YoQ/SVBBKF11hybjBDvXOOl 0BtKC5LyrJBVSGy4qtE32zsE5/oa7ZIlcFzqbq0Y4fVMNPybgNjOMit3MANdsonBMtZl E2thaDAdPIvAIkVQWEH1L6n+OBrv8X/0E1/Eg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=w9LHAj/1AmaU+bHsI5Y6vcjIMbt/oXVIrGEieyLwSS5+TR4eqO/J4fRIB4njipKzgS lHVNiwiyBJkoDEuSg7jPLusatF+PMDGL1fbcTyhDpbBW59BllC1gNGarMhXpwEtgKwtV YJBs9IKWHMoCYrux4Gmp4nbP1tQ86uO00WA8s= Received: by 10.52.164.227 with SMTP id yt3mr6346042vdb.103.1298745394113; Sat, 26 Feb 2011 10:36:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.20.77 with HTTP; Sat, 26 Feb 2011 10:36:14 -0800 (PST) In-Reply-To: <201102261625.41522.bschmidt@freebsd.org> References: <201102261625.41522.bschmidt@freebsd.org> From: "Paul B. Mahol" Date: Sat, 26 Feb 2011 19:36:14 +0100 Message-ID: To: Bernhard Schmidt Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: cardbus and kldunload issue 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, 26 Feb 2011 19:05:46 -0000 On Sat, Feb 26, 2011 at 4:25 PM, Bernhard Schmidt wr= ote: > Hi, > > while working on a wireless driver for a Cardbus card I stumbled over > an issue which bugs me quite a bit. > > The device: > > % none3@pci0:22:0:0: =A0 =A0 =A0class=3D0x028000 card=3D0x107f1043 chip= =3D0x02011814 rev=3D0x01 hdr=3D0x00 > > Loading the module attaches nicely to the device: > > # kldload if_ral > % ral0: mem 0xf4800000-0xf4801fff irq 16 at de= vice 0.0 on cardbus0 > % ral0: MAC/BBP RT2560 (rev 0x04), RF RT2525 > % ral0: [ITHREAD] > # pciconf -l > % ral0@pci0:22:0:0: =A0 =A0 =A0 class=3D0x028000 card=3D0x107f1043 chip= =3D0x02011814 rev=3D0x01 hdr=3D0x00 > > Though, kldunload doesn't detach the device, it doesn't even call the > module's detach function. > > # kldunload if_ral > # pciconf -l > % ral0@pci0:22:0:0: =A0 =A0 =A0 class=3D0x028000 card=3D0x107f1043 chip= =3D0x02011814 rev=3D0x01 hdr=3D0x00 > # kldstat > % Id Refs Address =A0 =A0 =A0 =A0 =A0 =A0Size =A0 =A0 Name > % =A01 =A0 27 0xffffffff80100000 e640a0 =A0 kernel > # ifconfig ral0 > % ral0: flags=3D8802 metric 0 mtu 2290 > % =A0 =A0 =A0 =A0 ether 00:0e:a6:a6:1b:70 > % =A0 =A0 =A0 =A0 media: IEEE 802.11 Wireless Ethernet autoselect (autose= lect) > % =A0 =A0 =A0 =A0 status: no carrier > > And of course trying to use the device at that point will result in > instant panics. Playing around a bit I've noticed that changing the bus > name in: > > % DRIVER_MODULE(ral, pci, ral_pci_driver, ral_devclass, 0, 0); > > from pci to cardbus makes a big difference. On module unload the detach > function is then called as expected. So, question is, are we doing some > too strict checks on module unload while matching the bus? Or is this > expected behavior and the drivers are supposed to indiciated that they > support both pci and cardbus? I don't see the later anywhere in tree. There is MODULE_DEPEND(), if_ndis depends on pccard, pci and usb modules and use both MODULE_DEPEND() and DRIVER_MODULE() with them. If I'm not mistaken pccard depends on cardbus. From owner-freebsd-current@FreeBSD.ORG Sat Feb 26 19:15: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 05469106566B for ; Sat, 26 Feb 2011 19:15:39 +0000 (UTC) (envelope-from lists@eitanadler.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 C236A8FC0A for ; Sat, 26 Feb 2011 19:15:38 +0000 (UTC) Received: by iyj12 with SMTP id 12so2044425iyj.13 for ; Sat, 26 Feb 2011 11:15:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=+dx7yspviXix5w8Kq1Y1Z35cHXfhJV7zuPd12mdhaUQ=; b=I5nj8fDiQ/Lgh3GUTnav08uwIfF2wr6sibXnGjZOOC/+W36c6WJLc9mY+h3/VghI2b 5NCsbNE9Ht8837DLpf8SD8QsCahuP7SH8CAV8NA15XoJjIG/ij0Xq2naab1aUvW0Nqp9 KRCGHaN/qcxcA8L38idG5U2GHnN3QKR0tklbY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=Ve8kT1ZE/qUWtrzpWWa2Bz2CGfExVkfGL2R/FHoOBfzE8qSh3t9GDgpMhtJ67fUm7u dI85ii3p3kGi49bOMtSM/1GlzZDuRrB8sbsqlnaGQo1gD1MN01IiuIIDM2A+i8LK6rwK iKd9JBB33ZpVOK8ce+ZYA9oasMkRZXwzxWC40= Received: by 10.231.40.2 with SMTP id i2mr3909756ibe.95.1298746342157; Sat, 26 Feb 2011 10:52:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.32.68 with HTTP; Sat, 26 Feb 2011 10:52:02 -0800 (PST) In-Reply-To: <20110226165815.GA4953@tinyCurrent> References: <20110226165815.GA4953@tinyCurrent> From: Eitan Adler Date: Sat, 26 Feb 2011 13:52:02 -0500 Message-ID: To: Matthias Apitz Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current@freebsd.org Subject: Re: snd_hda(4): speaker DISABLED after update to 9-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: Sat, 26 Feb 2011 19:15:39 -0000 On Sat, Feb 26, 2011 at 11:58 AM, Matthias Apitz wrote: > Could someone please give me a hint how to get the speaker working again? Try changing sysctl hw.snd.default_unit=0/1/2 -- Eitan Adler From owner-freebsd-current@FreeBSD.ORG Sat Feb 26 20:41: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 345E1106566C; Sat, 26 Feb 2011 20:41: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 F3C1E8FC0A; Sat, 26 Feb 2011 20: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 p1QKfhS2046541; Sat, 26 Feb 2011 15:41:43 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p1QKfhbT046500; Sat, 26 Feb 2011 20:41:43 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 26 Feb 2011 20:41:43 GMT Message-Id: <201102262041.p1QKfhbT046500@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, 26 Feb 2011 20:41:44 -0000 TB --- 2011-02-26 19:25:33 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2011-02-26 19:25:33 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2011-02-26 19:25:33 - cleaning the object tree TB --- 2011-02-26 19:25:49 - cvsupping the source tree TB --- 2011-02-26 19:25:49 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2011-02-26 19:26:03 - building world TB --- 2011-02-26 19:26:03 - MAKEOBJDIRPREFIX=/obj TB --- 2011-02-26 19:26:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-02-26 19:26:03 - TARGET=sparc64 TB --- 2011-02-26 19:26:03 - TARGET_ARCH=sparc64 TB --- 2011-02-26 19:26:03 - TZ=UTC TB --- 2011-02-26 19:26:03 - __MAKE_CONF=/dev/null TB --- 2011-02-26 19:26:03 - cd /src TB --- 2011-02-26 19:26:03 - /usr/bin/make -B buildworld >>> World build started on Sat Feb 26 19:26:03 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 Sat Feb 26 20:30:07 UTC 2011 TB --- 2011-02-26 20:30:07 - generating LINT kernel config TB --- 2011-02-26 20:30:07 - cd /src/sys/sparc64/conf TB --- 2011-02-26 20:30:07 - /usr/bin/make -B LINT TB --- 2011-02-26 20:30:07 - building LINT kernel TB --- 2011-02-26 20:30:07 - MAKEOBJDIRPREFIX=/obj TB --- 2011-02-26 20:30:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-02-26 20:30:07 - TARGET=sparc64 TB --- 2011-02-26 20:30:07 - TARGET_ARCH=sparc64 TB --- 2011-02-26 20:30:07 - TZ=UTC TB --- 2011-02-26 20:30:07 - __MAKE_CONF=/dev/null TB --- 2011-02-26 20:30:07 - cd /src TB --- 2011-02-26 20:30:07 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Feb 26 20:30: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 [...] /src/sys/netinet/sctp_sysctl.c:641: error: 'struct sctp_sysctl' has no member named 'sctp_rttvar_eqret' /src/sys/netinet/sctp_sysctl.c:641: error: 'struct sctp_sysctl' has no member named 'sctp_rttvar_eqret' /src/sys/netinet/sctp_sysctl.c:641: error: 'SCTPCTL_RTTVAR_EQRET_MAX' undeclared (first use in this function) /src/sys/netinet/sctp_sysctl.c:641: error: 'struct sctp_sysctl' has no member named 'sctp_rttvar_eqret' /src/sys/netinet/sctp_sysctl.c: At top level: /src/sys/netinet/sctp_sysctl.c:1109: error: 'struct sctp_sysctl' has no member named 'sctp_rttvar_bw' /src/sys/netinet/sctp_sysctl.c:1113: error: 'struct sctp_sysctl' has no member named 'sctp_rttvar_rtt' /src/sys/netinet/sctp_sysctl.c:1117: error: 'struct sctp_sysctl' has no member named 'sctp_rttvar_eqret' *** 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-02-26 20:41:42 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-02-26 20:41:42 - ERROR: failed to build lint kernel TB --- 2011-02-26 20:41:42 - 3488.14 user 721.48 system 4569.00 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sat Feb 26 20:50:25 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 826E5106566B; Sat, 26 Feb 2011 20:50:25 +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 1ACE48FC08; Sat, 26 Feb 2011 20:50:24 +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 p1QKoORt002733; Sat, 26 Feb 2011 15:50:24 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p1QKoOcR002732; Sat, 26 Feb 2011 20:50:24 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 26 Feb 2011 20:50:24 GMT Message-Id: <201102262050.p1QKoOcR002732@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, 26 Feb 2011 20:50:26 -0000 TB --- 2011-02-26 18:55:22 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2011-02-26 18:55:22 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2011-02-26 18:55:22 - cleaning the object tree TB --- 2011-02-26 18:55:38 - cvsupping the source tree TB --- 2011-02-26 18:55:38 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2011-02-26 18:55:50 - building world TB --- 2011-02-26 18:55:50 - MAKEOBJDIRPREFIX=/obj TB --- 2011-02-26 18:55:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-02-26 18:55:50 - TARGET=powerpc TB --- 2011-02-26 18:55:50 - TARGET_ARCH=powerpc TB --- 2011-02-26 18:55:50 - TZ=UTC TB --- 2011-02-26 18:55:50 - __MAKE_CONF=/dev/null TB --- 2011-02-26 18:55:50 - cd /src TB --- 2011-02-26 18:55:50 - /usr/bin/make -B buildworld >>> World build started on Sat Feb 26 18:55:50 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 Sat Feb 26 20:39:57 UTC 2011 TB --- 2011-02-26 20:39:57 - generating LINT kernel config TB --- 2011-02-26 20:39:57 - cd /src/sys/powerpc/conf TB --- 2011-02-26 20:39:57 - /usr/bin/make -B LINT TB --- 2011-02-26 20:39:57 - building LINT kernel TB --- 2011-02-26 20:39:57 - MAKEOBJDIRPREFIX=/obj TB --- 2011-02-26 20:39:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-02-26 20:39:57 - TARGET=powerpc TB --- 2011-02-26 20:39:57 - TARGET_ARCH=powerpc TB --- 2011-02-26 20:39:57 - TZ=UTC TB --- 2011-02-26 20:39:57 - __MAKE_CONF=/dev/null TB --- 2011-02-26 20:39:57 - cd /src TB --- 2011-02-26 20:39:57 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Feb 26 20:39:57 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 [...] /src/sys/netinet/sctp_sysctl.c:641: error: 'struct sctp_sysctl' has no member named 'sctp_rttvar_eqret' /src/sys/netinet/sctp_sysctl.c:641: error: 'struct sctp_sysctl' has no member named 'sctp_rttvar_eqret' /src/sys/netinet/sctp_sysctl.c:641: error: 'SCTPCTL_RTTVAR_EQRET_MAX' undeclared (first use in this function) /src/sys/netinet/sctp_sysctl.c:641: error: 'struct sctp_sysctl' has no member named 'sctp_rttvar_eqret' /src/sys/netinet/sctp_sysctl.c: At top level: /src/sys/netinet/sctp_sysctl.c:1109: error: 'struct sctp_sysctl' has no member named 'sctp_rttvar_bw' /src/sys/netinet/sctp_sysctl.c:1113: error: 'struct sctp_sysctl' has no member named 'sctp_rttvar_rtt' /src/sys/netinet/sctp_sysctl.c:1117: error: 'struct sctp_sysctl' has no member named 'sctp_rttvar_eqret' *** 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-02-26 20:50:24 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-02-26 20:50:24 - ERROR: failed to build lint kernel TB --- 2011-02-26 20:50:24 - 5543.39 user 935.51 system 6901.20 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sat Feb 26 21:04:05 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 2C53C1065672; Sat, 26 Feb 2011 21:04:05 +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 006498FC17; Sat, 26 Feb 2011 21:04:04 +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 p1QL44q8068087; Sat, 26 Feb 2011 16:04:04 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p1QL44gt068083; Sat, 26 Feb 2011 21:04:04 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 26 Feb 2011 21:04:04 GMT Message-Id: <201102262104.p1QL44gt068083@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/sun4v 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, 26 Feb 2011 21:04:05 -0000 TB --- 2011-02-26 19:50:18 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2011-02-26 19:50:18 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2011-02-26 19:50:18 - cleaning the object tree TB --- 2011-02-26 19:50:28 - cvsupping the source tree TB --- 2011-02-26 19:50:28 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2011-02-26 19:50:50 - building world TB --- 2011-02-26 19:50:50 - MAKEOBJDIRPREFIX=/obj TB --- 2011-02-26 19:50:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-02-26 19:50:50 - TARGET=sun4v TB --- 2011-02-26 19:50:50 - TARGET_ARCH=sparc64 TB --- 2011-02-26 19:50:50 - TZ=UTC TB --- 2011-02-26 19:50:50 - __MAKE_CONF=/dev/null TB --- 2011-02-26 19:50:50 - cd /src TB --- 2011-02-26 19:50:50 - /usr/bin/make -B buildworld >>> World build started on Sat Feb 26 19:50:50 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 Sat Feb 26 20:53:58 UTC 2011 TB --- 2011-02-26 20:53:58 - generating LINT kernel config TB --- 2011-02-26 20:53:58 - cd /src/sys/sun4v/conf TB --- 2011-02-26 20:53:58 - /usr/bin/make -B LINT TB --- 2011-02-26 20:53:58 - building LINT kernel TB --- 2011-02-26 20:53:58 - MAKEOBJDIRPREFIX=/obj TB --- 2011-02-26 20:53:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-02-26 20:53:58 - TARGET=sun4v TB --- 2011-02-26 20:53:58 - TARGET_ARCH=sparc64 TB --- 2011-02-26 20:53:58 - TZ=UTC TB --- 2011-02-26 20:53:58 - __MAKE_CONF=/dev/null TB --- 2011-02-26 20:53:58 - cd /src TB --- 2011-02-26 20:53:58 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Feb 26 20:53:58 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 [...] /src/sys/netinet/sctp_sysctl.c:641: error: 'struct sctp_sysctl' has no member named 'sctp_rttvar_eqret' /src/sys/netinet/sctp_sysctl.c:641: error: 'struct sctp_sysctl' has no member named 'sctp_rttvar_eqret' /src/sys/netinet/sctp_sysctl.c:641: error: 'SCTPCTL_RTTVAR_EQRET_MAX' undeclared (first use in this function) /src/sys/netinet/sctp_sysctl.c:641: error: 'struct sctp_sysctl' has no member named 'sctp_rttvar_eqret' /src/sys/netinet/sctp_sysctl.c: At top level: /src/sys/netinet/sctp_sysctl.c:1109: error: 'struct sctp_sysctl' has no member named 'sctp_rttvar_bw' /src/sys/netinet/sctp_sysctl.c:1113: error: 'struct sctp_sysctl' has no member named 'sctp_rttvar_rtt' /src/sys/netinet/sctp_sysctl.c:1117: error: 'struct sctp_sysctl' has no member named 'sctp_rttvar_eqret' *** Error code 1 Stop in /obj/sun4v.sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-02-26 21:04:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-02-26 21:04:04 - ERROR: failed to build lint kernel TB --- 2011-02-26 21:04:04 - 3453.45 user 712.50 system 4425.70 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Sat Feb 26 21:10: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 9D987106564A; Sat, 26 Feb 2011 21:10:04 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 6170C8FC16; Sat, 26 Feb 2011 21:10:04 +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 p1QLA385072439; Sat, 26 Feb 2011 16:10:03 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p1QLA3BO072438; Sat, 26 Feb 2011 21:10:03 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 26 Feb 2011 21:10:03 GMT Message-Id: <201102262110.p1QLA3BO072438@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, 26 Feb 2011 21:10:04 -0000 TB --- 2011-02-26 19:25:04 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2011-02-26 19:25:04 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2011-02-26 19:25:04 - cleaning the object tree TB --- 2011-02-26 19:25:20 - cvsupping the source tree TB --- 2011-02-26 19:25:20 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2011-02-26 19:25:33 - building world TB --- 2011-02-26 19:25:33 - MAKEOBJDIRPREFIX=/obj TB --- 2011-02-26 19:25:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-02-26 19:25:33 - TARGET=powerpc TB --- 2011-02-26 19:25:33 - TARGET_ARCH=powerpc64 TB --- 2011-02-26 19:25:33 - TZ=UTC TB --- 2011-02-26 19:25:33 - __MAKE_CONF=/dev/null TB --- 2011-02-26 19:25:33 - cd /src TB --- 2011-02-26 19:25:33 - /usr/bin/make -B buildworld >>> World build started on Sat Feb 26 19:25: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 >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Sat Feb 26 20:59:38 UTC 2011 TB --- 2011-02-26 20:59:38 - generating LINT kernel config TB --- 2011-02-26 20:59:38 - cd /src/sys/powerpc/conf TB --- 2011-02-26 20:59:38 - /usr/bin/make -B LINT TB --- 2011-02-26 20:59:38 - building LINT kernel TB --- 2011-02-26 20:59:38 - MAKEOBJDIRPREFIX=/obj TB --- 2011-02-26 20:59:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-02-26 20:59:38 - TARGET=powerpc TB --- 2011-02-26 20:59:38 - TARGET_ARCH=powerpc64 TB --- 2011-02-26 20:59:38 - TZ=UTC TB --- 2011-02-26 20:59:38 - __MAKE_CONF=/dev/null TB --- 2011-02-26 20:59:38 - cd /src TB --- 2011-02-26 20:59:38 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Feb 26 20:59:38 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 [...] /src/sys/netinet/sctp_sysctl.c:641: error: 'struct sctp_sysctl' has no member named 'sctp_rttvar_eqret' /src/sys/netinet/sctp_sysctl.c:641: error: 'struct sctp_sysctl' has no member named 'sctp_rttvar_eqret' /src/sys/netinet/sctp_sysctl.c:641: error: 'SCTPCTL_RTTVAR_EQRET_MAX' undeclared (first use in this function) /src/sys/netinet/sctp_sysctl.c:641: error: 'struct sctp_sysctl' has no member named 'sctp_rttvar_eqret' /src/sys/netinet/sctp_sysctl.c: At top level: /src/sys/netinet/sctp_sysctl.c:1109: error: 'struct sctp_sysctl' has no member named 'sctp_rttvar_bw' /src/sys/netinet/sctp_sysctl.c:1113: error: 'struct sctp_sysctl' has no member named 'sctp_rttvar_rtt' /src/sys/netinet/sctp_sysctl.c:1117: error: 'struct sctp_sysctl' has no member named 'sctp_rttvar_eqret' *** 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-02-26 21:10:03 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-02-26 21:10:03 - ERROR: failed to build lint kernel TB --- 2011-02-26 21:10:03 - 4933.44 user 1029.48 system 6299.38 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sat Feb 26 23:06: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 D86FF106566C; Sat, 26 Feb 2011 23:06:06 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) by mx1.freebsd.org (Postfix) with ESMTP id A043A8FC12; Sat, 26 Feb 2011 23:06:06 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA" (verified OK)) (Authenticated sender: imb@protected-networks.net) by sarah.protected-networks.net (Postfix) with ESMTPSA id 9CBF561CA; Sat, 26 Feb 2011 18:06:05 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=protected-networks.net; s=200705; t=1298761565; bh=VYpLxDP4T4q4Mwf10ugNAIBYDHPUjcQcfqnQQfg1jbw=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type; b=cO5XWHyVn1HACE9m72Mfv3hbJvENIlvD2o0XVWzwv2PWSUIXkpzm20rezltFo6Zuv BCUqfGXqfGTDsShW6gV2vKTsE6Nj8kvsvTIqj0tyXE6dZfrWxFQlnH/MFaaUWpQ DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: x-enigmail-version:openpgp:content-type; b=MiWG6EapwRnRXyPkhOfjhfx+Oj1liF3W5dTZthley8KZxuLIjojA9fmR5NRwWFtjr v6heJutjzDC3Dqf14voFf/KQeX60Sf5zquZVmuy/9uHwj/rrLNCL90eA6xneRQW Message-ID: <4D69875C.3090502@protected-networks.net> Date: Sat, 26 Feb 2011 18:06:04 -0500 From: Michael Butler User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.13) Gecko/20110116 Thunderbird/3.1.7 MIME-Version: 1.0 To: current@FreeBSD.org X-Enigmail-Version: 1.1.2 OpenPGP: id=0442D492 Content-Type: multipart/mixed; boundary="------------070907080606050903090309" Cc: rrs@freebsd.org Subject: Fwd: [head tinderbox] failure on .. SCTP 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, 26 Feb 2011 23:06:06 -0000 This is a multi-part message in MIME format. --------------070907080606050903090309 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -------- Original Message -------- Subject: [head tinderbox] failure on ia64/ia64 Date: Sat, 26 Feb 2011 18:55:22 GMT From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , >>> stage 3.2: building everything [...] /src/sys/netinet/sctp_sysctl.c:641: error: 'struct sctp_sysctl' has no member named 'sctp_rttvar_eqret' /src/sys/netinet/sctp_sysctl.c:641: error: 'struct sctp_sysctl' has no member named 'sctp_rttvar_eqret' [ .. snip .. ] While it's likely that this is not what the author intended, the attached patch will allow the kernel to be built, imb -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk1ph1wACgkQQv9rrgRC1JJ0kACfYcM/p4w/MoLLcxWENoeih8VN d60AnRmrl6AnWT59/vwQD9LzIN/1nJJx =CxgS -----END PGP SIGNATURE----- --------------070907080606050903090309 Content-Type: text/x-diff; name="sctp.h.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="sctp.h.patch" Index: sys/netinet/sctp.h =================================================================== --- sys/netinet/sctp.h (revision 219070) +++ sys/netinet/sctp.h (working copy) @@ -42,6 +42,8 @@ #define SCTP_PACKED __attribute__((packed)) +#define SCTP_HAS_RTTCC 1 + /* * SCTP protocol - RFC2960. */ --------------070907080606050903090309-- From owner-freebsd-current@FreeBSD.ORG Sat Feb 26 23:10: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 42275106564A; Sat, 26 Feb 2011 23:10:06 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id EB5E98FC0C; Sat, 26 Feb 2011 23:10:05 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:14c:e271:776c:35cb] (unknown [IPv6:2001:7b8:3a7:0:14c:e271:776c:35cb]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 6576C5C59; Sun, 27 Feb 2011 00:10:04 +0100 (CET) Message-ID: <4D69884E.1000002@FreeBSD.org> Date: Sun, 27 Feb 2011 00:10:06 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.15pre) Gecko/20110221 Lanikai/3.1.9pre MIME-Version: 1.0 To: Michael Butler References: <4D69875C.3090502@protected-networks.net> In-Reply-To: <4D69875C.3090502@protected-networks.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rrs@freebsd.org, current@FreeBSD.org Subject: Re: Fwd: [head tinderbox] failure on .. SCTP 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, 26 Feb 2011 23:10:06 -0000 On 2011-02-27 00:06, Michael Butler wrote: > /src/sys/netinet/sctp_sysctl.c:641: error: 'struct sctp_sysctl' has no > member named 'sctp_rttvar_eqret' > /src/sys/netinet/sctp_sysctl.c:641: error: 'struct sctp_sysctl' has no > member named 'sctp_rttvar_eqret' ... > While it's likely that this is not what the author intended, the > attached patch will allow the kernel to be built, I fixed this a bit differently in r219071, by sprinkling some #ifdefs. From owner-freebsd-current@FreeBSD.ORG Sat Feb 26 23:22:24 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 CC87B106566B; Sat, 26 Feb 2011 23:22:24 +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 820BC8FC0C; Sat, 26 Feb 2011 23:22:24 +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 p1QNMNnT085150; Sat, 26 Feb 2011 18:22:23 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p1QNMNsi085129; Sat, 26 Feb 2011 23:22:23 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 26 Feb 2011 23:22:23 GMT Message-Id: <201102262322.p1QNMNsi085129@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2011 23:22:25 -0000 TB --- 2011-02-26 21:20:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2011-02-26 21:20:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2011-02-26 21:20:00 - cleaning the object tree TB --- 2011-02-26 21:20:22 - cvsupping the source tree TB --- 2011-02-26 21:20:22 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2011-02-26 21:20:36 - building world TB --- 2011-02-26 21:20:36 - MAKEOBJDIRPREFIX=/obj TB --- 2011-02-26 21:20:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-02-26 21:20:36 - TARGET=pc98 TB --- 2011-02-26 21:20:36 - TARGET_ARCH=i386 TB --- 2011-02-26 21:20:36 - TZ=UTC TB --- 2011-02-26 21:20:36 - __MAKE_CONF=/dev/null TB --- 2011-02-26 21:20:36 - cd /src TB --- 2011-02-26 21:20:36 - /usr/bin/make -B buildworld >>> World build started on Sat Feb 26 21:20:36 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 Sat Feb 26 23:10:54 UTC 2011 TB --- 2011-02-26 23:10:54 - generating LINT kernel config TB --- 2011-02-26 23:10:54 - cd /src/sys/pc98/conf TB --- 2011-02-26 23:10:54 - /usr/bin/make -B LINT TB --- 2011-02-26 23:10:54 - building LINT kernel TB --- 2011-02-26 23:10:54 - MAKEOBJDIRPREFIX=/obj TB --- 2011-02-26 23:10:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-02-26 23:10:54 - TARGET=pc98 TB --- 2011-02-26 23:10:54 - TARGET_ARCH=i386 TB --- 2011-02-26 23:10:54 - TZ=UTC TB --- 2011-02-26 23:10:54 - __MAKE_CONF=/dev/null TB --- 2011-02-26 23:10:54 - cd /src TB --- 2011-02-26 23:10:54 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Feb 26 23:10:54 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 [...] /src/sys/netinet/sctp_sysctl.c:641: error: 'struct sctp_sysctl' has no member named 'sctp_rttvar_eqret' /src/sys/netinet/sctp_sysctl.c:641: error: 'struct sctp_sysctl' has no member named 'sctp_rttvar_eqret' /src/sys/netinet/sctp_sysctl.c:641: error: 'SCTPCTL_RTTVAR_EQRET_MAX' undeclared (first use in this function) /src/sys/netinet/sctp_sysctl.c:641: error: 'struct sctp_sysctl' has no member named 'sctp_rttvar_eqret' /src/sys/netinet/sctp_sysctl.c: At top level: /src/sys/netinet/sctp_sysctl.c:1109: error: 'struct sctp_sysctl' has no member named 'sctp_rttvar_bw' /src/sys/netinet/sctp_sysctl.c:1113: error: 'struct sctp_sysctl' has no member named 'sctp_rttvar_rtt' /src/sys/netinet/sctp_sysctl.c:1117: error: 'struct sctp_sysctl' has no member named 'sctp_rttvar_eqret' *** 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-02-26 23:22:22 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-02-26 23:22:22 - ERROR: failed to build lint kernel TB --- 2011-02-26 23:22:23 - 5885.61 user 1019.99 system 7342.19 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sat Feb 26 23:30:46 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 382B3106564A; Sat, 26 Feb 2011 23:30:46 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id E6CD18FC1B; Sat, 26 Feb 2011 23:30:45 +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 p1QNUjQ4042417; Sat, 26 Feb 2011 18:30:45 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p1QNUjiw042412; Sat, 26 Feb 2011 23:30:45 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 26 Feb 2011 23:30:45 GMT Message-Id: <201102262330.p1QNUjiw042412@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2011 23:30:46 -0000 TB --- 2011-02-26 21:20:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2011-02-26 21:20:00 - starting HEAD tinderbox run for i386/i386 TB --- 2011-02-26 21:20:00 - cleaning the object tree TB --- 2011-02-26 21:20:27 - cvsupping the source tree TB --- 2011-02-26 21:20:27 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-02-26 21:25:52 - building world TB --- 2011-02-26 21:25:52 - MAKEOBJDIRPREFIX=/obj TB --- 2011-02-26 21:25:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-02-26 21:25:52 - TARGET=i386 TB --- 2011-02-26 21:25:52 - TARGET_ARCH=i386 TB --- 2011-02-26 21:25:52 - TZ=UTC TB --- 2011-02-26 21:25:52 - __MAKE_CONF=/dev/null TB --- 2011-02-26 21:25:52 - cd /src TB --- 2011-02-26 21:25:52 - /usr/bin/make -B buildworld >>> World build started on Sat Feb 26 21:25:52 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 Sat Feb 26 23:17:37 UTC 2011 TB --- 2011-02-26 23:17:37 - generating LINT kernel config TB --- 2011-02-26 23:17:37 - cd /src/sys/i386/conf TB --- 2011-02-26 23:17:37 - /usr/bin/make -B LINT TB --- 2011-02-26 23:17:37 - building LINT kernel TB --- 2011-02-26 23:17:37 - MAKEOBJDIRPREFIX=/obj TB --- 2011-02-26 23:17:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-02-26 23:17:37 - TARGET=i386 TB --- 2011-02-26 23:17:37 - TARGET_ARCH=i386 TB --- 2011-02-26 23:17:37 - TZ=UTC TB --- 2011-02-26 23:17:37 - __MAKE_CONF=/dev/null TB --- 2011-02-26 23:17:37 - cd /src TB --- 2011-02-26 23:17:37 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Feb 26 23:17: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 [...] /src/sys/netinet/sctp_sysctl.c:641: error: 'struct sctp_sysctl' has no member named 'sctp_rttvar_eqret' /src/sys/netinet/sctp_sysctl.c:641: error: 'struct sctp_sysctl' has no member named 'sctp_rttvar_eqret' /src/sys/netinet/sctp_sysctl.c:641: error: 'SCTPCTL_RTTVAR_EQRET_MAX' undeclared (first use in this function) /src/sys/netinet/sctp_sysctl.c:641: error: 'struct sctp_sysctl' has no member named 'sctp_rttvar_eqret' /src/sys/netinet/sctp_sysctl.c: At top level: /src/sys/netinet/sctp_sysctl.c:1109: error: 'struct sctp_sysctl' has no member named 'sctp_rttvar_bw' /src/sys/netinet/sctp_sysctl.c:1113: error: 'struct sctp_sysctl' has no member named 'sctp_rttvar_rtt' /src/sys/netinet/sctp_sysctl.c:1117: error: 'struct sctp_sysctl' has no member named 'sctp_rttvar_eqret' *** 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-02-26 23:30:44 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-02-26 23:30:44 - ERROR: failed to build lint kernel TB --- 2011-02-26 23:30:44 - 6012.07 user 999.95 system 7844.14 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sat Feb 26 23:51:31 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 60C08106566C; Sat, 26 Feb 2011 23:51:31 +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 2CF0A8FC19; Sat, 26 Feb 2011 23:51:30 +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 p1QNpUB8019915; Sat, 26 Feb 2011 18:51:30 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p1QNpUFX019910; Sat, 26 Feb 2011 23:51:30 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 26 Feb 2011 23:51:30 GMT Message-Id: <201102262351.p1QNpUFX019910@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2011 23:51:31 -0000 TB --- 2011-02-26 21:20:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2011-02-26 21:20:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2011-02-26 21:20:00 - cleaning the object tree TB --- 2011-02-26 21:20:26 - cvsupping the source tree TB --- 2011-02-26 21:20:26 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2011-02-26 21:20:38 - building world TB --- 2011-02-26 21:20:38 - MAKEOBJDIRPREFIX=/obj TB --- 2011-02-26 21:20:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-02-26 21:20:38 - TARGET=amd64 TB --- 2011-02-26 21:20:38 - TARGET_ARCH=amd64 TB --- 2011-02-26 21:20:38 - TZ=UTC TB --- 2011-02-26 21:20:38 - __MAKE_CONF=/dev/null TB --- 2011-02-26 21:20:38 - cd /src TB --- 2011-02-26 21:20:38 - /usr/bin/make -B buildworld >>> World build started on Sat Feb 26 21:20:43 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 Sat Feb 26 23:39:13 UTC 2011 TB --- 2011-02-26 23:39:13 - generating LINT kernel config TB --- 2011-02-26 23:39:14 - cd /src/sys/amd64/conf TB --- 2011-02-26 23:39:14 - /usr/bin/make -B LINT TB --- 2011-02-26 23:39:14 - building LINT kernel TB --- 2011-02-26 23:39:14 - MAKEOBJDIRPREFIX=/obj TB --- 2011-02-26 23:39:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-02-26 23:39:14 - TARGET=amd64 TB --- 2011-02-26 23:39:14 - TARGET_ARCH=amd64 TB --- 2011-02-26 23:39:14 - TZ=UTC TB --- 2011-02-26 23:39:14 - __MAKE_CONF=/dev/null TB --- 2011-02-26 23:39:14 - cd /src TB --- 2011-02-26 23:39:14 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Feb 26 23:39:14 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 [...] /src/sys/netinet/sctp_sysctl.c:641: error: 'struct sctp_sysctl' has no member named 'sctp_rttvar_eqret' /src/sys/netinet/sctp_sysctl.c:641: error: 'struct sctp_sysctl' has no member named 'sctp_rttvar_eqret' /src/sys/netinet/sctp_sysctl.c:641: error: 'SCTPCTL_RTTVAR_EQRET_MAX' undeclared (first use in this function) /src/sys/netinet/sctp_sysctl.c:641: error: 'struct sctp_sysctl' has no member named 'sctp_rttvar_eqret' /src/sys/netinet/sctp_sysctl.c: At top level: /src/sys/netinet/sctp_sysctl.c:1109: error: 'struct sctp_sysctl' has no member named 'sctp_rttvar_bw' /src/sys/netinet/sctp_sysctl.c:1113: error: 'struct sctp_sysctl' has no member named 'sctp_rttvar_rtt' /src/sys/netinet/sctp_sysctl.c:1117: error: 'struct sctp_sysctl' has no member named 'sctp_rttvar_eqret' *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-02-26 23:51:29 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-02-26 23:51:29 - ERROR: failed to build lint kernel TB --- 2011-02-26 23:51:29 - 7207.40 user 1329.92 system 9089.04 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Sat Feb 26 23:55: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 5401D106564A; Sat, 26 Feb 2011 23:55: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 1F6F58FC0A; Sat, 26 Feb 2011 23:55: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 p1QNtYbC052994; Sat, 26 Feb 2011 18:55:34 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p1QNtYa0052990; Sat, 26 Feb 2011 23:55:34 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 26 Feb 2011 23:55:34 GMT Message-Id: <201102262355.p1QNtYa0052990@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2011 23:55:35 -0000 TB --- 2011-02-26 22:15:17 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2011-02-26 22:15:17 - starting HEAD tinderbox run for ia64/ia64 TB --- 2011-02-26 22:15:17 - cleaning the object tree TB --- 2011-02-26 22:15:25 - cvsupping the source tree TB --- 2011-02-26 22:15:25 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2011-02-26 22:15:36 - building world TB --- 2011-02-26 22:15:36 - MAKEOBJDIRPREFIX=/obj TB --- 2011-02-26 22:15:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-02-26 22:15:36 - TARGET=ia64 TB --- 2011-02-26 22:15:36 - TARGET_ARCH=ia64 TB --- 2011-02-26 22:15:36 - TZ=UTC TB --- 2011-02-26 22:15:36 - __MAKE_CONF=/dev/null TB --- 2011-02-26 22:15:36 - cd /src TB --- 2011-02-26 22:15:36 - /usr/bin/make -B buildworld >>> World build started on Sat Feb 26 22:15:37 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 Sat Feb 26 23:40:30 UTC 2011 TB --- 2011-02-26 23:40:30 - generating LINT kernel config TB --- 2011-02-26 23:40:30 - cd /src/sys/ia64/conf TB --- 2011-02-26 23:40:30 - /usr/bin/make -B LINT TB --- 2011-02-26 23:40:30 - building LINT kernel TB --- 2011-02-26 23:40:30 - MAKEOBJDIRPREFIX=/obj TB --- 2011-02-26 23:40:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-02-26 23:40:30 - TARGET=ia64 TB --- 2011-02-26 23:40:30 - TARGET_ARCH=ia64 TB --- 2011-02-26 23:40:30 - TZ=UTC TB --- 2011-02-26 23:40:30 - __MAKE_CONF=/dev/null TB --- 2011-02-26 23:40:30 - cd /src TB --- 2011-02-26 23:40:30 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Feb 26 23:40:30 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 [...] /src/sys/netinet/sctp_sysctl.c:641: error: 'struct sctp_sysctl' has no member named 'sctp_rttvar_eqret' /src/sys/netinet/sctp_sysctl.c:641: error: 'struct sctp_sysctl' has no member named 'sctp_rttvar_eqret' /src/sys/netinet/sctp_sysctl.c:641: error: 'SCTPCTL_RTTVAR_EQRET_MAX' undeclared (first use in this function) /src/sys/netinet/sctp_sysctl.c:641: error: 'struct sctp_sysctl' has no member named 'sctp_rttvar_eqret' /src/sys/netinet/sctp_sysctl.c: At top level: /src/sys/netinet/sctp_sysctl.c:1109: error: 'struct sctp_sysctl' has no member named 'sctp_rttvar_bw' /src/sys/netinet/sctp_sysctl.c:1113: error: 'struct sctp_sysctl' has no member named 'sctp_rttvar_rtt' /src/sys/netinet/sctp_sysctl.c:1117: error: 'struct sctp_sysctl' has no member named 'sctp_rttvar_eqret' *** 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-02-26 23:55:33 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-02-26 23:55:33 - ERROR: failed to build lint kernel TB --- 2011-02-26 23:55:34 - 4868.89 user 816.87 system 6016.24 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full